idnits 2.17.00 (12 Aug 2021) /tmp/idnits14400/draft-ietf-roll-useofrplinfo-26.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 : ---------------------------------------------------------------------------- ** There are 140 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 293 has weird spacing: '... act chg ...' == Line 362 has weird spacing: '... act chg ...' == Line 2040 has weird spacing: '... act chg ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In order to avoid a Flag Day caused by lack of interoperation between new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag in the DIO Configuration Option, to indicate when then new RPI value can be safely used. This means, the flag is going to indicate the type of RPI that the network is using. Thus, when a node join to a network will know which value to use. With this, RPL-capable nodes know if it is safe to use 0x23 when creating a new RPI. A node that forwards a packet with an RPI MUST not modify the option type of the RPI. -- The document date (May 15, 2019) is 1102 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) == Missing Reference: 'RFCXXXX' is mentioned on line 2043, but not defined -- Looks like a reference, but probably isn't: '1' on line 1716 -- Looks like a reference, but probably isn't: '2' on line 1043 == 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: 1 error (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Robles 3 Internet-Draft Aalto 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: November 16, 2019 P. Thubert 7 Cisco 8 May 15, 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-26 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 RFC 6553 (RPL Option Type), RFC 6554 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 RFC 6553 adding a change to the RPL Option Type. Additionally, this 24 document updates RFC 6550 defining a flag in the DIO Configuration 25 Option to indicate about this change and updates RFC8138 as well to 26 consider the new Option Type when the RPL Option is decompressed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 16, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 5 65 3. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 6 66 3.1. Updates to RFC6553: Indicating the new RPI value. . . . . 6 67 3.2. Updates to RFC6550: Indicating the new RPI in the 68 DODAG Configuration Option Flag. . . . . . . . . . . . . 10 69 3.3. Updates to RFC8138: Indicating the way to decompress with 70 the new RPI value. . . . . . . . . . . . . . . . . . . . 11 71 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 11 72 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 16 74 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 17 75 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 17 76 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 19 77 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 19 78 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 20 79 6.2. Storing Mode: Interaction between Leaf and Internet. . . 21 80 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 21 81 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 22 82 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 83 Internet . . . . . . . . . . . . . . . . . . . . . . 23 84 6.2.4. SM: Example of Flow from Internet to not-RPL-aware- 85 leaf. . . . . . . . . . . . . . . . . . . . . . . . . 24 86 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 25 87 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 88 leaf . . . . . . . . . . . . . . . . . . . . . . . . 25 89 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL- 90 aware-leaf . . . . . . . . . . . . . . . . . . . . . 26 91 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 92 aware-leaf . . . . . . . . . . . . . . . . . . . . . 27 94 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 95 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 29 96 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 30 97 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 31 98 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 32 99 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 32 100 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 101 leaf . . . . . . . . . . . . . . . . . . . . . . . . 33 102 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 103 root . . . . . . . . . . . . . . . . . . . . . . . . 34 104 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 105 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 106 Internet . . . . . . . . . . . . . . . . . . . . . . 35 107 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 108 leaf . . . . . . . . . . . . . . . . . . . . . . . . 36 109 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 110 Internet . . . . . . . . . . . . . . . . . . . . . . 37 111 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 112 aware-leaf . . . . . . . . . . . . . . . . . . . . . 38 113 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 39 114 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 115 aware-leaf . . . . . . . . . . . . . . . . . . . . . 39 116 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 117 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 41 118 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 119 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 42 120 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 121 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 43 122 8. Operational Considerations of supporting 123 not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 44 124 9. Operational considerations of introducing 0x23 . . . . . . . 45 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 127 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 129 13.1. Normative References . . . . . . . . . . . . . . . . . . 50 130 13.2. Informative References . . . . . . . . . . . . . . . . . 51 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 133 1. Introduction 135 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 136 [RFC6550] is a routing protocol for constrained networks. RFC 6553 137 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 138 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 139 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 140 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 141 RPL routing domain, particularly in non-storing mode. 143 These various items are referred to as RPL artifacts, and they are 144 seen on all of the data-plane traffic that occurs in RPL routed 145 networks; they do not in general appear on the RPL control plane 146 traffic at all which is mostly hop-by-hop traffic (one exception 147 being DAO messages in non-storing mode). 149 It has become clear from attempts to do multi-vendor 150 interoperability, and from a desire to compress as many of the above 151 artifacts as possible that not all implementers agree when artifacts 152 are necessary, or when they can be safely omitted, or removed. 154 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 155 storing use of RPL. The result was 24 data plane use cases. They 156 are exhaustively outlined here in order to be completely unambiguous. 157 During the processing of this document, new rules were published as 158 [RFC8200], and this document was updated to reflect the normative 159 changes in that document. 161 This document updates RFC6553, changing the RPI option value to make 162 RFC8200 routers ignore this option by default. 164 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 165 mechanism for compressing RPL Option information and Routing Header 166 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 167 technique. 169 Since some of the uses cases here described, use IPv6-in-IPv6 170 encapsulation. It MUST take in consideration, when encapsulation is 171 applied, the RFC6040 [RFC6040], which defines how the explicit 172 congestion notification (ECN) field of the IP header should be 173 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 174 Additionally, it is recommended the reading of 175 [I-D.ietf-intarea-tunnels]. 177 1.1. Overview 179 The rest of the document is organized as follows: Section 2 describes 180 the used terminology. Section 3 describes the updates to RFC6553, 181 RFC6550 and RFC 8138. Section 4 provides the reference topology used 182 for the uses cases. Section 5 describes the uses cases included. 183 Section 6 describes the storing mode cases and section 7 the non- 184 storing mode cases. Section 8 describes the operational 185 considerations of supporting not-RPL-aware-leaves. Section 9 depicts 186 operational considerations for the proposed change on RPL Option 187 type, section 10 the IANA considerations and then section 11 188 describes the security aspects. 190 2. Terminology and Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 194 "OPTIONAL" in this document are to be interpreted as described in BCP 195 14 [RFC2119], [RFC8174] when, and only when, they appear in all 196 capitals, as shown here. 198 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 199 RPL, RPL Domain and ROLL. 201 RPL-node: A device which implements RPL, thus the device is RPL- 202 aware. Please note that the device can be found inside the LLN or 203 outside LLN. In this document a RPL-node which is a leaf of a 204 (Destination Oriented Directed Acyclic Graph) DODAG is called RPL- 205 aware-leaf (Raf). 207 RPL-not-capable: A device which does not implement RPL, thus the 208 device is not-RPL-aware. Please note that the device can be found 209 inside the LLN. In this document a not-RPL-aware node which is a 210 leaf of a DODAG is called not-RPL-aware-leaf (~Raf). 212 6LN: [RFC6775] defines it as: "A 6LoWPAN node is any host or router 213 participating in a LoWPAN. This term is used when referring to 214 situations in which either a host or router can play the role 215 described.". In this document, a 6LN acts as a leaf. 217 6LR: [RFC6775] defines it as:" An intermediate router in the LoWPAN 218 that is able to send and receive Router Advertisements (RAs) and 219 Router Solicitations (RSs) as well as forward and route IPv6 packets. 220 6LoWPAN routers are present only in route-over topologies." 222 6LBR: [RFC6775] defines it as:"A border router located at the 223 junction of separate 6LoWPAN networks or between a 6LoWPAN network 224 and another IP network. There may be one or more 6LBRs at the 225 6LoWPAN network boundary. A 6LBR is the responsible authority for 226 IPv6 prefix propagation for the 6LoWPAN network it is serving. An 227 isolated LoWPAN also contains a 6LBR in the network, which provides 228 the prefix(es) for the isolated network." 230 Flag Day: A transition that involves having a network with different 231 values of RPL Option Type. Thus the network does not work correctly. 233 Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" 234 header refers to adding a header that originates from a node to an 235 adjacent node, using the addresses (usually the GUA or ULA, but could 236 use the link-local addresses) of each node. If the packet must 237 traverse multiple hops, then it must be decapsulated at each hop, and 238 then re-encapsulated again in a similar fashion. 240 RPL defines the RPL Control messages (control plane), a new ICMPv6 241 [RFC4443] message with Type 155. DIS (DODAG Information 242 Solicitation), DIO (DODAG Information Object) and DAO (Destination 243 Advertisement Object) messages are all RPL Control messages but with 244 different Code values. A RPL Stack is shown in Figure 1. 246 +--------------+ 247 | Upper Layers | 248 | | 249 +--------------+ 250 | RPL | 251 | | 252 +--------------+ 253 | ICMPv6 | 254 | | 255 +--------------+ 256 | IPv6 | 257 | | 258 +--------------+ 259 | 6LoWPAN | 260 | | 261 +--------------+ 262 | PHY-MAC | 263 | | 264 +--------------+ 266 Figure 1: RPL Stack. 268 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 269 it is fully stateful; in non-storing mode (RPL-NSM), it is fully 270 source routed. A RPL Instance is either fully storing or fully non- 271 storing, i.e. a RPL Instance with a combination of storing and non- 272 storing nodes is not supported with the current specifications at the 273 time of writing this document. 275 3. Updates to RFC6553, RFC6550 and RFC8138 277 3.1. Updates to RFC6553: Indicating the new RPI value. 279 This modification is required to be able to send, for example, IPv6 280 packets from a RPL-aware-leaf to a not-RPL-aware node through 281 Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 282 encapsulation. 284 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 285 the Option Type field of the RPL Option header, the two high order 286 bits must be set to '01' and the third bit is equal to '1'. The 287 first two bits indicate that the IPv6 node must discard the packet if 288 it doesn't recognize the option type, and the third bit indicates 289 that the Option Data may change in route. The remaining bits serve 290 as the option type. 292 Hex Value Binary Value 293 act chg rest Description Reference 294 --------- --- --- ------- ----------------- ---------- 295 0x63 01 1 00011 RPL Option [RFC6553] 297 Figure 2: Option Type in RPL Option. 299 This document illustrates that is is not always possible to know for 300 sure at the source that a packet will only travel within the RPL 301 domain or may leave it. 303 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 304 the outer IPv6 header chain could potentially impact core routers in 305 the internet. So at that time, it was decided to encapsulate any 306 packet with a RPL option using IPv6-in-IPv6 in all cases where it was 307 unclear whether the packet would remain within the RPL domain. In 308 the exception case where a packet would still leak, the Option Type 309 would ensure that the first router in the Internet that does not 310 recognize the option would drop the packet and protect the rest of 311 the network. 313 Even with [RFC8138] that compresses the IP-in-IP header, this 314 approach yields extra bytes in a packet which means consuming more 315 energy, more bandwidth, incurring higher chances of loss and possibly 316 causing a fragmentation at the 6LoWPAN level. This impacts the daily 317 operation of constrained devices for a case that generally does not 318 happen and would not heavily impact the core anyway. 320 While intention was and remains that the Hop-by-Hop header with a RPL 321 option should be confined within the RPL domain, this specification 322 modifies this behavior in order to reduce the dependency on IP-in-IP 323 and protect the constrained devices. Section 4 of [RFC8200] 324 clarifies the behaviour of routers in the Internet as follows: "it is 325 now expected that nodes along a packet's delivery path only examine 326 and process the Hop-by-Hop Options header if explicitly configured to 327 do so". This means that while it should be avoided, the impact on 328 the Internet of leaking a Hop-by-Hop header is acceptable. 330 When unclear about the travel of a packet, it becomes preferable for 331 a source not to encapsulate, accepting the fact that the packet may 332 leave the RPL domain on its way to its destination. In that event, 333 the packet should reach its destination and should not be discarded 334 by the first node that does not recognize the RPL option. But with 335 the current value of the Option Type, if a node in the Internet is 336 configured to process the Hop-by-Hop header, and if such node 337 encounters an option with the first two bits set to 01 and conforms 338 to [RFC8200], it will drop the packet. Host systems should do the 339 same, irrespective of the configuration. 341 Thus, this document updates the Option Type field to (Figure 3): the 342 two high order bits MUST be set to '00' and the third bit is equal to 343 '1'. The first two bits indicate that the IPv6 node MUST skip over 344 this option and continue processing the header ([RFC8200] 345 Section 4.2) if it doesn't recognize the option type, and the third 346 bit continues to be set to indicate that the Option Data may change 347 en route. The remaining bits serve as the option type and remain as 348 0x3. This ensures that a packet that leaves the RPL domain of an LLN 349 (or that leaves the LLN entirely) will not be discarded when it 350 contains the [RFC6553] RPL Hop-by-Hop option known as RPI. 352 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 353 capable) receives a packet with an RPL Option, it should ignore the 354 Hop-by-Hop RPL option (skip over this option and continue processing 355 the header). This is relevant, as it was mentioned previously, in 356 the case that there is a flow from RPL-aware-leaf to Internet (see 357 Section 6.2.1). 359 This is a significant update to [RFC6553]. 361 Hex Value Binary Value 362 act chg rest Description Reference 363 --------- --- --- ------- ----------------- ---------- 364 0x23 00 1 00011 RPL Option [RFCXXXX] 366 Figure 3: Revised Option Type in RPL Option. 368 Without the signaling described below, this change would otherwise 369 create a flag day for existing networks which are currently using 370 0x63 as the RPI value. A move to 0x23 will not be understood by 371 those networks. It is suggested that implementations accept both 372 0x63 and 0x23 when processing. 374 When forwarding packets, implementations SHOULD use the same value as 375 it was received (This is required because, RPI type code can not be 376 changed by [RFC8200]). It allows to the network to be incrementally 377 upgraded, and for the DODAG root to know which parts of the network 378 are upgraded. 380 When originating new packets, implementations SHOULD have an option 381 to determine which value to originate with, this option is controlled 382 by the DIO option described below. 384 A network which is switching from straight 6lowpan compression 385 mechanism to those described in [RFC8138] will experience a flag day 386 in the data compression anyway, and if possible this change can be 387 deployed at the same time. 389 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 390 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 391 therefore no longer a necessity to remove the artifacts when sending 392 traffic to the Internet. This change clarifies when to use an IPv6- 393 in-IPv6 header, and how to address them: The Hop-by-Hop Options 394 Header containing the RPI option MUST always be added when 6LRs 395 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 396 headers MUST always be added when a 6LR find that it needs to insert 397 a Hop-by-Hop Options Header containing the RPI option. The IPv6-in- 398 IPv6 header is to be addressed to the RPL root when on the way up, 399 and to the end-host when on the way down. 401 Non-constrained uses of RPL are not in scope of this document, and 402 applicability statements for those uses may provide different advice, 403 E.g. [I-D.ietf-anima-autonomic-control-plane]. 405 In the non-storing case, dealing with not-RPL aware leaf nodes is 406 much easier as the 6LBR (DODAG root) has complete knowledge about the 407 connectivity of all DODAG nodes, and all traffic flows through the 408 root node. 410 The 6LBR can recognize not-RPL aware leaf nodes because it will 411 receive a DAO about that node from the 6LR immediately above that 412 not-RPL aware node. This means that the non-storing mode case can 413 avoid ever using hop-by-hop IPv6-in-IPv6 headers for traffic 414 originating from the root to leafs. 416 The non-storing mode case does not require the type change from 0x63 417 to 0x23, as the root can always create the right packet. The type 418 change does not adversely affect the non-storing case. 420 3.2. Updates to RFC6550: Indicating the new RPI in the DODAG 421 Configuration Option Flag. 423 In order to avoid a Flag Day caused by lack of interoperation between 424 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 425 in the DIO Configuration Option, to indicate when then new RPI value 426 can be safely used. This means, the flag is going to indicate the 427 type of RPI that the network is using. Thus, when a node join to a 428 network will know which value to use. With this, RPL-capable nodes 429 know if it is safe to use 0x23 when creating a new RPI. A node that 430 forwards a packet with an RPI MUST not modify the option type of the 431 RPI. 433 This is done via a DODAG Configuration Option flag which will 434 propagate through the network. If the flag is received with a value 435 zero (which is the default), then new nodes will remain in RFC6553 436 Compatible Mode; originating traffic with the old-RPI (0x63) value. 438 As stated in [RFC6550] the DODAG Configuration option is present in 439 DIO messages. The DODAG Configuration option distributes 440 configuration information. It is generally static, and does not 441 change within the DODAG. This information is configured at the DODAG 442 root and distributed throughout the DODAG with the DODAG 443 Configuration option. Nodes other than the DODAG root do not modify 444 this information when propagating the DODAG Configuration option. 446 The DODAG Configuration Option has a Flag field which is modified by 447 this document. Currently, the DODAG Configuration Option in 448 [RFC6550] states: "the unused bits MUST be initialize to zero by the 449 sender and MUST be ignored by the receiver". 451 Bit number three of the flag field in the DODAG Configuration option 452 is to be used as shown in Figure 4 : 454 +------------+-----------------+---------------+ 455 | Bit number | Description | Reference | 456 +------------+-----------------+---------------+ 457 | 3 | RPI 0x23 enable | This document | 458 +------------+-----------------+---------------+ 460 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 461 day. 463 In case of rebooting, the node (6LN or 6LR) does not remember if the 464 flag is set, so DIO messages would be set with the flag unset until a 465 DIO is received with the flag set. 467 3.3. Updates to RFC8138: Indicating the way to decompress with the new 468 RPI value. 470 This modification is required to be able to decompress the RPL RPI 471 option with the new value (0x23). 473 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 474 in section 6. A node that is decompressing this header MUST 475 decompress using the RPL RPI option type that is currently active: 476 that is, a choice between 0x23 (new) and 0x63 (old). The node will 477 know which to use based upon the presence of the flag in the DODAG 478 Configuration Option defined in Section 3.2. E.g. If the network is 479 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 481 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 482 header. 484 There are potential significant advantages to having a single code 485 path that always processes IPv6-in-IPv6 headers with no conditional 486 branches. 488 In Storing Mode, for the examples of Flow from RPL-aware-leaf to not- 489 RPL-aware-leaf and not-RPL-aware-leaf to not-RPL-aware-leaf comprise 490 an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in- 491 IPv6 header is MANDATORY in this case, and it SHOULD be compressed 492 with [RFC8138] section 7. As exemplification of compressing the RPI, 493 section A.1 of [RFC8138] illustrates the case in Storing mode where 494 the packet is received from the Internet, then the root encapsulates 495 the packet to insert the RPI. The result is shown in Figure 5. 497 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 498 |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP 499 |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld 500 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 502 Figure 5: RPI Inserted by the Root in Storing Mode 504 4. Sample/reference topology 506 A RPL network in general is composed of a 6LBR (6LoWPAN Border 507 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 508 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 510 Figure 6 shows the reference RPL Topology for this document. The 511 letters above the nodes are there so that they may be referenced in 512 subsequent sections. In the figure, 6LR represents a full router 513 node. The 6LN is a RPL aware router, or host (as a leaf). 514 Additionally, for simplification purposes, it is supposed that the 515 6LBR has direct access to Internet, thus the 6BBR is not present in 516 the figure. 518 The 6LN leaves (Raf) marked as (F, H and I) are RPL nodes with no 519 children hosts. 521 The leafs marked as ~Raf (G and J) are devices which do not speak RPL 522 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 523 DAC and efficient-ND only to participate in the network [RFC6775]. 524 In the document these leafs (G and J) are also referred to as an IPv6 525 node. 527 The 6LBR ("A") in the figure is the root of the Global DODAG. 529 +------------+ 530 | INTERNET ----------+ 531 | | | 532 +------------+ | 533 | 534 | 535 | 536 A | 537 +-------+ 538 |6LBR | 539 +-----------|(root) |-------+ 540 | +-------+ | 541 | | 542 | | 543 | | 544 | | 545 | B |C 546 +---|---+ +---|---+ 547 | 6LR | | 6LR | 548 +---------| |--+ +--- ---+ 549 | +-------+ | | +-------+ | 550 | | | | 551 | | | | 552 | | | | 553 | | | | 554 | D | E | | 555 +-|-----+ +---|---+ | | 556 | 6LR | | 6LR | | | 557 | | +------ | | | 558 +---|---+ | +---|---+ | | 559 | | | | | 560 | | +--+ | | 561 | | | | | 562 | | | | | 563 | | | I | J | 564 F | | G | H | | 565 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 566 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 567 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 568 +-------+ +-------+ +------+ +-------+ +-------+ 570 Figure 6: A reference RPL Topology. 572 5. Use cases 574 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 575 encapsulation are going to be analyzed for a number of representative 576 traffic flows. 578 This document assumes that the LLN is using the no-drop RPI option 579 (0x23). 581 The uses cases describe the communication between RPL-aware-nodes, 582 with the root (6LBR), and with Internet. This document also 583 describes the communication between nodes acting as leaves that do 584 not understand RPL (~Raf nodes), but are part of the LLN. (e.g. 585 Section 6.1.4 Flow from not-RPL-aware-leaf to root) This document 586 depicts as well the communication inside of the LLN when it has the 587 final destination addressed outside of the LLN e.g. with destination 588 to Internet. For example, Section 6.2.3 Flow from not-RPL-aware-leaf 589 to Internet 591 The uses cases comprise as follow: 593 Interaction between Leaf and Root: 595 RPL-aware-leaf(Raf) to root 597 root to RPL-aware-leaf(Raf) 599 not-RPL-aware-leaf(~Raf) to root 601 root to not-RPL-aware-leaf(~Raf) 603 Interaction between Leaf and Internet: 605 RPL-aware-leaf(Raf) to Internet 607 Internet to RPL-aware-leaf(Raf) 609 not-RPL-aware-leaf(~Raf) to Internet 611 Internet to not-RPL-aware-leaf(~Raf) 613 Interaction between Leafs: 615 RPL-aware-leaf(Raf) to RPL-aware-leaf(Raf) (storing and non- 616 storing) 618 RPL-aware-leaf(Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 619 not-RPL-aware-leaf(~Raf) to RPL-aware-leaf(Raf) (storing and non- 620 storing) 622 not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 624 This document is consistent with the rule that a Header cannot be 625 inserted or removed on the fly inside an IPv6 packet that is being 626 routed. This is a fundamental precept of the IPv6 architecture as 627 outlined in [RFC8200]. Extensions headers may not be added or 628 removed except by the sender or the receiver. 630 However, unlike [RFC6553], the Hop-by-Hop Option Header used for the 631 RPI artifact has the first two bits set to '00'. This means that the 632 RPI artifact will be ignored when received by a host or router that 633 does not understand that option ( Section 4.2 [RFC8200]). 635 This means that when the no-drop RPI option code 0x23 is used, a 636 packet that leaves the RPL domain of an LLN (or that leaves the LLN 637 entirely) will not be discarded when it contains the [RFC6553] RPL 638 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is 639 left in place even if the end host does not understand it. 641 NOTE: No clear attack has been described when the RPI information is 642 released to the Internet. At a minimum, it is clear that the RPI 643 option would waste some network bandwidth when it escapes. This is 644 traded off against the savings in the LLN by not having to 645 encapsulate the packet in order to remove the artifact. Please check 646 the Security Considerations sections Section 11 for further details. 648 As the rank information in the RPI artifact is changed at each hop, 649 it will typically be zero when it arrives at the DODAG root. The 650 DODAG root MUST force it to zero when passing the packet out to the 651 Internet. The Internet will therefore not see any SenderRank 652 information. 654 Despite being legal to leave the RPI artifact in place, an 655 intermediate router that needs to add an extension header (e.g. RH3 656 or RPI Option) MUST still encapsulate the packet in an (additional) 657 outer IP header. The new header is placed after this new outer IP 658 header. 660 A corollary is that an RH3 or RPI Option can only be removed by an 661 intermediate router if it is placed in an encapsulating IPv6 Header, 662 which is addressed TO the intermediate router. When it does so, the 663 whole encapsulating header must be removed. (A replacement may be 664 added). This sometimes can result in outer IP headers being 665 addressed to the next hop router using link-local address. 667 Both RPI and RH3 headers may be modified in very specific ways by 668 routers on the path of the packet without the need to add and remove 669 an encapsulating header. Both headers were designed with this 670 modification in mind, and both the RPL RH3 and the RPL option are 671 marked mutable but recoverable: so an IPsec AH security header can be 672 applied across these headers, but it can not secure the values which 673 mutate. 675 RPI MUST be present in every single RPL data packet. 677 Prior to [RFC8138], there was significant interest in removing the 678 RPI for downward flows in non-storing mode. The exception covered a 679 very small number of cases, and causes significant interoperability 680 challenges, yet costed significant code and testing complexity. The 681 ability to compress the RPI down to three bytes or less removes much 682 of the pressure to optimize this any further 683 [I-D.ietf-anima-autonomic-control-plane]. 685 The earlier examples are more extensive to make sure that the process 686 is clear, while later examples are more concise. 688 6. Storing mode 690 In storing mode (fully stateful), the sender can determine if the 691 destination is inside the LLN by looking if the destination address 692 is matched by the DIO's Prefix Information Option (PIO) option. 694 The following table (Figure 7) itemizes which headers are needed in 695 each of the following scenarios. It indicates if the IPv6-in-IPv6 696 header that is added, must be addressed to the final destination (the 697 Raf node that is the target(tgt)), to the "root" or if a hop-by-hop 698 header must be added (indicated by "hop"). 700 In cases where no IPv6-in-IPv6 header is needed, the column states as 701 "No". If the IPv6-in-IPv6 header is needed is a "must". 703 In all cases the RPI headers are needed, since it identifies 704 inconsistencies (loops) in the routing topology. In all cases the 705 RH3 is not needed because it is not used in storing mode. 707 In each case, 6LR_i is the intermediate router from source to 708 destination. "1 <= i <= n", n is the number of routers (6LR) that 709 the packet goes through from source (6LN) to destination. 711 The leaf can be a router 6LR or a host, both indicated as 6LN. The 712 root refers to the 6LBR (see Figure 6). 714 +---------------------+--------------+------------+------------------+ 715 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 716 +---------------------+--------------+------------+------------------+ 717 | | Raf to root | No | No | 718 + +--------------+------------+------------------+ 719 | Leaf - Root | root to Raf | No | No | 720 + +--------------+------------+------------------+ 721 | | root to ~Raf | No | No | 722 + +--------------+------------+------------------+ 723 | | ~Raf to root | must | root | 724 +---------------------+--------------+------------+------------------+ 725 | | Raf to Int | No | No | 726 + +--------------+------------+------------------+ 727 | Leaf - Internet | Int to Raf | must | Raf (tgt) | 728 + +--------------+------------+------------------+ 729 | | ~Raf to Int | must | root | 730 + +--------------+------------+------------------+ 731 | | Int to ~Raf | must | hop | 732 +---------------------+--------------+------------+------------------+ 733 | | Raf to Raf | No | No | 734 + +--------------+------------+------------------+ 735 | | Raf to ~Raf | No | No | 736 + Leaf - Leaf +--------------+------------+------------------+ 737 | | ~Raf to Raf | must | Raf (tgt) | 738 + +--------------+------------+------------------+ 739 | | ~Raf to ~Raf | must | ~Raf | 740 +---------------------+--------------+------------+------------------+ 742 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 744 6.1. Storing Mode: Interaction between Leaf and Root 746 In this section is described the communication flow in storing mode 747 (SM) between, 749 RPL-aware-leaf to root 751 root to RPL-aware-leaf 753 not-RPL-aware-leaf to root 755 root to not-RPL-aware-leaf 757 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 759 In storing mode, RFC 6553 (RPI) is used to send RPL Information 760 instanceID and rank information. 762 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 763 generally issue DIO messages; a leaf node accepts DIO messages from 764 upstream. (When the inconsistency in routing occurs, a leaf node 765 will generate a DIO with an infinite rank, to fix it). It may issue 766 DAO and DIS messages though it generally ignores DAO and DIS 767 messages. 769 In this case the flow comprises: 771 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 773 For example, a communication flow could be: Node F --> Node D --> 774 Node B --> Node A root(6LBR) 776 As it was mentioned in this document 6LRs, 6LBR are always full- 777 fledged RPL routers. 779 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 780 (Node E) which decrements the rank in RPI and sends the packet up. 781 When the packet arrives at 6LBR (Node A), the RPI is removed and the 782 packet is processed. 784 No IPv6-in-IPv6 header is required. 786 The RPI header can be removed by the 6LBR because the packet is 787 addressed to the 6LBR. The 6LN must know that it is communicating 788 with the 6LBR to make use of this scenario. The 6LN can know the 789 address of the 6LBR because it knows the address of the root via the 790 DODAGID in the DIO messages. 792 The Table 1 summarizes what headers are needed for this use case. 794 +-------------------+---------+-------+----------+ 795 | Header | 6LN src | 6LR_i | 6LBR dst | 796 +-------------------+---------+-------+----------+ 797 | Inserted headers | RPI | -- | -- | 798 | Removed headers | -- | -- | RPI | 799 | Re-added headers | -- | -- | -- | 800 | Modified headers | -- | RPI | -- | 801 | Untouched headers | -- | -- | -- | 802 +-------------------+---------+-------+----------+ 804 Table 1: Storing: Summary of the use of headers from RPL-aware-leaf 805 to root 807 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 809 In this case the flow comprises: 811 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 813 For example, a communication flow could be: Node A root(6LBR) --> 814 Node B --> Node D --> Node F 816 In this case the 6LBR inserts RPI header and sends the packet down, 817 the 6LR is going to increment the rank in RPI (it examines the 818 instanceID to identify the right forwarding table), the packet is 819 processed in the 6LN and the RPI removed. 821 No IPv6-in-IPv6 header is required. 823 The Table 2 summarizes what headers are needed for this use case. 825 +-------------------+------+-------+------+ 826 | Header | 6LBR | 6LR_i | 6LN | 827 +-------------------+------+-------+------+ 828 | Inserted headers | RPI | -- | -- | 829 | Removed headers | -- | -- | RPI | 830 | Re-added headers | -- | -- | -- | 831 | Modified headers | -- | RPI | -- | 832 | Untouched headers | -- | -- | -- | 833 +-------------------+------+-------+------+ 835 Table 2: Storing: Summary of the use of headers from root to RPL- 836 aware-leaf 838 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 840 In this case the flow comprises: 842 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 844 For example, a communication flow could be: Node A root(6LBR) --> 845 Node B --> Node E --> Node G 847 As the RPI extension can be ignored by the not-RPL-aware leaf, this 848 situation is identical to the previous scenario. 850 The Table 3 summarizes what headers are needed for this use case. 852 +-------------------+----------+-------+----------------+ 853 | Header | 6LBR src | 6LR_i | IPv6 dst node | 854 +-------------------+----------+-------+----------------+ 855 | Inserted headers | RPI | -- | -- | 856 | Removed headers | -- | -- | -- | 857 | Re-added headers | -- | -- | -- | 858 | Modified headers | -- | RPI | -- | 859 | Untouched headers | -- | -- | RPI (Ignored) | 860 +-------------------+----------+-------+----------------+ 862 Table 3: Storing: Summary of the use of headers from root to not-RPL- 863 aware-leaf 865 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 867 In this case the flow comprises: 869 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 871 For example, a communication flow could be: Node G --> Node E --> 872 Node B --> Node A root(6LBR) 874 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 875 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 876 header. The IPv6-in-IPv6 header can be addressed to the next hop 877 (Node B), or to the root (Node A). The root removes the header and 878 processes the packet. 880 The Figure 8 shows the table that summarizes what headers are needed 881 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 883 +-----------+------+--------------+-----------------+--------------------+ 884 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 885 | | src | | | | 886 | | node | | | | 887 +-----------+------+--------------+-----------------+--------------------+ 888 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 889 | headers | | | | | 890 +-----------+------+--------------+-----------------+--------------------+ 891 | Removed | -- | -- | -- | IP6-IP6(RPI)[1][2] | 892 | headers | | | | | 893 +-----------+------+--------------+-----------------+--------------------+ 894 | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | 895 | headers | | | | | 896 +-----------+------+--------------+-----------------+--------------------+ 897 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 898 | headers | | | | | 899 +-----------+------+--------------+-----------------+--------------------+ 900 | Untouched | -- | -- | -- | -- | 901 | headers | | | | | 902 +-----------+------+--------------+-----------------+--------------------+ 904 Figure 8: Storing mode: Summary of the use of headers from not-RPL- 905 aware-leaf to root. [[1] Case where the IPv6-in-IPv6 header is 906 addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 907 header is addressed to the root (Node A). 909 6.2. Storing Mode: Interaction between Leaf and Internet. 911 In this section is described the communication flow in storing mode 912 (SM) between, 914 RPL-aware-leaf to Internet 916 Internet to RPL-aware-leaf 918 not-RPL-aware-leaf to Internet 920 Internet to not-RPL-aware-leaf 922 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 924 RPL information from RFC 6553 may go out to Internet as it will be 925 ignored by nodes which have not been configured to be RPI aware. 927 In this case the flow comprises: 929 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 930 For example, the communication flow could be: Node F --> Node D --> 931 Node B --> Node A root(6LBR) --> Internet 933 No IPv6-in-IPv6 header is required. 935 Note: In this use case it is used a node as leaf, but this use case 936 can be also applicable to any RPL-node type (e.g. 6LR) 938 The Table 4 summarizes what headers are needed for this use case. 940 +-------------------+---------+-------+------+----------------+ 941 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 942 +-------------------+---------+-------+------+----------------+ 943 | Inserted headers | RPI | -- | -- | -- | 944 | Removed headers | -- | -- | -- | -- | 945 | Re-added headers | -- | -- | -- | -- | 946 | Modified headers | -- | RPI | -- | -- | 947 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 948 +-------------------+---------+-------+------+----------------+ 950 Table 4: Storing: Summary of the use of headers from RPL-aware-leaf 951 to Internet 953 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 955 In this case the flow comprises: 957 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 959 For example, a communication flow could be: Internet --> Node A 960 root(6LBR) --> Node B --> Node D --> Node F 962 When the packet arrives from Internet to 6LBR the RPI header is added 963 in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination 964 address set to the 6LR) and sent to 6LR, which modifies the rank in 965 the RPI. When the packet arrives at 6LN the RPI header is removed 966 and the packet processed. 968 The Figure 9 shows the table that summarizes what headers are needed 969 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 971 +-----------+----------+--------------+--------------+------------------+ 972 | Header | Internet | 6LBR | 6LR_i | 6LN dst | 973 | | src | | | | 974 +-----------+----------+--------------+--------------+------------------+ 975 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 976 | headers | | | | | 977 +-----------+----------+--------------+--------------+------------------+ 978 | Removed | -- | -- | -- | IP6-IP6(RPI) | 979 | headers | | | | | 980 +-----------+----------+--------------+--------------+------------------+ 981 | Re-added | -- | -- | -- | -- | 982 | headers | | | | | 983 +-----------+----------+--------------+--------------+------------------+ 984 | Modified | -- | -- | IP6-IP6(RPI) | -- | 985 | headers | | | | | 986 +-----------+----------+--------------+--------------+------------------+ 987 | Untouched | -- | -- | -- | -- | 988 | headers | | | | | 989 +-----------+----------+--------------+--------------+------------------+ 991 Figure 9: Storing mode: Summary of the use of headers from Internet 992 to RPL-aware-leaf. 994 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 996 In this case the flow comprises: 998 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 999 Internet 1001 For example, a communication flow could be: Node G --> Node E --> 1002 Node B --> Node A root(6LBR) --> Internet 1004 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 1005 either to the root, or hop-by-hop such that the root can remove the 1006 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 1007 root cause less processing overhead. On the other hand, with hop-by- 1008 hop the intermediate routers can check the routing tables for a 1009 better routing path, thus it could be more efficient and faster. 1010 Implementation should decide which approach to take. 1012 The originating node will ideally leave the IPv6 flow label as zero 1013 so that the packet can be better compressed through the LLN. The 1014 6LBR will set the flow label of the packet to a non-zero value when 1015 sending to the Internet. 1017 The Figure 10 shows the table that summarizes what headers are needed 1018 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1020 +---------+-------+------------+--------------+-------------+--------+ 1021 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1022 | | src | | [i=2,...,n] | | dst | 1023 | | node | | | | | 1024 +---------+-------+------------+--------------+-------------+--------+ 1025 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1026 | headers | | | [2] | | | 1027 +---------+-------+------------+--------------+-------------+--------+ 1028 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1029 | headers | | | [2] | [1][2] | | 1030 +---------+-------+------------+--------------+-------------+--------+ 1031 | Re-added| -- | -- | -- | -- | -- | 1032 | headers | | | | | | 1033 +---------+-------+------------+--------------+-------------+--------+ 1034 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1035 | headers | | | [1] | | | 1036 +---------+-------+------------+--------------+-------------+--------+ 1037 |Untouched| -- | -- | -- | -- | -- | 1038 | headers | | | | | | 1039 +---------+-------+------------+--------------+-------------+--------+ 1041 Figure 10: Storing mode: Summary of the use of headers from not-RPL- 1042 aware-leaf to Internet. [1] Case when packet is addressed to the 1043 root. [2] Case when the packet is addressed hop-by-hop. 1045 6.2.4. SM: Example of Flow from Internet to not-RPL-aware-leaf. 1047 In this case the flow comprises: 1049 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1051 For example, a communication flow could be: Internet --> Node A 1052 root(6LBR) --> Node B --> Node E --> Node G 1054 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 1055 header. The IPv6-in-IPv6 is addressed hop-by-hop. 1057 The final node should be able to remove one or more IPv6-in-IPv6 1058 headers which are all addressed to it. The final node does not 1059 process the RPI, the node ignores the RPI. Furhter details about 1060 this are mentioned in [I-D.thubert-roll-unaware-leaves], which 1061 specifies RPL routing for a 6LN acting as a plain host and not aware 1062 of RPL. 1064 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1065 zero in order to aid in compression. 1067 The Figure 11 shows the table that summarizes what headers are needed 1068 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1070 +-----------+----------+--------------+--------------+--------------+ 1071 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1072 | | src | | | | 1073 +-----------+----------+--------------+--------------+--------------+ 1074 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1075 | headers | | | | | 1076 +-----------+----------+--------------+--------------+--------------+ 1077 | Removed | -- | -- | | IP6-IP6(RPI)| 1078 | headers | | | | RPI Ignored | 1079 +-----------+----------+--------------+--------------+--------------+ 1080 | Re-added | -- | -- | -- | -- | 1081 | headers | | | | | 1082 +-----------+----------+--------------+--------------+--------------+ 1083 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1084 | headers | | | | | 1085 +-----------+----------+--------------+--------------+--------------+ 1086 | Untouched | -- | -- | -- | -- | 1087 | headers | | | | | 1088 +-----------+----------+--------------+--------------+--------------+ 1090 Figure 11: Storing mode: Summary of the use of headers from Internet 1091 to not-RPL-aware-leaf. 1093 6.3. Storing Mode: Interaction between Leaf and Leaf 1095 In this section is described the communication flow in storing mode 1096 (SM) between, 1098 RPL-aware-leaf to RPL-aware-leaf 1100 RPL-aware-leaf to not-RPL-aware-leaf 1102 not-RPL-aware-leaf to RPL-aware-leaf 1104 not-RPL-aware-leaf to not-RPL-aware-leaf 1106 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1108 In [RFC6550] RPL allows a simple one-hop optimization for both 1109 storing and non-storing networks. A node may send a packet destined 1110 to a one-hop neighbor directly to that node. See section 9 in 1111 [RFC6550]. 1113 When the nodes are not directly connected, then in storing mode, the 1114 flow comprises: 1116 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1118 For example, a communication flow could be: Node F --> Node D --> 1119 Node B --> Node E --> Node H 1121 6LR_ia (Node D) is the intermediate router from source to the common 1122 parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the number 1123 of routers (6LR) that the packet goes through from 6LN (Node F) to 1124 the common parent (6LR_x). 1126 6LR_id (Node E) is the intermediate router from the common parent 1127 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1128 <= m", m is the number of routers (6LR) that the packet goes through 1129 from the common parent (6LR_x) to destination 6LN. 1131 It is assumed that the two nodes are in the same RPL Domain (that 1132 they share the same DODAG root). At the common parent (Node B), the 1133 direction of RPI is changed (from increasing to decreasing the rank). 1135 While the 6LR nodes will update the RPI, no node needs to add or 1136 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1138 The Table 5 summarizes what headers are needed for this use case. 1140 +---------------+--------+--------+---------------+--------+--------+ 1141 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1142 | | src | | parent) | | dst | 1143 +---------------+--------+--------+---------------+--------+--------+ 1144 | Inserted | RPI | -- | -- | -- | -- | 1145 | headers | | | | | | 1146 | Removed | -- | -- | -- | -- | RPI | 1147 | headers | | | | | | 1148 | Re-added | -- | -- | -- | -- | -- | 1149 | headers | | | | | | 1150 | Modified | -- | RPI | RPI | RPI | -- | 1151 | headers | | | | | | 1152 | Untouched | -- | -- | -- | -- | -- | 1153 | headers | | | | | | 1154 +---------------+--------+--------+---------------+--------+--------+ 1156 Table 5: Storing: Summary of the use of headers for RPL-aware-leaf to 1157 RPL-aware-leaf 1159 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 1161 In this case the flow comprises: 1163 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1164 6LN (IPv6) 1166 For example, a communication flow could be: Node F --> Node D --> 1167 Node B --> Node E --> Node G 1169 6LR_ia is the intermediate router from source (6LN) to the common 1170 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1171 routers (6LR) that the packet goes through from 6LN to the common 1172 parent (6LR_x). 1174 6LR_id (Node E) is the intermediate router from the common parent 1175 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1176 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1177 the packet goes through from the common parent (6LR_x) to destination 1178 6LN. 1180 This situation is identical to the previous situation Section 6.3.1 1182 The Table 6 summarizes what headers are needed for this use case. 1184 +-----------+------+--------+---------------+--------+--------------+ 1185 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | 1186 | | src | | parent) | | node | 1187 +-----------+------+--------+---------------+--------+--------------+ 1188 | Inserted | RPI | -- | -- | -- | -- | 1189 | headers | | | | | | 1190 | Removed | -- | -- | -- | -- | -- | 1191 | headers | | | | | | 1192 | Re-added | -- | -- | -- | -- | -- | 1193 | headers | | | | | | 1194 | Modified | -- | RPI | RPI | RPI | -- | 1195 | headers | | | | | | 1196 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1197 | headers | | | | | | 1198 +-----------+------+--------+---------------+--------+--------------+ 1200 Table 6: Storing: Summary of the use of headers for RPL-aware-leaf to 1201 not-RPL-aware-leaf 1203 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1205 In this case the flow comprises: 1207 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1208 6LR_id --> 6LN 1209 For example, a communication flow could be: Node G --> Node E --> 1210 Node B --> Node D --> Node F 1212 6LR_ia (Node E) is the intermediate router from source (not-RPL-aware 1213 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In this 1214 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1215 packet ges through from source to the common parent. 1217 6LR_id (Node D) is the intermediate router from the common parent 1218 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1219 <= m", m is the number of routers (6LR) that the packet goes through 1220 from the common parent (6LR_x) to destination 6LN. 1222 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1223 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1224 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1225 (Node F). 1227 The Figure 12 shows the table that summarizes what headers are needed 1228 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1230 +----------+-----+--------------+--------------+--------------+------------+ 1231 | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | 1232 | |src | | Parent | | dst | 1233 | |node | | (6LRx) | | | 1234 +----------+-----+--------------+--------------+--------------+------------+ 1235 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1236 | headers | | | | | | 1237 +----------+-----+--------------+--------------+--------------+------------+ 1238 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1239 | headers | | | | | | 1240 +----------+-----+--------------+--------------+--------------+------------+ 1241 | Re-added | -- | -- | -- | -- | -- | 1242 | headers | | | | | | 1243 +----------+-----+--------------+--------------+--------------+------------+ 1244 | Modified | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- | 1245 | headers | | | | | | 1246 +----------+-----+--------------+--------------+--------------+------------+ 1247 |Untouched | -- | -- | -- | -- | -- | 1248 | headers | | | | | | 1249 +----------+-----+--------------+--------------+--------------+------------+ 1251 Figure 12: Storing mode: Summary of the use of headers from not-RPL- 1252 aware-leaf to RPL-aware-leaf. 1254 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1255 leaf 1257 In this case the flow comprises: 1259 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id 1260 --> not-RPL-aware 6LN (IPv6 dst) 1262 For example, a communication flow could be: Node G --> Node E --> 1263 Node B --> Node A (root) --> Node C --> Node J 1265 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1266 router from the not-RPL-aware source (Node G) to the root (6LBR) 1267 (Node A). In this case, "1 < ia <= n", n is the number of routers 1268 (6LR) that the packet goes through from IPv6 src to the root. 1270 6LR_id (C) is the intermediate router from the root (Node A) to the 1271 destination Node J. In this case, "1 <= id <= m", m is the number of 1272 routers (6LR) that the packet goes through from the root to 1273 destination (IPv6 dst). 1275 Note that this flow is identical to Section 6.3.3, except that the 1276 RPI is ignored at the IPv6 dst node. 1278 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1279 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1280 header. The IPv6-in-IPv6 header is addressed to the final 1281 destination (Node J). 1283 The Figure 13 shows the table that summarizes what headers are needed 1284 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1286 +---------+------+------------+------------+------------+------------+ 1287 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LR_m | IPv6 | 1288 | | src | | | | dst | 1289 | | node | | | | node | 1290 +---------+------+------------+------------+------------+------------+ 1291 | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- | 1292 | headers | | | | | | 1293 +---------+------+------------+------------+------------+------------+ 1294 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1295 | headers | | | | | RPI Ignored| 1296 +---------+------+------------+------------+------------+------------+ 1297 | Re-added| -- | -- | -- | -- | -- | 1298 | headers | | | | | | 1299 +---------+------+------------+------------+------------+------------+ 1300 | Modified| -- | -- |IP6-IP6(RPI)|IP6-IP6(RPI)| -- | 1301 | headers | | | | | | 1302 +---------+------+------------+------------+------------+------------+ 1303 |Untouched| -- | -- | -- | -- | -- | 1304 | headers | | | | | | 1305 +---------+------+------------+------------+------------+------------+ 1307 Figure 13: Storing mode: Summary of the use of headers from not-RPL- 1308 aware-leaf to not-RPL-aware-leaf 1310 7. Non Storing mode 1312 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1313 root) has complete knowledge about the connectivity of all DODAG 1314 nodes, and all traffic flows through the root node. Thus, there is 1315 no need for all nodes to know about the existence of not-RPL aware 1316 nodes. Only the 6LBR needs to act if compensation is necessary for 1317 not-RPL aware receivers. 1319 The following table (Figure 14) summarizes what headers are needed in 1320 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1321 IPv6 header are to be inserted. It depicts the target destination 1322 address possible (indicated by "Raf"), to a 6LR (parent of a 6LN) or 1323 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1324 column states as "No". There is no expectation on RPL that RPI can 1325 be omitted, because it is needed for routing, quality of service and 1326 compression. This specification expects that is always a RPI 1327 Present. 1329 The leaf can be a router 6LR or a host, both indicated as 6LN 1330 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1331 where the RPI header may still be needed for the instanceID to be 1332 available for priority/channel selection at each hop. 1334 +-----------------+--------------+-----+-----+------------+------------+ 1335 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1336 | between | | | | | dst | 1337 +-----------------+--------------+-----+-----+------------+------------+ 1338 | | Raf to root | Yes | No | No | No | 1339 + +--------------+-----+-----+------------+------------+ 1340 | Leaf - Root | root to Raf | Yes | Yes | No | No | 1341 + +--------------+-----+-----+------------+------------+ 1342 | | root to ~Raf | Yes | Yes | must | 6LR | 1343 | | | (1) | | | | 1344 + +--------------+-----+-----+------------+------------+ 1345 | | ~Raf to root | Yes | No | must | root | 1346 +-----------------+--------------+-----+-----+------------+------------+ 1347 | | Raf to Int | Yes | No | No | No | 1348 + +--------------+-----+-----+------------+------------+ 1349 | Leaf - Internet | Int to Raf | Yes | Yes | must | Raf | 1350 + +--------------+-----+-----+------------+------------+ 1351 | | ~Raf to Int | Yes | No | must | root | 1352 + +--------------+-----+-----+------------+------------+ 1353 | | Int to ~Raf | Yes | Yes | must | 6LR | 1354 +-----------------+--------------+-----+-----+------------+------------+ 1355 | | Raf to Raf | Yes | Yes | must | root/Raf | 1356 + +--------------+-----+-----+------------+------------+ 1357 | | Raf to ~Raf | Yes | Yes | must | root/6LR | 1358 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1359 | | ~Raf to Raf | Yes | Yes | must | root/Raf | 1360 + +--------------+-----+-----+------------+------------+ 1361 | | ~Raf to ~Raf | Yes | Yes | must | root/6LR | 1362 +-----------------+--------------+-----+-----+------------+------------+ 1364 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1365 RH3, IPv6-in-IPv6 encapsulation. 1367 7.1. Non-Storing Mode: Interaction between Leaf and Root 1369 In this section is described the communication flow in Non Storing 1370 Mode (Non-SM) between, 1372 RPL-aware-leaf to root 1374 root to RPL-aware-leaf 1376 not-RPL-aware-leaf to root 1378 root to not-RPL-aware-leaf 1380 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1382 In non-storing mode the leaf node uses default routing to send 1383 traffic to the root. The RPI header must be included since it 1384 contains the rank information, which is used to avoid/detect loops. 1386 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1388 For example, a communication flow could be: Node F --> Node D --> 1389 Node B --> Node A (root) 1391 6LR_i is the intermediate router from source to destination. In this 1392 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1393 goes through from source (6LN) to destination (6LBR). 1395 This situation is the same case as storing mode. 1397 The Table 7 summarizes what headers are needed for this use case. 1399 +-------------------+---------+-------+----------+ 1400 | Header | 6LN src | 6LR_i | 6LBR dst | 1401 +-------------------+---------+-------+----------+ 1402 | Inserted headers | RPI | -- | -- | 1403 | Removed headers | -- | -- | RPI | 1404 | Re-added headers | -- | -- | -- | 1405 | Modified headers | -- | RPI | -- | 1406 | Untouched headers | -- | -- | -- | 1407 +-------------------+---------+-------+----------+ 1409 Table 7: Non Storing: Summary of the use of headers from RPL-aware- 1410 leaf to root 1412 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1414 In this case the flow comprises: 1416 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1418 For example, a communication flow could be: Node A (root) --> Node B 1419 --> Node D --> Node F 1421 6LR_i is the intermediate router from source to destination. In this 1422 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1423 goes through from source (6LBR) to destination (6LN). 1425 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1426 necessary as the traffic originates with an RPL aware node, the 6LBR. 1428 The destination is known to be RPL-aware because the root knows the 1429 whole topology in non-storing mode. 1431 The Table 8 summarizes what headers are needed for this use case. 1433 +-------------------+----------+-----------+-----------+ 1434 | Header | 6LBR src | 6LR_i | 6LN dst | 1435 +-------------------+----------+-----------+-----------+ 1436 | Inserted headers | RPI, RH3 | -- | -- | 1437 | Removed headers | -- | -- | RH3, RPI | 1438 | Re-added headers | -- | -- | -- | 1439 | Modified headers | -- | RPI, RH3 | -- | 1440 | Untouched headers | -- | -- | -- | 1441 +-------------------+----------+-----------+-----------+ 1443 Table 8: Non Storing: Summary of the use of headers from root to RPL- 1444 aware-leaf 1446 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1448 In this case the flow comprises: 1450 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1452 For example, a communication flow could be: Node A (root) --> Node B 1453 --> Node E --> Node G 1455 6LR_i is the intermediate router from source to destination. In this 1456 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1457 goes through from source (6LBR) to destination (IPv6). 1459 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1460 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1461 but left there. As the RPI is added, then the IPv6 node which does 1462 not understand the RPI, will ignore it (following RFC8200), thus 1463 encapsulation is not necessary. 1465 The Figure 15 depicts the table that summarizes what headers are 1466 needed for this use case. 1468 +-----------+----------+--------------+----------------+----------+ 1469 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1470 | | | i=(1,..,n-1) | | dst | 1471 | | | | | node | 1472 +-----------+----------+--------------+----------------+----------+ 1473 | Inserted | RPI, RH3 | -- | -- | -- | 1474 | headers | | | | | 1475 +-----------+----------+--------------+----------------+----------+ 1476 | Removed | -- | -- | | -- | 1477 | headers | | | | | 1478 +-----------+----------+--------------+----------------+----------+ 1479 | Re-added | -- | -- | -- | -- | 1480 | headers | | | | | 1481 +-----------+----------+--------------+----------------+----------+ 1482 | Modified | -- | RPI, RH3 | RPI, | -- | 1483 | headers | | | RH3(consumed) | | 1484 +-----------+----------+--------------+----------------+----------+ 1485 | Untouched | -- | -- | -- | RPI, RH3 | 1486 | headers | | | | (both | 1487 | | | | | ignored) | 1488 +-----------+----------+--------------+----------------+----------+ 1490 Figure 15: Non Storing: Summary of the use of headers from root to 1491 not-RPL-aware-leaf 1493 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1495 In this case the flow comprises: 1497 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1499 For example, a communication flow could be: Node G --> Node E --> 1500 Node B --> Node A (root) 1502 6LR_i is the intermediate router from source to destination. In this 1503 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1504 goes through from source (IPv6) to destination (6LBR). For example, 1505 6LR_1 (i=1) is the router that receives the packets from the IPv6 1506 node. 1508 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1509 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1510 following 6LRs. The RPI and entire packet is consumed by the root. 1512 The Figure 16 shows the table that summarizes what headers are needed 1513 for this use case. 1515 +----------+------+-------------------+------------------+-----------------+ 1516 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 1517 | | src | | | | 1518 | | node | | | | 1519 +----------+------+-------------------+------------------+-----------------+ 1520 | Inserted | -- | IPv6-in-IPv6(RPI) | -- | -- | 1521 | headers | | | | | 1522 +----------+------+-------------------+------------------+-----------------+ 1523 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1524 | headers | | | | | 1525 +----------+------+-------------------+------------------+-----------------+ 1526 | Re-added | -- | -- | -- | -- | 1527 | headers | | | | | 1528 +----------+------+-------------------+------------------+-----------------+ 1529 | Modified | -- | -- | IPv6-in-IPv6(RPI)| -- | 1530 | headers | | | | | 1531 +----------+------+-------------------+------------------+-----------------+ 1532 |Untouched | -- | -- | -- | -- | 1533 | headers | | | | | 1534 +----------+------+-------------------+------------------+-----------------+ 1536 Figure 16: Non Storing: Summary of the use of headers from not-RPL- 1537 aware-leaf to root 1539 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1541 This section will describe the communication flow in Non Storing Mode 1542 (Non-SM) between: 1544 RPL-aware-leaf to Internet 1546 Internet to RPL-aware-leaf 1548 not-RPL-aware-leaf to Internet 1550 Internet to not-RPL-aware-leaf 1552 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1554 In this case the flow comprises: 1556 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1558 For example, a communication flow could be: Node F --> Node D --> 1559 Node B --> Node A --> Internet 1560 6LR_i is the intermediate router from source to destination. In this 1561 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1562 goes through from source (6LN) to 6LBR. 1564 This case is identical to storing-mode case. 1566 The IPv6 flow label should be set to zero to aid in compression, and 1567 the 6LBR will set it to a non-zero value when sending towards the 1568 Internet. 1570 The Table 9 summarizes what headers are needed for this use case. 1572 +-------------------+---------+-------+------+----------------+ 1573 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 1574 +-------------------+---------+-------+------+----------------+ 1575 | Inserted headers | RPI | -- | -- | -- | 1576 | Removed headers | -- | -- | -- | -- | 1577 | Re-added headers | -- | -- | -- | -- | 1578 | Modified headers | -- | RPI | -- | -- | 1579 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1580 +-------------------+---------+-------+------+----------------+ 1582 Table 9: Non Storing: Summary of the use of headers from RPL-aware- 1583 leaf to Internet 1585 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1587 In this case the flow comprises: 1589 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1591 For example, a communication flow could be: Internet --> Node A 1592 (root) --> Node B --> Node D --> Node F 1594 6LR_i is the intermediate router from source to destination. In this 1595 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1596 goes through from 6LBR to destination(6LN). 1598 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1599 address of the target node, it can address the IPv6-in-IPv6 header to 1600 that node. The 6LBR will zero the flow label upon entry in order to 1601 aid compression. 1603 The Table 10 summarizes what headers are needed for this use case. 1605 +-----------+----------+--------------+--------------+--------------+ 1606 | Header | Internet | 6LBR | 6LR_i | 6LN src | 1607 | | dst | | | | 1608 +-----------+----------+--------------+--------------+--------------+ 1609 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1610 | headers | | (RH3,RPI) | | | 1611 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1612 | headers | | | | (RH3,RPI) | 1613 | Re-added | -- | -- | -- | -- | 1614 | headers | | | | | 1615 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1616 | headers | | | (RH3,RPI) | | 1617 | Untouched | -- | -- | -- | -- | 1618 | headers | | | | | 1619 +-----------+----------+--------------+--------------+--------------+ 1621 Table 10: Non Storing: Summary of the use of headers from Internet to 1622 RPL-aware-leaf 1624 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1626 In this case the flow comprises: 1628 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1629 Internet 1631 For example, a communication flow could be: Node G --> Node E --> 1632 Node B --> Node A --> Internet 1634 6LR_i is the intermediate router from source to destination. In this 1635 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1636 goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1638 In this case the flow label is recommended to be zero in the IPv6 1639 node. As RPL headers are added in the IPv6 node packet, the first 1640 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1641 The IPv6-in-IPv6 header will be addressed to the root. This case is 1642 identical to the storing-mode case (see Section 6.2.3). 1644 The Figure 17 shows the table that summarizes what headers are needed 1645 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1647 +-----------+------+--------------+--------------+--------------+----------+ 1648 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | 1649 | | src | | [i=2,..,n] | | dst | 1650 | | node | | | | | 1651 +-----------+------+--------------+--------------+--------------+----------+ 1652 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1653 | headers | | | | | | 1654 +-----------+------+--------------+--------------+--------------+----------+ 1655 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1656 | headers | | | | | | 1657 +-----------+------+--------------+--------------+--------------+----------+ 1658 | Re-added | -- | -- | -- | -- | -- | 1659 | headers | | | | | | 1660 +-----------+------+--------------+--------------+--------------+----------+ 1661 | Modified | -- | -- | IP6-IP6(RPI) | -- | -- | 1662 | headers | | | | | | 1663 +-----------+------+--------------+--------------+--------------+----------+ 1664 | Untouched | -- | -- | -- | -- | -- | 1665 | headers | | | | | | 1666 +-----------+------+--------------+--------------+--------------+----------+ 1668 Figure 17: Non Storing: Summary of the use of headers from not-RPL- 1669 aware-leaf to Internet 1671 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1673 In this case the flow comprises: 1675 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1677 For example, a communication flow could be: Internet --> Node A 1678 (root) --> Node B --> Node E --> Node G 1680 6LR_i is the intermediate router from source to destination. In this 1681 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1682 goes through from 6LBR to not-RPL-aware-leaf (IPv6). 1684 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1685 6LBR will know the path, and will recognize that the final node is 1686 not an RPL capable node as it will have received the connectivity DAO 1687 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1688 header destination be the last 6LR. The 6LBR will set to zero the 1689 flow label upon entry in order to aid compression. 1691 The Figure 18 shows the table that summarizes what headers are needed 1692 for this use case. 1694 +-----------+--------+--------------+--------------+--------------+------+ 1695 | Header |Internet| 6LBR | 6LR_1 | 6lR_i | IPv6 | 1696 | | src | | | (i=2,...,n) | dst | 1697 | | | | | | node | 1698 +-----------+--------+--------------+--------------+--------------+------+ 1699 | Inserted | -- | IPv6-in-IPv6 | -- | -- | -- | 1700 | headers | | (RH3,RPI) | | | | 1701 +-----------+--------+--------------+--------------+--------------+------+ 1702 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1703 | headers | | | | (RH3,RPI)[1] | | 1704 +-----------+--------+--------------+--------------+--------------+------+ 1705 | Re-added | -- | -- | -- | -- | -- | 1706 | headers | | | | | | 1707 +-----------+--------+--------------+--------------+--------------+------+ 1708 | Modified | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1709 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1710 +-----------+--------+--------------+--------------+--------------+------+ 1711 | Untouched | -- | -- | -- | -- | -- | 1712 | headers | | | | | | 1713 +-----------+--------+--------------+--------------+--------------+------+ 1715 Figure 18: Non-Storing mode: Summary of the use of headers from 1716 Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node. 1718 7.3. Non-Storing Mode: Interaction between Leafs 1720 In this section is described the communication flow in Non Storing 1721 Mode (Non-SM) between, 1723 RPL-aware-leaf to RPL-aware-leaf 1725 RPL-aware-leaf to not-RPL-aware-leaf 1727 not-RPL-aware-leaf to RPL-aware-leaf 1729 not-RPL-aware-leaf to not-RPL-aware-leaf 1731 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1733 In this case the flow comprises: 1735 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1737 For example, a communication flow could be: Node F --> Node D --> 1738 Node B --> Node A (root) --> Node B --> Node E --> Node H 1739 6LR_ia is the intermediate router from source to the root In this 1740 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1741 packet goes through from 6LN to the root. 1743 6LR_id is the intermediate router from the root to the destination. 1744 In this case, "1 <= ia <= m", m is the number of the intermediate 1745 routers (6LR). 1747 This case involves only nodes in same RPL Domain. The originating 1748 node will add a RPI header to the original packet, and send the 1749 packet upwards. 1751 The originating node must put the RPI into an IPv6-in-IPv6 header 1752 addressed to the root, so that the 6LBR can remove that header. If 1753 it does not, then additional resources are wasted on the way down to 1754 carry the useless RPI option. 1756 The 6LBR will need to insert an RH3 header, which requires that it 1757 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1758 it was contained in an IPv6-in-IPv6 header addressed to it. 1759 Otherwise, there may be a RPI header buried inside the inner IP 1760 header, which should get ignored. 1762 Networks that use the RPL P2P extension [RFC6997] are essentially 1763 non-storing DODAGs and fall into this scenario or scenario 1764 Section 7.1.2, with the originating node acting as 6LBR. 1766 The Figure 19 shows the table that summarizes what headers are needed 1767 for this use case. 1769 +---------+------------+------------+------------+------------+------------+ 1770 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | 1771 | | src | | | | dst | 1772 +---------+------------+------------+------------+------------+------------+ 1773 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1774 | headers | (RPI1) | |(RH3-> 6LN, | | | 1775 | | | | RPI2) | | | 1776 +---------+------------+------------+------------+------------+------------+ 1777 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1778 | headers | | | (RPI1) | | (RH3, | 1779 | | | | | | RPI2) | 1780 +---------+------------+------------+------------+------------+------------+ 1781 | Re-added| -- | -- | -- | -- | -- | 1782 | headers | | | | | | 1783 +---------+------------+------------+------------+------------+------------+ 1784 | Modified| -- |IPv6-in-IPv | -- |IPv6-in-IPv6| -- | 1785 | headers | | (RPI1) | | (RPI2) | | 1786 +---------+------------+------------+------------+------------+------------+ 1787 |Untouched| -- | -- | -- | -- | -- | 1788 | headers | | | | | | 1789 +---------+------------+------------+------------+------------+------------+ 1791 Figure 19: Non Storing mode: Summary of the use of headers for RPL- 1792 aware-leaf to RPL-aware-leaf 1794 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1795 leaf 1797 In this case the flow comprises: 1799 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1801 For example, a communication flow could be: Node F --> Node D --> 1802 Node B --> Node A (root) --> Node B --> Node E --> Node G 1804 6LR_ia is the intermediate router from source to the root In this 1805 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1807 6LR_id is the intermediate router from the root to the destination. 1808 In this case, "1 <= ia <= m", m is the number of the intermediate 1809 routers (6LRs). 1811 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1812 which must be in an IPv6-in-IPv6 header addressed to the root so that 1813 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1814 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. 1816 The Figure 20 shows the table that summarizes what headers are needed 1817 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1819 +-----------+---------+---------+---------+---------+---------+------+ 1820 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | 1821 | | src | | | | | dst | 1822 | | | | | | | node | 1823 +-----------+---------+---------+---------+---------+---------+------+ 1824 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1825 | headers | (RPI1) | | (RH3, | | | | 1826 | | | | RPI2) | | | | 1827 +-----------+---------+---------+---------+---------+---------+------+ 1828 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1829 | headers | | | (RPI1) | | (RH3, | | 1830 | | | | | | RPI2) | | 1831 +-----------+---------+---------+---------+---------+---------+------+ 1832 | Re-added | -- | -- | -- | -- | -- | -- | 1833 | headers | | | | | | | 1834 +-----------+---------+---------+---------+---------+---------+------+ 1835 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1836 | headers | | (RPI1) | | (RH3, | | | 1837 | | | | | RPI2) | | | 1838 +-----------+---------+---------+---------+---------+---------+------+ 1839 | Untouched | -- | -- | -- | -- | -- | -- | 1840 | headers | | | | | | | 1841 +-----------+---------+---------+---------+---------+---------+------+ 1843 Figure 20: Non Storing: Summary of the use of headers from RPL-aware- 1844 leaf to not-RPL-aware-leaf. 1846 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1847 leaf 1849 In this case the flow comprises: 1851 not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1852 6LR_id --> 6LN 1854 For example, a communication flow could be: Node G --> Node E --> 1855 Node B --> Node A (root) --> Node B --> Node E --> Node H 1857 6LR_ia is the intermediate router from source to the root. In this 1858 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1860 6LR_id is the intermediate router from the root to the destination. 1861 In this case, "1 <= ia <= m", m is the number of the intermediate 1862 routers (6LR). 1864 This scenario is mostly identical to the previous one. The RPI is 1865 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1866 addressed to the root. The 6LBR will remove this RPI, and add it's 1867 own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). 1869 The Figure 21 shows the table that summarizes what headers are needed 1870 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1872 +-----------+------+---------+---------+---------+---------+---------+ 1873 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | 1874 | | src | | | | | dst | 1875 | | node | | | | | | 1876 +-----------+------+---------+---------+---------+---------+---------+ 1877 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1878 | headers | | (RPI1) | | (RH3, | | | 1879 | | | | | RPI2) | | | 1880 +-----------+------+---------+---------+---------+---------+---------+ 1881 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1882 | headers | | | | (RPI1) | | (RH3, | 1883 | | | | | | | RPI2) | 1884 +-----------+------+---------+---------+---------+---------+---------+ 1885 | Re-added | -- | | -- | -- | -- | -- | 1886 | headers | | | | | | | 1887 +-----------+------+---------+---------+---------+---------+---------+ 1888 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1889 | headers | | | (RPI1) | | (RH3, | | 1890 | | | | | | RPI2) | | 1891 +-----------+------+---------+---------+---------+---------+---------+ 1892 | Untouched | -- | | -- | -- | -- | -- | 1893 | headers | | | | | | | 1894 +-----------+------+---------+---------+---------+---------+---------+ 1896 Figure 21: Non Storing: Summary of the use of headers from not-RPL- 1897 aware-leaf to RPL-aware-leaf. 1899 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1900 aware-leaf 1902 In this case the flow comprises: 1904 not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1905 6LR_id --> not-RPL-aware (IPv6 dst) 1907 For example, a communication flow could be: Node G --> Node E --> 1908 Node B --> Node A (root) --> Node C --> Node J 1910 6LR_ia is the intermediate router from source to the root. In this 1911 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1912 6LR_id is the intermediate router from the root to the destination. 1913 In this case, "1 <= ia <= m", m is the number of the intermediate 1914 routers (6LR). 1916 This scenario is the combination of the previous two cases. 1918 The Figure 22 shows the table that summarizes what headers are needed 1919 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1921 +---------+------+-------+-------+---------+-------+---------+------+ 1922 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | 1923 | | src | | | | | | dst | 1924 | | node | | | | | | node | 1925 +---------+------+-------+-------+---------+-------+---------+------+ 1926 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 1927 | headers | | (RPI1)| | (RH3, | | | | 1928 | | | | | RPI2) | | | | 1929 +---------+------+-------+-------+---------+-------+---------+------+ 1930 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1931 | headers | | | | (RPI1) | | (RH3, | | 1932 | | | | | | | RPI2) | | 1933 +---------+------+-------+-------+---------+-------+---------+------+ 1934 | Re-added| -- | -- | -- | -- | -- | -- | -- | 1935 | headers | | | | | | | | 1936 +---------+------+-------+-------+---------+-------+---------+------+ 1937 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 1938 | headers | | | (RPI1)| | (RH3, | | | 1939 | | | | | | RPI2)| | | 1940 +---------+------+-------+-------+---------+-------+---------+------+ 1941 |Untouched| -- | -- | -- | -- | -- | -- | -- | 1942 | headers | | | | | | | | 1943 +---------+------+-------+-------+---------+-------+---------+------+ 1945 Figure 22: Non Storing: Summary of the use of headers from not-RPL- 1946 aware-leaf to not-RPL-aware-leaf 1948 8. Operational Considerations of supporting not-RPL-aware-leaves 1950 Roughly half of the situations described in this document involve 1951 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1952 further categories: ones that drop a packet that have RPI or RH3 1953 headers, and ones that continue to process a packet that has RPI and/ 1954 or RH3 headers. 1956 [RFC8200] provides for new rules that suggest that nodes that have 1957 not been configured (explicitly) to examine Hop-by-Hop headers, 1958 should ignore those headers, and continue processing the packet. 1959 Despite this, and despite the switch from 0x63 to 0x23, there may be 1960 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1961 drop packets that continue to have RPL artifacts in them. In 1962 general, such hosts can not be easily supported in RPL LLNs. 1964 There are some specific cases where it is possible to remove the RPL 1965 artifacts prior to forwarding the packet to the leaf host. The 1966 critical thing is that the artifacts have been inserted by the RPL 1967 root inside an IPv6-in-IPv6 header, and that the header has been 1968 addressed to the 6LR immediately prior to the leaf node. In that 1969 case, in the process of removing the IPv6-in-IPv6 header, the 1970 artifacts can also be removed. 1972 The above case occurs whenever traffic originates from the outside 1973 the LLN (the "Internet" cases above), and non-storing mode is used. 1974 In non-storing mode, the RPL root knows the exact topology (as it 1975 must be create the RH3 header), and therefore knows what the 6LR 1976 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 1977 to the leaf node G, or node C is the 6LR prior to the leaf node J. 1979 Traffic originating from the RPL root (such as when the data 1980 collection system is co-located on the RPL root), does not require an 1981 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1982 the root, and the root can insert the RPI and RH3 headers directly 1983 into the packet, as it is formed. Such a packet is slightly smaller, 1984 but only can be sent to nodes (whether RPL aware or not), that will 1985 tolerate the RPL artifacts. 1987 An operator that finds itself with a lot of traffic from the RPL root 1988 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1989 if the leaf is not tolerant of the RPL artifacts. Such an operator 1990 could otherwise omit this unnecessary header if it was certain of the 1991 properties of the leaf. 1993 As storing mode can not know the final path of the traffic, 1994 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1995 be supported. 1997 9. Operational considerations of introducing 0x23 1999 This section describes the operational considerations of introducing 2000 the new RPI value of 0x23. 2002 During bootstrapping the node gets the DIO with the information of 2003 RPL Option Type, indicating the new RPI in the DODAG Configuration 2004 Option Flag. The DODAG root is in charge to configure the current 2005 network to the new value, through DIO messages and when all the nodes 2006 are set with the new value. The DODAG should change to a new DODAG 2007 version. In case of rebooting, the node does not remember the RPL 2008 Option Type. Thus, the DIO is sent with a flag indicating the new 2009 RPI value. 2011 The DODAG Configuration option is contained in a RPL DIO message, 2012 which contains a unique DTSN counter. The leaf nodes respond to this 2013 message with DAO messages containing the same DTSN. This is a normal 2014 part of RPL routing; the RPL root therefore knows when the updated 2015 DODAG Configuration Option has been seen by all nodes. 2017 Before the migration happens, all the RPL-aware nodes should support 2018 both values . The migration procedure it is triggered when the DIO 2019 is sent with the flag indicating the new RPI value. Namely, it 2020 remains at 0x63 until it is sure that the network is capable of 0x23, 2021 then it abruptly change to 0x23. This options allows to send packets 2022 to not-RPL nodes, which should ignore the option and continue 2023 processing the packets. 2025 In case that a node join to a network that only process 0x63, it 2026 would produce a flag day as was mentioned previously. Indicating the 2027 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2028 flag day in a network. It is recommended that a network process both 2029 options to enable interoperability. 2031 10. IANA Considerations 2033 This document updates the registration made in [RFC6553] Destination 2034 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2035 Figure 23. 2037 [RFCXXXX] represents this document. 2039 Hex Value Binary Value 2040 act chg rest Description Reference 2041 --------- --- --- ------- ----------------- ---------- 2042 0x23 00 1 00011 RPL Option [RFCXXXX] 2043 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 2045 Figure 23: Option Type in RPL Option. 2047 DODAG Configuration option is updated as follows (Figure 24): 2049 +------------+-----------------+---------------+ 2050 | Bit number | Description | Reference | 2051 +------------+-----------------+---------------+ 2052 | 3 | RPI 0x23 enable | This document | 2053 +------------+-----------------+---------------+ 2055 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2056 day. 2058 11. Security Considerations 2060 The security considerations covered in [RFC6553] and [RFC6554] apply 2061 when the packets are in the RPL Domain. 2063 The IPv6-in-IPv6 mechanism described in this document is much more 2064 limited than the general mechanism described in [RFC2473]. The 2065 willingness of each node in the LLN to decapsulate packets and 2066 forward them could be exploited by nodes to disguise the origin of an 2067 attack. 2069 While a typical LLN may be a very poor origin for attack traffic (as 2070 the networks tend to be very slow, and the nodes often have very low 2071 duty cycles) given enough nodes, they could still have a significant 2072 impact, particularly if the target of the attack is targeting another 2073 LLN. Additionally, some uses of RPL involve large backbone ISP scale 2074 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2075 equipped with multiple 100Gb/s interfaces. 2077 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2078 LLN as described above will make sure that any attack that is mounted 2079 must originate from compromised nodes within the LLN. The use of 2080 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2081 alert the operator to the existence of the attack, as well as drop 2082 the attack traffic. As the RPL network is typically numbered from a 2083 single prefix, which is itself assigned by RPL, BCP38 filtering 2084 involves a single prefix comparison and should be trivial to 2085 automatically configure. 2087 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2088 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2089 communications between a new Pledge and the Join Registrar/ 2090 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2091 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2092 the RPL root to do careful filtering: it occurs only when the Join 2093 Coordinator is not co-located inside the RPL root. 2095 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2096 only be by a node within the LLN on another node within the LLN. 2097 Such an attack could, of course, be done directly. An attack of this 2098 kind is meaningful only if the source addresses are either fake or if 2099 the point is to amplify return traffic. Such an attack, could also 2100 be done without the use of IPv6-in-IPv6 headers using forged source 2101 addresses. If the attack requires bi-directional communication, then 2102 IPv6-in-IPv6 provides no advantages. 2104 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2105 about creating security issues. In the security section of 2106 [RFC2473], it was suggested that tunnel entry and exit points can be 2107 secured, via "Use IPsec". This recommendation is not practical for 2108 RPL networks. [RFC5406] goes into some detail on what additional 2109 details would be needed in order to "Use IPsec". Use of ESP would 2110 prevent RFC8183 compression (compression must occur before 2111 encryption), and RFC8183 compression is lossy in a way that prevents 2112 use of AH. These are minor issues. The major issue is how to 2113 establish trust enough such that IKEv2 could be used. This would 2114 require a system of certificates to be present in every single node, 2115 including any Internet nodes that might need to communicate with the 2116 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2118 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2119 IPv6 headers would in the general case scale with the square of the 2120 number of nodes. This is a lot of resource for a constrained nodes 2121 on a constrained network. In the end, the IPsec tunnels would be 2122 providing only BCP38-like origin authentication! Just doing BCP38 2123 origin filtering at the entry and exit of the LLN provides a similar 2124 level amount of security without all the scaling and trust problems 2125 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2127 An LLN with hostile nodes within it would not be protected against 2128 impersonation with the LLN by entry/exit filtering. 2130 The RH3 header usage described here can be abused in equivalent ways 2131 (to disguise the origin of traffic and attack other nodes) with an 2132 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2133 attacker's RH3 header will not be seen by the network until it 2134 reaches the end host, which will decapsulate it. An end-host should 2135 be suspicious about a RH3 header which has additional hops which have 2136 not yet been processed, and SHOULD ignore such a second RH3 header. 2138 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2139 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2140 will see the second RH3 header and MAY choose to discard the packet 2141 if the RH3 header has not been completely consumed. A consumed 2142 (inert) RH3 header could be present in a packet that flows from one 2143 LLN, crosses the Internet, and enters another LLN. As per the 2144 discussion in this document, such headers do not need to be removed. 2145 However, there is no case described in this document where an RH3 is 2146 inserted in a non-storing network on traffic that is leaving the LLN, 2147 but this document should not preclude such a future innovation. It 2148 should just be noted that an incoming RH3 must be fully consumed, or 2149 very carefully inspected. 2151 The RPI header, if permitted to enter the LLN, could be used by an 2152 attacker to change the priority of a packet by selecting a different 2153 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2154 It could also be that not all nodes are reachable in an LLN using the 2155 default instanceID, but a change of instanceID would permit an 2156 attacker to bypass such filtering. Like the RH3, a RPI header is to 2157 be inserted by the RPL root on traffic entering the LLN by first 2158 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2159 therefore will not be seen by the network. Upon reaching the 2160 destination node the RPI header has no further meaning and is just 2161 skipped; the presence of a second RPI header will have no meaning to 2162 the end node as the packet has already been identified as being at 2163 it's final destination. 2165 The RH3 and RPI headers could be abused by an attacker inside of the 2166 network to route packets on non-obvious ways, perhaps eluding 2167 observation. This usage is in fact part of [RFC6997] and can not be 2168 restricted at all. This is a feature, not a bug. 2170 [RFC7416] deals with many other threats to LLNs not directly related 2171 to the use of IPv6-in-IPv6 headers, and this document does not change 2172 that analysis. 2174 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2175 attack on another part of the LLN, while disguising the origin of the 2176 attack. The mechanism can even be abused to make it appear that the 2177 attack is coming from outside the LLN, and unless countered, this 2178 could be used to mount a Distributed Denial Of Service attack upon 2179 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2180 such attacks already seen in the real world. 2182 If an attack comes from inside of LLN, it can be alleviated with SAVI 2183 (Source Address Validation Improvement) using [RFC8505] with 2184 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2185 traffic with an address that is not registered, and the registration 2186 process checks for topological correctness. Notice that there is an 2187 L2 authentication in most of the cases. If an attack comes from 2188 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2189 but by construction, the RH3 can typically only address nodes within 2190 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2191 considered an attack (see RFC6554, section 3). 2193 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2194 through the RPL root to perform this attack. To counter, the RPL 2195 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2196 simpler solution), or it SHOULD walk the IP header extension chain 2197 until it can inspect the upper-layer-payload as described in 2198 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2199 on the source addresses of all IP headers that it examines in both 2200 directions. 2202 Note: there are some situations where a prefix will spread across 2203 multiple LLNs via mechanisms such as the one described in 2204 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2205 needs to take this into account, either by exchanging detailed 2206 routing information on each LLN, or by moving the BCP38 filtering 2207 further towards the Internet, so that the details of the multiple 2208 LLNs do not matter. 2210 12. Acknowledgments 2212 This work is done thanks to the grant by the Stand.ICT project. 2214 A special BIG thanks to C. M. Heard for the help with the 2215 Section 3. Much of the redaction in that section is based on his 2216 comments. 2218 Additionally, the authors would like to acknowledge the review, 2219 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2220 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2221 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2223 13. References 2225 13.1. Normative References 2227 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2228 Defeating Denial of Service Attacks which employ IP Source 2229 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2230 May 2000, . 2232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2233 Requirement Levels", BCP 14, RFC 2119, 2234 DOI 10.17487/RFC2119, March 1997, 2235 . 2237 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2238 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2239 2010, . 2241 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2242 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2243 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2244 Low-Power and Lossy Networks", RFC 6550, 2245 DOI 10.17487/RFC6550, March 2012, 2246 . 2248 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2249 Power and Lossy Networks (RPL) Option for Carrying RPL 2250 Information in Data-Plane Datagrams", RFC 6553, 2251 DOI 10.17487/RFC6553, March 2012, 2252 . 2254 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2255 Routing Header for Source Routes with the Routing Protocol 2256 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2257 DOI 10.17487/RFC6554, March 2012, 2258 . 2260 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2261 of IPv6 Extension Headers", RFC 7045, 2262 DOI 10.17487/RFC7045, December 2013, 2263 . 2265 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2266 "IPv6 over Low-Power Wireless Personal Area Network 2267 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2268 April 2017, . 2270 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2271 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2272 May 2017, . 2274 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2275 (IPv6) Specification", STD 86, RFC 8200, 2276 DOI 10.17487/RFC8200, July 2017, 2277 . 2279 13.2. Informative References 2281 [DDOS-KREBS] 2282 Goodin, D., "Record-breaking DDoS reportedly delivered by 2283 >145k hacked cameras", September 2016, 2284 . 2287 [I-D.ietf-6lo-ap-nd] 2288 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2289 "Address Protected Neighbor Discovery for Low-power and 2290 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2291 progress), April 2019. 2293 [I-D.ietf-6lo-backbone-router] 2294 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2295 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2296 in progress), February 2019. 2298 [I-D.ietf-6tisch-dtsecurity-secure-join] 2299 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2300 6tisch-dtsecurity-secure-join-01 (work in progress), 2301 February 2017. 2303 [I-D.ietf-anima-autonomic-control-plane] 2304 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2305 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2306 plane-19 (work in progress), March 2019. 2308 [I-D.ietf-anima-bootstrapping-keyinfra] 2309 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2310 S., and K. Watsen, "Bootstrapping Remote Secure Key 2311 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2312 keyinfra-20 (work in progress), May 2019. 2314 [I-D.ietf-intarea-tunnels] 2315 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2316 Architecture", draft-ietf-intarea-tunnels-09 (work in 2317 progress), July 2018. 2319 [I-D.thubert-roll-unaware-leaves] 2320 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2321 unaware-leaves-07 (work in progress), April 2019. 2323 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2324 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2325 December 1998, . 2327 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2328 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2329 December 1998, . 2331 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2332 Control Message Protocol (ICMPv6) for the Internet 2333 Protocol Version 6 (IPv6) Specification", STD 89, 2334 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2335 . 2337 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2338 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2339 February 2009, . 2341 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2342 Bormann, "Neighbor Discovery Optimization for IPv6 over 2343 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2344 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2345 . 2347 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2348 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2349 in Low-Power and Lossy Networks", RFC 6997, 2350 DOI 10.17487/RFC6997, August 2013, 2351 . 2353 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2354 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2355 2014, . 2357 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2358 and M. Richardson, Ed., "A Security Threat Analysis for 2359 the Routing Protocol for Low-Power and Lossy Networks 2360 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2361 . 2363 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2364 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2365 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2366 May 2017, . 2368 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2369 Perkins, "Registration Extensions for IPv6 over Low-Power 2370 Wireless Personal Area Network (6LoWPAN) Neighbor 2371 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2372 . 2374 Authors' Addresses 2376 Maria Ines Robles 2377 Aalto University 2378 Innopoli 2379 Espoo 02150 2380 Finland 2382 Email: mariainesrobles@gmail.com 2384 Michael C. Richardson 2385 Sandelman Software Works 2386 470 Dawson Avenue 2387 Ottawa, ON K1Z 5V7 2388 CA 2390 Email: mcr+ietf@sandelman.ca 2391 URI: http://www.sandelman.ca/mcr/ 2393 Pascal Thubert 2394 Cisco Systems, Inc 2395 Village d'Entreprises Green Side 400, Avenue de Roumanille 2396 Batiment T3, Biot - Sophia Antipolis 06410 2397 France 2399 Email: pthubert@cisco.com