idnits 2.17.00 (12 Aug 2021) /tmp/idnits26206/draft-ietf-roll-useofrplinfo-30.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 (June 25, 2019) is 1061 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 1722 -- Looks like a reference, but probably isn't: '2' on line 1059 == Outdated reference: draft-ietf-6lo-ap-nd has been published as RFC 8928 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: A later version (-10) 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: December 27, 2019 P. Thubert 7 Cisco 8 June 25, 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-30 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 December 27, 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 . . . . . . . . . . . . 4 65 3. RPL Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 67 4.1. Updates to RFC6553: Indicating the new RPI value. . . . . 7 68 4.2. Updates to RFC6550: Indicating the new RPI in the 69 DODAG Configuration Option Flag. . . . . . . . . . . . . 10 70 4.3. Updates to RFC8138: Indicating the way to decompress with 71 the new RPI value. . . . . . . . . . . . . . . . . . . . 11 72 5. Sample/reference topology . . . . . . . . . . . . . . . . . . 12 73 6. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.1. Storing Mode: Interaction between Leaf and Root . . . . . 18 76 7.1.1. SM: Example of Flow from RAL to root . . . . . . . . 18 77 7.1.2. SM: Example of Flow from root to RAL . . . . . . . . 19 78 7.1.3. SM: Example of Flow from root to RUL . . . . . . . . 20 79 7.1.4. SM: Example of Flow from RUL to root . . . . . . . . 20 80 7.2. SM: Interaction between Leaf and Internet. . . . . . . . 21 81 7.2.1. SM: Example of Flow from RAL to Internet . . . . . . 22 82 7.2.2. SM: Example of Flow from Internet to RAL . . . . . . 22 83 7.2.3. SM: Example of Flow from RUL to Internet . . . . . . 23 84 7.2.4. SM: Example of Flow from Internet to RUL. . . . . . . 24 85 7.3. SM: Interaction between Leaf and Leaf . . . . . . . . . . 25 86 7.3.1. SM: Example of Flow from RAL to RAL . . . . . . . . . 25 87 7.3.2. SM: Example of Flow from RAL to RUL . . . . . . . . . 27 88 7.3.3. SM: Example of Flow from RUL to RAL . . . . . . . . . 27 89 7.3.4. SM: Example of Flow from RUL to RUL . . . . . . . . . 29 90 8. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 30 91 8.1. Non-Storing Mode: Interaction between Leaf and Root . . . 31 92 8.1.1. Non-SM: Example of Flow from RAL to root . . . . . . 32 93 8.1.2. Non-SM: Example of Flow from root to RAL . . . . . . 32 94 8.1.3. Non-SM: Example of Flow from root to RUL . . . . . . 33 95 8.1.4. Non-SM: Example of Flow from RUL to root . . . . . . 34 96 8.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 97 8.2.1. Non-SM: Example of Flow from RAL to Internet . . . . 35 98 8.2.2. Non-SM: Example of Flow from Internet to RAL . . . . 36 99 8.2.3. Non-SM: Example of Flow from RUL to Internet . . . . 37 100 8.2.4. Non-SM: Example of Flow from Internet to RUL . . . . 38 101 8.3. Non-SM: Interaction between Leafs . . . . . . . . . . . . 39 102 8.3.1. Non-SM: Example of Flow from RAL to RAL . . . . . . . 39 103 8.3.2. Non-SM: Example of Flow from RAL to RUL . . . . . . . 41 104 8.3.3. Non-SM: Example of Flow from RUL to RAL . . . . . . . 42 105 8.3.4. Non-SM: Example of Flow from RUL to RUL . . . . . . . 43 106 9. Operational Considerations of supporting 107 not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 44 108 10. Operational considerations of introducing 0x23 . . . . . . . 45 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 111 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 112 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 113 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 114 14.2. Informative References . . . . . . . . . . . . . . . . . 51 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 117 1. Introduction 119 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 120 [RFC6550] is a routing protocol for constrained networks. RFC6553 121 [RFC6553] defines the "RPL option" (RPL Packet Information or RPI), 122 carried within the IPv6 Hop-by-Hop header to quickly identify 123 inconsistencies (loops) in the routing topology. RFC6554 [RFC6554] 124 defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header 125 to deliver datagrams within a RPL routing domain, particularly in 126 non-storing mode. 128 These various items are referred to as RPL artifacts, and they are 129 seen on all of the data-plane traffic that occurs in RPL routed 130 networks; they do not in general appear on the RPL control plane 131 traffic at all which is mostly hop-by-hop traffic (one exception 132 being DAO messages in non-storing mode). 134 It has become clear from attempts to do multi-vendor 135 interoperability, and from a desire to compress as many of the above 136 artifacts as possible that not all implementers agree when artifacts 137 are necessary, or when they can be safely omitted, or removed. 139 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 140 storing use of RPL. The result was 24 data plane use cases. They 141 are exhaustively outlined here in order to be completely unambiguous. 142 During the processing of this document, new rules were published as 143 [RFC8200], and this document was updated to reflect the normative 144 changes in that document. 146 This document updates RFC6553, changing the RPI option value to make 147 RFC8200 routers ignore this option by default. 149 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 150 mechanism for compressing RPL Option information and Routing Header 151 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 152 technique. 154 Since some of the uses cases here described, use IPv6-in-IPv6 155 encapsulation. It MUST take in consideration, when encapsulation is 156 applied, the RFC6040 [RFC6040], which defines how the explicit 157 congestion notification (ECN) field of the IP header should be 158 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 159 Additionally, it is recommended the reading of 160 [I-D.ietf-intarea-tunnels] that explains the relationship of IP 161 tunnels to existing protocol layers and the challenges in supporting 162 IP tunneling. 164 Non-constrained uses of RPL are not in scope of this document, and 165 applicability statements for those uses may provide different advice, 166 E.g. [I-D.ietf-anima-autonomic-control-plane]. 168 1.1. Overview 170 The rest of the document is organized as follows: Section 2 describes 171 the used terminology. Section 3 describes the updates to RFC6553, 172 RFC6550 and RFC 8138. Section 4 provides the reference topology used 173 for the uses cases. Section 5 describes the uses cases included. 174 Section 6 describes the storing mode cases and section 7 the non- 175 storing mode cases. Section 8 describes the operational 176 considerations of supporting not-RPL-aware-leaves. Section 9 depicts 177 operational considerations for the proposed change on RPL Option 178 type, section 10 the IANA considerations and then section 11 179 describes the security aspects. 181 2. Terminology and Requirements Language 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 185 "OPTIONAL" in this document are to be interpreted as described in BCP 186 14 [RFC2119] [RFC8174] when, and only when, they appear in all 187 capitals, as shown here. 189 Terminology defined in [RFC7102] applies to this document: LLN, RPL, 190 RPL Domain and ROLL. 192 RPL-aware-node: A device which implements RPL. Please note that the 193 device can be found inside the LLN or outside LLN. 195 RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a 196 (Destination Oriented Directed Acyclic Graph) DODAG. 198 RPL-unaware-node: A device which does not implement RPL, thus the 199 device is not-RPL-aware. Please note that the device can be found 200 inside the LLN. 202 RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a 203 (Destination Oriented Directed Acyclic Graph) DODAG. 205 6LoWPAN Node (6LN): [RFC6775] defines it as: "A 6LoWPAN node is any 206 host or router participating in a LoWPAN. This term is used when 207 referring to situations in which either a host or router can play the 208 role described.". In this document, a 6LN acts as a leaf. 210 6LoWPAN Router (6LR): [RFC6775] defines it as:" An intermediate 211 router in the LoWPAN that is able to send and receive Router 212 Advertisements (RAs) and Router Solicitations (RSs) as well as 213 forward and route IPv6 packets. 6LoWPAN routers are present only in 214 route-over topologies." 216 6LoWPAN Border Router (6LBR): [RFC6775] defines it as:"A border 217 router located at the junction of separate 6LoWPAN networks or 218 between a 6LoWPAN network and another IP network. There may be one 219 or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the 220 responsible authority for IPv6 prefix propagation for the 6LoWPAN 221 network it is serving. An isolated LoWPAN also contains a 6LBR in 222 the network, which provides the prefix(es) for the isolated network." 224 Flag Day: A transition that involves having a network with different 225 values of RPL Option Type. Thus the network does not work correctly 226 (Lack of interoperation). 228 Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" 229 header refers to adding a header that originates from a node to an 230 adjacent node, using the addresses (usually the GUA or ULA, but could 231 use the link-local addresses) of each node. If the packet must 232 traverse multiple hops, then it must be decapsulated at each hop, and 233 then re-encapsulated again in a similar fashion. 235 Non-storing Mode (Non-SM): RPL mode of operation in which the RPL- 236 aware-nodes send information to the root about its parents. Thus, 237 the root know the topology, then the intermediate 6LRs do not 238 maintain routing state so that source routing is needed. 240 Storing Mode (SM): RPL mode of operation in which RPL-aware-nodes 241 (6LRs) maintain routing state (of the children) so that source 242 routing is not needed. 244 Due to lack of space in some figures (tables) we refers IPv6-in-IPv6 245 as IP6-IP6. 247 3. RPL Overview 249 RPL defines the RPL Control messages (control plane), a new ICMPv6 250 [RFC4443] message with Type 155. DIS (DODAG Information 251 Solicitation), DIO (DODAG Information Object) and DAO (Destination 252 Advertisement Object) messages are all RPL Control messages but with 253 different Code values. A RPL Stack is shown in Figure 1. 255 +--------------+ 256 | Upper Layers | 257 | | 258 +--------------+ 259 | RPL | 260 | | 261 +--------------+ 262 | ICMPv6 | 263 | | 264 +--------------+ 265 | IPv6 | 266 | | 267 +--------------+ 268 | 6LoWPAN | 269 | | 270 +--------------+ 271 | PHY-MAC | 272 | | 273 +--------------+ 275 Figure 1: RPL Stack. 277 RPL supports two modes of Downward traffic: in storing mode (SM), it 278 is fully stateful; in non-storing mode (Non-SM), it is fully source 279 routed. A RPL Instance is either fully storing or fully non-storing, 280 i.e. a RPL Instance with a combination of storing and non-storing 281 nodes is not supported with the current specifications at the time of 282 writing this document. 284 4. Updates to RFC6553, RFC6550 and RFC8138 286 4.1. Updates to RFC6553: Indicating the new RPI value. 288 This modification is required to be able to send, for example, IPv6 289 packets from a RPL-Aware-Leaf to a not-RPL-aware node through 290 Internet (see Section 7.2.1), without requiring IPv6-in-IPv6 291 encapsulation. 293 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 294 the Option Type field of the RPL Option header, the two high order 295 bits must be set to '01' and the third bit is equal to '1'. The 296 first two bits indicate that the IPv6 node must discard the packet if 297 it doesn't recognize the option type, and the third bit indicates 298 that the Option Data may change in route. The remaining bits serve 299 as the option type. 301 +-------+-------------------+----------------+-----------+ 302 | Hex | Binary Value | Description | Reference | 303 + Value +-------------------+ + + 304 | | act | chg | rest | | | 305 +-------+-----+-----+-------+----------------+-----------+ 306 | 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] | 307 +-------+-----+-----+-------+----------------+-----------+ 309 Figure 2: Option Type in RPL Option. 311 This document illustrates that is is not always possible to know for 312 sure at the source that a packet will only travel within the RPL 313 domain or may leave it. 315 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 316 the outer IPv6 header chain could potentially impact core routers in 317 the internet. So at that time, it was decided to encapsulate any 318 packet with a RPL option using IPv6-in-IPv6 in all cases where it was 319 unclear whether the packet would remain within the RPL domain. In 320 the exception case where a packet would still leak, the Option Type 321 would ensure that the first router in the Internet that does not 322 recognize the option would drop the packet and protect the rest of 323 the network. 325 Even with [RFC8138] that compresses the IPv6-in-IPv6 header, this 326 approach yields extra bytes in a packet which means consuming more 327 energy, more bandwidth, incurring higher chances of loss and possibly 328 causing a fragmentation at the 6LoWPAN level. This impacts the daily 329 operation of constrained devices for a case that generally does not 330 happen and would not heavily impact the core anyway. 332 While intention was and remains that the Hop-by-Hop header with a RPL 333 option should be confined within the RPL domain, this specification 334 modifies this behavior in order to reduce the dependency on IPv6-in- 335 IPv6 and protect the constrained devices. Section 4 of [RFC8200] 336 clarifies the behaviour of routers in the Internet as follows: "it is 337 now expected that nodes along a packet's delivery path only examine 338 and process the Hop-by-Hop Options header if explicitly configured to 339 do so". 341 When unclear about the travel of a packet, it becomes preferable for 342 a source not to encapsulate, accepting the fact that the packet may 343 leave the RPL domain on its way to its destination. In that event, 344 the packet should reach its destination and should not be discarded 345 by the first node that does not recognize the RPL option. But with 346 the current value of the Option Type, if a node in the Internet is 347 configured to process the Hop-by-Hop header, and if such node 348 encounters an option with the first two bits set to 01 and conforms 349 to [RFC8200], it will drop the packet. Host systems should do the 350 same, irrespective of the configuration. 352 Thus, this document updates the Option Type field to (Figure 3): the 353 two high order bits MUST be set to '00' and the third bit is equal to 354 '1'. The first two bits indicate that the IPv6 node MUST skip over 355 this option and continue processing the header ([RFC8200] 356 Section 4.2) if it doesn't recognize the option type, and the third 357 bit continues to be set to indicate that the Option Data may change 358 en route. The remaining bits serve as the option type and remain as 359 0x3. This ensures that a packet that leaves the RPL domain of an LLN 360 (or that leaves the LLN entirely) will not be discarded when it 361 contains the [RFC6553] RPL Hop-by-Hop option known as RPI. 363 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 364 capable) receives a packet with an RPL Option, it should ignore the 365 Hop-by-Hop RPL option (skip over this option and continue processing 366 the header). This is relevant, as it was mentioned previously, in 367 the case that there is a flow from RAL to Internet (see 368 Section 7.2.1). 370 This is a significant update to [RFC6553]. 372 +-------+-------------------+-------------+------------+ 373 | Hex | Binary Value | Description | Reference | 374 + Value +-------------------+ + + 375 | | act | chg | rest | | | 376 +-------+-----+-----+-------+-------------+------------+ 377 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 378 +-------+-----+-----+-------+-------------+------------+ 380 Figure 3: Revised Option Type in RPL Option. (*)represents this 381 document 383 Without the signaling described below, this change would otherwise 384 create a lack of interoperation (flag day) for existing networks 385 which are currently using 0x63 as the RPI value. A move to 0x23 will 386 not be understood by those networks. It is suggested that RPL 387 implementations accept both 0x63 and 0x23 when processing the header. 389 When forwarding packets, implementations SHOULD use the same value as 390 it was received (This is required because, RPI type code can not be 391 changed by [RFC8200] - Section 4.2). It allows to the network to be 392 incrementally upgraded, and for the DODAG root to know which parts of 393 the network are upgraded. 395 When originating new packets, implementations SHOULD have an option 396 to determine which value to originate with, this option is controlled 397 by the DIO option described below. 399 A network which is switching from straight 6LoWPAN compression 400 mechanism to those described in [RFC8138] will experience a flag day 401 in the data compression anyway, and if possible this change can be 402 deployed at the same time. 404 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 405 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 406 therefore no longer a necessity to remove the artifacts when sending 407 traffic to the Internet. This change clarifies when to use an IPv6- 408 in-IPv6 header, and how to address them: The Hop-by-Hop Options 409 Header containing the RPI option MUST always be added when 6LRs 410 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 411 headers MUST always be added when a 6LR find that it needs to insert 412 a Hop-by-Hop Options Header containing the RPI option. The IPv6-in- 413 IPv6 header is to be addressed to the RPL root when on the way up, 414 and to the end-host when on the way down. 416 In the non-storing case, dealing with not-RPL aware leaf nodes is 417 much easier as the 6LBR (DODAG root) has complete knowledge about the 418 connectivity of all DODAG nodes, and all traffic flows through the 419 root node. 421 The 6LBR can recognize not-RPL aware leaf nodes because it will 422 receive a DAO about that node from the 6LR immediately above that 423 not-RPL aware node. This means that the non-storing mode case can 424 avoid ever using hop-by-hop re-encapsulation headers for traffic 425 originating from the root to the leafs. 427 The non-storing mode case does not require the type change from 0x63 428 to 0x23, as the root can always create the right packet. The type 429 change does not adversely affect the non-storing case. 431 4.2. Updates to RFC6550: Indicating the new RPI in the DODAG 432 Configuration Option Flag. 434 In order to avoid a Flag Day caused by lack of interoperation between 435 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 436 in the DIO Configuration Option, to indicate when then new RPI value 437 can be safely used. This means, the flag is going to indicate the 438 type of RPI that the network is using. Thus, when a node join to a 439 network will know which value to use. With this, RPL-capable nodes 440 know if it is safe to use 0x23 when creating a new RPI. A node that 441 forwards a packet with an RPI MUST NOT modify the option type of the 442 RPI. 444 This is done via a DODAG Configuration Option flag which will 445 propagate through the network. If the flag is received with a value 446 zero (which is the default), then new nodes will remain in RFC6553 447 Compatible Mode; originating traffic with the old-RPI (0x63) value. 449 As stated in [RFC6550] the DODAG Configuration option is present in 450 DIO messages. The DODAG Configuration option distributes 451 configuration information. It is generally static, and does not 452 change within the DODAG. This information is configured at the DODAG 453 root and distributed throughout the DODAG with the DODAG 454 Configuration option. Nodes other than the DODAG root do not modify 455 this information when propagating the DODAG Configuration option. 457 The DODAG Configuration Option has a Flag field which is modified by 458 this document. Currently, the DODAG Configuration Option in 459 [RFC6550] states: "the unused bits MUST be initialize to zero by the 460 sender and MUST be ignored by the receiver". 462 Bit number three of the flag field in the DODAG Configuration option 463 is to be used as shown in Figure 4 : 465 +------------+-----------------+---------------+ 466 | Bit number | Description | Reference | 467 +------------+-----------------+---------------+ 468 | 3 | RPI 0x23 enable | This document | 469 +------------+-----------------+---------------+ 471 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 472 day. 474 In case of rebooting, the node (6LN or 6LR) does not remember the RPL 475 Option Type, that is if the flag is set, so DIO messages sent by the 476 node would be set with the flag unset until a DIO message is received 477 with the flag set indicating the new RPI value. The node sets to 478 0x23 if the node supports this feature. 480 4.3. Updates to RFC8138: Indicating the way to decompress with the new 481 RPI value. 483 This modification is required to be able to decompress the RPL RPI 484 option with the new value (0x23). 486 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 487 in section 6. A node that is decompressing this header MUST 488 decompress using the RPL RPI option type that is currently active: 489 that is, a choice between 0x23 (new) and 0x63 (old). The node will 490 know which to use based upon the presence of the flag in the DODAG 491 Configuration Option defined in Section 4.2. E.g. If the network is 492 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 494 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 495 header. 497 There are potential significant advantages to having a single code 498 path that always processes IPv6-in-IPv6 headers with no conditional 499 branches. 501 In Storing Mode, for the examples of Flow from RAL to RUL and RUL to 502 RUL comprise an IPv6-in-IPv6 and RPI compression headers. The use of 503 the IPv6-in-IPv6 header is MANDATORY in this case, and it SHOULD be 504 compressed with [RFC8138] section 7. As exemplification of 505 compressing the RPI, section A.1 of [RFC8138] illustrates the case in 506 Storing mode where the packet is received from the Internet, then the 507 root encapsulates the packet to insert the RPI. The result is shown 508 in Figure 5. 510 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 511 |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP 512 |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld 513 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 515 Figure 5: RPI Inserted by the Root in Storing Mode 517 5. Sample/reference topology 519 A RPL network in general is composed of a 6LBR, Backbone Router 520 (6BBR), 6LR and 6LN as leaf logically organized in a DODAG structure. 522 Figure 6 shows the reference RPL Topology for this document. The 523 letters above the nodes are there so that they may be referenced in 524 subsequent sections. In the figure, 6LR represents a full router 525 node. The 6LN is a RPL aware router, or host (as a leaf). 526 Additionally, for simplification purposes, it is supposed that the 527 6LBR has direct access to Internet, thus the 6BBR is not present in 528 the figure. 530 The 6LN leaves (RAL) marked as (F, H and I) are RPL nodes with no 531 children hosts. 533 The leafs marked as RUL (G and J) are devices which do not speak RPL 534 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 535 DAC and efficient-ND only to participate in the network [RFC6775]. 536 In the document these leafs (G and J) are also referred to as an IPv6 537 node. 539 The 6LBR ("A") in the figure is the root of the Global DODAG. 541 +------------+ 542 | INTERNET ----------+ 543 | | | 544 +------------+ | 545 | 546 | 547 | 548 A | 549 +-------+ 550 |6LBR | 551 +-----------|(root) |-------+ 552 | +-------+ | 553 | | 554 | | 555 | | 556 | | 557 | B |C 558 +---|---+ +---|---+ 559 | 6LR | | 6LR | 560 +---------| |--+ +--- ---+ 561 | +-------+ | | +-------+ | 562 | | | | 563 | | | | 564 | | | | 565 | | | | 566 | D | E | | 567 +-|-----+ +---|---+ | | 568 | 6LR | | 6LR | | | 569 | | +------ | | | 570 +---|---+ | +---|---+ | | 571 | | | | | 572 | | +--+ | | 573 | | | | | 574 | | | | | 575 | | | I | J | 576 F | | G | H | | 577 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 578 | RAL | | RUL | | RAL | | RAL | | RUL | 579 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 580 +-------+ +-------+ +------+ +-------+ +-------+ 582 Figure 6: A reference RPL Topology. 584 6. Use cases 586 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 587 encapsulation are going to be analyzed for a number of representative 588 traffic flows. 590 This document assumes that the LLN is using the no-drop RPI option 591 (0x23). 593 The use cases describe the communication in the following cases: - 594 Between RPL-aware-nodes with the root (6LBR) - Between RPL-aware- 595 nodes with the Internet - Between RUL nodes within the LLN (e.g. see 596 Section 7.1.4) - Inside of the LLN when the final destination address 597 resides outside of the LLN (e.g. see Section 7.2.3). 599 The uses cases are as follows: 601 Interaction between Leaf and Root: 603 RAL to root 605 root to RAL 607 RUL to root 609 root to RUL 611 Interaction between Leaf and Internet: 613 RAL to Internet 615 Internet to RAL 617 RUL to Internet 619 Internet to RUL 621 Interaction between Leafs: 623 RAL to RAL (storing and non-storing) 625 RAL to RUL (non-storing) 627 RUL to RAL (storing and non-storing) 629 RUL to RUL (non-storing) 631 This document is consistent with the rule that a Header cannot be 632 inserted or removed on the fly inside an IPv6 packet that is being 633 routed. This is a fundamental precept of the IPv6 architecture as 634 outlined in [RFC8200]. 636 As the rank information in the RPI artifact is changed at each hop, 637 it will typically be zero when it arrives at the DODAG root. The 638 DODAG root MUST force it to zero when passing the packet out to the 639 Internet. The Internet will therefore not see any SenderRank 640 information. 642 Despite being legal to leave the RPI artifact in place, an 643 intermediate router that needs to add an extension header (e.g. RH3 644 or RPI Option) MUST still encapsulate the packet in an (additional) 645 outer IP header. The new header is placed after this new outer IP 646 header. 648 A corollary is that an RH3 or RPI Option can only be removed by an 649 intermediate router if it is placed in an encapsulating IPv6 Header, 650 which is addressed TO the intermediate router. When it does so, the 651 whole encapsulating header must be removed. (A replacement may be 652 added). This sometimes can result in outer IP headers being 653 addressed to the next hop router using link-local address. 655 Both RPI and RH3 headers may be modified in very specific ways by 656 routers on the path of the packet without the need to add and remove 657 an encapsulating header. Both headers were designed with this 658 modification in mind, and both the RPL RH3 and the RPL option are 659 marked mutable but recoverable: so an IPsec AH security header can be 660 applied across these headers, but it can not secure the values which 661 mutate. 663 RPI MUST be present in every single RPL data packet. 665 Prior to [RFC8138], there was significant interest in removing the 666 RPI for downward flows in non-storing mode. The exception covered a 667 very small number of cases, and causes significant interoperability 668 challenges, yet costed significant code and testing complexity. The 669 ability to compress the RPI down to three bytes or less removes much 670 of the pressure to optimize this any further 671 [I-D.ietf-anima-autonomic-control-plane]. 673 The earlier examples are more extensive to make sure that the process 674 is clear, while later examples are more concise. 676 The uses cases are delineated based on the following requirements: 678 The RPI option has to be in every packet that traverses the LLN. 680 - Because of (1), packets from the Internet have to be 681 encapsulated. 683 - A Header cannot be inserted or removed on the fly inside an IPv6 684 packet that is being routed. 686 - Extension headers may not be added or removed except by the 687 sender or the receiver. 689 - RPI and RH3 headers may be modified by routers on the path of 690 the packet without the need to add and remove an encapsulating 691 header. 693 - An RH3 or RPI Option can only be removed by an intermediate 694 router if it is placed in an encapsulating IPv6 Header, which is 695 addressed to the intermediate router. 697 - Non-storing mode requires downstream encapsulation by root for 698 RH3. 700 The uses cases are delineated based on the following assumptions: 702 This document assumes that the LLN is using the no-drop RPI option 703 (0x23). 705 - Each IPv6 node (including Internet routers) obeys [RFC8200] 706 8200, so that 0x23 RPI can be safely inserted. 708 - All 6LRs obey [RFC8200]. 710 - The RPI is ignored at the IPv6 dst node (RPL-unaware-leaf). 712 - The leaf can be a router 6LR or a host, both indicated as 6LN. 714 - Non-constrained uses of RPL are not in scope of this document. 716 - Compression is based on [RFC8138]. 718 - The flow label [RFC6437] is not needed in RPL. 720 7. Storing mode 722 In storing mode (SM) (fully stateful), the sender can determine if 723 the destination is inside the LLN by looking if the destination 724 address is matched by the DIO's Prefix Information Option (PIO) 725 option. 727 The following table (Figure 7) itemizes which headers are needed in 728 each of the following scenarios. It indicates if the IPv6-in-IPv6 729 header that is added, must be addressed to the final destination (the 730 RAL node that is the target(tgt)), to the "root" or if a hop-by-hop 731 header must be added (indicated by "hop"). In the hop-by-hop basis, 732 the destination address for the next hop is the link-layer address of 733 the next hop. 735 In cases where no IPv6-in-IPv6 header is needed, the column states as 736 "No". If the IPv6-in-IPv6 header is needed is a "must". 738 In all cases the RPI headers are needed, since it identifies 739 inconsistencies (loops) in the routing topology. In all cases the 740 RH3 is not needed because it is not used in storing mode. 742 In each case, 6LR_i are the intermediate routers from source to 743 destination. "1 <= i <= n", n is the number of routers (6LR) that 744 the packet goes through from source (6LN) to destination. 746 The leaf can be a router 6LR or a host, both indicated as 6LN. The 747 root refers to the 6LBR (see Figure 6). 749 +---------------------+--------------+------------+------------------+ 750 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 751 +---------------------+--------------+------------+------------------+ 752 | | RAL to root | No | No | 753 + +--------------+------------+------------------+ 754 | Leaf - Root | root to RAL | No | No | 755 + +--------------+------------+------------------+ 756 | | root to RUL | No | No | 757 + +--------------+------------+------------------+ 758 | | RUL to root | must | root | 759 +---------------------+--------------+------------+------------------+ 760 | | RAL to Int | No | No | 761 + +--------------+------------+------------------+ 762 | Leaf - Internet | Int to RAL | must | RAL (tgt) | 763 + +--------------+------------+------------------+ 764 | | RUL to Int | must | root | 765 + +--------------+------------+------------------+ 766 | | Int to RUL | must | hop | 767 +---------------------+--------------+------------+------------------+ 768 | | RAL to RAL | No | No | 769 + +--------------+------------+------------------+ 770 | | RAL to RUL | No | No | 771 + Leaf - Leaf +--------------+------------+------------------+ 772 | | RUL to RAL | must | RAL (tgt) | 773 + +--------------+------------+------------------+ 774 | | RUL to RUL | must | hop | 775 +---------------------+--------------+------------+------------------+ 777 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 779 7.1. Storing Mode: Interaction between Leaf and Root 781 In this section is described the communication flow in storing mode 782 (SM) between, 784 RAL to root 786 root to RAL 788 RUL to root 790 root to RUL 792 7.1.1. SM: Example of Flow from RAL to root 794 In storing mode, RFC 6553 (RPI) is used to send RPL Information 795 instanceID and rank information. 797 In this case the flow comprises: 799 RAL (6LN) --> 6LR_i --> root(6LBR) 801 For example, a communication flow could be: Node F --> Node D --> 802 Node B --> Node A root(6LBR) 804 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 805 (Node E) which decrements the rank in RPI and sends the packet up. 806 When the packet arrives at 6LBR (Node A), the RPI is removed and the 807 packet is processed. 809 No IPv6-in-IPv6 header is required. 811 The RPI header can be removed by the 6LBR because the packet is 812 addressed to the 6LBR. The 6LN must know that it is communicating 813 with the 6LBR to make use of this scenario. The 6LN can know the 814 address of the 6LBR because it knows the address of the root via the 815 DODAGID in the DIO messages. 817 The Table 1 summarizes what headers are needed for this use case. 819 +-------------------+---------+-------+----------+ 820 | Header | 6LN src | 6LR_i | 6LBR dst | 821 +-------------------+---------+-------+----------+ 822 | Inserted headers | RPI | -- | -- | 823 | Removed headers | -- | -- | RPI | 824 | Re-added headers | -- | -- | -- | 825 | Modified headers | -- | RPI | -- | 826 | Untouched headers | -- | -- | -- | 827 +-------------------+---------+-------+----------+ 829 Table 1: SM: Summary of the use of headers from RAL to root 831 7.1.2. SM: Example of Flow from root to RAL 833 In this case the flow comprises: 835 root (6LBR) --> 6LR_i --> RAL (6LN) 837 For example, a communication flow could be: Node A root(6LBR) --> 838 Node B --> Node D --> Node F 840 In this case the 6LBR inserts RPI header and sends the packet down, 841 the 6LR is going to increment the rank in RPI (it examines the 842 instanceID to identify the right forwarding table), the packet is 843 processed in the 6LN and the RPI removed. 845 No IPv6-in-IPv6 header is required. 847 The Table 2 summarizes what headers are needed for this use case. 849 +-------------------+------+-------+------+ 850 | Header | 6LBR | 6LR_i | 6LN | 851 +-------------------+------+-------+------+ 852 | Inserted headers | RPI | -- | -- | 853 | Removed headers | -- | -- | RPI | 854 | Re-added headers | -- | -- | -- | 855 | Modified headers | -- | RPI | -- | 856 | Untouched headers | -- | -- | -- | 857 +-------------------+------+-------+------+ 859 Table 2: SM: Summary of the use of headers from root to RAL 861 7.1.3. SM: Example of Flow from root to RUL 863 In this case the flow comprises: 865 root (6LBR) --> 6LR_i --> RUL (IPv6) 867 For example, a communication flow could be: Node A root(6LBR) --> 868 Node B --> Node E --> Node G 870 As the RPI extension can be ignored by the not-RPL-aware leaf, this 871 situation is identical to the previous scenario. 873 The Table 3 summarizes what headers are needed for this use case. 875 +-------------------+----------+-------+----------------+ 876 | Header | 6LBR src | 6LR_i | IPv6 dst node | 877 +-------------------+----------+-------+----------------+ 878 | Inserted headers | RPI | -- | -- | 879 | Removed headers | -- | -- | -- | 880 | Re-added headers | -- | -- | -- | 881 | Modified headers | -- | RPI | -- | 882 | Untouched headers | -- | -- | RPI (Ignored) | 883 +-------------------+----------+-------+----------------+ 885 Table 3: SM: Summary of the use of headers from root to RUL 887 7.1.4. SM: Example of Flow from RUL to root 889 In this case the flow comprises: 891 RUL (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 892 For example, a communication flow could be: Node G --> Node E --> 893 Node B --> Node A root(6LBR) 895 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 896 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 897 header. The IPv6-in-IPv6 header can be addressed to the next hop 898 (Node B), or to the root (Node A). The root removes the header and 899 processes the packet. 901 The Figure 8 shows the table that summarizes what headers are needed 902 for this use case. [1] refers the case where the IPv6-in-IPv6 header 903 is addressed to the next hop (Node B). [2] refers the case where the 904 IPv6-in-IPv6 header is addressed to the root (Node A). 906 +-----------+------+--------------+-----------------+------------------+ 907 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 908 | | src | | | | 909 | | node | | | | 910 +-----------+------+--------------+-----------------+------------------+ 911 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 912 | headers | | | | | 913 +-----------+------+--------------+-----------------+------------------+ 914 | Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]| 915 | headers | | | | | 916 +-----------+------+--------------+-----------------+------------------+ 917 | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | 918 | headers | | | | | 919 +-----------+------+--------------+-----------------+------------------+ 920 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 921 | headers | | | | | 922 +-----------+------+--------------+-----------------+------------------+ 923 | Untouched | -- | -- | -- | -- | 924 | headers | | | | | 925 +-----------+------+--------------+-----------------+------------------+ 927 Figure 8: SM: Summary of the use of headers from RUL to root. 929 7.2. SM: Interaction between Leaf and Internet. 931 In this section is described the communication flow in storing mode 932 (SM) between, 934 RAL to Internet 936 Internet to RAL 938 RUL to Internet 939 Internet to RUL 941 7.2.1. SM: Example of Flow from RAL to Internet 943 RPL information from RFC 6553 may go out to Internet as it will be 944 ignored by nodes which have not been configured to be RPI aware. 946 In this case the flow comprises: 948 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 950 For example, the communication flow could be: Node F --> Node D --> 951 Node B --> Node A root(6LBR) --> Internet 953 No IPv6-in-IPv6 header is required. 955 Note: In this use case it is used a node as leaf, but this use case 956 can be also applicable to any RPL-aware-node type (e.g. 6LR) 958 The Table 4 summarizes what headers are needed for this use case. 960 +-------------------+---------+-------+------+----------------+ 961 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 962 +-------------------+---------+-------+------+----------------+ 963 | Inserted headers | RPI | -- | -- | -- | 964 | Removed headers | -- | -- | -- | -- | 965 | Re-added headers | -- | -- | -- | -- | 966 | Modified headers | -- | RPI | -- | -- | 967 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 968 +-------------------+---------+-------+------+----------------+ 970 Table 4: SM: Summary of the use of headers from RAL to Internet 972 7.2.2. SM: Example of Flow from Internet to RAL 974 In this case the flow comprises: 976 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 978 For example, a communication flow could be: Internet --> Node A 979 root(6LBR) --> Node B --> Node D --> Node F 981 When the packet arrives from Internet to 6LBR the RPI header is added 982 in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination 983 address set to the 6LR) and sent to 6LR, which modifies the rank in 984 the RPI. When the packet arrives at 6LN the RPI header is removed 985 and the packet processed. 987 The Figure 9 shows the table that summarizes what headers are needed 988 for this use case. 990 +-----------+----------+--------------+--------------+--------------+ 991 | Header | Internet | 6LBR | 6LR_i | 6LN dst | 992 | | src | | | | 993 +-----------+----------+--------------+--------------+--------------+ 994 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 995 | headers | | | | | 996 +-----------+----------+--------------+--------------+--------------+ 997 | Removed | -- | -- | -- | IP6-IP6(RPI) | 998 | headers | | | | | 999 +-----------+----------+--------------+--------------+--------------+ 1000 | Re-added | -- | -- | -- | -- | 1001 | headers | | | | | 1002 +-----------+----------+--------------+--------------+--------------+ 1003 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1004 | headers | | | | | 1005 +-----------+----------+--------------+--------------+--------------+ 1006 | Untouched | -- | -- | -- | -- | 1007 | headers | | | | | 1008 +-----------+----------+--------------+--------------+--------------+ 1010 Figure 9: SM: Summary of the use of headers from Internet to RAL. 1012 7.2.3. SM: Example of Flow from RUL to Internet 1014 In this case the flow comprises: 1016 RUL (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1018 For example, a communication flow could be: Node G --> Node E --> 1019 Node B --> Node A root(6LBR) --> Internet 1021 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 1022 either to the root, or hop-by-hop such that the root can remove the 1023 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 1024 root cause less processing overhead. On the other hand, with hop-by- 1025 hop the intermediate routers can check the routing tables for a 1026 better routing path, thus it could be more efficient and faster. 1027 Implementation should decide which approach to take. 1029 The originating node will ideally leave the IPv6 flow label as zero 1030 so that the packet can be better compressed through the LLN. The 1031 6LBR will set the flow label of the packet to a non-zero value when 1032 sending to the Internet, for details check [RFC6437]. 1034 The Figure 10 shows the table that summarizes what headers are needed 1035 for this use case. 1037 +---------+-------+------------+--------------+-------------+--------+ 1038 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1039 | | src | | [i=2,...,n] | | dst | 1040 | | node | | | | | 1041 +---------+-------+------------+--------------+-------------+--------+ 1042 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1043 | headers | | | [2] | | | 1044 +---------+-------+------------+--------------+-------------+--------+ 1045 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1046 | headers | | | [2] | [1][2] | | 1047 +---------+-------+------------+--------------+-------------+--------+ 1048 | Re-added| -- | -- | -- | -- | -- | 1049 | headers | | | | | | 1050 +---------+-------+------------+--------------+-------------+--------+ 1051 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1052 | headers | | | [1] | | | 1053 +---------+-------+------------+--------------+-------------+--------+ 1054 |Untouched| -- | -- | -- | -- | -- | 1055 | headers | | | | | | 1056 +---------+-------+------------+--------------+-------------+--------+ 1058 Figure 10: SM: Summary of the use of headers from RUL to Internet. 1059 [1] Case when packet is addressed to the root. [2] Case when the 1060 packet is addressed hop-by-hop. 1062 7.2.4. SM: Example of Flow from Internet to RUL. 1064 In this case the flow comprises: 1066 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6) 1068 For example, a communication flow could be: Internet --> Node A 1069 root(6LBR) --> Node B --> Node E --> Node G 1071 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 1072 header. The IPv6-in-IPv6 is addressed hop-by-hop. 1074 The final node should be able to remove one or more IPv6-in-IPv6 1075 headers which are all addressed to it. The final node does not 1076 process the RPI, the node ignores the RPI. Furhter details about 1077 this are mentioned in [I-D.thubert-roll-unaware-leaves], which 1078 specifies RPL routing for a 6LN acting as a plain host and not aware 1079 of RPL. 1081 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1082 zero in order to aid in compression [RFC8138][RFC6437]. 1084 The Figure 11 shows the table that summarizes what headers are needed 1085 for this use case. 1087 +-----------+----------+--------------+--------------+--------------+ 1088 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1089 | | src | | | | 1090 +-----------+----------+--------------+--------------+--------------+ 1091 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1092 | headers | | | | | 1093 +-----------+----------+--------------+--------------+--------------+ 1094 | Removed | -- | -- | | IP6-IP6(RPI)| 1095 | headers | | | | RPI Ignored | 1096 +-----------+----------+--------------+--------------+--------------+ 1097 | Re-added | -- | -- | -- | -- | 1098 | headers | | | | | 1099 +-----------+----------+--------------+--------------+--------------+ 1100 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1101 | headers | | | | | 1102 +-----------+----------+--------------+--------------+--------------+ 1103 | Untouched | -- | -- | -- | -- | 1104 | headers | | | | | 1105 +-----------+----------+--------------+--------------+--------------+ 1107 Figure 11: SM: Summary of the use of headers from Internet to RUL. 1109 7.3. SM: Interaction between Leaf and Leaf 1111 In this section is described the communication flow in storing mode 1112 (SM) between, 1114 RAL to RAL 1116 RAL to RUL 1118 RUL to RAL 1120 RUL to RUL 1122 7.3.1. SM: Example of Flow from RAL to RAL 1124 In [RFC6550] RPL allows a simple one-hop optimization for both 1125 storing and non-storing networks. A node may send a packet destined 1126 to a one-hop neighbor directly to that node. See section 9 in 1127 [RFC6550]. 1129 When the nodes are not directly connected, then in storing mode, the 1130 flow comprises: 1132 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1134 For example, a communication flow could be: Node F --> Node D --> 1135 Node B --> Node E --> Node H 1137 6LR_ia (Node D) are the intermediate routers from source to the 1138 common parent (6LR_x) (Node B) In this case, 1 <= ia <= n, n is the 1139 number of routers (6LR) that the packet goes through from 6LN (Node 1140 F) to the common parent (6LR_x). 1142 6LR_id (Node E) are the intermediate routers from the common parent 1143 (6LR_x) (Node B) to destination 6LN (Node H). In this case, 1 <= id 1144 <= m, m is the number of routers (6LR) that the packet goes through 1145 from the common parent (6LR_x) to destination 6LN. 1147 It is assumed that the two nodes are in the same RPL Domain (that 1148 they share the same DODAG root). At the common parent (Node B), the 1149 direction of RPI is changed (from increasing to decreasing the rank). 1151 While the 6LR nodes will update the RPI, no node needs to add or 1152 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1154 The Table 5 summarizes what headers are needed for this use case. 1156 +---------------+--------+--------+---------------+--------+--------+ 1157 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1158 | | src | | parent) | | dst | 1159 +---------------+--------+--------+---------------+--------+--------+ 1160 | Inserted | RPI | -- | -- | -- | -- | 1161 | headers | | | | | | 1162 | Removed | -- | -- | -- | -- | RPI | 1163 | headers | | | | | | 1164 | Re-added | -- | -- | -- | -- | -- | 1165 | headers | | | | | | 1166 | Modified | -- | RPI | RPI | RPI | -- | 1167 | headers | | | | | | 1168 | Untouched | -- | -- | -- | -- | -- | 1169 | headers | | | | | | 1170 +---------------+--------+--------+---------------+--------+--------+ 1172 Table 5: SM: Summary of the use of headers for RAL to RAL 1174 7.3.2. SM: Example of Flow from RAL to RUL 1176 In this case the flow comprises: 1178 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1179 6LN (IPv6) 1181 For example, a communication flow could be: Node F --> Node D --> 1182 Node B --> Node E --> Node G 1184 6LR_ia are the intermediate routers from source (6LN) to the common 1185 parent (6LR_x) In this case, 1 <= ia <= n, n is the number of routers 1186 (6LR) that the packet goes through from 6LN to the common parent 1187 (6LR_x). 1189 6LR_id (Node E) are the intermediate routers from the common parent 1190 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1191 In this case, 1 <= id <= m, m is the number of routers (6LR) that the 1192 packet goes through from the common parent (6LR_x) to destination 1193 6LN. 1195 This situation is identical to the previous situation Section 7.3.1 1197 The Table 6 summarizes what headers are needed for this use case. 1199 +-----------+------+--------+---------------+--------+--------------+ 1200 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | 1201 | | src | | parent) | | node | 1202 +-----------+------+--------+---------------+--------+--------------+ 1203 | Inserted | RPI | -- | -- | -- | -- | 1204 | headers | | | | | | 1205 | Removed | -- | -- | -- | -- | -- | 1206 | headers | | | | | | 1207 | Re-added | -- | -- | -- | -- | -- | 1208 | headers | | | | | | 1209 | Modified | -- | RPI | RPI | RPI | -- | 1210 | headers | | | | | | 1211 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1212 | headers | | | | | | 1213 +-----------+------+--------+---------------+--------+--------------+ 1215 Table 6: SM: Summary of the use of headers for RAL to RUL 1217 7.3.3. SM: Example of Flow from RUL to RAL 1219 In this case the flow comprises: 1221 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1222 6LR_id --> 6LN 1224 For example, a communication flow could be: Node G --> Node E --> 1225 Node B --> Node D --> Node F 1227 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 1228 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In 1229 this case, 1 <= ia <= n, n is the number of routers (6LR) that the 1230 packet ges through from source to the common parent. 1232 6LR_id (Node D) are the intermediate routers from the common parent 1233 (6LR_x) (Node B) to destination 6LN (Node F). In this case, 1 <= id 1234 <= m, m is the number of routers (6LR) that the packet goes through 1235 from the common parent (6LR_x) to destination 6LN. 1237 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1238 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1239 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1240 (Node F). 1242 The Figure 12 shows the table that summarizes what headers are needed 1243 for this use case. 1245 +---------+-----+------------+-------------+-------------+------------+ 1246 | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | 1247 | |src | | Parent | | dst | 1248 | |node | | (6LRx) | | | 1249 +---------+-----+------------+-------------+-------------+------------+ 1250 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1251 | headers | | | | | | 1252 +---------+-----+------------+-------------+-------------+------------+ 1253 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1254 | headers | | | | | | 1255 +---------+-----+------------+-------------+-------------+------------+ 1256 | Re-added| -- | -- | -- | -- | -- | 1257 | headers | | | | | | 1258 +---------+-----+------------+-------------+-------------+------------+ 1259 | Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- | 1260 | headers | | | | | | 1261 +---------+-----+------------+-------------+-------------+------------+ 1262 |Untouched| -- | -- | -- | -- | -- | 1263 | headers | | | | | | 1264 +---------+-----+------------+-------------+-------------+------------+ 1266 Figure 12: SM: Summary of the use of headers from RUL to RAL. 1268 7.3.4. SM: Example of Flow from RUL to RUL 1270 In this case the flow comprises: 1272 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id 1273 --> not-RPL-aware 6LN (IPv6 dst) 1275 For example, a communication flow could be: Node G --> Node E --> 1276 Node B --> Node A (root) --> Node C --> Node J 1278 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1279 router from the not-RPL-aware source (Node G) to the root (6LBR) 1280 (Node A). In this case, "1 < ia <= n", n is the number of routers 1281 (6LR) that the packet goes through from IPv6 src to the root. 1283 6LR_id (Node C) are the intermediate routers from the root (Node A) 1284 to the destination Node J. In this case, 1 <= id <= m, m is the 1285 number of routers (6LR) that the packet goes through from the root to 1286 destination (IPv6 dst). 1288 The RPI is ignored at the IPv6 dst node. 1290 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1291 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1292 header. The IPv6-in-IPv6 header is addressed hop-by-hop. 1294 The Figure 13 shows the table that summarizes what headers are needed 1295 for this use case. 1297 +---------+------+-------+-------+---------+-------+-------+ 1298 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | 1299 | | src | | | | | dst | 1300 | | node | | | | | node | 1301 +---------+------+-------+-------+---------+-------+-------+ 1302 | Inserted| -- |IP6-IP6| -- | | -- | -- | 1303 | headers | | (RPI )| | | | | 1304 | | | | | | | | 1305 +---------+------+-------+-------+---------+-------+-------+ 1306 | Removed | -- | -- | -- | | -- |IP6-IP6| 1307 | headers | | | | | |(RPI) | 1308 | | | | | | | RPI | 1309 | | | | | | |Ignored| 1310 +---------+------+-------+-------+---------+-------+-------+ 1311 | Re-added| -- | -- | -- | -- | -- | -- | 1312 | headers | | | | | | | 1313 +---------+------+-------+-------+---------+-------+-------+ 1314 | Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | 1315 | headers | | | (RPI) | (RPI) | (RPI) | | 1316 | | | | | | | | 1317 +---------+------+-------+-------+---------+-------+-------+ 1318 |Untouched| -- | -- | -- | -- | -- | -- | 1319 | headers | | | | | | | 1320 +---------+------+-------+-------+---------+-------+-------+ 1322 Figure 13: SM: Summary of the use of headers from RUL to RUL 1324 8. Non Storing mode 1326 In Non Storing Mode (Non-SM) (fully source routed), the 6LBR (DODAG 1327 root) has complete knowledge about the connectivity of all DODAG 1328 nodes, and all traffic flows through the root node. Thus, there is 1329 no need for all nodes to know about the existence of not-RPL aware 1330 nodes. Only the 6LBR needs to act if compensation is necessary for 1331 not-RPL aware receivers. 1333 The following table (Figure 14) summarizes what headers are needed in 1334 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1335 IPv6 header are to be inserted. It depicts the target destination 1336 address possible (indicated by "RAL"), to a 6LR (parent of a 6LN) or 1337 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1338 column states as "No". There is no expectation on RPL that RPI can 1339 be omitted, because it is needed for routing, quality of service and 1340 compression. This specification expects that is always a RPI 1341 Present. 1343 The leaf can be a router 6LR or a host, both indicated as 6LN 1344 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1345 where the RPI header may still be needed for the instanceID to be 1346 available for priority/channel selection at each hop. 1348 +-----------------+--------------+-----+-----+------------+------------+ 1349 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1350 | between | | | | | dst | 1351 +-----------------+--------------+-----+-----+------------+------------+ 1352 | | RAL to root | Yes | No | No | No | 1353 + +--------------+-----+-----+------------+------------+ 1354 | Leaf - Root | root to RAL | Yes | Yes | No | No | 1355 + +--------------+-----+-----+------------+------------+ 1356 | | root to RUL | Yes | Yes | must | 6LR | 1357 | | | (1) | | | | 1358 + +--------------+-----+-----+------------+------------+ 1359 | | RUL to root | Yes | No | must | root | 1360 +-----------------+--------------+-----+-----+------------+------------+ 1361 | | RAL to Int | Yes | No | No | No | 1362 + +--------------+-----+-----+------------+------------+ 1363 | Leaf - Internet | Int to RAL | Yes | Yes | must | RAL | 1364 + +--------------+-----+-----+------------+------------+ 1365 | | RUL to Int | Yes | No | must | root | 1366 + +--------------+-----+-----+------------+------------+ 1367 | | Int to RUL | Yes | Yes | must | 6LR | 1368 +-----------------+--------------+-----+-----+------------+------------+ 1369 | | RAL to RAL | Yes | Yes | must | root/RAL | 1370 + +--------------+-----+-----+------------+------------+ 1371 | | RAL to RUL | Yes | Yes | must | root/6LR | 1372 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1373 | | RUL to RAL | Yes | Yes | must | root/RAL | 1374 + +--------------+-----+-----+------------+------------+ 1375 | | RUL to RUL | Yes | Yes | must | root/6LR | 1376 +-----------------+--------------+-----+-----+------------+------------+ 1378 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1379 RH3, IPv6-in-IPv6 encapsulation. 1381 8.1. Non-Storing Mode: Interaction between Leaf and Root 1383 In this section is described the communication flow in Non Storing 1384 Mode (Non-SM) between, 1386 RAL to root 1388 root to RAL 1390 RUL to root 1392 root to RUL 1394 8.1.1. Non-SM: Example of Flow from RAL to root 1396 In non-storing mode the leaf node uses default routing to send 1397 traffic to the root. The RPI header must be included since it 1398 contains the rank information, which is used to avoid/detect loops. 1400 RAL (6LN) --> 6LR_i --> root(6LBR) 1402 For example, a communication flow could be: Node F --> Node D --> 1403 Node B --> Node A (root) 1405 6LR_i are the intermediate routers from source to destination. In 1406 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1407 packet goes through from source (6LN) to destination (6LBR). 1409 This situation is the same case as storing mode. 1411 The Table 7 summarizes what headers are needed for this use case. 1413 +-------------------+---------+-------+----------+ 1414 | Header | 6LN src | 6LR_i | 6LBR dst | 1415 +-------------------+---------+-------+----------+ 1416 | Inserted headers | RPI | -- | -- | 1417 | Removed headers | -- | -- | RPI | 1418 | Re-added headers | -- | -- | -- | 1419 | Modified headers | -- | RPI | -- | 1420 | Untouched headers | -- | -- | -- | 1421 +-------------------+---------+-------+----------+ 1423 Table 7: Non-SM: Summary of the use of headers from RAL to root 1425 8.1.2. Non-SM: Example of Flow from root to RAL 1427 In this case the flow comprises: 1429 root (6LBR) --> 6LR_i --> RAL (6LN) 1431 For example, a communication flow could be: Node A (root) --> Node B 1432 --> Node D --> Node F 1434 6LR_i are the intermediate routers from source to destination. In 1435 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1436 packet goes through from source (6LBR) to destination (6LN). 1438 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1439 necessary as the traffic originates with an RPL aware node, the 6LBR. 1440 The destination is known to be RPL-aware because the root knows the 1441 whole topology in non-storing mode. 1443 The Table 8 summarizes what headers are needed for this use case. 1445 +-------------------+----------+-----------+-----------+ 1446 | Header | 6LBR src | 6LR_i | 6LN dst | 1447 +-------------------+----------+-----------+-----------+ 1448 | Inserted headers | RPI, RH3 | -- | -- | 1449 | Removed headers | -- | -- | RH3, RPI | 1450 | Re-added headers | -- | -- | -- | 1451 | Modified headers | -- | RPI, RH3 | -- | 1452 | Untouched headers | -- | -- | -- | 1453 +-------------------+----------+-----------+-----------+ 1455 Table 8: Non-SM: Summary of the use of headers from root to RAL 1457 8.1.3. Non-SM: Example of Flow from root to RUL 1459 In this case the flow comprises: 1461 root (6LBR) --> 6LR_i --> RUL (IPv6) 1463 For example, a communication flow could be: Node A (root) --> Node B 1464 --> Node E --> Node G 1466 6LR_i are the intermediate routers from source to destination. In 1467 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1468 packet goes through from source (6LBR) to destination (IPv6). 1470 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1471 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1472 but left there. As the RPI is added, then the IPv6 node which does 1473 not understand the RPI, will ignore it (following RFC8200), thus 1474 encapsulation is not necessary. 1476 The Figure 15 depicts the table that summarizes what headers are 1477 needed for this use case. 1479 +-----------+----------+--------------+----------------+----------+ 1480 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1481 | | | i=(1,..,n-1) | | dst | 1482 | | | | | node | 1483 +-----------+----------+--------------+----------------+----------+ 1484 | Inserted | RPI, RH3 | -- | -- | -- | 1485 | headers | | | | | 1486 +-----------+----------+--------------+----------------+----------+ 1487 | Removed | -- | -- | | -- | 1488 | headers | | | | | 1489 +-----------+----------+--------------+----------------+----------+ 1490 | Re-added | -- | -- | -- | -- | 1491 | headers | | | | | 1492 +-----------+----------+--------------+----------------+----------+ 1493 | Modified | -- | RPI, RH3 | RPI, | -- | 1494 | headers | | | RH3(consumed) | | 1495 +-----------+----------+--------------+----------------+----------+ 1496 | Untouched | -- | -- | -- | RPI, RH3 | 1497 | headers | | | | (both | 1498 | | | | | ignored) | 1499 +-----------+----------+--------------+----------------+----------+ 1501 Figure 15: Non-SM: Summary of the use of headers from root to RUL 1503 8.1.4. Non-SM: Example of Flow from RUL to root 1505 In this case the flow comprises: 1507 RUL (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1509 For example, a communication flow could be: Node G --> Node E --> 1510 Node B --> Node A (root) 1512 6LR_i are the intermediate routers from source to destination. In 1513 this case, "1 < i <= n", n is the number of routers (6LR) that the 1514 packet goes through from source (IPv6) to destination (6LBR). For 1515 example, 6LR_1 (i=1) is the router that receives the packets from the 1516 IPv6 node. 1518 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1519 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1520 following 6LRs. The RPI and entire packet is consumed by the root. 1522 The Figure 16 shows the table that summarizes what headers are needed 1523 for this use case. 1525 +---------+----+-----------------+-----------------+-----------------+ 1526 | Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst | 1527 | |src | | | | 1528 | |node| | | | 1529 +---------+----+-----------------+-----------------+-----------------+ 1530 | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- | 1531 | headers | | | | | 1532 +---------+----+-----------------+-----------------+-----------------+ 1533 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1534 | headers | | | | | 1535 +---------+----+-----------------+-----------------+-----------------+ 1536 | Re-added| -- | -- | -- | -- | 1537 | headers | | | | | 1538 +---------+----+-----------------+-----------------+-----------------+ 1539 | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- | 1540 | headers | | | | | 1541 +---------+----+-----------------+-----------------+-----------------+ 1542 |Untouched| -- | -- | -- | -- | 1543 | headers | | | | | 1544 +---------+----+-----------------+-----------------+-----------------+ 1546 Figure 16: Non-SM: Summary of the use of headers from RUL to root 1548 8.2. Non-Storing Mode: Interaction between Leaf and Internet 1550 This section will describe the communication flow in Non Storing Mode 1551 (Non-SM) between: 1553 RAL to Internet 1555 Internet to RAL 1557 RUL to Internet 1559 Internet to RUL 1561 8.2.1. Non-SM: Example of Flow from RAL to Internet 1563 In this case the flow comprises: 1565 RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet 1567 For example, a communication flow could be: Node F --> Node D --> 1568 Node B --> Node A --> Internet 1570 6LR_i are the intermediate routers from source to destination. In 1571 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1572 packet goes through from source (6LN) to 6LBR. 1574 This case is identical to storing-mode case. 1576 The IPv6 flow label should be set to zero to aid in compression 1577 [RFC8138], and the 6LBR will set it to a non-zero value when sending 1578 towards the Internet [RFC6437]. 1580 The Table 9 summarizes what headers are needed for this use case. 1582 +-------------------+---------+-------+------+----------------+ 1583 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 1584 +-------------------+---------+-------+------+----------------+ 1585 | Inserted headers | RPI | -- | -- | -- | 1586 | Removed headers | -- | -- | -- | -- | 1587 | Re-added headers | -- | -- | -- | -- | 1588 | Modified headers | -- | RPI | -- | -- | 1589 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1590 +-------------------+---------+-------+------+----------------+ 1592 Table 9: Non-SM: Summary of the use of headers from RAL to Internet 1594 8.2.2. Non-SM: Example of Flow from Internet to RAL 1596 In this case the flow comprises: 1598 Internet --> root (6LBR) --> 6LR_i --> RAL (6LN) 1600 For example, a communication flow could be: Internet --> Node A 1601 (root) --> Node B --> Node D --> Node F 1603 6LR_i are the intermediate routers from source to destination. In 1604 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1605 packet goes through from 6LBR to destination(6LN). 1607 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1608 address of the target node, it can address the IPv6-in-IPv6 header to 1609 that node. The 6LBR will zero the flow label upon entry in order to 1610 aid compression [RFC8138]. 1612 The Table 10 summarizes what headers are needed for this use case. 1614 +-----------+----------+--------------+--------------+--------------+ 1615 | Header | Internet | 6LBR | 6LR_i | 6LN src | 1616 | | dst | | | | 1617 +-----------+----------+--------------+--------------+--------------+ 1618 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1619 | headers | | (RH3,RPI) | | | 1620 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1621 | headers | | | | (RH3,RPI) | 1622 | Re-added | -- | -- | -- | -- | 1623 | headers | | | | | 1624 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1625 | headers | | | (RH3,RPI) | | 1626 | Untouched | -- | -- | -- | -- | 1627 | headers | | | | | 1628 +-----------+----------+--------------+--------------+--------------+ 1630 Table 10: Non-SM: Summary of the use of headers from Internet to RAL 1632 8.2.3. Non-SM: Example of Flow from RUL to Internet 1634 In this case the flow comprises: 1636 RUL (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> Internet 1638 For example, a communication flow could be: Node G --> Node E --> 1639 Node B --> Node A --> Internet 1641 6LR_i are the intermediate routers from source to destination. In 1642 this case, "1 < i <= n", n is the number of routers (6LR) that the 1643 packet goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1645 In this case the flow label is recommended to be zero in the IPv6 1646 node. As RPL headers are added in the IPv6 node packet, the first 1647 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1648 The IPv6-in-IPv6 header will be addressed to the root. This case is 1649 identical to the storing-mode case (see Section 7.2.3). 1651 The Figure 17 shows the table that summarizes what headers are needed 1652 for this use case. 1654 +---------+----+-------------+--------------+--------------+--------+ 1655 | Header |IPv6| 6LR_1 | 6LR_i | 6LBR |Internet| 1656 | |src | | [i=2,..,n] | | dst | 1657 | |node| | | | | 1658 +---------+----+-------------+--------------+--------------+--------+ 1659 | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- | 1660 | headers | | | | | | 1661 +---------+----+-------------+--------------+--------------+--------+ 1662 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1663 | headers | | | | | | 1664 +---------+----+-------------+--------------+--------------+--------+ 1665 | Re-added| -- | -- | -- | -- | -- | 1666 | headers | | | | | | 1667 +---------+----+-------------+--------------+--------------+--------+ 1668 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1669 | headers | | | | | | 1670 +---------+----+-------------+--------------+--------------+--------+ 1671 |Untouched| -- | -- | -- | -- | -- | 1672 | headers | | | | | | 1673 +---------+----+-------------+--------------+--------------+--------+ 1675 Figure 17: Non-SM: Summary of the use of headers from RUL to Internet 1677 8.2.4. Non-SM: Example of Flow from Internet to RUL 1679 In this case the flow comprises: 1681 Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6) 1683 For example, a communication flow could be: Internet --> Node A 1684 (root) --> Node B --> Node E --> Node G 1686 6LR_i are the intermediate routers from source to destination. In 1687 this case, "1 < i <= n", n is the number of routers (6LR) that the 1688 packet goes through from 6LBR to RUL (IPv6). 1690 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1691 6LBR will know the path, and will recognize that the final node is 1692 not an RPL capable node as it will have received the connectivity DAO 1693 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1694 header destination be the last 6LR. The 6LBR will set to zero the 1695 flow label upon entry in order to aid compression [RFC8138]. 1697 The Figure 18 shows the table that summarizes what headers are needed 1698 for this use case. 1700 +---------+--------+-------------+--------------+--------------+-----+ 1701 | Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 | 1702 | | src | | | (i=2,...,n) |dst | 1703 | | | | | |node | 1704 +---------+--------+-------------+--------------+--------------+-----+ 1705 | Inserted| -- | IPv6-in-IPv6| -- | -- | -- | 1706 | headers | | (RH3,RPI) | | | | 1707 +---------+--------+-------------+--------------+--------------+-----+ 1708 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1709 | headers | | | | (RH3,RPI)[1] | | 1710 +---------+--------+-------------+--------------+--------------+-----+ 1711 | Re-added| -- | -- | -- | -- | -- | 1712 | headers | | | | | | 1713 +---------+--------+-------------+--------------+--------------+-----+ 1714 | Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1715 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1716 +---------+--------+-------------+--------------+--------------+-----+ 1717 |Untouched| -- | -- | -- | -- | -- | 1718 | headers | | | | | | 1719 +---------+--------+-------------+--------------+--------------+-----+ 1721 Figure 18: Non-SM: Summary of the use of headers from Internet to RUL 1722 [1] The last 6LR before the IPv6 node. 1724 8.3. Non-SM: Interaction between Leafs 1726 In this section is described the communication flow in Non Storing 1727 Mode (Non-SM) between, 1729 RAL to RAL 1731 RAL to RUL 1733 RUL to RAL 1735 RUL to RUL 1737 8.3.1. Non-SM: Example of Flow from RAL to RAL 1739 In this case the flow comprises: 1741 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1743 For example, a communication flow could be: Node F --> Node D --> 1744 Node B --> Node A (root) --> Node B --> Node E --> Node H 1745 6LR_ia are the intermediate routers from source to the root In this 1746 case, 1 <= ia <= n, n is the number of routers (6LR) that the packet 1747 goes through from 6LN to the root. 1749 6LR_id are the intermediate routers from the root to the destination. 1750 In this case, "1 <= ia <= m", m is the number of the intermediate 1751 routers (6LR). 1753 This case involves only nodes in same RPL Domain. The originating 1754 node will add a RPI header to the original packet, and send the 1755 packet upwards. 1757 The originating node must put the RPI into an IPv6-in-IPv6 header 1758 addressed to the root, so that the 6LBR can remove that header. If 1759 it does not, then additional resources are wasted on the way down to 1760 carry the useless RPI option. 1762 The 6LBR will need to insert an RH3 header, which requires that it 1763 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1764 it was contained in an IPv6-in-IPv6 header addressed to it. 1765 Otherwise, there may be a RPI header buried inside the inner IP 1766 header, which should get ignored. 1768 Networks that use the RPL P2P extension [RFC6997] are essentially 1769 non-storing DODAGs and fall into this scenario or scenario 1770 Section 8.1.2, with the originating node acting as 6LBR. 1772 The Figure 19 shows the table that summarizes what headers are needed 1773 for this use case. 1775 +---------+------------+----------+------------+----------+------------+ 1776 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | 1777 | | src | | | | dst | 1778 +---------+------------+----------+------------+----------+------------+ 1779 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1780 | headers | (RPI1) | |(RH3-> 6LN, | | | 1781 | | | | RPI2) | | | 1782 +---------+------------+----------+------------+----------+------------+ 1783 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1784 | headers | | | (RPI1) | | (RH3, | 1785 | | | | | | RPI2) | 1786 +---------+------------+----------+------------+----------+------------+ 1787 | Re-added| -- | -- | -- | -- | -- | 1788 | headers | | | | | | 1789 +---------+------------+----------+------------+----------+------------+ 1790 | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- | 1791 | headers | | (RPI1) | | (RPI2) | | 1792 +---------+------------+----------+------------+----------+------------+ 1793 |Untouched| -- | -- | -- | -- | -- | 1794 | headers | | | | | | 1795 +---------+------------+----------+------------+----------+------------+ 1797 Figure 19: Non-SM: Summary of the use of headers for RAL to RAL. 1798 IP6-in-IP6 refers to IPv6-in-IPv6. 1800 8.3.2. Non-SM: Example of Flow from RAL to RUL 1802 In this case the flow comprises: 1804 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1806 For example, a communication flow could be: Node F --> Node D --> 1807 Node B --> Node A (root) --> Node B --> Node E --> Node G 1809 6LR_ia are the intermediate routers from source to the root In this 1810 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 1812 6LR_id are the intermediate routers from the root to the destination. 1813 In this case, "1 <= ia <= m", m is the number of the intermediate 1814 routers (6LRs). 1816 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1817 which must be in an IPv6-in-IPv6 header addressed to the root so that 1818 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1819 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. 1821 The Figure 20 shows the table that summarizes what headers are needed 1822 for this use case. 1824 +-----------+---------+---------+---------+---------+---------+------+ 1825 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | 1826 | | src | | | | | dst | 1827 | | | | | | | node | 1828 +-----------+---------+---------+---------+---------+---------+------+ 1829 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1830 | headers | (RPI1) | | (RH3, | | | | 1831 | | | | RPI2) | | | | 1832 +-----------+---------+---------+---------+---------+---------+------+ 1833 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1834 | headers | | | (RPI1) | | (RH3, | | 1835 | | | | | | RPI2) | | 1836 +-----------+---------+---------+---------+---------+---------+------+ 1837 | Re-added | -- | -- | -- | -- | -- | -- | 1838 | headers | | | | | | | 1839 +-----------+---------+---------+---------+---------+---------+------+ 1840 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1841 | headers | | (RPI1) | | (RH3, | | | 1842 | | | | | RPI2) | | | 1843 +-----------+---------+---------+---------+---------+---------+------+ 1844 | Untouched | -- | -- | -- | -- | -- | -- | 1845 | headers | | | | | | | 1846 +-----------+---------+---------+---------+---------+---------+------+ 1848 Figure 20: Non-SM: Summary of the use of headers from RAL to RUL. 1850 8.3.3. Non-SM: Example of Flow from RUL to RAL 1852 In this case the flow comprises: 1854 not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1855 6LR_id --> 6LN 1857 For example, a communication flow could be: Node G --> Node E --> 1858 Node B --> Node A (root) --> Node B --> Node E --> Node H 1860 6LR_ia are the intermediate routers from source to the root. In this 1861 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 1863 6LR_id are the intermediate routers from the root to the destination. 1864 In this case, "1 <= ia <= m", m is the number of the intermediate 1865 routers (6LR). 1867 This scenario is mostly identical to the previous one. The RPI is 1868 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1869 addressed to the root. The 6LBR will remove this RPI, and add it's 1870 own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). 1872 The Figure 21 shows the table that summarizes what headers are needed 1873 for this use case. 1875 +-----------+------+---------+---------+---------+---------+---------+ 1876 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | 1877 | | src | | | | | dst | 1878 | | node | | | | | | 1879 +-----------+------+---------+---------+---------+---------+---------+ 1880 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1881 | headers | | (RPI1) | | (RH3, | | | 1882 | | | | | RPI2) | | | 1883 +-----------+------+---------+---------+---------+---------+---------+ 1884 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1885 | headers | | | | (RPI1) | | (RH3, | 1886 | | | | | | | RPI2) | 1887 +-----------+------+---------+---------+---------+---------+---------+ 1888 | Re-added | -- | | -- | -- | -- | -- | 1889 | headers | | | | | | | 1890 +-----------+------+---------+---------+---------+---------+---------+ 1891 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1892 | headers | | | (RPI1) | | (RH3, | | 1893 | | | | | | RPI2) | | 1894 +-----------+------+---------+---------+---------+---------+---------+ 1895 | Untouched | -- | | -- | -- | -- | -- | 1896 | headers | | | | | | | 1897 +-----------+------+---------+---------+---------+---------+---------+ 1899 Figure 21: Non-SM: Summary of the use of headers from RUL to RAL. 1901 8.3.4. Non-SM: Example of Flow from RUL to RUL 1903 In this case the flow comprises: 1905 not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1906 6LR_id --> not-RPL-aware (IPv6 dst) 1908 For example, a communication flow could be: Node G --> Node E --> 1909 Node B --> Node A (root) --> Node C --> Node J 1911 6LR_ia are the intermediate routers from source to the root. In this 1912 case, 1 <= ia <= n, n is the number of intermediate routers (6LR) 1914 6LR_id are the intermediate routers from the root to the destination. 1915 In this case, "1 <= ia <= m", m is the number of the intermediate 1916 routers (6LR). 1918 This scenario is the combination of the previous two cases. 1920 The Figure 22 shows the table that summarizes what headers are needed 1921 for this use case. 1923 +---------+------+-------+-------+---------+-------+---------+------+ 1924 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | 1925 | | src | | | | | | dst | 1926 | | node | | | | | | node | 1927 +---------+------+-------+-------+---------+-------+---------+------+ 1928 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 1929 | headers | | (RPI1)| | (RH3, | | | | 1930 | | | | | RPI2) | | | | 1931 +---------+------+-------+-------+---------+-------+---------+------+ 1932 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1933 | headers | | | | (RPI1) | | (RH3, | | 1934 | | | | | | | RPI2) | | 1935 +---------+------+-------+-------+---------+-------+---------+------+ 1936 | Re-added| -- | -- | -- | -- | -- | -- | -- | 1937 | headers | | | | | | | | 1938 +---------+------+-------+-------+---------+-------+---------+------+ 1939 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 1940 | headers | | | (RPI1)| | (RH3, | | | 1941 | | | | | | RPI2)| | | 1942 +---------+------+-------+-------+---------+-------+---------+------+ 1943 |Untouched| -- | -- | -- | -- | -- | -- | -- | 1944 | headers | | | | | | | | 1945 +---------+------+-------+-------+---------+-------+---------+------+ 1947 Figure 22: Non-SM: Summary of the use of headers from RUL to RUL 1949 9. Operational Considerations of supporting not-RPL-aware-leaves 1951 Roughly half of the situations described in this document involve 1952 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1953 further categories: ones that drop a packet that have RPI or RH3 1954 headers, and ones that continue to process a packet that has RPI and/ 1955 or RH3 headers. 1957 [RFC8200] provides for new rules that suggest that nodes that have 1958 not been configured (explicitly) to examine Hop-by-Hop headers, 1959 should ignore those headers, and continue processing the packet. 1960 Despite this, and despite the switch from 0x63 to 0x23, there may be 1961 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1962 drop packets that continue to have RPL artifacts in them. In 1963 general, such hosts can not be easily supported in RPL LLNs. 1965 There are some specific cases where it is possible to remove the RPL 1966 artifacts prior to forwarding the packet to the leaf host. The 1967 critical thing is that the artifacts have been inserted by the RPL 1968 root inside an IPv6-in-IPv6 header, and that the header has been 1969 addressed to the 6LR immediately prior to the leaf node. In that 1970 case, in the process of removing the IPv6-in-IPv6 header, the 1971 artifacts can also be removed. 1973 The above case occurs whenever traffic originates from the outside 1974 the LLN (the "Internet" cases above), and non-storing mode is used. 1975 In non-storing mode, the RPL root knows the exact topology (as it 1976 must be create the RH3 header), and therefore knows what the 6LR 1977 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 1978 to the leaf node G, or node C is the 6LR prior to the leaf node J. 1980 traffic originating from the RPL root (such as when the data 1981 collection system is co-located on the RPL root), does not require an 1982 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1983 the root, and the root can insert the RPI and RH3 headers directly 1984 into the packet, as it is formed. Such a packet is slightly smaller, 1985 but only can be sent to nodes (whether RPL aware or not), that will 1986 tolerate the RPL artifacts. 1988 An operator that finds itself with a lot of traffic from the RPL root 1989 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1990 if the leaf is not tolerant of the RPL artifacts. Such an operator 1991 could otherwise omit this unnecessary header if it was certain of the 1992 properties of the leaf. 1994 As storing mode can not know the final path of the traffic, 1995 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1996 be supported. 1998 10. Operational considerations of introducing 0x23 2000 This section describes the operational considerations of introducing 2001 the new RPI value of 0x23. 2003 During bootstrapping the node gets the DIO with the information of 2004 RPL Option Type, indicating the new RPI in the DODAG Configuration 2005 Option Flag. The DODAG root is in charge to configure the current 2006 network to the new value, through DIO messages and when all the nodes 2007 are set with the new value. The DODAG should change to a new DODAG 2008 version. In case of rebooting, the node does not remember the RPL 2009 Option Type. Thus, the DIO is sent with a flag indicating the new 2010 RPI value. 2012 The DODAG Configuration option is contained in a RPL DIO message, 2013 which contains a unique DTSN counter. The leaf nodes respond to this 2014 message with DAO messages containing the same DTSN. This is a normal 2015 part of RPL routing; the RPL root therefore knows when the updated 2016 DODAG Configuration Option has been seen by all nodes. 2018 Before the migration happens, all the RPL-aware nodes should support 2019 both values . The migration procedure it is triggered when the DIO 2020 is sent with the flag indicating the new RPI value. Namely, it 2021 remains at 0x63 until it is sure that the network is capable of 0x23, 2022 then it abruptly change to 0x23. This options allows to send packets 2023 to not-RPL nodes, which should ignore the option and continue 2024 processing the packets. 2026 In case that a node join to a network that only process 0x63, it 2027 would produce a flag day as was mentioned previously. Indicating the 2028 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2029 flag day in a network. It is recommended that a network process both 2030 options to enable interoperability. 2032 11. IANA Considerations 2034 This document updates the registration made in [RFC6553] Destination 2035 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2036 Figure 23. 2038 +-------+-------------------+------------------------+---------- -+ 2039 | Hex | Binary Value | Description | Reference | 2040 + Value +-------------------+ + + 2041 | | act | chg | rest | | | 2042 +-------+-----+-----+-------+------------------------+------------+ 2043 | 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)| 2044 +-------+-----+-----+-------+------------------------+------------+ 2045 | 0x63 | 01 | 1 | 00011 | RPL Option(DEPRECATED) | [RFC6553] | 2046 | | | | | |[RFCXXXX](*)| 2047 +-------+-----+-----+-------+------------------------+------------+ 2049 Figure 23: Option Type in RPL Option.(*)represents this document 2051 DODAG Configuration option is updated as follows (Figure 24): 2053 +------------+-----------------+---------------+ 2054 | Bit number | Description | Reference | 2055 +------------+-----------------+---------------+ 2056 | 3 | RPI 0x23 enable | This document | 2057 +------------+-----------------+---------------+ 2059 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2060 day. 2062 12. Security Considerations 2064 The security considerations covered in [RFC6553] and [RFC6554] apply 2065 when the packets are in the RPL Domain. 2067 The IPv6-in-IPv6 mechanism described in this document is much more 2068 limited than the general mechanism described in [RFC2473]. The 2069 willingness of each node in the LLN to decapsulate packets and 2070 forward them could be exploited by nodes to disguise the origin of an 2071 attack. 2073 While a typical LLN may be a very poor origin for attack traffic (as 2074 the networks tend to be very slow, and the nodes often have very low 2075 duty cycles) given enough nodes, they could still have a significant 2076 impact, particularly if attack is targeting another LLN. 2077 Additionally, some uses of RPL involve large backbone ISP scale 2078 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2079 equipped with multiple 100Gb/s interfaces. 2081 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2082 LLN as described above will make sure that any attack that is mounted 2083 must originate from compromised nodes within the LLN. The use of 2084 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2085 alert the operator to the existence of the attack, as well as drop 2086 the attack traffic. As the RPL network is typically numbered from a 2087 single prefix, which is itself assigned by RPL, BCP38 filtering 2088 involves a single prefix comparison and should be trivial to 2089 automatically configure. 2091 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2092 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2093 communications between a new Pledge and the Join Registrar/ 2094 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2095 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2096 the RPL root to do careful filtering: it occurs only when the Join 2097 Coordinator is not co-located inside the RPL root. 2099 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2100 only be by a node within the LLN on another node within the LLN. 2101 Such an attack could, of course, be done directly. An attack of this 2102 kind is meaningful only if the source addresses are either fake or if 2103 the point is to amplify return traffic. Such an attack, could also 2104 be done without the use of IPv6-in-IPv6 headers using forged source 2105 addresses. If the attack requires bi-directional communication, then 2106 IPv6-in-IPv6 provides no advantages. 2108 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2109 about creating security issues. In the security section of 2111 [RFC2473], it was suggested that tunnel entry and exit points can be 2112 secured, via "Use IPsec". This recommendation is not practical for 2113 RPL networks. [RFC5406] goes into some detail on what additional 2114 details would be needed in order to "Use IPsec". Use of ESP would 2115 prevent RFC8183 compression (compression must occur before 2116 encryption), and RFC8183 compression is lossy in a way that prevents 2117 use of AH. These are minor issues. The major issue is how to 2118 establish trust enough such that IKEv2 could be used. This would 2119 require a system of certificates to be present in every single node, 2120 including any Internet nodes that might need to communicate with the 2121 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2123 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2124 IPv6 headers would in the general case scale with the square of the 2125 number of nodes. This is a lot of resource for a constrained nodes 2126 on a constrained network. In the end, the IPsec tunnels would be 2127 providing only BCP38-like origin authentication! That is, IPsec 2128 provides a transitive guarantee to the tunnel exit point that the 2129 tunnel entry point did BCP38 on traffic going in. Just doing BCP38 2130 origin filtering at the entry and exit of the LLN provides a similar 2131 level amount of security without all the scaling and trust problems 2132 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2134 An LLN with hostile nodes within it would not be protected against 2135 impersonation with the LLN by entry/exit filtering. 2137 The RH3 header usage described here can be abused in equivalent ways 2138 (to disguise the origin of traffic and attack other nodes) with an 2139 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2140 attacker's RH3 header will not be seen by the network until it 2141 reaches the end host, which will decapsulate it. An end-host should 2142 be suspicious about a RH3 header which has additional hops which have 2143 not yet been processed, and SHOULD ignore such a second RH3 header. 2145 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2146 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2147 will see the second RH3 header and MAY choose to discard the packet 2148 if the RH3 header has not been completely consumed. A consumed 2149 (inert) RH3 header could be present in a packet that flows from one 2150 LLN, crosses the Internet, and enters another LLN. As per the 2151 discussion in this document, such headers do not need to be removed. 2152 However, there is no case described in this document where an RH3 is 2153 inserted in a non-storing network on traffic that is leaving the LLN, 2154 but this document should not preclude such a future innovation. It 2155 should just be noted that an incoming RH3 must be fully consumed, or 2156 very carefully inspected. 2158 The RPI header, if permitted to enter the LLN, could be used by an 2159 attacker to change the priority of a packet by selecting a different 2160 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2161 It could also be that not all nodes are reachable in an LLN using the 2162 default instanceID, but a change of instanceID would permit an 2163 attacker to bypass such filtering. Like the RH3, a RPI header is to 2164 be inserted by the RPL root on traffic entering the LLN by first 2165 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2166 therefore will not be seen by the network. Upon reaching the 2167 destination node the RPI header has no further meaning and is just 2168 skipped; the presence of a second RPI header will have no meaning to 2169 the end node as the packet has already been identified as being at 2170 it's final destination. 2172 The RH3 and RPI headers could be abused by an attacker inside of the 2173 network to route packets on non-obvious ways, perhaps eluding 2174 observation. This usage is in fact part of [RFC6997] and can not be 2175 restricted at all. This is a feature, not a bug. 2177 [RFC7416] deals with many other threats to LLNs not directly related 2178 to the use of IPv6-in-IPv6 headers, and this document does not change 2179 that analysis. 2181 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2182 attack on another part of the LLN, while disguising the origin of the 2183 attack. The mechanism can even be abused to make it appear that the 2184 attack is coming from outside the LLN, and unless countered, this 2185 could be used to mount a Distributed Denial Of Service attack upon 2186 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2187 such attacks already seen in the real world. 2189 If an attack comes from inside of LLN, it can be alleviated with SAVI 2190 (Source Address Validation Improvement) using [RFC8505] with 2191 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2192 traffic with an address that is not registered, and the registration 2193 process checks for topological correctness. Notice that there is an 2194 L2 authentication in most of the cases. If an attack comes from 2195 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2196 but by construction, the RH3 can typically only address nodes within 2197 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2198 considered an attack (see RFC6554, section 3). 2200 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2201 through the RPL root to perform this attack. To counter, the RPL 2202 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2203 simpler solution), or it SHOULD walk the IP header extension chain 2204 until it can inspect the upper-layer-payload as described in 2205 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2206 on the source addresses of all IP headers that it examines in both 2207 directions. 2209 Note: there are some situations where a prefix will spread across 2210 multiple LLNs via mechanisms such as the one described in 2211 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2212 needs to take this into account, either by exchanging detailed 2213 routing information on each LLN, or by moving the BCP38 filtering 2214 further towards the Internet, so that the details of the multiple 2215 LLNs do not matter. 2217 13. Acknowledgments 2219 This work is done thanks to the grant by the Stand.ICT project. 2221 A special BIG thanks to C. M. Heard for the help with the 2222 Section 4. Much of the redaction in that section is based on his 2223 comments. 2225 Additionally, the authors would like to acknowledge the review, 2226 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2227 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2228 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2230 14. References 2232 14.1. Normative References 2234 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2235 Defeating Denial of Service Attacks which employ IP Source 2236 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2237 May 2000, . 2239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2240 Requirement Levels", BCP 14, RFC 2119, 2241 DOI 10.17487/RFC2119, March 1997, 2242 . 2244 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2245 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2246 2010, . 2248 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2249 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2250 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2251 Low-Power and Lossy Networks", RFC 6550, 2252 DOI 10.17487/RFC6550, March 2012, 2253 . 2255 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2256 Power and Lossy Networks (RPL) Option for Carrying RPL 2257 Information in Data-Plane Datagrams", RFC 6553, 2258 DOI 10.17487/RFC6553, March 2012, 2259 . 2261 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2262 Routing Header for Source Routes with the Routing Protocol 2263 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2264 DOI 10.17487/RFC6554, March 2012, 2265 . 2267 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2268 of IPv6 Extension Headers", RFC 7045, 2269 DOI 10.17487/RFC7045, December 2013, 2270 . 2272 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2273 "IPv6 over Low-Power Wireless Personal Area Network 2274 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2275 April 2017, . 2277 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2278 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2279 May 2017, . 2281 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2282 (IPv6) Specification", STD 86, RFC 8200, 2283 DOI 10.17487/RFC8200, July 2017, 2284 . 2286 14.2. Informative References 2288 [DDOS-KREBS] 2289 Goodin, D., "Record-breaking DDoS reportedly delivered by 2290 >145k hacked cameras", September 2016, 2291 . 2294 [I-D.ietf-6lo-ap-nd] 2295 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2296 "Address Protected Neighbor Discovery for Low-power and 2297 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2298 progress), April 2019. 2300 [I-D.ietf-6lo-backbone-router] 2301 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2302 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2303 in progress), February 2019. 2305 [I-D.ietf-6tisch-dtsecurity-secure-join] 2306 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2307 6tisch-dtsecurity-secure-join-01 (work in progress), 2308 February 2017. 2310 [I-D.ietf-anima-autonomic-control-plane] 2311 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2312 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2313 plane-19 (work in progress), March 2019. 2315 [I-D.ietf-anima-bootstrapping-keyinfra] 2316 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2317 S., and K. Watsen, "Bootstrapping Remote Secure Key 2318 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2319 keyinfra-22 (work in progress), June 2019. 2321 [I-D.ietf-intarea-tunnels] 2322 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2323 Architecture", draft-ietf-intarea-tunnels-09 (work in 2324 progress), July 2018. 2326 [I-D.thubert-roll-unaware-leaves] 2327 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2328 unaware-leaves-07 (work in progress), April 2019. 2330 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2331 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2332 December 1998, . 2334 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2335 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2336 December 1998, . 2338 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2339 Control Message Protocol (ICMPv6) for the Internet 2340 Protocol Version 6 (IPv6) Specification", STD 89, 2341 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2342 . 2344 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2345 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2346 February 2009, . 2348 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 2349 "IPv6 Flow Label Specification", RFC 6437, 2350 DOI 10.17487/RFC6437, November 2011, 2351 . 2353 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2354 Bormann, "Neighbor Discovery Optimization for IPv6 over 2355 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2356 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2357 . 2359 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2360 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2361 in Low-Power and Lossy Networks", RFC 6997, 2362 DOI 10.17487/RFC6997, August 2013, 2363 . 2365 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2366 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2367 2014, . 2369 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2370 and M. Richardson, Ed., "A Security Threat Analysis for 2371 the Routing Protocol for Low-Power and Lossy Networks 2372 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2373 . 2375 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2376 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2377 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2378 May 2017, . 2380 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2381 Perkins, "Registration Extensions for IPv6 over Low-Power 2382 Wireless Personal Area Network (6LoWPAN) Neighbor 2383 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2384 . 2386 Authors' Addresses 2388 Maria Ines Robles 2389 Aalto University 2390 Otaniemi 2391 Espoo 02150 2392 Finland 2394 Email: mariainesrobles@gmail.com 2395 Michael C. Richardson 2396 Sandelman Software Works 2397 470 Dawson Avenue 2398 Ottawa, ON K1Z 5V7 2399 CA 2401 Email: mcr+ietf@sandelman.ca 2402 URI: http://www.sandelman.ca/mcr/ 2404 Pascal Thubert 2405 Cisco Systems, Inc 2406 Village d'Entreprises Green Side 400, Avenue de Roumanille 2407 Batiment T3, Biot - Sophia Antipolis 06410 2408 France 2410 Email: pthubert@cisco.com