idnits 2.17.1 draft-ietf-roll-useofrplinfo-29.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 (May 20, 2019) is 1802 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 1707 -- Looks like a reference, but probably isn't: '2' on line 1034 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-12 == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-11 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-19 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-20 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-09 -- 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: November 21, 2019 P. Thubert 7 Cisco 8 May 20, 2019 10 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 11 encapsulation in the RPL Data Plane 12 draft-ietf-roll-useofrplinfo-29 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 (RPL 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 RPL 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 November 21, 2019. 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. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 6 66 3.1. Updates to RFC6553: Indicating the new RPI value. . . . . 6 67 3.2. Updates to RFC6550: Indicating the new RPI in the 68 DODAG Configuration Option Flag. . . . . . . . . . . . . 10 69 3.3. Updates to RFC8138: Indicating the way to decompress with 70 the new RPI value. . . . . . . . . . . . . . . . . . . . 11 71 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 11 72 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 17 75 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 17 76 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 19 77 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 19 78 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 20 79 6.2. Storing Mode: Interaction between Leaf and Internet. . . 21 80 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 21 81 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 22 82 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 83 Internet . . . . . . . . . . . . . . . . . . . . . . 23 84 6.2.4. SM: Example of Flow from Internet to not-RPL-aware- 85 leaf. . . . . . . . . . . . . . . . . . . . . . . . . 24 86 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 25 87 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 88 leaf . . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL- 90 aware-leaf . . . . . . . . . . . . . . . . . . . . . 26 91 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 92 aware-leaf . . . . . . . . . . . . . . . . . . . . . 27 94 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 95 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 29 96 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 30 97 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 31 98 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 32 99 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 32 100 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 101 leaf . . . . . . . . . . . . . . . . . . . . . . . . 33 102 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 103 root . . . . . . . . . . . . . . . . . . . . . . . . 34 104 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 105 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 106 Internet . . . . . . . . . . . . . . . . . . . . . . 35 107 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 108 leaf . . . . . . . . . . . . . . . . . . . . . . . . 36 109 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 110 Internet . . . . . . . . . . . . . . . . . . . . . . 37 111 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 112 aware-leaf . . . . . . . . . . . . . . . . . . . . . 38 113 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 39 114 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 115 aware-leaf . . . . . . . . . . . . . . . . . . . . . 39 116 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 117 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 41 118 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 119 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 42 120 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 121 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 43 122 8. Operational Considerations of supporting 123 not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 44 124 9. Operational considerations of introducing 0x23 . . . . . . . 45 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 127 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 50 130 13.2. Informative References . . . . . . . . . . . . . . . . . 51 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 133 1. Introduction 135 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 136 [RFC6550] is a routing protocol for constrained networks. RFC6553 137 [RFC6553] defines the "RPL option" (RPL Packet Information or RPI), 138 carried within the IPv6 Hop-by-Hop header to quickly identify 139 inconsistencies (loops) in the routing topology. RFC6554 [RFC6554] 140 defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header 141 to deliver datagrams within a RPL routing domain, particularly in 142 non-storing mode. 144 These various items are referred to as RPL artifacts, and they are 145 seen on all of the data-plane traffic that occurs in RPL routed 146 networks; they do not in general appear on the RPL control plane 147 traffic at all which is mostly hop-by-hop traffic (one exception 148 being DAO messages in non-storing mode). 150 It has become clear from attempts to do multi-vendor 151 interoperability, and from a desire to compress as many of the above 152 artifacts as possible that not all implementers agree when artifacts 153 are necessary, or when they can be safely omitted, or removed. 155 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 156 storing use of RPL. The result was 24 data plane use cases. They 157 are exhaustively outlined here in order to be completely unambiguous. 158 During the processing of this document, new rules were published as 159 [RFC8200], and this document was updated to reflect the normative 160 changes in that document. 162 This document updates RFC6553, changing the RPI option value to make 163 RFC8200 routers ignore this option by default. 165 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 166 mechanism for compressing RPL Option information and Routing Header 167 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 168 technique. 170 Since some of the uses cases here described, use IPv6-in-IPv6 171 encapsulation. It MUST take in consideration, when encapsulation is 172 applied, the RFC6040 [RFC6040], which defines how the explicit 173 congestion notification (ECN) field of the IP header should be 174 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 175 Additionally, it is recommended the reading of 176 [I-D.ietf-intarea-tunnels]. 178 1.1. Overview 180 The rest of the document is organized as follows: Section 2 describes 181 the used terminology. Section 3 describes the updates to RFC6553, 182 RFC6550 and RFC 8138. Section 4 provides the reference topology used 183 for the uses cases. Section 5 describes the uses cases included. 184 Section 6 describes the storing mode cases and section 7 the non- 185 storing mode cases. Section 8 describes the operational 186 considerations of supporting not-RPL-aware-leaves. Section 9 depicts 187 operational considerations for the proposed change on RPL Option 188 type, section 10 the IANA considerations and then section 11 189 describes the security aspects. 191 2. Terminology and Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119] [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 200 RPL, RPL Domain and ROLL. 202 RPL-node: A device which implements RPL, thus the device is RPL- 203 aware. Please note that the device can be found inside the LLN or 204 outside LLN. In this document a RPL-node which is a leaf of a 205 (Destination Oriented Directed Acyclic Graph) DODAG is called RPL- 206 aware-leaf (Raf). 208 RPL-not-capable: A device which does not implement RPL, thus the 209 device is not-RPL-aware. Please note that the device can be found 210 inside the LLN. In this document a not-RPL-aware node which is a 211 leaf of a DODAG is called not-RPL-aware-leaf (~Raf). 213 6LN: [RFC6775] defines it as: "A 6LoWPAN node is any host or router 214 participating in a LoWPAN. This term is used when referring to 215 situations in which either a host or router can play the role 216 described.". In this document, a 6LN acts as a leaf. 218 6LR: [RFC6775] defines it as:" An intermediate router in the LoWPAN 219 that is able to send and receive Router Advertisements (RAs) and 220 Router Solicitations (RSs) as well as forward and route IPv6 packets. 221 6LoWPAN routers are present only in route-over topologies." 223 6LBR: [RFC6775] defines it as:"A border router located at the 224 junction of separate 6LoWPAN networks or between a 6LoWPAN network 225 and another IP network. There may be one or more 6LBRs at the 226 6LoWPAN network boundary. A 6LBR is the responsible authority for 227 IPv6 prefix propagation for the 6LoWPAN network it is serving. An 228 isolated LoWPAN also contains a 6LBR in the network, which provides 229 the prefix(es) for the isolated network." 231 Flag Day: A transition that involves having a network with different 232 values of RPL Option Type. Thus the network does not work correctly. 234 Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" 235 header refers to adding a header that originates from a node to an 236 adjacent node, using the addresses (usually the GUA or ULA, but could 237 use the link-local addresses) of each node. If the packet must 238 traverse multiple hops, then it must be decapsulated at each hop, and 239 then re-encapsulated again in a similar fashion. 241 RPL defines the RPL Control messages (control plane), a new ICMPv6 242 [RFC4443] message with Type 155. DIS (DODAG Information 243 Solicitation), DIO (DODAG Information Object) and DAO (Destination 244 Advertisement Object) messages are all RPL Control messages but with 245 different Code values. A RPL Stack is shown in Figure 1. 247 +--------------+ 248 | Upper Layers | 249 | | 250 +--------------+ 251 | RPL | 252 | | 253 +--------------+ 254 | ICMPv6 | 255 | | 256 +--------------+ 257 | IPv6 | 258 | | 259 +--------------+ 260 | 6LoWPAN | 261 | | 262 +--------------+ 263 | PHY-MAC | 264 | | 265 +--------------+ 267 Figure 1: RPL Stack. 269 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 270 it is fully stateful; in non-storing mode (RPL-NSM), it is fully 271 source routed. A RPL Instance is either fully storing or fully non- 272 storing, i.e. a RPL Instance with a combination of storing and non- 273 storing nodes is not supported with the current specifications at the 274 time of writing this document. 276 3. Updates to RFC6553, RFC6550 and RFC8138 278 3.1. Updates to RFC6553: Indicating the new RPI value. 280 This modification is required to be able to send, for example, IPv6 281 packets from a RPL-aware-leaf to a not-RPL-aware node through 282 Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 283 encapsulation. 285 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 286 the Option Type field of the RPL Option header, the two high order 287 bits must be set to '01' and the third bit is equal to '1'. The 288 first two bits indicate that the IPv6 node must discard the packet if 289 it doesn't recognize the option type, and the third bit indicates 290 that the Option Data may change in route. The remaining bits serve 291 as the option type. 293 +-------+-------------------+----------------+-----------+ 294 | Hex | Binary Value | Description | Reference | 295 + Value +-------------------+ + + 296 | | act | chg | rest | | | 297 +-------+-----+-----+-------+----------------+-----------+ 298 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 299 +-------+-----+-----+-------+----------------+-----------+ 301 Figure 2: Option Type in RPL Option. 303 This document illustrates that is is not always possible to know for 304 sure at the source that a packet will only travel within the RPL 305 domain or may leave it. 307 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 308 the outer IPv6 header chain could potentially impact core routers in 309 the internet. So at that time, it was decided to encapsulate any 310 packet with a RPL option using IPv6-in-IPv6 in all cases where it was 311 unclear whether the packet would remain within the RPL domain. In 312 the exception case where a packet would still leak, the Option Type 313 would ensure that the first router in the Internet that does not 314 recognize the option would drop the packet and protect the rest of 315 the network. 317 Even with [RFC8138] that compresses the IP-in-IP header, this 318 approach yields extra bytes in a packet which means consuming more 319 energy, more bandwidth, incurring higher chances of loss and possibly 320 causing a fragmentation at the 6LoWPAN level. This impacts the daily 321 operation of constrained devices for a case that generally does not 322 happen and would not heavily impact the core anyway. 324 While intention was and remains that the Hop-by-Hop header with a RPL 325 option should be confined within the RPL domain, this specification 326 modifies this behavior in order to reduce the dependency on IP-in-IP 327 and protect the constrained devices. Section 4 of [RFC8200] 328 clarifies the behaviour of routers in the Internet as follows: "it is 329 now expected that nodes along a packet's delivery path only examine 330 and process the Hop-by-Hop Options header if explicitly configured to 331 do so". This means that while it should be avoided, the impact on 332 the Internet of leaking a Hop-by-Hop header is acceptable. 334 When unclear about the travel of a packet, it becomes preferable for 335 a source not to encapsulate, accepting the fact that the packet may 336 leave the RPL domain on its way to its destination. In that event, 337 the packet should reach its destination and should not be discarded 338 by the first node that does not recognize the RPL option. But with 339 the current value of the Option Type, if a node in the Internet is 340 configured to process the Hop-by-Hop header, and if such node 341 encounters an option with the first two bits set to 01 and conforms 342 to [RFC8200], it will drop the packet. Host systems should do the 343 same, irrespective of the configuration. 345 Thus, this document updates the Option Type field to (Figure 3): the 346 two high order bits MUST be set to '00' and the third bit is equal to 347 '1'. The first two bits indicate that the IPv6 node MUST skip over 348 this option and continue processing the header ([RFC8200] 349 Section 4.2) if it doesn't recognize the option type, and the third 350 bit continues to be set to indicate that the Option Data may change 351 en route. The remaining bits serve as the option type and remain as 352 0x3. This ensures that a packet that leaves the RPL domain of an LLN 353 (or that leaves the LLN entirely) will not be discarded when it 354 contains the [RFC6553] RPL Hop-by-Hop option known as RPI. 356 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 357 capable) receives a packet with an RPL Option, it should ignore the 358 Hop-by-Hop RPL option (skip over this option and continue processing 359 the header). This is relevant, as it was mentioned previously, in 360 the case that there is a flow from RPL-aware-leaf to Internet (see 361 Section 6.2.1). 363 This is a significant update to [RFC6553]. 365 +-------+-------------------+-------------+------------+ 366 | Hex | Binary Value | Description | Reference | 367 + Value +-------------------+ + + 368 | | act | chg | rest | | | 369 +-------+-----+-----+-------+-------------+------------+ 370 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 371 +-------+-----+-----+-------+-------------+------------+ 373 Figure 3: Revised Option Type in RPL Option. (*)represents this 374 document 376 Without the signaling described below, this change would otherwise 377 create a flag day for existing networks which are currently using 378 0x63 as the RPI value. A move to 0x23 will not be understood by 379 those networks. It is suggested that implementations accept both 380 0x63 and 0x23 when processing. 382 When forwarding packets, implementations SHOULD use the same value as 383 it was received (This is required because, RPI type code can not be 384 changed by [RFC8200]). It allows to the network to be incrementally 385 upgraded, and for the DODAG root to know which parts of the network 386 are upgraded. 388 When originating new packets, implementations SHOULD have an option 389 to determine which value to originate with, this option is controlled 390 by the DIO option described below. 392 A network which is switching from straight 6lowpan compression 393 mechanism to those described in [RFC8138] will experience a flag day 394 in the data compression anyway, and if possible this change can be 395 deployed at the same time. 397 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 398 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 399 therefore no longer a necessity to remove the artifacts when sending 400 traffic to the Internet. This change clarifies when to use an IPv6- 401 in-IPv6 header, and how to address them: The Hop-by-Hop Options 402 Header containing the RPI option MUST always be added when 6LRs 403 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 404 headers MUST always be added when a 6LR find that it needs to insert 405 a Hop-by-Hop Options Header containing the RPI option. The IPv6-in- 406 IPv6 header is to be addressed to the RPL root when on the way up, 407 and to the end-host when on the way down. 409 Non-constrained uses of RPL are not in scope of this document, and 410 applicability statements for those uses may provide different advice, 411 E.g. [I-D.ietf-anima-autonomic-control-plane]. 413 In the non-storing case, dealing with not-RPL aware leaf nodes is 414 much easier as the 6LBR (DODAG root) has complete knowledge about the 415 connectivity of all DODAG nodes, and all traffic flows through the 416 root node. 418 The 6LBR can recognize not-RPL aware leaf nodes because it will 419 receive a DAO about that node from the 6LR immediately above that 420 not-RPL aware node. This means that the non-storing mode case can 421 avoid ever using hop-by-hop re-encapsulation headers for traffic 422 originating from the root to the leafs. 424 The non-storing mode case does not require the type change from 0x63 425 to 0x23, as the root can always create the right packet. The type 426 change does not adversely affect the non-storing case. 428 3.2. Updates to RFC6550: Indicating the new RPI in the DODAG 429 Configuration Option Flag. 431 In order to avoid a Flag Day caused by lack of interoperation between 432 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 433 in the DIO Configuration Option, to indicate when then new RPI value 434 can be safely used. This means, the flag is going to indicate the 435 type of RPI that the network is using. Thus, when a node join to a 436 network will know which value to use. With this, RPL-capable nodes 437 know if it is safe to use 0x23 when creating a new RPI. A node that 438 forwards a packet with an RPI MUST NOT modify the option type of the 439 RPI. 441 This is done via a DODAG Configuration Option flag which will 442 propagate through the network. If the flag is received with a value 443 zero (which is the default), then new nodes will remain in RFC6553 444 Compatible Mode; originating traffic with the old-RPI (0x63) value. 446 As stated in [RFC6550] the DODAG Configuration option is present in 447 DIO messages. The DODAG Configuration option distributes 448 configuration information. It is generally static, and does not 449 change within the DODAG. This information is configured at the DODAG 450 root and distributed throughout the DODAG with the DODAG 451 Configuration option. Nodes other than the DODAG root do not modify 452 this information when propagating the DODAG Configuration option. 454 The DODAG Configuration Option has a Flag field which is modified by 455 this document. Currently, the DODAG Configuration Option in 456 [RFC6550] states: "the unused bits MUST be initialize to zero by the 457 sender and MUST be ignored by the receiver". 459 Bit number three of the flag field in the DODAG Configuration option 460 is to be used as shown in Figure 4 : 462 +------------+-----------------+---------------+ 463 | Bit number | Description | Reference | 464 +------------+-----------------+---------------+ 465 | 3 | RPI 0x23 enable | This document | 466 +------------+-----------------+---------------+ 468 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 469 day. 471 In case of rebooting, the node (6LN or 6LR) does not remember if the 472 flag is set, so DIO messages would be set with the flag unset until a 473 DIO is received with the flag set. 475 3.3. Updates to RFC8138: Indicating the way to decompress with the new 476 RPI value. 478 This modification is required to be able to decompress the RPL RPI 479 option with the new value (0x23). 481 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 482 in section 6. A node that is decompressing this header MUST 483 decompress using the RPL RPI option type that is currently active: 484 that is, a choice between 0x23 (new) and 0x63 (old). The node will 485 know which to use based upon the presence of the flag in the DODAG 486 Configuration Option defined in Section 3.2. E.g. If the network is 487 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 489 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 490 header. 492 There are potential significant advantages to having a single code 493 path that always processes IPv6-in-IPv6 headers with no conditional 494 branches. 496 In Storing Mode, for the examples of Flow from RPL-aware-leaf to not- 497 RPL-aware-leaf and not-RPL-aware-leaf to not-RPL-aware-leaf comprise 498 an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in- 499 IPv6 header is MANDATORY in this case, and it SHOULD be compressed 500 with [RFC8138] section 7. As exemplification of compressing the RPI, 501 section A.1 of [RFC8138] illustrates the case in Storing mode where 502 the packet is received from the Internet, then the root encapsulates 503 the packet to insert the RPI. The result is shown in Figure 5. 505 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 506 |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP 507 |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld 508 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 510 Figure 5: RPI Inserted by the Root in Storing Mode 512 4. Sample/reference topology 514 A RPL network in general is composed of a 6LBR (6LoWPAN Border 515 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 516 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 518 Figure 6 shows the reference RPL Topology for this document. The 519 letters above the nodes are there so that they may be referenced in 520 subsequent sections. In the figure, 6LR represents a full router 521 node. The 6LN is a RPL aware router, or host (as a leaf). 522 Additionally, for simplification purposes, it is supposed that the 523 6LBR has direct access to Internet, thus the 6BBR is not present in 524 the figure. 526 The 6LN leaves (Raf) marked as (F, H and I) are RPL nodes with no 527 children hosts. 529 The leafs marked as ~Raf (G and J) are devices which do not speak RPL 530 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 531 DAC and efficient-ND only to participate in the network [RFC6775]. 532 In the document these leafs (G and J) are also referred to as an IPv6 533 node. 535 The 6LBR ("A") in the figure is the root of the Global DODAG. 537 +------------+ 538 | INTERNET ----------+ 539 | | | 540 +------------+ | 541 | 542 | 543 | 544 A | 545 +-------+ 546 |6LBR | 547 +-----------|(root) |-------+ 548 | +-------+ | 549 | | 550 | | 551 | | 552 | | 553 | B |C 554 +---|---+ +---|---+ 555 | 6LR | | 6LR | 556 +---------| |--+ +--- ---+ 557 | +-------+ | | +-------+ | 558 | | | | 559 | | | | 560 | | | | 561 | | | | 562 | D | E | | 563 +-|-----+ +---|---+ | | 564 | 6LR | | 6LR | | | 565 | | +------ | | | 566 +---|---+ | +---|---+ | | 567 | | | | | 568 | | +--+ | | 569 | | | | | 570 | | | | | 571 | | | I | J | 572 F | | G | H | | 573 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 574 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 575 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 576 +-------+ +-------+ +------+ +-------+ +-------+ 578 Figure 6: A reference RPL Topology. 580 5. Use cases 582 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 583 encapsulation are going to be analyzed for a number of representative 584 traffic flows. 586 This document assumes that the LLN is using the no-drop RPI option 587 (0x23). 589 The uses cases describe the communication between RPL-aware-nodes, 590 with the root (6LBR), and with Internet. This document also 591 describes the communication between nodes acting as leaves that do 592 not understand RPL (~Raf nodes), but are part of the LLN. (e.g. 593 Section 6.1.4 Flow from not-RPL-aware-leaf to root) This document 594 depicts as well the communication inside of the LLN when it has the 595 final destination addressed outside of the LLN e.g. with destination 596 to Internet. For example, Section 6.2.3 Flow from not-RPL-aware-leaf 597 to Internet 599 The uses cases comprise as follow: 601 Interaction between Leaf and Root: 603 RPL-aware-leaf(Raf) to root 605 root to RPL-aware-leaf(Raf) 607 not-RPL-aware-leaf(~Raf) to root 609 root to not-RPL-aware-leaf(~Raf) 611 Interaction between Leaf and Internet: 613 RPL-aware-leaf(Raf) to Internet 615 Internet to RPL-aware-leaf(Raf) 617 not-RPL-aware-leaf(~Raf) to Internet 619 Internet to not-RPL-aware-leaf(~Raf) 621 Interaction between Leafs: 623 RPL-aware-leaf(Raf) to RPL-aware-leaf(Raf) (storing and non- 624 storing) 626 RPL-aware-leaf(Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 627 not-RPL-aware-leaf(~Raf) to RPL-aware-leaf(Raf) (storing and non- 628 storing) 630 not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 632 This document is consistent with the rule that a Header cannot be 633 inserted or removed on the fly inside an IPv6 packet that is being 634 routed. This is a fundamental precept of the IPv6 architecture as 635 outlined in [RFC8200]. Extensions headers may not be added or 636 removed except by the sender or the receiver. 638 As the rank information in the RPI artifact is changed at each hop, 639 it will typically be zero when it arrives at the DODAG root. The 640 DODAG root MUST force it to zero when passing the packet out to the 641 Internet. The Internet will therefore not see any SenderRank 642 information. 644 Despite being legal to leave the RPI artifact in place, an 645 intermediate router that needs to add an extension header (e.g. RH3 646 or RPI Option) MUST still encapsulate the packet in an (additional) 647 outer IP header. The new header is placed after this new outer IP 648 header. 650 A corollary is that an RH3 or RPI Option can only be removed by an 651 intermediate router if it is placed in an encapsulating IPv6 Header, 652 which is addressed TO the intermediate router. When it does so, the 653 whole encapsulating header must be removed. (A replacement may be 654 added). This sometimes can result in outer IP headers being 655 addressed to the next hop router using link-local address. 657 Both RPI and RH3 headers may be modified in very specific ways by 658 routers on the path of the packet without the need to add and remove 659 an encapsulating header. Both headers were designed with this 660 modification in mind, and both the RPL RH3 and the RPL option are 661 marked mutable but recoverable: so an IPsec AH security header can be 662 applied across these headers, but it can not secure the values which 663 mutate. 665 RPI MUST be present in every single RPL data packet. 667 Prior to [RFC8138], there was significant interest in removing the 668 RPI for downward flows in non-storing mode. The exception covered a 669 very small number of cases, and causes significant interoperability 670 challenges, yet costed significant code and testing complexity. The 671 ability to compress the RPI down to three bytes or less removes much 672 of the pressure to optimize this any further 673 [I-D.ietf-anima-autonomic-control-plane]. 675 The earlier examples are more extensive to make sure that the process 676 is clear, while later examples are more concise. 678 6. Storing mode 680 In storing mode (SM) (fully stateful), the sender can determine if 681 the destination is inside the LLN by looking if the destination 682 address is matched by the DIO's Prefix Information Option (PIO) 683 option. 685 The following table (Figure 7) itemizes which headers are needed in 686 each of the following scenarios. It indicates if the IPv6-in-IPv6 687 header that is added, must be addressed to the final destination (the 688 Raf node that is the target(tgt)), to the "root" or if a hop-by-hop 689 header must be added (indicated by "hop"). 691 In cases where no IPv6-in-IPv6 header is needed, the column states as 692 "No". If the IPv6-in-IPv6 header is needed is a "must". 694 In all cases the RPI headers are needed, since it identifies 695 inconsistencies (loops) in the routing topology. In all cases the 696 RH3 is not needed because it is not used in storing mode. 698 In each case, 6LR_i is the intermediate router from source to 699 destination. "1 <= i <= n", n is the number of routers (6LR) that 700 the packet goes through from source (6LN) to destination. 702 The leaf can be a router 6LR or a host, both indicated as 6LN. The 703 root refers to the 6LBR (see Figure 6). 705 +---------------------+--------------+------------+------------------+ 706 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 707 +---------------------+--------------+------------+------------------+ 708 | | Raf to root | No | No | 709 + +--------------+------------+------------------+ 710 | Leaf - Root | root to Raf | No | No | 711 + +--------------+------------+------------------+ 712 | | root to ~Raf | No | No | 713 + +--------------+------------+------------------+ 714 | | ~Raf to root | must | root | 715 +---------------------+--------------+------------+------------------+ 716 | | Raf to Int | No | No | 717 + +--------------+------------+------------------+ 718 | Leaf - Internet | Int to Raf | must | Raf (tgt) | 719 + +--------------+------------+------------------+ 720 | | ~Raf to Int | must | root | 721 + +--------------+------------+------------------+ 722 | | Int to ~Raf | must | hop | 723 +---------------------+--------------+------------+------------------+ 724 | | Raf to Raf | No | No | 725 + +--------------+------------+------------------+ 726 | | Raf to ~Raf | No | No | 727 + Leaf - Leaf +--------------+------------+------------------+ 728 | | ~Raf to Raf | must | Raf (tgt) | 729 + +--------------+------------+------------------+ 730 | | ~Raf to ~Raf | must | hop | 731 +---------------------+--------------+------------+------------------+ 733 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 735 6.1. Storing Mode: Interaction between Leaf and Root 737 In this section is described the communication flow in storing mode 738 (SM) between, 740 RPL-aware-leaf to root 742 root to RPL-aware-leaf 744 not-RPL-aware-leaf to root 746 root to not-RPL-aware-leaf 748 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 750 In storing mode, RFC 6553 (RPI) is used to send RPL Information 751 instanceID and rank information. 753 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 754 generally issue DIO messages; a leaf node accepts DIO messages from 755 upstream. (When the inconsistency in routing occurs, a leaf node 756 will generate a DIO with an infinite rank, to fix it). It may issue 757 DAO and DIS messages though it generally ignores DAO and DIS 758 messages. 760 In this case the flow comprises: 762 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 764 For example, a communication flow could be: Node F --> Node D --> 765 Node B --> Node A root(6LBR) 767 As it was mentioned in this document 6LRs, 6LBR are always full- 768 fledged RPL routers. 770 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 771 (Node E) which decrements the rank in RPI and sends the packet up. 772 When the packet arrives at 6LBR (Node A), the RPI is removed and the 773 packet is processed. 775 No IPv6-in-IPv6 header is required. 777 The RPI header can be removed by the 6LBR because the packet is 778 addressed to the 6LBR. The 6LN must know that it is communicating 779 with the 6LBR to make use of this scenario. The 6LN can know the 780 address of the 6LBR because it knows the address of the root via the 781 DODAGID in the DIO messages. 783 The Table 1 summarizes what headers are needed for this use case. 785 +-------------------+---------+-------+----------+ 786 | Header | 6LN src | 6LR_i | 6LBR dst | 787 +-------------------+---------+-------+----------+ 788 | Inserted headers | RPI | -- | -- | 789 | Removed headers | -- | -- | RPI | 790 | Re-added headers | -- | -- | -- | 791 | Modified headers | -- | RPI | -- | 792 | Untouched headers | -- | -- | -- | 793 +-------------------+---------+-------+----------+ 795 Table 1: Storing mode: Summary of the use of headers from RPL-aware- 796 leaf to root 798 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 800 In this case the flow comprises: 802 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 804 For example, a communication flow could be: Node A root(6LBR) --> 805 Node B --> Node D --> Node F 807 In this case the 6LBR inserts RPI header and sends the packet down, 808 the 6LR is going to increment the rank in RPI (it examines the 809 instanceID to identify the right forwarding table), the packet is 810 processed in the 6LN and the RPI removed. 812 No IPv6-in-IPv6 header is required. 814 The Table 2 summarizes what headers are needed for this use case. 816 +-------------------+------+-------+------+ 817 | Header | 6LBR | 6LR_i | 6LN | 818 +-------------------+------+-------+------+ 819 | Inserted headers | RPI | -- | -- | 820 | Removed headers | -- | -- | RPI | 821 | Re-added headers | -- | -- | -- | 822 | Modified headers | -- | RPI | -- | 823 | Untouched headers | -- | -- | -- | 824 +-------------------+------+-------+------+ 826 Table 2: Storing mode: Summary of the use of headers from root to 827 RPL-aware-leaf 829 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 831 In this case the flow comprises: 833 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 835 For example, a communication flow could be: Node A root(6LBR) --> 836 Node B --> Node E --> Node G 838 As the RPI extension can be ignored by the not-RPL-aware leaf, this 839 situation is identical to the previous scenario. 841 The Table 3 summarizes what headers are needed for this use case. 843 +-------------------+----------+-------+----------------+ 844 | Header | 6LBR src | 6LR_i | IPv6 dst node | 845 +-------------------+----------+-------+----------------+ 846 | Inserted headers | RPI | -- | -- | 847 | Removed headers | -- | -- | -- | 848 | Re-added headers | -- | -- | -- | 849 | Modified headers | -- | RPI | -- | 850 | Untouched headers | -- | -- | RPI (Ignored) | 851 +-------------------+----------+-------+----------------+ 853 Table 3: Storing mode: Summary of the use of headers from root to 854 not-RPL-aware-leaf 856 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 858 In this case the flow comprises: 860 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 862 For example, a communication flow could be: Node G --> Node E --> 863 Node B --> Node A root(6LBR) 865 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 866 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 867 header. The IPv6-in-IPv6 header can be addressed to the next hop 868 (Node B), or to the root (Node A). The root removes the header and 869 processes the packet. 871 The Figure 8 shows the table that summarizes what headers are needed 872 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 874 +-----------+------+--------------+-----------------+------------------+ 875 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 876 | | src | | | | 877 | | node | | | | 878 +-----------+------+--------------+-----------------+------------------+ 879 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 880 | headers | | | | | 881 +-----------+------+--------------+-----------------+------------------+ 882 | Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]| 883 | headers | | | | | 884 +-----------+------+--------------+-----------------+------------------+ 885 | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | 886 | headers | | | | | 887 +-----------+------+--------------+-----------------+------------------+ 888 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 889 | headers | | | | | 890 +-----------+------+--------------+-----------------+------------------+ 891 | Untouched | -- | -- | -- | -- | 892 | headers | | | | | 893 +-----------+------+--------------+-----------------+------------------+ 895 Figure 8: Storing mode: Summary of the use of headers from not-RPL- 896 aware-leaf to root. [1] Case where the IPv6-in-IPv6 header is 897 addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 898 header is addressed to the root (Node A). 900 6.2. Storing Mode: Interaction between Leaf and Internet. 902 In this section is described the communication flow in storing mode 903 (SM) between, 905 RPL-aware-leaf to Internet 907 Internet to RPL-aware-leaf 909 not-RPL-aware-leaf to Internet 911 Internet to not-RPL-aware-leaf 913 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 915 RPL information from RFC 6553 may go out to Internet as it will be 916 ignored by nodes which have not been configured to be RPI aware. 918 In this case the flow comprises: 920 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 921 For example, the communication flow could be: Node F --> Node D --> 922 Node B --> Node A root(6LBR) --> Internet 924 No IPv6-in-IPv6 header is required. 926 Note: In this use case it is used a node as leaf, but this use case 927 can be also applicable to any RPL-node type (e.g. 6LR) 929 The Table 4 summarizes what headers are needed for this use case. 931 +-------------------+---------+-------+------+----------------+ 932 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 933 +-------------------+---------+-------+------+----------------+ 934 | Inserted headers | RPI | -- | -- | -- | 935 | Removed headers | -- | -- | -- | -- | 936 | Re-added headers | -- | -- | -- | -- | 937 | Modified headers | -- | RPI | -- | -- | 938 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 939 +-------------------+---------+-------+------+----------------+ 941 Table 4: Storing mode: Summary of the use of headers from RPL-aware- 942 leaf to Internet 944 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 946 In this case the flow comprises: 948 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 950 For example, a communication flow could be: Internet --> Node A 951 root(6LBR) --> Node B --> Node D --> Node F 953 When the packet arrives from Internet to 6LBR the RPI header is added 954 in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination 955 address set to the 6LR) and sent to 6LR, which modifies the rank in 956 the RPI. When the packet arrives at 6LN the RPI header is removed 957 and the packet processed. 959 The Figure 9 shows the table that summarizes what headers are needed 960 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 962 +-----------+----------+--------------+--------------+--------------+ 963 | Header | Internet | 6LBR | 6LR_i | 6LN dst | 964 | | src | | | | 965 +-----------+----------+--------------+--------------+--------------+ 966 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 967 | headers | | | | | 968 +-----------+----------+--------------+--------------+--------------+ 969 | Removed | -- | -- | -- | IP6-IP6(RPI) | 970 | headers | | | | | 971 +-----------+----------+--------------+--------------+--------------+ 972 | Re-added | -- | -- | -- | -- | 973 | headers | | | | | 974 +-----------+----------+--------------+--------------+--------------+ 975 | Modified | -- | -- | IP6-IP6(RPI) | -- | 976 | headers | | | | | 977 +-----------+----------+--------------+--------------+--------------+ 978 | Untouched | -- | -- | -- | -- | 979 | headers | | | | | 980 +-----------+----------+--------------+--------------+--------------+ 982 Figure 9: Storing mode: Summary of the use of headers from Internet 983 to RPL-aware-leaf. 985 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 987 In this case the flow comprises: 989 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 990 Internet 992 For example, a communication flow could be: Node G --> Node E --> 993 Node B --> Node A root(6LBR) --> Internet 995 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 996 either to the root, or hop-by-hop such that the root can remove the 997 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 998 root cause less processing overhead. On the other hand, with hop-by- 999 hop the intermediate routers can check the routing tables for a 1000 better routing path, thus it could be more efficient and faster. 1001 Implementation should decide which approach to take. 1003 The originating node will ideally leave the IPv6 flow label as zero 1004 so that the packet can be better compressed through the LLN. The 1005 6LBR will set the flow label of the packet to a non-zero value when 1006 sending to the Internet. 1008 The Figure 10 shows the table that summarizes what headers are needed 1009 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1011 +---------+-------+------------+--------------+-------------+--------+ 1012 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1013 | | src | | [i=2,...,n] | | dst | 1014 | | node | | | | | 1015 +---------+-------+------------+--------------+-------------+--------+ 1016 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1017 | headers | | | [2] | | | 1018 +---------+-------+------------+--------------+-------------+--------+ 1019 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1020 | headers | | | [2] | [1][2] | | 1021 +---------+-------+------------+--------------+-------------+--------+ 1022 | Re-added| -- | -- | -- | -- | -- | 1023 | headers | | | | | | 1024 +---------+-------+------------+--------------+-------------+--------+ 1025 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1026 | headers | | | [1] | | | 1027 +---------+-------+------------+--------------+-------------+--------+ 1028 |Untouched| -- | -- | -- | -- | -- | 1029 | headers | | | | | | 1030 +---------+-------+------------+--------------+-------------+--------+ 1032 Figure 10: Storing mode: Summary of the use of headers from not-RPL- 1033 aware-leaf to Internet. [1] Case when packet is addressed to the 1034 root. [2] Case when the packet is addressed hop-by-hop. 1036 6.2.4. SM: Example of Flow from Internet to not-RPL-aware-leaf. 1038 In this case the flow comprises: 1040 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1042 For example, a communication flow could be: Internet --> Node A 1043 root(6LBR) --> Node B --> Node E --> Node G 1045 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 1046 header. The IPv6-in-IPv6 is addressed hop-by-hop. 1048 The final node should be able to remove one or more IPv6-in-IPv6 1049 headers which are all addressed to it. The final node does not 1050 process the RPI, the node ignores the RPI. Furhter details about 1051 this are mentioned in [I-D.thubert-roll-unaware-leaves], which 1052 specifies RPL routing for a 6LN acting as a plain host and not aware 1053 of RPL. 1055 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1056 zero in order to aid in compression. 1058 The Figure 11 shows the table that summarizes what headers are needed 1059 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1061 +-----------+----------+--------------+--------------+--------------+ 1062 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1063 | | src | | | | 1064 +-----------+----------+--------------+--------------+--------------+ 1065 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1066 | headers | | | | | 1067 +-----------+----------+--------------+--------------+--------------+ 1068 | Removed | -- | -- | | IP6-IP6(RPI)| 1069 | headers | | | | RPI Ignored | 1070 +-----------+----------+--------------+--------------+--------------+ 1071 | Re-added | -- | -- | -- | -- | 1072 | headers | | | | | 1073 +-----------+----------+--------------+--------------+--------------+ 1074 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1075 | headers | | | | | 1076 +-----------+----------+--------------+--------------+--------------+ 1077 | Untouched | -- | -- | -- | -- | 1078 | headers | | | | | 1079 +-----------+----------+--------------+--------------+--------------+ 1081 Figure 11: Storing mode: Summary of the use of headers from Internet 1082 to not-RPL-aware-leaf. 1084 6.3. Storing Mode: Interaction between Leaf and Leaf 1086 In this section is described the communication flow in storing mode 1087 (SM) between, 1089 RPL-aware-leaf to RPL-aware-leaf 1091 RPL-aware-leaf to not-RPL-aware-leaf 1093 not-RPL-aware-leaf to RPL-aware-leaf 1095 not-RPL-aware-leaf to not-RPL-aware-leaf 1097 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1099 In [RFC6550] RPL allows a simple one-hop optimization for both 1100 storing and non-storing networks. A node may send a packet destined 1101 to a one-hop neighbor directly to that node. See section 9 in 1102 [RFC6550]. 1104 When the nodes are not directly connected, then in storing mode, the 1105 flow comprises: 1107 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1109 For example, a communication flow could be: Node F --> Node D --> 1110 Node B --> Node E --> Node H 1112 6LR_ia (Node D) is the intermediate router from source to the common 1113 parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the number 1114 of routers (6LR) that the packet goes through from 6LN (Node F) to 1115 the common parent (6LR_x). 1117 6LR_id (Node E) is the intermediate router from the common parent 1118 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1119 <= m", m is the number of routers (6LR) that the packet goes through 1120 from the common parent (6LR_x) to destination 6LN. 1122 It is assumed that the two nodes are in the same RPL Domain (that 1123 they share the same DODAG root). At the common parent (Node B), the 1124 direction of RPI is changed (from increasing to decreasing the rank). 1126 While the 6LR nodes will update the RPI, no node needs to add or 1127 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1129 The Table 5 summarizes what headers are needed for this use case. 1131 +---------------+--------+--------+---------------+--------+--------+ 1132 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1133 | | src | | parent) | | dst | 1134 +---------------+--------+--------+---------------+--------+--------+ 1135 | Inserted | RPI | -- | -- | -- | -- | 1136 | headers | | | | | | 1137 | Removed | -- | -- | -- | -- | RPI | 1138 | headers | | | | | | 1139 | Re-added | -- | -- | -- | -- | -- | 1140 | headers | | | | | | 1141 | Modified | -- | RPI | RPI | RPI | -- | 1142 | headers | | | | | | 1143 | Untouched | -- | -- | -- | -- | -- | 1144 | headers | | | | | | 1145 +---------------+--------+--------+---------------+--------+--------+ 1147 Table 5: Storing mode: Summary of the use of headers for RPL-aware- 1148 leaf to RPL-aware-leaf 1150 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 1152 In this case the flow comprises: 1154 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1155 6LN (IPv6) 1157 For example, a communication flow could be: Node F --> Node D --> 1158 Node B --> Node E --> Node G 1160 6LR_ia is the intermediate router from source (6LN) to the common 1161 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1162 routers (6LR) that the packet goes through from 6LN to the common 1163 parent (6LR_x). 1165 6LR_id (Node E) is the intermediate router from the common parent 1166 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1167 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1168 the packet goes through from the common parent (6LR_x) to destination 1169 6LN. 1171 This situation is identical to the previous situation Section 6.3.1 1173 The Table 6 summarizes what headers are needed for this use case. 1175 +-----------+------+--------+---------------+--------+--------------+ 1176 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | 1177 | | src | | parent) | | node | 1178 +-----------+------+--------+---------------+--------+--------------+ 1179 | Inserted | RPI | -- | -- | -- | -- | 1180 | headers | | | | | | 1181 | Removed | -- | -- | -- | -- | -- | 1182 | headers | | | | | | 1183 | Re-added | -- | -- | -- | -- | -- | 1184 | headers | | | | | | 1185 | Modified | -- | RPI | RPI | RPI | -- | 1186 | headers | | | | | | 1187 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1188 | headers | | | | | | 1189 +-----------+------+--------+---------------+--------+--------------+ 1191 Table 6: Storing mode: Summary of the use of headers for RPL-aware- 1192 leaf to not-RPL-aware-leaf 1194 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1196 In this case the flow comprises: 1198 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1199 6LR_id --> 6LN 1200 For example, a communication flow could be: Node G --> Node E --> 1201 Node B --> Node D --> Node F 1203 6LR_ia (Node E) is the intermediate router from source (not-RPL-aware 1204 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In this 1205 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1206 packet ges through from source to the common parent. 1208 6LR_id (Node D) is the intermediate router from the common parent 1209 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1210 <= m", m is the number of routers (6LR) that the packet goes through 1211 from the common parent (6LR_x) to destination 6LN. 1213 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1214 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1215 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1216 (Node F). 1218 The Figure 12 shows the table that summarizes what headers are needed 1219 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1221 +---------+-----+------------+-------------+-------------+------------+ 1222 | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | 1223 | |src | | Parent | | dst | 1224 | |node | | (6LRx) | | | 1225 +---------+-----+------------+-------------+-------------+------------+ 1226 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1227 | headers | | | | | | 1228 +---------+-----+------------+-------------+-------------+------------+ 1229 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1230 | headers | | | | | | 1231 +---------+-----+------------+-------------+-------------+------------+ 1232 | Re-added| -- | -- | -- | -- | -- | 1233 | headers | | | | | | 1234 +---------+-----+------------+-------------+-------------+------------+ 1235 | Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- | 1236 | headers | | | | | | 1237 +---------+-----+------------+-------------+-------------+------------+ 1238 |Untouched| -- | -- | -- | -- | -- | 1239 | headers | | | | | | 1240 +---------+-----+------------+-------------+-------------+------------+ 1242 Figure 12: Storing mode: Summary of the use of headers from not-RPL- 1243 aware-leaf to RPL-aware-leaf. 1245 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1246 leaf 1248 In this case the flow comprises: 1250 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id 1251 --> not-RPL-aware 6LN (IPv6 dst) 1253 For example, a communication flow could be: Node G --> Node E --> 1254 Node B --> Node A (root) --> Node C --> Node J 1256 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1257 router from the not-RPL-aware source (Node G) to the root (6LBR) 1258 (Node A). In this case, "1 < ia <= n", n is the number of routers 1259 (6LR) that the packet goes through from IPv6 src to the root. 1261 6LR_id (C) is the intermediate router from the root (Node A) to the 1262 destination Node J. In this case, "1 <= id <= m", m is the number of 1263 routers (6LR) that the packet goes through from the root to 1264 destination (IPv6 dst). 1266 The RPI is ignored at the IPv6 dst node. 1268 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1269 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1270 header. The IPv6-in-IPv6 header is addressed hop-by-hop. 1272 The Figure 13 shows the table that summarizes what headers are needed 1273 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1275 +---------+------+-------+-------+---------+-------+-------+ 1276 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | 1277 | | src | | | | | dst | 1278 | | node | | | | | node | 1279 +---------+------+-------+-------+---------+-------+-------+ 1280 | Inserted| -- |IP6-IP6| -- | | -- | -- | 1281 | headers | | (RPI )| | | | | 1282 | | | | | | | | 1283 +---------+------+-------+-------+---------+-------+-------+ 1284 | Removed | -- | -- | -- | | -- |IP6-IP6| 1285 | headers | | | | | |(RPI) | 1286 | | | | | | | RPI | 1287 | | | | | | |Ignored| 1288 +---------+------+-------+-------+---------+-------+-------+ 1289 | Re-added| -- | -- | -- | -- | -- | -- | 1290 | headers | | | | | | | 1291 +---------+------+-------+-------+---------+-------+-------+ 1292 | Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | 1293 | headers | | | (RPI) | (RPI) | (RPI) | | 1294 | | | | | | | | 1295 +---------+------+-------+-------+---------+-------+-------+ 1296 |Untouched| -- | -- | -- | -- | -- | -- | 1297 | headers | | | | | | | 1298 +---------+------+-------+-------+---------+-------+-------+ 1300 Figure 13: Storing mode: Summary of the use of headers from not-RPL- 1301 aware-leaf to not-RPL-aware-leaf 1303 7. Non Storing mode 1305 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1306 root) has complete knowledge about the connectivity of all DODAG 1307 nodes, and all traffic flows through the root node. Thus, there is 1308 no need for all nodes to know about the existence of not-RPL aware 1309 nodes. Only the 6LBR needs to act if compensation is necessary for 1310 not-RPL aware receivers. 1312 The following table (Figure 14) summarizes what headers are needed in 1313 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1314 IPv6 header are to be inserted. It depicts the target destination 1315 address possible (indicated by "Raf"), to a 6LR (parent of a 6LN) or 1316 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1317 column states as "No". There is no expectation on RPL that RPI can 1318 be omitted, because it is needed for routing, quality of service and 1319 compression. This specification expects that is always a RPI 1320 Present. 1322 The leaf can be a router 6LR or a host, both indicated as 6LN 1323 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1324 where the RPI header may still be needed for the instanceID to be 1325 available for priority/channel selection at each hop. 1327 +-----------------+--------------+-----+-----+------------+------------+ 1328 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1329 | between | | | | | dst | 1330 +-----------------+--------------+-----+-----+------------+------------+ 1331 | | Raf to root | Yes | No | No | No | 1332 + +--------------+-----+-----+------------+------------+ 1333 | Leaf - Root | root to Raf | Yes | Yes | No | No | 1334 + +--------------+-----+-----+------------+------------+ 1335 | | root to ~Raf | Yes | Yes | must | 6LR | 1336 | | | (1) | | | | 1337 + +--------------+-----+-----+------------+------------+ 1338 | | ~Raf to root | Yes | No | must | root | 1339 +-----------------+--------------+-----+-----+------------+------------+ 1340 | | Raf to Int | Yes | No | No | No | 1341 + +--------------+-----+-----+------------+------------+ 1342 | Leaf - Internet | Int to Raf | Yes | Yes | must | Raf | 1343 + +--------------+-----+-----+------------+------------+ 1344 | | ~Raf to Int | Yes | No | must | root | 1345 + +--------------+-----+-----+------------+------------+ 1346 | | Int to ~Raf | Yes | Yes | must | 6LR | 1347 +-----------------+--------------+-----+-----+------------+------------+ 1348 | | Raf to Raf | Yes | Yes | must | root/Raf | 1349 + +--------------+-----+-----+------------+------------+ 1350 | | Raf to ~Raf | Yes | Yes | must | root/6LR | 1351 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1352 | | ~Raf to Raf | Yes | Yes | must | root/Raf | 1353 + +--------------+-----+-----+------------+------------+ 1354 | | ~Raf to ~Raf | Yes | Yes | must | root/6LR | 1355 +-----------------+--------------+-----+-----+------------+------------+ 1357 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1358 RH3, IPv6-in-IPv6 encapsulation. 1360 7.1. Non-Storing Mode: Interaction between Leaf and Root 1362 In this section is described the communication flow in Non Storing 1363 Mode (Non-SM) between, 1365 RPL-aware-leaf to root 1367 root to RPL-aware-leaf 1369 not-RPL-aware-leaf to root 1370 root to not-RPL-aware-leaf 1372 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1374 In non-storing mode the leaf node uses default routing to send 1375 traffic to the root. The RPI header must be included since it 1376 contains the rank information, which is used to avoid/detect loops. 1378 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1380 For example, a communication flow could be: Node F --> Node D --> 1381 Node B --> Node A (root) 1383 6LR_i is the intermediate router from source to destination. In this 1384 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1385 goes through from source (6LN) to destination (6LBR). 1387 This situation is the same case as storing mode. 1389 The Table 7 summarizes what headers are needed for this use case. 1391 +-------------------+---------+-------+----------+ 1392 | Header | 6LN src | 6LR_i | 6LBR dst | 1393 +-------------------+---------+-------+----------+ 1394 | Inserted headers | RPI | -- | -- | 1395 | Removed headers | -- | -- | RPI | 1396 | Re-added headers | -- | -- | -- | 1397 | Modified headers | -- | RPI | -- | 1398 | Untouched headers | -- | -- | -- | 1399 +-------------------+---------+-------+----------+ 1401 Table 7: Non Storing mode: Summary of the use of headers from RPL- 1402 aware-leaf to root 1404 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1406 In this case the flow comprises: 1408 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1410 For example, a communication flow could be: Node A (root) --> Node B 1411 --> Node D --> Node F 1413 6LR_i is the intermediate router from source to destination. In this 1414 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1415 goes through from source (6LBR) to destination (6LN). 1417 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1418 necessary as the traffic originates with an RPL aware node, the 6LBR. 1419 The destination is known to be RPL-aware because the root knows the 1420 whole topology in non-storing mode. 1422 The Table 8 summarizes what headers are needed for this use case. 1424 +-------------------+----------+-----------+-----------+ 1425 | Header | 6LBR src | 6LR_i | 6LN dst | 1426 +-------------------+----------+-----------+-----------+ 1427 | Inserted headers | RPI, RH3 | -- | -- | 1428 | Removed headers | -- | -- | RH3, RPI | 1429 | Re-added headers | -- | -- | -- | 1430 | Modified headers | -- | RPI, RH3 | -- | 1431 | Untouched headers | -- | -- | -- | 1432 +-------------------+----------+-----------+-----------+ 1434 Table 8: Non Storing mode: Summary of the use of headers from root to 1435 RPL-aware-leaf 1437 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1439 In this case the flow comprises: 1441 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1443 For example, a communication flow could be: Node A (root) --> Node B 1444 --> Node E --> Node G 1446 6LR_i is the intermediate router from source to destination. In this 1447 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1448 goes through from source (6LBR) to destination (IPv6). 1450 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1451 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1452 but left there. As the RPI is added, then the IPv6 node which does 1453 not understand the RPI, will ignore it (following RFC8200), thus 1454 encapsulation is not necessary. 1456 The Figure 15 depicts the table that summarizes what headers are 1457 needed for this use case. 1459 +-----------+----------+--------------+----------------+----------+ 1460 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1461 | | | i=(1,..,n-1) | | dst | 1462 | | | | | node | 1463 +-----------+----------+--------------+----------------+----------+ 1464 | Inserted | RPI, RH3 | -- | -- | -- | 1465 | headers | | | | | 1466 +-----------+----------+--------------+----------------+----------+ 1467 | Removed | -- | -- | | -- | 1468 | headers | | | | | 1469 +-----------+----------+--------------+----------------+----------+ 1470 | Re-added | -- | -- | -- | -- | 1471 | headers | | | | | 1472 +-----------+----------+--------------+----------------+----------+ 1473 | Modified | -- | RPI, RH3 | RPI, | -- | 1474 | headers | | | RH3(consumed) | | 1475 +-----------+----------+--------------+----------------+----------+ 1476 | Untouched | -- | -- | -- | RPI, RH3 | 1477 | headers | | | | (both | 1478 | | | | | ignored) | 1479 +-----------+----------+--------------+----------------+----------+ 1481 Figure 15: Non Storing mode: Summary of the use of headers from root 1482 to not-RPL-aware-leaf 1484 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1486 In this case the flow comprises: 1488 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1490 For example, a communication flow could be: Node G --> Node E --> 1491 Node B --> Node A (root) 1493 6LR_i is the intermediate router from source to destination. In this 1494 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1495 goes through from source (IPv6) to destination (6LBR). For example, 1496 6LR_1 (i=1) is the router that receives the packets from the IPv6 1497 node. 1499 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1500 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1501 following 6LRs. The RPI and entire packet is consumed by the root. 1503 The Figure 16 shows the table that summarizes what headers are needed 1504 for this use case. 1506 +---------+----+-----------------+-----------------+-----------------+ 1507 | Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst | 1508 | |src | | | | 1509 | |node| | | | 1510 +---------+----+-----------------+-----------------+-----------------+ 1511 | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- | 1512 | headers | | | | | 1513 +---------+----+-----------------+-----------------+-----------------+ 1514 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1515 | headers | | | | | 1516 +---------+----+-----------------+-----------------+-----------------+ 1517 | Re-added| -- | -- | -- | -- | 1518 | headers | | | | | 1519 +---------+----+-----------------+-----------------+-----------------+ 1520 | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- | 1521 | headers | | | | | 1522 +---------+----+-----------------+-----------------+-----------------+ 1523 |Untouched| -- | -- | -- | -- | 1524 | headers | | | | | 1525 +---------+----+-----------------+-----------------+-----------------+ 1527 Figure 16: Non Storing mode: Summary of the use of headers from not- 1528 RPL-aware-leaf to root 1530 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1532 This section will describe the communication flow in Non Storing Mode 1533 (Non-SM) between: 1535 RPL-aware-leaf to Internet 1537 Internet to RPL-aware-leaf 1539 not-RPL-aware-leaf to Internet 1541 Internet to not-RPL-aware-leaf 1543 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1545 In this case the flow comprises: 1547 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1549 For example, a communication flow could be: Node F --> Node D --> 1550 Node B --> Node A --> Internet 1551 6LR_i is the intermediate router from source to destination. In this 1552 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1553 goes through from source (6LN) to 6LBR. 1555 This case is identical to storing-mode case. 1557 The IPv6 flow label should be set to zero to aid in compression, and 1558 the 6LBR will set it to a non-zero value when sending towards the 1559 Internet. 1561 The Table 9 summarizes what headers are needed for this use case. 1563 +-------------------+---------+-------+------+----------------+ 1564 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 1565 +-------------------+---------+-------+------+----------------+ 1566 | Inserted headers | RPI | -- | -- | -- | 1567 | Removed headers | -- | -- | -- | -- | 1568 | Re-added headers | -- | -- | -- | -- | 1569 | Modified headers | -- | RPI | -- | -- | 1570 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1571 +-------------------+---------+-------+------+----------------+ 1573 Table 9: Non Storing mode: Summary of the use of headers from RPL- 1574 aware-leaf to Internet 1576 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1578 In this case the flow comprises: 1580 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1582 For example, a communication flow could be: Internet --> Node A 1583 (root) --> Node B --> Node D --> Node F 1585 6LR_i is the intermediate router from source to destination. In this 1586 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1587 goes through from 6LBR to destination(6LN). 1589 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1590 address of the target node, it can address the IPv6-in-IPv6 header to 1591 that node. The 6LBR will zero the flow label upon entry in order to 1592 aid compression. 1594 The Table 10 summarizes what headers are needed for this use case. 1596 +-----------+----------+--------------+--------------+--------------+ 1597 | Header | Internet | 6LBR | 6LR_i | 6LN src | 1598 | | dst | | | | 1599 +-----------+----------+--------------+--------------+--------------+ 1600 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1601 | headers | | (RH3,RPI) | | | 1602 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1603 | headers | | | | (RH3,RPI) | 1604 | Re-added | -- | -- | -- | -- | 1605 | headers | | | | | 1606 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1607 | headers | | | (RH3,RPI) | | 1608 | Untouched | -- | -- | -- | -- | 1609 | headers | | | | | 1610 +-----------+----------+--------------+--------------+--------------+ 1612 Table 10: Non Storing mode: Summary of the use of headers from 1613 Internet to RPL-aware-leaf 1615 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1617 In this case the flow comprises: 1619 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1620 Internet 1622 For example, a communication flow could be: Node G --> Node E --> 1623 Node B --> Node A --> Internet 1625 6LR_i is the intermediate router from source to destination. In this 1626 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1627 goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1629 In this case the flow label is recommended to be zero in the IPv6 1630 node. As RPL headers are added in the IPv6 node packet, the first 1631 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1632 The IPv6-in-IPv6 header will be addressed to the root. This case is 1633 identical to the storing-mode case (see Section 6.2.3). 1635 The Figure 17 shows the table that summarizes what headers are needed 1636 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1638 +---------+----+-------------+--------------+--------------+--------+ 1639 | Header |IPv6| 6LR_1 | 6LR_i | 6LBR |Internet| 1640 | |src | | [i=2,..,n] | | dst | 1641 | |node| | | | | 1642 +---------+----+-------------+--------------+--------------+--------+ 1643 | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- | 1644 | headers | | | | | | 1645 +---------+----+-------------+--------------+--------------+--------+ 1646 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1647 | headers | | | | | | 1648 +---------+----+-------------+--------------+--------------+--------+ 1649 | Re-added| -- | -- | -- | -- | -- | 1650 | headers | | | | | | 1651 +---------+----+-------------+--------------+--------------+--------+ 1652 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1653 | headers | | | | | | 1654 +---------+----+-------------+--------------+--------------+--------+ 1655 |Untouched| -- | -- | -- | -- | -- | 1656 | headers | | | | | | 1657 +---------+----+-------------+--------------+--------------+--------+ 1659 Figure 17: Non Storing mode: Summary of the use of headers from not- 1660 RPL-aware-leaf to Internet 1662 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1664 In this case the flow comprises: 1666 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1668 For example, a communication flow could be: Internet --> Node A 1669 (root) --> Node B --> Node E --> Node G 1671 6LR_i is the intermediate router from source to destination. In this 1672 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1673 goes through from 6LBR to not-RPL-aware-leaf (IPv6). 1675 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1676 6LBR will know the path, and will recognize that the final node is 1677 not an RPL capable node as it will have received the connectivity DAO 1678 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1679 header destination be the last 6LR. The 6LBR will set to zero the 1680 flow label upon entry in order to aid compression. 1682 The Figure 18 shows the table that summarizes what headers are needed 1683 for this use case. 1685 +---------+--------+-------------+--------------+--------------+-----+ 1686 | Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 | 1687 | | src | | | (i=2,...,n) |dst | 1688 | | | | | |node | 1689 +---------+--------+-------------+--------------+--------------+-----+ 1690 | Inserted| -- | IPv6-in-IPv6| -- | -- | -- | 1691 | headers | | (RH3,RPI) | | | | 1692 +---------+--------+-------------+--------------+--------------+-----+ 1693 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1694 | headers | | | | (RH3,RPI)[1] | | 1695 +---------+--------+-------------+--------------+--------------+-----+ 1696 | Re-added| -- | -- | -- | -- | -- | 1697 | headers | | | | | | 1698 +---------+--------+-------------+--------------+--------------+-----+ 1699 | Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1700 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1701 +---------+--------+-------------+--------------+--------------+-----+ 1702 |Untouched| -- | -- | -- | -- | -- | 1703 | headers | | | | | | 1704 +---------+--------+-------------+--------------+--------------+-----+ 1706 Figure 18: Non-Storing mode: Summary of the use of headers from 1707 Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node. 1709 7.3. Non-Storing Mode: Interaction between Leafs 1711 In this section is described the communication flow in Non Storing 1712 Mode (Non-SM) between, 1714 RPL-aware-leaf to RPL-aware-leaf 1716 RPL-aware-leaf to not-RPL-aware-leaf 1718 not-RPL-aware-leaf to RPL-aware-leaf 1720 not-RPL-aware-leaf to not-RPL-aware-leaf 1722 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1724 In this case the flow comprises: 1726 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1728 For example, a communication flow could be: Node F --> Node D --> 1729 Node B --> Node A (root) --> Node B --> Node E --> Node H 1730 6LR_ia is the intermediate router from source to the root In this 1731 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1732 packet goes through from 6LN to the root. 1734 6LR_id is the intermediate router from the root to the destination. 1735 In this case, "1 <= ia <= m", m is the number of the intermediate 1736 routers (6LR). 1738 This case involves only nodes in same RPL Domain. The originating 1739 node will add a RPI header to the original packet, and send the 1740 packet upwards. 1742 The originating node must put the RPI into an IPv6-in-IPv6 header 1743 addressed to the root, so that the 6LBR can remove that header. If 1744 it does not, then additional resources are wasted on the way down to 1745 carry the useless RPI option. 1747 The 6LBR will need to insert an RH3 header, which requires that it 1748 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1749 it was contained in an IPv6-in-IPv6 header addressed to it. 1750 Otherwise, there may be a RPI header buried inside the inner IP 1751 header, which should get ignored. 1753 Networks that use the RPL P2P extension [RFC6997] are essentially 1754 non-storing DODAGs and fall into this scenario or scenario 1755 Section 7.1.2, with the originating node acting as 6LBR. 1757 The Figure 19 shows the table that summarizes what headers are needed 1758 for this use case. 1760 +---------+------------+----------+------------+----------+------------+ 1761 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | 1762 | | src | | | | dst | 1763 +---------+------------+----------+------------+----------+------------+ 1764 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1765 | headers | (RPI1) | |(RH3-> 6LN, | | | 1766 | | | | RPI2) | | | 1767 +---------+------------+----------+------------+----------+------------+ 1768 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1769 | headers | | | (RPI1) | | (RH3, | 1770 | | | | | | RPI2) | 1771 +---------+------------+----------+------------+----------+------------+ 1772 | Re-added| -- | -- | -- | -- | -- | 1773 | headers | | | | | | 1774 +---------+------------+----------+------------+----------+------------+ 1775 | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- | 1776 | headers | | (RPI1) | | (RPI2) | | 1777 +---------+------------+----------+------------+----------+------------+ 1778 |Untouched| -- | -- | -- | -- | -- | 1779 | headers | | | | | | 1780 +---------+------------+----------+------------+----------+------------+ 1782 Figure 19: Non Storing mode: Summary of the use of headers for RPL- 1783 aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6. 1785 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1786 leaf 1788 In this case the flow comprises: 1790 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1792 For example, a communication flow could be: Node F --> Node D --> 1793 Node B --> Node A (root) --> Node B --> Node E --> Node G 1795 6LR_ia is the intermediate router from source to the root In this 1796 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1798 6LR_id is the intermediate router from the root to the destination. 1799 In this case, "1 <= ia <= m", m is the number of the intermediate 1800 routers (6LRs). 1802 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1803 which must be in an IPv6-in-IPv6 header addressed to the root so that 1804 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1805 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. 1807 The Figure 20 shows the table that summarizes what headers are needed 1808 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1810 +-----------+---------+---------+---------+---------+---------+------+ 1811 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | 1812 | | src | | | | | dst | 1813 | | | | | | | node | 1814 +-----------+---------+---------+---------+---------+---------+------+ 1815 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1816 | headers | (RPI1) | | (RH3, | | | | 1817 | | | | RPI2) | | | | 1818 +-----------+---------+---------+---------+---------+---------+------+ 1819 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1820 | headers | | | (RPI1) | | (RH3, | | 1821 | | | | | | RPI2) | | 1822 +-----------+---------+---------+---------+---------+---------+------+ 1823 | Re-added | -- | -- | -- | -- | -- | -- | 1824 | headers | | | | | | | 1825 +-----------+---------+---------+---------+---------+---------+------+ 1826 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1827 | headers | | (RPI1) | | (RH3, | | | 1828 | | | | | RPI2) | | | 1829 +-----------+---------+---------+---------+---------+---------+------+ 1830 | Untouched | -- | -- | -- | -- | -- | -- | 1831 | headers | | | | | | | 1832 +-----------+---------+---------+---------+---------+---------+------+ 1834 Figure 20: Non Storing mode: Summary of the use of headers from RPL- 1835 aware-leaf to not-RPL-aware-leaf. 1837 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1838 leaf 1840 In this case the flow comprises: 1842 not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1843 6LR_id --> 6LN 1845 For example, a communication flow could be: Node G --> Node E --> 1846 Node B --> Node A (root) --> Node B --> Node E --> Node H 1848 6LR_ia is the intermediate router from source to the root. In this 1849 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1851 6LR_id is the intermediate router from the root to the destination. 1852 In this case, "1 <= ia <= m", m is the number of the intermediate 1853 routers (6LR). 1855 This scenario is mostly identical to the previous one. The RPI is 1856 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1857 addressed to the root. The 6LBR will remove this RPI, and add it's 1858 own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). 1860 The Figure 21 shows the table that summarizes what headers are needed 1861 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1863 +-----------+------+---------+---------+---------+---------+---------+ 1864 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | 1865 | | src | | | | | dst | 1866 | | node | | | | | | 1867 +-----------+------+---------+---------+---------+---------+---------+ 1868 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1869 | headers | | (RPI1) | | (RH3, | | | 1870 | | | | | RPI2) | | | 1871 +-----------+------+---------+---------+---------+---------+---------+ 1872 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1873 | headers | | | | (RPI1) | | (RH3, | 1874 | | | | | | | RPI2) | 1875 +-----------+------+---------+---------+---------+---------+---------+ 1876 | Re-added | -- | | -- | -- | -- | -- | 1877 | headers | | | | | | | 1878 +-----------+------+---------+---------+---------+---------+---------+ 1879 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1880 | headers | | | (RPI1) | | (RH3, | | 1881 | | | | | | RPI2) | | 1882 +-----------+------+---------+---------+---------+---------+---------+ 1883 | Untouched | -- | | -- | -- | -- | -- | 1884 | headers | | | | | | | 1885 +-----------+------+---------+---------+---------+---------+---------+ 1887 Figure 21: Non Storing mode: Summary of the use of headers from not- 1888 RPL-aware-leaf to RPL-aware-leaf. 1890 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1891 aware-leaf 1893 In this case the flow comprises: 1895 not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1896 6LR_id --> not-RPL-aware (IPv6 dst) 1898 For example, a communication flow could be: Node G --> Node E --> 1899 Node B --> Node A (root) --> Node C --> Node J 1901 6LR_ia is the intermediate router from source to the root. In this 1902 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1903 6LR_id is the intermediate router from the root to the destination. 1904 In this case, "1 <= ia <= m", m is the number of the intermediate 1905 routers (6LR). 1907 This scenario is the combination of the previous two cases. 1909 The Figure 22 shows the table that summarizes what headers are needed 1910 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1912 +---------+------+-------+-------+---------+-------+---------+------+ 1913 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | 1914 | | src | | | | | | dst | 1915 | | node | | | | | | node | 1916 +---------+------+-------+-------+---------+-------+---------+------+ 1917 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 1918 | headers | | (RPI1)| | (RH3, | | | | 1919 | | | | | RPI2) | | | | 1920 +---------+------+-------+-------+---------+-------+---------+------+ 1921 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1922 | headers | | | | (RPI1) | | (RH3, | | 1923 | | | | | | | RPI2) | | 1924 +---------+------+-------+-------+---------+-------+---------+------+ 1925 | Re-added| -- | -- | -- | -- | -- | -- | -- | 1926 | headers | | | | | | | | 1927 +---------+------+-------+-------+---------+-------+---------+------+ 1928 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 1929 | headers | | | (RPI1)| | (RH3, | | | 1930 | | | | | | RPI2)| | | 1931 +---------+------+-------+-------+---------+-------+---------+------+ 1932 |Untouched| -- | -- | -- | -- | -- | -- | -- | 1933 | headers | | | | | | | | 1934 +---------+------+-------+-------+---------+-------+---------+------+ 1936 Figure 22: Non Storing mode: Summary of the use of headers from not- 1937 RPL-aware-leaf to not-RPL-aware-leaf 1939 8. Operational Considerations of supporting not-RPL-aware-leaves 1941 Roughly half of the situations described in this document involve 1942 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1943 further categories: ones that drop a packet that have RPI or RH3 1944 headers, and ones that continue to process a packet that has RPI and/ 1945 or RH3 headers. 1947 [RFC8200] provides for new rules that suggest that nodes that have 1948 not been configured (explicitly) to examine Hop-by-Hop headers, 1949 should ignore those headers, and continue processing the packet. 1950 Despite this, and despite the switch from 0x63 to 0x23, there may be 1951 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1952 drop packets that continue to have RPL artifacts in them. In 1953 general, such hosts can not be easily supported in RPL LLNs. 1955 There are some specific cases where it is possible to remove the RPL 1956 artifacts prior to forwarding the packet to the leaf host. The 1957 critical thing is that the artifacts have been inserted by the RPL 1958 root inside an IPv6-in-IPv6 header, and that the header has been 1959 addressed to the 6LR immediately prior to the leaf node. In that 1960 case, in the process of removing the IPv6-in-IPv6 header, the 1961 artifacts can also be removed. 1963 The above case occurs whenever traffic originates from the outside 1964 the LLN (the "Internet" cases above), and non-storing mode is used. 1965 In non-storing mode, the RPL root knows the exact topology (as it 1966 must be create the RH3 header), and therefore knows what the 6LR 1967 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 1968 to the leaf node G, or node C is the 6LR prior to the leaf node J. 1970 Traffic originating from the RPL root (such as when the data 1971 collection system is co-located on the RPL root), does not require an 1972 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1973 the root, and the root can insert the RPI and RH3 headers directly 1974 into the packet, as it is formed. Such a packet is slightly smaller, 1975 but only can be sent to nodes (whether RPL aware or not), that will 1976 tolerate the RPL artifacts. 1978 An operator that finds itself with a lot of traffic from the RPL root 1979 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1980 if the leaf is not tolerant of the RPL artifacts. Such an operator 1981 could otherwise omit this unnecessary header if it was certain of the 1982 properties of the leaf. 1984 As storing mode can not know the final path of the traffic, 1985 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1986 be supported. 1988 9. Operational considerations of introducing 0x23 1990 This section describes the operational considerations of introducing 1991 the new RPI value of 0x23. 1993 During bootstrapping the node gets the DIO with the information of 1994 RPL Option Type, indicating the new RPI in the DODAG Configuration 1995 Option Flag. The DODAG root is in charge to configure the current 1996 network to the new value, through DIO messages and when all the nodes 1997 are set with the new value. The DODAG should change to a new DODAG 1998 version. In case of rebooting, the node does not remember the RPL 1999 Option Type. Thus, the DIO is sent with a flag indicating the new 2000 RPI value. 2002 The DODAG Configuration option is contained in a RPL DIO message, 2003 which contains a unique DTSN counter. The leaf nodes respond to this 2004 message with DAO messages containing the same DTSN. This is a normal 2005 part of RPL routing; the RPL root therefore knows when the updated 2006 DODAG Configuration Option has been seen by all nodes. 2008 Before the migration happens, all the RPL-aware nodes should support 2009 both values . The migration procedure it is triggered when the DIO 2010 is sent with the flag indicating the new RPI value. Namely, it 2011 remains at 0x63 until it is sure that the network is capable of 0x23, 2012 then it abruptly change to 0x23. This options allows to send packets 2013 to not-RPL nodes, which should ignore the option and continue 2014 processing the packets. 2016 In case that a node join to a network that only process 0x63, it 2017 would produce a flag day as was mentioned previously. Indicating the 2018 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2019 flag day in a network. It is recommended that a network process both 2020 options to enable interoperability. 2022 10. IANA Considerations 2024 This document updates the registration made in [RFC6553] Destination 2025 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2026 Figure 23. 2028 +-------+-------------------+------------------------+---------- -+ 2029 | Hex | Binary Value | Description | Reference | 2030 + Value +-------------------+ + + 2031 | | act | chg | rest | | | 2032 +-------+-----+-----+-------+------------------------+------------+ 2033 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2034 +-------+-----+-----+-------+------------------------+------------+ 2035 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2036 | | | | | |[RFCXXXX](*)| 2037 +-------+-----+-----+-------+------------------------+------------+ 2039 Figure 23: Option Type in RPL Option.(*)represents this document 2041 DODAG Configuration option is updated as follows (Figure 24): 2043 +------------+-----------------+---------------+ 2044 | Bit number | Description | Reference | 2045 +------------+-----------------+---------------+ 2046 | 3 | RPI 0x23 enable | This document | 2047 +------------+-----------------+---------------+ 2049 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2050 day. 2052 11. Security Considerations 2054 The security considerations covered in [RFC6553] and [RFC6554] apply 2055 when the packets are in the RPL Domain. 2057 The IPv6-in-IPv6 mechanism described in this document is much more 2058 limited than the general mechanism described in [RFC2473]. The 2059 willingness of each node in the LLN to decapsulate packets and 2060 forward them could be exploited by nodes to disguise the origin of an 2061 attack. 2063 While a typical LLN may be a very poor origin for attack traffic (as 2064 the networks tend to be very slow, and the nodes often have very low 2065 duty cycles) given enough nodes, they could still have a significant 2066 impact, particularly if the target of the attack is targeting another 2067 LLN. Additionally, some uses of RPL involve large backbone ISP scale 2068 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2069 equipped with multiple 100Gb/s interfaces. 2071 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2072 LLN as described above will make sure that any attack that is mounted 2073 must originate from compromised nodes within the LLN. The use of 2074 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2075 alert the operator to the existence of the attack, as well as drop 2076 the attack traffic. As the RPL network is typically numbered from a 2077 single prefix, which is itself assigned by RPL, BCP38 filtering 2078 involves a single prefix comparison and should be trivial to 2079 automatically configure. 2081 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2082 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2083 communications between a new Pledge and the Join Registrar/ 2084 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2085 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2086 the RPL root to do careful filtering: it occurs only when the Join 2087 Coordinator is not co-located inside the RPL root. 2089 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2090 only be by a node within the LLN on another node within the LLN. 2091 Such an attack could, of course, be done directly. An attack of this 2092 kind is meaningful only if the source addresses are either fake or if 2093 the point is to amplify return traffic. Such an attack, could also 2094 be done without the use of IPv6-in-IPv6 headers using forged source 2095 addresses. If the attack requires bi-directional communication, then 2096 IPv6-in-IPv6 provides no advantages. 2098 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2099 about creating security issues. In the security section of 2100 [RFC2473], it was suggested that tunnel entry and exit points can be 2101 secured, via "Use IPsec". This recommendation is not practical for 2102 RPL networks. [RFC5406] goes into some detail on what additional 2103 details would be needed in order to "Use IPsec". Use of ESP would 2104 prevent RFC8183 compression (compression must occur before 2105 encryption), and RFC8183 compression is lossy in a way that prevents 2106 use of AH. These are minor issues. The major issue is how to 2107 establish trust enough such that IKEv2 could be used. This would 2108 require a system of certificates to be present in every single node, 2109 including any Internet nodes that might need to communicate with the 2110 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2112 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2113 IPv6 headers would in the general case scale with the square of the 2114 number of nodes. This is a lot of resource for a constrained nodes 2115 on a constrained network. In the end, the IPsec tunnels would be 2116 providing only BCP38-like origin authentication! Just doing BCP38 2117 origin filtering at the entry and exit of the LLN provides a similar 2118 level amount of security without all the scaling and trust problems 2119 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2121 An LLN with hostile nodes within it would not be protected against 2122 impersonation with the LLN by entry/exit filtering. 2124 The RH3 header usage described here can be abused in equivalent ways 2125 (to disguise the origin of traffic and attack other nodes) with an 2126 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2127 attacker's RH3 header will not be seen by the network until it 2128 reaches the end host, which will decapsulate it. An end-host should 2129 be suspicious about a RH3 header which has additional hops which have 2130 not yet been processed, and SHOULD ignore such a second RH3 header. 2132 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2133 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2134 will see the second RH3 header and MAY choose to discard the packet 2135 if the RH3 header has not been completely consumed. A consumed 2136 (inert) RH3 header could be present in a packet that flows from one 2137 LLN, crosses the Internet, and enters another LLN. As per the 2138 discussion in this document, such headers do not need to be removed. 2139 However, there is no case described in this document where an RH3 is 2140 inserted in a non-storing network on traffic that is leaving the LLN, 2141 but this document should not preclude such a future innovation. It 2142 should just be noted that an incoming RH3 must be fully consumed, or 2143 very carefully inspected. 2145 The RPI header, if permitted to enter the LLN, could be used by an 2146 attacker to change the priority of a packet by selecting a different 2147 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2148 It could also be that not all nodes are reachable in an LLN using the 2149 default instanceID, but a change of instanceID would permit an 2150 attacker to bypass such filtering. Like the RH3, a RPI header is to 2151 be inserted by the RPL root on traffic entering the LLN by first 2152 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2153 therefore will not be seen by the network. Upon reaching the 2154 destination node the RPI header has no further meaning and is just 2155 skipped; the presence of a second RPI header will have no meaning to 2156 the end node as the packet has already been identified as being at 2157 it's final destination. 2159 The RH3 and RPI headers could be abused by an attacker inside of the 2160 network to route packets on non-obvious ways, perhaps eluding 2161 observation. This usage is in fact part of [RFC6997] and can not be 2162 restricted at all. This is a feature, not a bug. 2164 [RFC7416] deals with many other threats to LLNs not directly related 2165 to the use of IPv6-in-IPv6 headers, and this document does not change 2166 that analysis. 2168 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2169 attack on another part of the LLN, while disguising the origin of the 2170 attack. The mechanism can even be abused to make it appear that the 2171 attack is coming from outside the LLN, and unless countered, this 2172 could be used to mount a Distributed Denial Of Service attack upon 2173 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2174 such attacks already seen in the real world. 2176 If an attack comes from inside of LLN, it can be alleviated with SAVI 2177 (Source Address Validation Improvement) using [RFC8505] with 2178 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2179 traffic with an address that is not registered, and the registration 2180 process checks for topological correctness. Notice that there is an 2181 L2 authentication in most of the cases. If an attack comes from 2182 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2183 but by construction, the RH3 can typically only address nodes within 2184 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2185 considered an attack (see RFC6554, section 3). 2187 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2188 through the RPL root to perform this attack. To counter, the RPL 2189 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2190 simpler solution), or it SHOULD walk the IP header extension chain 2191 until it can inspect the upper-layer-payload as described in 2192 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2193 on the source addresses of all IP headers that it examines in both 2194 directions. 2196 Note: there are some situations where a prefix will spread across 2197 multiple LLNs via mechanisms such as the one described in 2198 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2199 needs to take this into account, either by exchanging detailed 2200 routing information on each LLN, or by moving the BCP38 filtering 2201 further towards the Internet, so that the details of the multiple 2202 LLNs do not matter. 2204 12. Acknowledgments 2206 This work is done thanks to the grant by the Stand.ICT project. 2208 A special BIG thanks to C. M. Heard for the help with the 2209 Section 3. Much of the redaction in that section is based on his 2210 comments. 2212 Additionally, the authors would like to acknowledge the review, 2213 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2214 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2215 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2217 13. References 2219 13.1. Normative References 2221 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2222 Defeating Denial of Service Attacks which employ IP Source 2223 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2224 May 2000, . 2226 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2227 Requirement Levels", BCP 14, RFC 2119, 2228 DOI 10.17487/RFC2119, March 1997, 2229 . 2231 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2232 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2233 2010, . 2235 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2236 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2237 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2238 Low-Power and Lossy Networks", RFC 6550, 2239 DOI 10.17487/RFC6550, March 2012, 2240 . 2242 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2243 Power and Lossy Networks (RPL) Option for Carrying RPL 2244 Information in Data-Plane Datagrams", RFC 6553, 2245 DOI 10.17487/RFC6553, March 2012, 2246 . 2248 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2249 Routing Header for Source Routes with the Routing Protocol 2250 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2251 DOI 10.17487/RFC6554, March 2012, 2252 . 2254 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2255 of IPv6 Extension Headers", RFC 7045, 2256 DOI 10.17487/RFC7045, December 2013, 2257 . 2259 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2260 "IPv6 over Low-Power Wireless Personal Area Network 2261 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2262 April 2017, . 2264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2266 May 2017, . 2268 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2269 (IPv6) Specification", STD 86, RFC 8200, 2270 DOI 10.17487/RFC8200, July 2017, 2271 . 2273 13.2. Informative References 2275 [DDOS-KREBS] 2276 Goodin, D., "Record-breaking DDoS reportedly delivered by 2277 >145k hacked cameras", September 2016, 2278 . 2281 [I-D.ietf-6lo-ap-nd] 2282 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2283 "Address Protected Neighbor Discovery for Low-power and 2284 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2285 progress), April 2019. 2287 [I-D.ietf-6lo-backbone-router] 2288 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2289 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2290 in progress), February 2019. 2292 [I-D.ietf-6tisch-dtsecurity-secure-join] 2293 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2294 6tisch-dtsecurity-secure-join-01 (work in progress), 2295 February 2017. 2297 [I-D.ietf-anima-autonomic-control-plane] 2298 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2299 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2300 plane-19 (work in progress), March 2019. 2302 [I-D.ietf-anima-bootstrapping-keyinfra] 2303 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2304 S., and K. Watsen, "Bootstrapping Remote Secure Key 2305 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2306 keyinfra-20 (work in progress), May 2019. 2308 [I-D.ietf-intarea-tunnels] 2309 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2310 Architecture", draft-ietf-intarea-tunnels-09 (work in 2311 progress), July 2018. 2313 [I-D.thubert-roll-unaware-leaves] 2314 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2315 unaware-leaves-07 (work in progress), April 2019. 2317 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2318 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2319 December 1998, . 2321 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2322 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2323 December 1998, . 2325 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2326 Control Message Protocol (ICMPv6) for the Internet 2327 Protocol Version 6 (IPv6) Specification", STD 89, 2328 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2329 . 2331 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2332 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2333 February 2009, . 2335 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2336 Bormann, "Neighbor Discovery Optimization for IPv6 over 2337 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2338 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2339 . 2341 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2342 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2343 in Low-Power and Lossy Networks", RFC 6997, 2344 DOI 10.17487/RFC6997, August 2013, 2345 . 2347 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2348 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2349 2014, . 2351 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2352 and M. Richardson, Ed., "A Security Threat Analysis for 2353 the Routing Protocol for Low-Power and Lossy Networks 2354 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2355 . 2357 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2358 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2359 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2360 May 2017, . 2362 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2363 Perkins, "Registration Extensions for IPv6 over Low-Power 2364 Wireless Personal Area Network (6LoWPAN) Neighbor 2365 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2366 . 2368 Authors' Addresses 2370 Maria Ines Robles 2371 Aalto University 2372 Otaniemi 2373 Espoo 02150 2374 Finland 2376 Email: mariainesrobles@gmail.com 2378 Michael C. Richardson 2379 Sandelman Software Works 2380 470 Dawson Avenue 2381 Ottawa, ON K1Z 5V7 2382 CA 2384 Email: mcr+ietf@sandelman.ca 2385 URI: http://www.sandelman.ca/mcr/ 2387 Pascal Thubert 2388 Cisco Systems, Inc 2389 Village d'Entreprises Green Side 400, Avenue de Roumanille 2390 Batiment T3, Biot - Sophia Antipolis 06410 2391 France 2393 Email: pthubert@cisco.com