idnits 2.17.00 (12 Aug 2021) /tmp/idnits9781/draft-ietf-roll-useofrplinfo-27.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 294 has weird spacing: '... act chg ...' == Line 363 has weird spacing: '... act chg ...' == Line 2041 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 16, 2019) is 1101 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 2044, but not defined -- Looks like a reference, but probably isn't: '1' on line 1717 -- Looks like a reference, but probably isn't: '2' on line 1044 == 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 17, 2019 P. Thubert 7 Cisco 8 May 16, 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-27 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 17, 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" (RPL Packet Information or RPI), 138 carried within the IPv6 Hop-by-Hop header to quickly identify 139 inconsistencies (loops) in the routing topology. RFC 6554 [RFC6554] 140 defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header 141 to deliver datagrams within a RPL routing domain, particularly in 142 non-storing mode. 144 These various items are referred to as RPL artifacts, and they are 145 seen on all of the data-plane traffic that occurs in RPL routed 146 networks; they do not in general appear on the RPL control plane 147 traffic at all which is mostly hop-by-hop traffic (one exception 148 being DAO messages in non-storing mode). 150 It has become clear from attempts to do multi-vendor 151 interoperability, and from a desire to compress as many of the above 152 artifacts as possible that not all implementers agree when artifacts 153 are necessary, or when they can be safely omitted, or removed. 155 The ROLL WG analysized how [RFC2460] rules apply to storing and non- 156 storing use of RPL. The result was 24 data plane use cases. They 157 are exhaustively outlined here in order to be completely unambiguous. 158 During the processing of this document, new rules were published as 159 [RFC8200], and this document was updated to reflect the normative 160 changes in that document. 162 This document updates RFC6553, changing the RPI option value to make 163 RFC8200 routers ignore this option by default. 165 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 166 mechanism for compressing RPL Option information and Routing Header 167 type 3 (RH3) [RFC6554], as well as an efficient IPv6-in-IPv6 168 technique. 170 Since some of the uses cases here described, use IPv6-in-IPv6 171 encapsulation. It MUST take in consideration, when encapsulation is 172 applied, the RFC6040 [RFC6040], which defines how the explicit 173 congestion notification (ECN) field of the IP header should be 174 constructed on entry to and exit from any IPV6-in-IPV6 tunnel. 175 Additionally, it is recommended the reading of 176 [I-D.ietf-intarea-tunnels]. 178 1.1. Overview 180 The rest of the document is organized as follows: Section 2 describes 181 the used terminology. Section 3 describes the updates to RFC6553, 182 RFC6550 and RFC 8138. Section 4 provides the reference topology used 183 for the uses cases. Section 5 describes the uses cases included. 184 Section 6 describes the storing mode cases and section 7 the non- 185 storing mode cases. Section 8 describes the operational 186 considerations of supporting not-RPL-aware-leaves. Section 9 depicts 187 operational considerations for the proposed change on RPL Option 188 type, section 10 the IANA considerations and then section 11 189 describes the security aspects. 191 2. Terminology and Requirements Language 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 195 "OPTIONAL" in this document are to be interpreted as described in BCP 196 14 [RFC2119], [RFC8174] when, and only when, they appear in all 197 capitals, as shown here. 199 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 200 RPL, RPL Domain and ROLL. 202 RPL-node: A device which implements RPL, thus the device is RPL- 203 aware. Please note that the device can be found inside the LLN or 204 outside LLN. In this document a RPL-node which is a leaf of a 205 (Destination Oriented Directed Acyclic Graph) DODAG is called RPL- 206 aware-leaf (Raf). 208 RPL-not-capable: A device which does not implement RPL, thus the 209 device is not-RPL-aware. Please note that the device can be found 210 inside the LLN. In this document a not-RPL-aware node which is a 211 leaf of a DODAG is called not-RPL-aware-leaf (~Raf). 213 6LN: [RFC6775] defines it as: "A 6LoWPAN node is any host or router 214 participating in a LoWPAN. This term is used when referring to 215 situations in which either a host or router can play the role 216 described.". In this document, a 6LN acts as a leaf. 218 6LR: [RFC6775] defines it as:" An intermediate router in the LoWPAN 219 that is able to send and receive Router Advertisements (RAs) and 220 Router Solicitations (RSs) as well as forward and route IPv6 packets. 221 6LoWPAN routers are present only in route-over topologies." 223 6LBR: [RFC6775] defines it as:"A border router located at the 224 junction of separate 6LoWPAN networks or between a 6LoWPAN network 225 and another IP network. There may be one or more 6LBRs at the 226 6LoWPAN network boundary. A 6LBR is the responsible authority for 227 IPv6 prefix propagation for the 6LoWPAN network it is serving. An 228 isolated LoWPAN also contains a 6LBR in the network, which provides 229 the prefix(es) for the isolated network." 231 Flag Day: A transition that involves having a network with different 232 values of RPL Option Type. Thus the network does not work correctly. 234 Hop-by-hop re-encapsulation: The term "hop-by-hop re-encapsulation" 235 header refers to adding a header that originates from a node to an 236 adjacent node, using the addresses (usually the GUA or ULA, but could 237 use the link-local addresses) of each node. If the packet must 238 traverse multiple hops, then it must be decapsulated at each hop, and 239 then re-encapsulated again in a similar fashion. 241 RPL defines the RPL Control messages (control plane), a new ICMPv6 242 [RFC4443] message with Type 155. DIS (DODAG Information 243 Solicitation), DIO (DODAG Information Object) and DAO (Destination 244 Advertisement Object) messages are all RPL Control messages but with 245 different Code values. A RPL Stack is shown in Figure 1. 247 +--------------+ 248 | Upper Layers | 249 | | 250 +--------------+ 251 | RPL | 252 | | 253 +--------------+ 254 | ICMPv6 | 255 | | 256 +--------------+ 257 | IPv6 | 258 | | 259 +--------------+ 260 | 6LoWPAN | 261 | | 262 +--------------+ 263 | PHY-MAC | 264 | | 265 +--------------+ 267 Figure 1: RPL Stack. 269 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 270 it is fully stateful; in non-storing mode (RPL-NSM), it is fully 271 source routed. A RPL Instance is either fully storing or fully non- 272 storing, i.e. a RPL Instance with a combination of storing and non- 273 storing nodes is not supported with the current specifications at the 274 time of writing this document. 276 3. Updates to RFC6553, RFC6550 and RFC8138 278 3.1. Updates to RFC6553: Indicating the new RPI value. 280 This modification is required to be able to send, for example, IPv6 281 packets from a RPL-aware-leaf to a not-RPL-aware node through 282 Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 283 encapsulation. 285 [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in 286 the Option Type field of the RPL Option header, the two high order 287 bits must be set to '01' and the third bit is equal to '1'. The 288 first two bits indicate that the IPv6 node must discard the packet if 289 it doesn't recognize the option type, and the third bit indicates 290 that the Option Data may change in route. The remaining bits serve 291 as the option type. 293 Hex Value Binary Value 294 act chg rest Description Reference 295 --------- --- --- ------- ----------------- ---------- 296 0x63 01 1 00011 RPL Option [RFC6553] 298 Figure 2: Option Type in RPL Option. 300 This document illustrates that is is not always possible to know for 301 sure at the source that a packet will only travel within the RPL 302 domain or may leave it. 304 At the time [RFC6553] was published, leaking a Hop-by-Hop header in 305 the outer IPv6 header chain could potentially impact core routers in 306 the internet. So at that time, it was decided to encapsulate any 307 packet with a RPL option using IPv6-in-IPv6 in all cases where it was 308 unclear whether the packet would remain within the RPL domain. In 309 the exception case where a packet would still leak, the Option Type 310 would ensure that the first router in the Internet that does not 311 recognize the option would drop the packet and protect the rest of 312 the network. 314 Even with [RFC8138] that compresses the IP-in-IP header, this 315 approach yields extra bytes in a packet which means consuming more 316 energy, more bandwidth, incurring higher chances of loss and possibly 317 causing a fragmentation at the 6LoWPAN level. This impacts the daily 318 operation of constrained devices for a case that generally does not 319 happen and would not heavily impact the core anyway. 321 While intention was and remains that the Hop-by-Hop header with a RPL 322 option should be confined within the RPL domain, this specification 323 modifies this behavior in order to reduce the dependency on IP-in-IP 324 and protect the constrained devices. Section 4 of [RFC8200] 325 clarifies the behaviour of routers in the Internet as follows: "it is 326 now expected that nodes along a packet's delivery path only examine 327 and process the Hop-by-Hop Options header if explicitly configured to 328 do so". This means that while it should be avoided, the impact on 329 the Internet of leaking a Hop-by-Hop header is acceptable. 331 When unclear about the travel of a packet, it becomes preferable for 332 a source not to encapsulate, accepting the fact that the packet may 333 leave the RPL domain on its way to its destination. In that event, 334 the packet should reach its destination and should not be discarded 335 by the first node that does not recognize the RPL option. But with 336 the current value of the Option Type, if a node in the Internet is 337 configured to process the Hop-by-Hop header, and if such node 338 encounters an option with the first two bits set to 01 and conforms 339 to [RFC8200], it will drop the packet. Host systems should do the 340 same, irrespective of the configuration. 342 Thus, this document updates the Option Type field to (Figure 3): the 343 two high order bits MUST be set to '00' and the third bit is equal to 344 '1'. The first two bits indicate that the IPv6 node MUST skip over 345 this option and continue processing the header ([RFC8200] 346 Section 4.2) if it doesn't recognize the option type, and the third 347 bit continues to be set to indicate that the Option Data may change 348 en route. The remaining bits serve as the option type and remain as 349 0x3. This ensures that a packet that leaves the RPL domain of an LLN 350 (or that leaves the LLN entirely) will not be discarded when it 351 contains the [RFC6553] RPL Hop-by-Hop option known as RPI. 353 With the new Option Type, if an IPv6 (intermediate) node (RPL-not- 354 capable) receives a packet with an RPL Option, it should ignore the 355 Hop-by-Hop RPL option (skip over this option and continue processing 356 the header). This is relevant, as it was mentioned previously, in 357 the case that there is a flow from RPL-aware-leaf to Internet (see 358 Section 6.2.1). 360 This is a significant update to [RFC6553]. 362 Hex Value Binary Value 363 act chg rest Description Reference 364 --------- --- --- ------- ----------------- ---------- 365 0x23 00 1 00011 RPL Option [RFCXXXX] 367 Figure 3: Revised Option Type in RPL Option. 369 Without the signaling described below, this change would otherwise 370 create a flag day for existing networks which are currently using 371 0x63 as the RPI value. A move to 0x23 will not be understood by 372 those networks. It is suggested that implementations accept both 373 0x63 and 0x23 when processing. 375 When forwarding packets, implementations SHOULD use the same value as 376 it was received (This is required because, RPI type code can not be 377 changed by [RFC8200]). It allows to the network to be incrementally 378 upgraded, and for the DODAG root to know which parts of the network 379 are upgraded. 381 When originating new packets, implementations SHOULD have an option 382 to determine which value to originate with, this option is controlled 383 by the DIO option described below. 385 A network which is switching from straight 6lowpan compression 386 mechanism to those described in [RFC8138] will experience a flag day 387 in the data compression anyway, and if possible this change can be 388 deployed at the same time. 390 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 391 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 392 therefore no longer a necessity to remove the artifacts when sending 393 traffic to the Internet. This change clarifies when to use an IPv6- 394 in-IPv6 header, and how to address them: The Hop-by-Hop Options 395 Header containing the RPI option MUST always be added when 6LRs 396 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 397 headers MUST always be added when a 6LR find that it needs to insert 398 a Hop-by-Hop Options Header containing the RPI option. The IPv6-in- 399 IPv6 header is to be addressed to the RPL root when on the way up, 400 and to the end-host when on the way down. 402 Non-constrained uses of RPL are not in scope of this document, and 403 applicability statements for those uses may provide different advice, 404 E.g. [I-D.ietf-anima-autonomic-control-plane]. 406 In the non-storing case, dealing with not-RPL aware leaf nodes is 407 much easier as the 6LBR (DODAG root) has complete knowledge about the 408 connectivity of all DODAG nodes, and all traffic flows through the 409 root node. 411 The 6LBR can recognize not-RPL aware leaf nodes because it will 412 receive a DAO about that node from the 6LR immediately above that 413 not-RPL aware node. This means that the non-storing mode case can 414 avoid ever using hop-by-hop re-encapsulation headers for traffic 415 originating from the root to the leafs. 417 The non-storing mode case does not require the type change from 0x63 418 to 0x23, as the root can always create the right packet. The type 419 change does not adversely affect the non-storing case. 421 3.2. Updates to RFC6550: Indicating the new RPI in the DODAG 422 Configuration Option Flag. 424 In order to avoid a Flag Day caused by lack of interoperation between 425 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 426 in the DIO Configuration Option, to indicate when then new RPI value 427 can be safely used. This means, the flag is going to indicate the 428 type of RPI that the network is using. Thus, when a node join to a 429 network will know which value to use. With this, RPL-capable nodes 430 know if it is safe to use 0x23 when creating a new RPI. A node that 431 forwards a packet with an RPI MUST not modify the option type of the 432 RPI. 434 This is done via a DODAG Configuration Option flag which will 435 propagate through the network. If the flag is received with a value 436 zero (which is the default), then new nodes will remain in RFC6553 437 Compatible Mode; originating traffic with the old-RPI (0x63) value. 439 As stated in [RFC6550] the DODAG Configuration option is present in 440 DIO messages. The DODAG Configuration option distributes 441 configuration information. It is generally static, and does not 442 change within the DODAG. This information is configured at the DODAG 443 root and distributed throughout the DODAG with the DODAG 444 Configuration option. Nodes other than the DODAG root do not modify 445 this information when propagating the DODAG Configuration option. 447 The DODAG Configuration Option has a Flag field which is modified by 448 this document. Currently, the DODAG Configuration Option in 449 [RFC6550] states: "the unused bits MUST be initialize to zero by the 450 sender and MUST be ignored by the receiver". 452 Bit number three of the flag field in the DODAG Configuration option 453 is to be used as shown in Figure 4 : 455 +------------+-----------------+---------------+ 456 | Bit number | Description | Reference | 457 +------------+-----------------+---------------+ 458 | 3 | RPI 0x23 enable | This document | 459 +------------+-----------------+---------------+ 461 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 462 day. 464 In case of rebooting, the node (6LN or 6LR) does not remember if the 465 flag is set, so DIO messages would be set with the flag unset until a 466 DIO is received with the flag set. 468 3.3. Updates to RFC8138: Indicating the way to decompress with the new 469 RPI value. 471 This modification is required to be able to decompress the RPL RPI 472 option with the new value (0x23). 474 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 475 in section 6. A node that is decompressing this header MUST 476 decompress using the RPL RPI option type that is currently active: 477 that is, a choice between 0x23 (new) and 0x63 (old). The node will 478 know which to use based upon the presence of the flag in the DODAG 479 Configuration Option defined in Section 3.2. E.g. If the network is 480 in 0x23 mode (by DIO option), then it should be decompressed to 0x23. 482 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 483 header. 485 There are potential significant advantages to having a single code 486 path that always processes IPv6-in-IPv6 headers with no conditional 487 branches. 489 In Storing Mode, for the examples of Flow from RPL-aware-leaf to not- 490 RPL-aware-leaf and not-RPL-aware-leaf to not-RPL-aware-leaf comprise 491 an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in- 492 IPv6 header is MANDATORY in this case, and it SHOULD be compressed 493 with [RFC8138] section 7. As exemplification of compressing the RPI, 494 section A.1 of [RFC8138] illustrates the case in Storing mode where 495 the packet is received from the Internet, then the root encapsulates 496 the packet to insert the RPI. The result is shown in Figure 5. 498 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 499 |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP 500 |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld 501 +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... 503 Figure 5: RPI Inserted by the Root in Storing Mode 505 4. Sample/reference topology 507 A RPL network in general is composed of a 6LBR (6LoWPAN Border 508 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 509 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 511 Figure 6 shows the reference RPL Topology for this document. The 512 letters above the nodes are there so that they may be referenced in 513 subsequent sections. In the figure, 6LR represents a full router 514 node. The 6LN is a RPL aware router, or host (as a leaf). 515 Additionally, for simplification purposes, it is supposed that the 516 6LBR has direct access to Internet, thus the 6BBR is not present in 517 the figure. 519 The 6LN leaves (Raf) marked as (F, H and I) are RPL nodes with no 520 children hosts. 522 The leafs marked as ~Raf (G and J) are devices which do not speak RPL 523 at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ 524 DAC and efficient-ND only to participate in the network [RFC6775]. 525 In the document these leafs (G and J) are also referred to as an IPv6 526 node. 528 The 6LBR ("A") in the figure is the root of the Global DODAG. 530 +------------+ 531 | INTERNET ----------+ 532 | | | 533 +------------+ | 534 | 535 | 536 | 537 A | 538 +-------+ 539 |6LBR | 540 +-----------|(root) |-------+ 541 | +-------+ | 542 | | 543 | | 544 | | 545 | | 546 | B |C 547 +---|---+ +---|---+ 548 | 6LR | | 6LR | 549 +---------| |--+ +--- ---+ 550 | +-------+ | | +-------+ | 551 | | | | 552 | | | | 553 | | | | 554 | | | | 555 | D | E | | 556 +-|-----+ +---|---+ | | 557 | 6LR | | 6LR | | | 558 | | +------ | | | 559 +---|---+ | +---|---+ | | 560 | | | | | 561 | | +--+ | | 562 | | | | | 563 | | | | | 564 | | | I | J | 565 F | | G | H | | 566 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 567 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 568 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 569 +-------+ +-------+ +------+ +-------+ +-------+ 571 Figure 6: A reference RPL Topology. 573 5. Use cases 575 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 576 encapsulation are going to be analyzed for a number of representative 577 traffic flows. 579 This document assumes that the LLN is using the no-drop RPI option 580 (0x23). 582 The uses cases describe the communication between RPL-aware-nodes, 583 with the root (6LBR), and with Internet. This document also 584 describes the communication between nodes acting as leaves that do 585 not understand RPL (~Raf nodes), but are part of the LLN. (e.g. 586 Section 6.1.4 Flow from not-RPL-aware-leaf to root) This document 587 depicts as well the communication inside of the LLN when it has the 588 final destination addressed outside of the LLN e.g. with destination 589 to Internet. For example, Section 6.2.3 Flow from not-RPL-aware-leaf 590 to Internet 592 The uses cases comprise as follow: 594 Interaction between Leaf and Root: 596 RPL-aware-leaf(Raf) to root 598 root to RPL-aware-leaf(Raf) 600 not-RPL-aware-leaf(~Raf) to root 602 root to not-RPL-aware-leaf(~Raf) 604 Interaction between Leaf and Internet: 606 RPL-aware-leaf(Raf) to Internet 608 Internet to RPL-aware-leaf(Raf) 610 not-RPL-aware-leaf(~Raf) to Internet 612 Internet to not-RPL-aware-leaf(~Raf) 614 Interaction between Leafs: 616 RPL-aware-leaf(Raf) to RPL-aware-leaf(Raf) (storing and non- 617 storing) 619 RPL-aware-leaf(Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 620 not-RPL-aware-leaf(~Raf) to RPL-aware-leaf(Raf) (storing and non- 621 storing) 623 not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing) 625 This document is consistent with the rule that a Header cannot be 626 inserted or removed on the fly inside an IPv6 packet that is being 627 routed. This is a fundamental precept of the IPv6 architecture as 628 outlined in [RFC8200]. Extensions headers may not be added or 629 removed except by the sender or the receiver. 631 However, unlike [RFC6553], the Hop-by-Hop Option Header used for the 632 RPI artifact has the first two bits set to '00'. This means that the 633 RPI artifact will be ignored when received by a host or router that 634 does not understand that option ( Section 4.2 [RFC8200]). 636 This means that when the no-drop RPI option code 0x23 is used, a 637 packet that leaves the RPL domain of an LLN (or that leaves the LLN 638 entirely) will not be discarded when it contains the [RFC6553] RPL 639 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is 640 left in place even if the end host does not understand it. 642 NOTE: No clear attack has been described when the RPI information is 643 released to the Internet. At a minimum, it is clear that the RPI 644 option would waste some network bandwidth when it escapes. This is 645 traded off against the savings in the LLN by not having to 646 encapsulate the packet in order to remove the artifact. Please check 647 the Security Considerations sections Section 11 for further details. 649 As the rank information in the RPI artifact is changed at each hop, 650 it will typically be zero when it arrives at the DODAG root. The 651 DODAG root MUST force it to zero when passing the packet out to the 652 Internet. The Internet will therefore not see any SenderRank 653 information. 655 Despite being legal to leave the RPI artifact in place, an 656 intermediate router that needs to add an extension header (e.g. RH3 657 or RPI Option) MUST still encapsulate the packet in an (additional) 658 outer IP header. The new header is placed after this new outer IP 659 header. 661 A corollary is that an RH3 or RPI Option can only be removed by an 662 intermediate router if it is placed in an encapsulating IPv6 Header, 663 which is addressed TO the intermediate router. When it does so, the 664 whole encapsulating header must be removed. (A replacement may be 665 added). This sometimes can result in outer IP headers being 666 addressed to the next hop router using link-local address. 668 Both RPI and RH3 headers may be modified in very specific ways by 669 routers on the path of the packet without the need to add and remove 670 an encapsulating header. Both headers were designed with this 671 modification in mind, and both the RPL RH3 and the RPL option are 672 marked mutable but recoverable: so an IPsec AH security header can be 673 applied across these headers, but it can not secure the values which 674 mutate. 676 RPI MUST be present in every single RPL data packet. 678 Prior to [RFC8138], there was significant interest in removing the 679 RPI for downward flows in non-storing mode. The exception covered a 680 very small number of cases, and causes significant interoperability 681 challenges, yet costed significant code and testing complexity. The 682 ability to compress the RPI down to three bytes or less removes much 683 of the pressure to optimize this any further 684 [I-D.ietf-anima-autonomic-control-plane]. 686 The earlier examples are more extensive to make sure that the process 687 is clear, while later examples are more concise. 689 6. Storing mode 691 In storing mode (fully stateful), the sender can determine if the 692 destination is inside the LLN by looking if the destination address 693 is matched by the DIO's Prefix Information Option (PIO) option. 695 The following table (Figure 7) itemizes which headers are needed in 696 each of the following scenarios. It indicates if the IPv6-in-IPv6 697 header that is added, must be addressed to the final destination (the 698 Raf node that is the target(tgt)), to the "root" or if a hop-by-hop 699 header must be added (indicated by "hop"). 701 In cases where no IPv6-in-IPv6 header is needed, the column states as 702 "No". If the IPv6-in-IPv6 header is needed is a "must". 704 In all cases the RPI headers are needed, since it identifies 705 inconsistencies (loops) in the routing topology. In all cases the 706 RH3 is not needed because it is not used in storing mode. 708 In each case, 6LR_i is the intermediate router from source to 709 destination. "1 <= i <= n", n is the number of routers (6LR) that 710 the packet goes through from source (6LN) to destination. 712 The leaf can be a router 6LR or a host, both indicated as 6LN. The 713 root refers to the 6LBR (see Figure 6). 715 +---------------------+--------------+------------+------------------+ 716 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 717 +---------------------+--------------+------------+------------------+ 718 | | Raf to root | No | No | 719 + +--------------+------------+------------------+ 720 | Leaf - Root | root to Raf | No | No | 721 + +--------------+------------+------------------+ 722 | | root to ~Raf | No | No | 723 + +--------------+------------+------------------+ 724 | | ~Raf to root | must | root | 725 +---------------------+--------------+------------+------------------+ 726 | | Raf to Int | No | No | 727 + +--------------+------------+------------------+ 728 | Leaf - Internet | Int to Raf | must | Raf (tgt) | 729 + +--------------+------------+------------------+ 730 | | ~Raf to Int | must | root | 731 + +--------------+------------+------------------+ 732 | | Int to ~Raf | must | hop | 733 +---------------------+--------------+------------+------------------+ 734 | | Raf to Raf | No | No | 735 + +--------------+------------+------------------+ 736 | | Raf to ~Raf | No | No | 737 + Leaf - Leaf +--------------+------------+------------------+ 738 | | ~Raf to Raf | must | Raf (tgt) | 739 + +--------------+------------+------------------+ 740 | | ~Raf to ~Raf | must | hop | 741 +---------------------+--------------+------------+------------------+ 743 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 745 6.1. Storing Mode: Interaction between Leaf and Root 747 In this section is described the communication flow in storing mode 748 (SM) between, 750 RPL-aware-leaf to root 752 root to RPL-aware-leaf 754 not-RPL-aware-leaf to root 756 root to not-RPL-aware-leaf 758 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 760 In storing mode, RFC 6553 (RPI) is used to send RPL Information 761 instanceID and rank information. 763 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 764 generally issue DIO messages; a leaf node accepts DIO messages from 765 upstream. (When the inconsistency in routing occurs, a leaf node 766 will generate a DIO with an infinite rank, to fix it). It may issue 767 DAO and DIS messages though it generally ignores DAO and DIS 768 messages. 770 In this case the flow comprises: 772 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 774 For example, a communication flow could be: Node F --> Node D --> 775 Node B --> Node A root(6LBR) 777 As it was mentioned in this document 6LRs, 6LBR are always full- 778 fledged RPL routers. 780 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 781 (Node E) which decrements the rank in RPI and sends the packet up. 782 When the packet arrives at 6LBR (Node A), the RPI is removed and the 783 packet is processed. 785 No IPv6-in-IPv6 header is required. 787 The RPI header can be removed by the 6LBR because the packet is 788 addressed to the 6LBR. The 6LN must know that it is communicating 789 with the 6LBR to make use of this scenario. The 6LN can know the 790 address of the 6LBR because it knows the address of the root via the 791 DODAGID in the DIO messages. 793 The Table 1 summarizes what headers are needed for this use case. 795 +-------------------+---------+-------+----------+ 796 | Header | 6LN src | 6LR_i | 6LBR dst | 797 +-------------------+---------+-------+----------+ 798 | Inserted headers | RPI | -- | -- | 799 | Removed headers | -- | -- | RPI | 800 | Re-added headers | -- | -- | -- | 801 | Modified headers | -- | RPI | -- | 802 | Untouched headers | -- | -- | -- | 803 +-------------------+---------+-------+----------+ 805 Table 1: Storing mode: Summary of the use of headers from RPL-aware- 806 leaf to root 808 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 810 In this case the flow comprises: 812 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 814 For example, a communication flow could be: Node A root(6LBR) --> 815 Node B --> Node D --> Node F 817 In this case the 6LBR inserts RPI header and sends the packet down, 818 the 6LR is going to increment the rank in RPI (it examines the 819 instanceID to identify the right forwarding table), the packet is 820 processed in the 6LN and the RPI removed. 822 No IPv6-in-IPv6 header is required. 824 The Table 2 summarizes what headers are needed for this use case. 826 +-------------------+------+-------+------+ 827 | Header | 6LBR | 6LR_i | 6LN | 828 +-------------------+------+-------+------+ 829 | Inserted headers | RPI | -- | -- | 830 | Removed headers | -- | -- | RPI | 831 | Re-added headers | -- | -- | -- | 832 | Modified headers | -- | RPI | -- | 833 | Untouched headers | -- | -- | -- | 834 +-------------------+------+-------+------+ 836 Table 2: Storing mode: Summary of the use of headers from root to 837 RPL-aware-leaf 839 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 841 In this case the flow comprises: 843 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 845 For example, a communication flow could be: Node A root(6LBR) --> 846 Node B --> Node E --> Node G 848 As the RPI extension can be ignored by the not-RPL-aware leaf, this 849 situation is identical to the previous scenario. 851 The Table 3 summarizes what headers are needed for this use case. 853 +-------------------+----------+-------+----------------+ 854 | Header | 6LBR src | 6LR_i | IPv6 dst node | 855 +-------------------+----------+-------+----------------+ 856 | Inserted headers | RPI | -- | -- | 857 | Removed headers | -- | -- | -- | 858 | Re-added headers | -- | -- | -- | 859 | Modified headers | -- | RPI | -- | 860 | Untouched headers | -- | -- | RPI (Ignored) | 861 +-------------------+----------+-------+----------------+ 863 Table 3: Storing mode: Summary of the use of headers from root to 864 not-RPL-aware-leaf 866 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 868 In this case the flow comprises: 870 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 872 For example, a communication flow could be: Node G --> Node E --> 873 Node B --> Node A root(6LBR) 875 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 876 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 877 header. The IPv6-in-IPv6 header can be addressed to the next hop 878 (Node B), or to the root (Node A). The root removes the header and 879 processes the packet. 881 The Figure 8 shows the table that summarizes what headers are needed 882 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 884 +-----------+------+--------------+-----------------+--------------------+ 885 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 886 | | src | | | | 887 | | node | | | | 888 +-----------+------+--------------+-----------------+--------------------+ 889 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 890 | headers | | | | | 891 +-----------+------+--------------+-----------------+--------------------+ 892 | Removed | -- | -- | -- | IP6-IP6(RPI)[1][2] | 893 | headers | | | | | 894 +-----------+------+--------------+-----------------+--------------------+ 895 | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | 896 | headers | | | | | 897 +-----------+------+--------------+-----------------+--------------------+ 898 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 899 | headers | | | | | 900 +-----------+------+--------------+-----------------+--------------------+ 901 | Untouched | -- | -- | -- | -- | 902 | headers | | | | | 903 +-----------+------+--------------+-----------------+--------------------+ 905 Figure 8: Storing mode: Summary of the use of headers from not-RPL- 906 aware-leaf to root. [[1] Case where the IPv6-in-IPv6 header is 907 addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 908 header is addressed to the root (Node A). 910 6.2. Storing Mode: Interaction between Leaf and Internet. 912 In this section is described the communication flow in storing mode 913 (SM) between, 915 RPL-aware-leaf to Internet 917 Internet to RPL-aware-leaf 919 not-RPL-aware-leaf to Internet 921 Internet to not-RPL-aware-leaf 923 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 925 RPL information from RFC 6553 may go out to Internet as it will be 926 ignored by nodes which have not been configured to be RPI aware. 928 In this case the flow comprises: 930 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 931 For example, the communication flow could be: Node F --> Node D --> 932 Node B --> Node A root(6LBR) --> Internet 934 No IPv6-in-IPv6 header is required. 936 Note: In this use case it is used a node as leaf, but this use case 937 can be also applicable to any RPL-node type (e.g. 6LR) 939 The Table 4 summarizes what headers are needed for this use case. 941 +-------------------+---------+-------+------+----------------+ 942 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 943 +-------------------+---------+-------+------+----------------+ 944 | Inserted headers | RPI | -- | -- | -- | 945 | Removed headers | -- | -- | -- | -- | 946 | Re-added headers | -- | -- | -- | -- | 947 | Modified headers | -- | RPI | -- | -- | 948 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 949 +-------------------+---------+-------+------+----------------+ 951 Table 4: Storing mode: Summary of the use of headers from RPL-aware- 952 leaf to Internet 954 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 956 In this case the flow comprises: 958 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 960 For example, a communication flow could be: Internet --> Node A 961 root(6LBR) --> Node B --> Node D --> Node F 963 When the packet arrives from Internet to 6LBR the RPI header is added 964 in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination 965 address set to the 6LR) and sent to 6LR, which modifies the rank in 966 the RPI. When the packet arrives at 6LN the RPI header is removed 967 and the packet processed. 969 The Figure 9 shows the table that summarizes what headers are needed 970 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 972 +-----------+----------+--------------+--------------+------------------+ 973 | Header | Internet | 6LBR | 6LR_i | 6LN dst | 974 | | src | | | | 975 +-----------+----------+--------------+--------------+------------------+ 976 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 977 | headers | | | | | 978 +-----------+----------+--------------+--------------+------------------+ 979 | Removed | -- | -- | -- | IP6-IP6(RPI) | 980 | headers | | | | | 981 +-----------+----------+--------------+--------------+------------------+ 982 | Re-added | -- | -- | -- | -- | 983 | headers | | | | | 984 +-----------+----------+--------------+--------------+------------------+ 985 | Modified | -- | -- | IP6-IP6(RPI) | -- | 986 | headers | | | | | 987 +-----------+----------+--------------+--------------+------------------+ 988 | Untouched | -- | -- | -- | -- | 989 | headers | | | | | 990 +-----------+----------+--------------+--------------+------------------+ 992 Figure 9: Storing mode: Summary of the use of headers from Internet 993 to RPL-aware-leaf. 995 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 997 In this case the flow comprises: 999 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1000 Internet 1002 For example, a communication flow could be: Node G --> Node E --> 1003 Node B --> Node A root(6LBR) --> Internet 1005 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 1006 either to the root, or hop-by-hop such that the root can remove the 1007 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 1008 root cause less processing overhead. On the other hand, with hop-by- 1009 hop the intermediate routers can check the routing tables for a 1010 better routing path, thus it could be more efficient and faster. 1011 Implementation should decide which approach to take. 1013 The originating node will ideally leave the IPv6 flow label as zero 1014 so that the packet can be better compressed through the LLN. The 1015 6LBR will set the flow label of the packet to a non-zero value when 1016 sending to the Internet. 1018 The Figure 10 shows the table that summarizes what headers are needed 1019 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1021 +---------+-------+------------+--------------+-------------+--------+ 1022 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1023 | | src | | [i=2,...,n] | | dst | 1024 | | node | | | | | 1025 +---------+-------+------------+--------------+-------------+--------+ 1026 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1027 | headers | | | [2] | | | 1028 +---------+-------+------------+--------------+-------------+--------+ 1029 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1030 | headers | | | [2] | [1][2] | | 1031 +---------+-------+------------+--------------+-------------+--------+ 1032 | Re-added| -- | -- | -- | -- | -- | 1033 | headers | | | | | | 1034 +---------+-------+------------+--------------+-------------+--------+ 1035 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1036 | headers | | | [1] | | | 1037 +---------+-------+------------+--------------+-------------+--------+ 1038 |Untouched| -- | -- | -- | -- | -- | 1039 | headers | | | | | | 1040 +---------+-------+------------+--------------+-------------+--------+ 1042 Figure 10: Storing mode: Summary of the use of headers from not-RPL- 1043 aware-leaf to Internet. [1] Case when packet is addressed to the 1044 root. [2] Case when the packet is addressed hop-by-hop. 1046 6.2.4. SM: Example of Flow from Internet to not-RPL-aware-leaf. 1048 In this case the flow comprises: 1050 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1052 For example, a communication flow could be: Internet --> Node A 1053 root(6LBR) --> Node B --> Node E --> Node G 1055 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 1056 header. The IPv6-in-IPv6 is addressed hop-by-hop. 1058 The final node should be able to remove one or more IPv6-in-IPv6 1059 headers which are all addressed to it. The final node does not 1060 process the RPI, the node ignores the RPI. Furhter details about 1061 this are mentioned in [I-D.thubert-roll-unaware-leaves], which 1062 specifies RPL routing for a 6LN acting as a plain host and not aware 1063 of RPL. 1065 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1066 zero in order to aid in compression. 1068 The Figure 11 shows the table that summarizes what headers are needed 1069 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1071 +-----------+----------+--------------+--------------+--------------+ 1072 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1073 | | src | | | | 1074 +-----------+----------+--------------+--------------+--------------+ 1075 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1076 | headers | | | | | 1077 +-----------+----------+--------------+--------------+--------------+ 1078 | Removed | -- | -- | | IP6-IP6(RPI)| 1079 | headers | | | | RPI Ignored | 1080 +-----------+----------+--------------+--------------+--------------+ 1081 | Re-added | -- | -- | -- | -- | 1082 | headers | | | | | 1083 +-----------+----------+--------------+--------------+--------------+ 1084 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1085 | headers | | | | | 1086 +-----------+----------+--------------+--------------+--------------+ 1087 | Untouched | -- | -- | -- | -- | 1088 | headers | | | | | 1089 +-----------+----------+--------------+--------------+--------------+ 1091 Figure 11: Storing mode: Summary of the use of headers from Internet 1092 to not-RPL-aware-leaf. 1094 6.3. Storing Mode: Interaction between Leaf and Leaf 1096 In this section is described the communication flow in storing mode 1097 (SM) between, 1099 RPL-aware-leaf to RPL-aware-leaf 1101 RPL-aware-leaf to not-RPL-aware-leaf 1103 not-RPL-aware-leaf to RPL-aware-leaf 1105 not-RPL-aware-leaf to not-RPL-aware-leaf 1107 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1109 In [RFC6550] RPL allows a simple one-hop optimization for both 1110 storing and non-storing networks. A node may send a packet destined 1111 to a one-hop neighbor directly to that node. See section 9 in 1112 [RFC6550]. 1114 When the nodes are not directly connected, then in storing mode, the 1115 flow comprises: 1117 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1119 For example, a communication flow could be: Node F --> Node D --> 1120 Node B --> Node E --> Node H 1122 6LR_ia (Node D) is the intermediate router from source to the common 1123 parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the number 1124 of routers (6LR) that the packet goes through from 6LN (Node F) to 1125 the common parent (6LR_x). 1127 6LR_id (Node E) is the intermediate router from the common parent 1128 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1129 <= m", m is the number of routers (6LR) that the packet goes through 1130 from the common parent (6LR_x) to destination 6LN. 1132 It is assumed that the two nodes are in the same RPL Domain (that 1133 they share the same DODAG root). At the common parent (Node B), the 1134 direction of RPI is changed (from increasing to decreasing the rank). 1136 While the 6LR nodes will update the RPI, no node needs to add or 1137 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1139 The Table 5 summarizes what headers are needed for this use case. 1141 +---------------+--------+--------+---------------+--------+--------+ 1142 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1143 | | src | | parent) | | dst | 1144 +---------------+--------+--------+---------------+--------+--------+ 1145 | Inserted | RPI | -- | -- | -- | -- | 1146 | headers | | | | | | 1147 | Removed | -- | -- | -- | -- | RPI | 1148 | headers | | | | | | 1149 | Re-added | -- | -- | -- | -- | -- | 1150 | headers | | | | | | 1151 | Modified | -- | RPI | RPI | RPI | -- | 1152 | headers | | | | | | 1153 | Untouched | -- | -- | -- | -- | -- | 1154 | headers | | | | | | 1155 +---------------+--------+--------+---------------+--------+--------+ 1157 Table 5: Storing mode: Summary of the use of headers for RPL-aware- 1158 leaf to RPL-aware-leaf 1160 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 1162 In this case the flow comprises: 1164 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1165 6LN (IPv6) 1167 For example, a communication flow could be: Node F --> Node D --> 1168 Node B --> Node E --> Node G 1170 6LR_ia is the intermediate router from source (6LN) to the common 1171 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1172 routers (6LR) that the packet goes through from 6LN to the common 1173 parent (6LR_x). 1175 6LR_id (Node E) is the intermediate router from the common parent 1176 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1177 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1178 the packet goes through from the common parent (6LR_x) to destination 1179 6LN. 1181 This situation is identical to the previous situation Section 6.3.1 1183 The Table 6 summarizes what headers are needed for this use case. 1185 +-----------+------+--------+---------------+--------+--------------+ 1186 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | 1187 | | src | | parent) | | node | 1188 +-----------+------+--------+---------------+--------+--------------+ 1189 | Inserted | RPI | -- | -- | -- | -- | 1190 | headers | | | | | | 1191 | Removed | -- | -- | -- | -- | -- | 1192 | headers | | | | | | 1193 | Re-added | -- | -- | -- | -- | -- | 1194 | headers | | | | | | 1195 | Modified | -- | RPI | RPI | RPI | -- | 1196 | headers | | | | | | 1197 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1198 | headers | | | | | | 1199 +-----------+------+--------+---------------+--------+--------------+ 1201 Table 6: Storing mode: Summary of the use of headers for RPL-aware- 1202 leaf to not-RPL-aware-leaf 1204 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1206 In this case the flow comprises: 1208 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1209 6LR_id --> 6LN 1210 For example, a communication flow could be: Node G --> Node E --> 1211 Node B --> Node D --> Node F 1213 6LR_ia (Node E) is the intermediate router from source (not-RPL-aware 1214 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In this 1215 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1216 packet ges through from source to the common parent. 1218 6LR_id (Node D) is the intermediate router from the common parent 1219 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1220 <= m", m is the number of routers (6LR) that the packet goes through 1221 from the common parent (6LR_x) to destination 6LN. 1223 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1224 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1225 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1226 (Node F). 1228 The Figure 12 shows the table that summarizes what headers are needed 1229 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1231 +----------+-----+--------------+--------------+--------------+------------+ 1232 | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | 1233 | |src | | Parent | | dst | 1234 | |node | | (6LRx) | | | 1235 +----------+-----+--------------+--------------+--------------+------------+ 1236 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1237 | headers | | | | | | 1238 +----------+-----+--------------+--------------+--------------+------------+ 1239 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1240 | headers | | | | | | 1241 +----------+-----+--------------+--------------+--------------+------------+ 1242 | Re-added | -- | -- | -- | -- | -- | 1243 | headers | | | | | | 1244 +----------+-----+--------------+--------------+--------------+------------+ 1245 | Modified | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- | 1246 | headers | | | | | | 1247 +----------+-----+--------------+--------------+--------------+------------+ 1248 |Untouched | -- | -- | -- | -- | -- | 1249 | headers | | | | | | 1250 +----------+-----+--------------+--------------+--------------+------------+ 1252 Figure 12: Storing mode: Summary of the use of headers from not-RPL- 1253 aware-leaf to RPL-aware-leaf. 1255 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1256 leaf 1258 In this case the flow comprises: 1260 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id 1261 --> not-RPL-aware 6LN (IPv6 dst) 1263 For example, a communication flow could be: Node G --> Node E --> 1264 Node B --> Node A (root) --> Node C --> Node J 1266 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1267 router from the not-RPL-aware source (Node G) to the root (6LBR) 1268 (Node A). In this case, "1 < ia <= n", n is the number of routers 1269 (6LR) that the packet goes through from IPv6 src to the root. 1271 6LR_id (C) is the intermediate router from the root (Node A) to the 1272 destination Node J. In this case, "1 <= id <= m", m is the number of 1273 routers (6LR) that the packet goes through from the root to 1274 destination (IPv6 dst). 1276 The 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 hop-by-hop. 1282 The Figure 13 shows the table that summarizes what headers are needed 1283 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1285 +---------+------+-------+-------+---------+-------+-------+ 1286 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | 1287 | | src | | | | | dst | 1288 | | node | | | | | node | 1289 +---------+------+-------+-------+---------+-------+-------+ 1290 | Inserted| -- |IP6-IP6| -- | | -- | -- | 1291 | headers | | (RPI )| | | | | 1292 | | | | | | | | 1293 +---------+------+-------+-------+---------+-------+-------+ 1294 | Removed | -- | -- | -- | | -- |IP6-IP6| 1295 | headers | | | | | |(RPI) | 1296 | | | | | | | RPI | 1297 | | | | | | |Ignored| 1298 +---------+------+-------+-------+---------+-------+-------+ 1299 | Re-added| -- | -- | -- | -- | -- | -- | 1300 | headers | | | | | | | 1301 +---------+------+-------+-------+---------+-------+-------+ 1302 | Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | 1303 | headers | | | (RPI) | (RPI) | (RPI) | | 1304 | | | | | | | | 1305 +---------+------+-------+-------+---------+-------+-------+ 1306 |Untouched| -- | -- | -- | -- | -- | -- | 1307 | headers | | | | | | | 1308 +---------+------+-------+-------+---------+-------+-------+ 1310 Figure 13: Storing mode: Summary of the use of headers from not-RPL- 1311 aware-leaf to not-RPL-aware-leaf 1313 7. Non Storing mode 1315 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1316 root) has complete knowledge about the connectivity of all DODAG 1317 nodes, and all traffic flows through the root node. Thus, there is 1318 no need for all nodes to know about the existence of not-RPL aware 1319 nodes. Only the 6LBR needs to act if compensation is necessary for 1320 not-RPL aware receivers. 1322 The following table (Figure 14) summarizes what headers are needed in 1323 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1324 IPv6 header are to be inserted. It depicts the target destination 1325 address possible (indicated by "Raf"), to a 6LR (parent of a 6LN) or 1326 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1327 column states as "No". There is no expectation on RPL that RPI can 1328 be omitted, because it is needed for routing, quality of service and 1329 compression. This specification expects that is always a RPI 1330 Present. 1332 The leaf can be a router 6LR or a host, both indicated as 6LN 1333 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1334 where the RPI header may still be needed for the instanceID to be 1335 available for priority/channel selection at each hop. 1337 +-----------------+--------------+-----+-----+------------+------------+ 1338 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1339 | between | | | | | dst | 1340 +-----------------+--------------+-----+-----+------------+------------+ 1341 | | Raf to root | Yes | No | No | No | 1342 + +--------------+-----+-----+------------+------------+ 1343 | Leaf - Root | root to Raf | Yes | Yes | No | No | 1344 + +--------------+-----+-----+------------+------------+ 1345 | | root to ~Raf | Yes | Yes | must | 6LR | 1346 | | | (1) | | | | 1347 + +--------------+-----+-----+------------+------------+ 1348 | | ~Raf to root | Yes | No | must | root | 1349 +-----------------+--------------+-----+-----+------------+------------+ 1350 | | Raf to Int | Yes | No | No | No | 1351 + +--------------+-----+-----+------------+------------+ 1352 | Leaf - Internet | Int to Raf | Yes | Yes | must | Raf | 1353 + +--------------+-----+-----+------------+------------+ 1354 | | ~Raf to Int | Yes | No | must | root | 1355 + +--------------+-----+-----+------------+------------+ 1356 | | Int to ~Raf | Yes | Yes | must | 6LR | 1357 +-----------------+--------------+-----+-----+------------+------------+ 1358 | | Raf to Raf | Yes | Yes | must | root/Raf | 1359 + +--------------+-----+-----+------------+------------+ 1360 | | Raf to ~Raf | Yes | Yes | must | root/6LR | 1361 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1362 | | ~Raf to Raf | Yes | Yes | must | root/Raf | 1363 + +--------------+-----+-----+------------+------------+ 1364 | | ~Raf to ~Raf | Yes | Yes | must | root/6LR | 1365 +-----------------+--------------+-----+-----+------------+------------+ 1367 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1368 RH3, IPv6-in-IPv6 encapsulation. 1370 7.1. Non-Storing Mode: Interaction between Leaf and Root 1372 In this section is described the communication flow in Non Storing 1373 Mode (Non-SM) between, 1375 RPL-aware-leaf to root 1377 root to RPL-aware-leaf 1379 not-RPL-aware-leaf to root 1380 root to not-RPL-aware-leaf 1382 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1384 In non-storing mode the leaf node uses default routing to send 1385 traffic to the root. The RPI header must be included since it 1386 contains the rank information, which is used to avoid/detect loops. 1388 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1390 For example, a communication flow could be: Node F --> Node D --> 1391 Node B --> Node A (root) 1393 6LR_i is the intermediate router from source to destination. In this 1394 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1395 goes through from source (6LN) to destination (6LBR). 1397 This situation is the same case as storing mode. 1399 The Table 7 summarizes what headers are needed for this use case. 1401 +-------------------+---------+-------+----------+ 1402 | Header | 6LN src | 6LR_i | 6LBR dst | 1403 +-------------------+---------+-------+----------+ 1404 | Inserted headers | RPI | -- | -- | 1405 | Removed headers | -- | -- | RPI | 1406 | Re-added headers | -- | -- | -- | 1407 | Modified headers | -- | RPI | -- | 1408 | Untouched headers | -- | -- | -- | 1409 +-------------------+---------+-------+----------+ 1411 Table 7: Non Storing mode: Summary of the use of headers from RPL- 1412 aware-leaf to root 1414 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1416 In this case the flow comprises: 1418 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1420 For example, a communication flow could be: Node A (root) --> Node B 1421 --> Node D --> Node F 1423 6LR_i is the intermediate router from source to destination. In this 1424 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1425 goes through from source (6LBR) to destination (6LN). 1427 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1428 necessary as the traffic originates with an RPL aware node, the 6LBR. 1429 The destination is known to be RPL-aware because the root knows the 1430 whole topology in non-storing mode. 1432 The Table 8 summarizes what headers are needed for this use case. 1434 +-------------------+----------+-----------+-----------+ 1435 | Header | 6LBR src | 6LR_i | 6LN dst | 1436 +-------------------+----------+-----------+-----------+ 1437 | Inserted headers | RPI, RH3 | -- | -- | 1438 | Removed headers | -- | -- | RH3, RPI | 1439 | Re-added headers | -- | -- | -- | 1440 | Modified headers | -- | RPI, RH3 | -- | 1441 | Untouched headers | -- | -- | -- | 1442 +-------------------+----------+-----------+-----------+ 1444 Table 8: Non Storing mode: Summary of the use of headers from root to 1445 RPL-aware-leaf 1447 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1449 In this case the flow comprises: 1451 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1453 For example, a communication flow could be: Node A (root) --> Node B 1454 --> Node E --> Node G 1456 6LR_i is the intermediate router from source to destination. In this 1457 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1458 goes through from source (6LBR) to destination (IPv6). 1460 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1461 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1462 but left there. As the RPI is added, then the IPv6 node which does 1463 not understand the RPI, will ignore it (following RFC8200), thus 1464 encapsulation is not necessary. 1466 The Figure 15 depicts the table that summarizes what headers are 1467 needed for this use case. 1469 +-----------+----------+--------------+----------------+----------+ 1470 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1471 | | | i=(1,..,n-1) | | dst | 1472 | | | | | node | 1473 +-----------+----------+--------------+----------------+----------+ 1474 | Inserted | RPI, RH3 | -- | -- | -- | 1475 | headers | | | | | 1476 +-----------+----------+--------------+----------------+----------+ 1477 | Removed | -- | -- | | -- | 1478 | headers | | | | | 1479 +-----------+----------+--------------+----------------+----------+ 1480 | Re-added | -- | -- | -- | -- | 1481 | headers | | | | | 1482 +-----------+----------+--------------+----------------+----------+ 1483 | Modified | -- | RPI, RH3 | RPI, | -- | 1484 | headers | | | RH3(consumed) | | 1485 +-----------+----------+--------------+----------------+----------+ 1486 | Untouched | -- | -- | -- | RPI, RH3 | 1487 | headers | | | | (both | 1488 | | | | | ignored) | 1489 +-----------+----------+--------------+----------------+----------+ 1491 Figure 15: Non Storing mode: Summary of the use of headers from root 1492 to not-RPL-aware-leaf 1494 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1496 In this case the flow comprises: 1498 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1500 For example, a communication flow could be: Node G --> Node E --> 1501 Node B --> Node A (root) 1503 6LR_i is the intermediate router from source to destination. In this 1504 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1505 goes through from source (IPv6) to destination (6LBR). For example, 1506 6LR_1 (i=1) is the router that receives the packets from the IPv6 1507 node. 1509 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1510 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1511 following 6LRs. The RPI and entire packet is consumed by the root. 1513 The Figure 16 shows the table that summarizes what headers are needed 1514 for this use case. 1516 +----------+------+-------------------+------------------+-----------------+ 1517 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 1518 | | src | | | | 1519 | | node | | | | 1520 +----------+------+-------------------+------------------+-----------------+ 1521 | Inserted | -- | IPv6-in-IPv6(RPI) | -- | -- | 1522 | headers | | | | | 1523 +----------+------+-------------------+------------------+-----------------+ 1524 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1525 | headers | | | | | 1526 +----------+------+-------------------+------------------+-----------------+ 1527 | Re-added | -- | -- | -- | -- | 1528 | headers | | | | | 1529 +----------+------+-------------------+------------------+-----------------+ 1530 | Modified | -- | -- | IPv6-in-IPv6(RPI)| -- | 1531 | headers | | | | | 1532 +----------+------+-------------------+------------------+-----------------+ 1533 |Untouched | -- | -- | -- | -- | 1534 | headers | | | | | 1535 +----------+------+-------------------+------------------+-----------------+ 1537 Figure 16: Non Storing mode: Summary of the use of headers from not- 1538 RPL-aware-leaf to root 1540 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1542 This section will describe the communication flow in Non Storing Mode 1543 (Non-SM) between: 1545 RPL-aware-leaf to Internet 1547 Internet to RPL-aware-leaf 1549 not-RPL-aware-leaf to Internet 1551 Internet to not-RPL-aware-leaf 1553 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1555 In this case the flow comprises: 1557 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1559 For example, a communication flow could be: Node F --> Node D --> 1560 Node B --> Node A --> Internet 1561 6LR_i is the intermediate router from source to destination. In this 1562 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1563 goes through from source (6LN) to 6LBR. 1565 This case is identical to storing-mode case. 1567 The IPv6 flow label should be set to zero to aid in compression, and 1568 the 6LBR will set it to a non-zero value when sending towards the 1569 Internet. 1571 The Table 9 summarizes what headers are needed for this use case. 1573 +-------------------+---------+-------+------+----------------+ 1574 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 1575 +-------------------+---------+-------+------+----------------+ 1576 | Inserted headers | RPI | -- | -- | -- | 1577 | Removed headers | -- | -- | -- | -- | 1578 | Re-added headers | -- | -- | -- | -- | 1579 | Modified headers | -- | RPI | -- | -- | 1580 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1581 +-------------------+---------+-------+------+----------------+ 1583 Table 9: Non Storing mode: Summary of the use of headers from RPL- 1584 aware-leaf to Internet 1586 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1588 In this case the flow comprises: 1590 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1592 For example, a communication flow could be: Internet --> Node A 1593 (root) --> Node B --> Node D --> Node F 1595 6LR_i is the intermediate router from source to destination. In this 1596 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1597 goes through from 6LBR to destination(6LN). 1599 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1600 address of the target node, it can address the IPv6-in-IPv6 header to 1601 that node. The 6LBR will zero the flow label upon entry in order to 1602 aid compression. 1604 The Table 10 summarizes what headers are needed for this use case. 1606 +-----------+----------+--------------+--------------+--------------+ 1607 | Header | Internet | 6LBR | 6LR_i | 6LN src | 1608 | | dst | | | | 1609 +-----------+----------+--------------+--------------+--------------+ 1610 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1611 | headers | | (RH3,RPI) | | | 1612 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1613 | headers | | | | (RH3,RPI) | 1614 | Re-added | -- | -- | -- | -- | 1615 | headers | | | | | 1616 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1617 | headers | | | (RH3,RPI) | | 1618 | Untouched | -- | -- | -- | -- | 1619 | headers | | | | | 1620 +-----------+----------+--------------+--------------+--------------+ 1622 Table 10: Non Storing mode: Summary of the use of headers from 1623 Internet to RPL-aware-leaf 1625 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1627 In this case the flow comprises: 1629 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1630 Internet 1632 For example, a communication flow could be: Node G --> Node E --> 1633 Node B --> Node A --> Internet 1635 6LR_i is the intermediate router from source to destination. In this 1636 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1637 goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1639 In this case the flow label is recommended to be zero in the IPv6 1640 node. As RPL headers are added in the IPv6 node packet, the first 1641 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1642 The IPv6-in-IPv6 header will be addressed to the root. This case is 1643 identical to the storing-mode case (see Section 6.2.3). 1645 The Figure 17 shows the table that summarizes what headers are needed 1646 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1648 +-----------+------+--------------+--------------+--------------+----------+ 1649 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | 1650 | | src | | [i=2,..,n] | | dst | 1651 | | node | | | | | 1652 +-----------+------+--------------+--------------+--------------+----------+ 1653 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1654 | headers | | | | | | 1655 +-----------+------+--------------+--------------+--------------+----------+ 1656 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1657 | headers | | | | | | 1658 +-----------+------+--------------+--------------+--------------+----------+ 1659 | Re-added | -- | -- | -- | -- | -- | 1660 | headers | | | | | | 1661 +-----------+------+--------------+--------------+--------------+----------+ 1662 | Modified | -- | -- | IP6-IP6(RPI) | -- | -- | 1663 | headers | | | | | | 1664 +-----------+------+--------------+--------------+--------------+----------+ 1665 | Untouched | -- | -- | -- | -- | -- | 1666 | headers | | | | | | 1667 +-----------+------+--------------+--------------+--------------+----------+ 1669 Figure 17: Non Storing mode: Summary of the use of headers from not- 1670 RPL-aware-leaf to Internet 1672 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1674 In this case the flow comprises: 1676 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1678 For example, a communication flow could be: Internet --> Node A 1679 (root) --> Node B --> Node E --> Node G 1681 6LR_i is the intermediate router from source to destination. In this 1682 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1683 goes through from 6LBR to not-RPL-aware-leaf (IPv6). 1685 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1686 6LBR will know the path, and will recognize that the final node is 1687 not an RPL capable node as it will have received the connectivity DAO 1688 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1689 header destination be the last 6LR. The 6LBR will set to zero the 1690 flow label upon entry in order to aid compression. 1692 The Figure 18 shows the table that summarizes what headers are needed 1693 for this use case. 1695 +-----------+--------+--------------+--------------+--------------+------+ 1696 | Header |Internet| 6LBR | 6LR_1 | 6lR_i | IPv6 | 1697 | | src | | | (i=2,...,n) | dst | 1698 | | | | | | node | 1699 +-----------+--------+--------------+--------------+--------------+------+ 1700 | Inserted | -- | IPv6-in-IPv6 | -- | -- | -- | 1701 | headers | | (RH3,RPI) | | | | 1702 +-----------+--------+--------------+--------------+--------------+------+ 1703 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1704 | headers | | | | (RH3,RPI)[1] | | 1705 +-----------+--------+--------------+--------------+--------------+------+ 1706 | Re-added | -- | -- | -- | -- | -- | 1707 | headers | | | | | | 1708 +-----------+--------+--------------+--------------+--------------+------+ 1709 | Modified | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1710 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1711 +-----------+--------+--------------+--------------+--------------+------+ 1712 | Untouched | -- | -- | -- | -- | -- | 1713 | headers | | | | | | 1714 +-----------+--------+--------------+--------------+--------------+------+ 1716 Figure 18: Non-Storing mode: Summary of the use of headers from 1717 Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node. 1719 7.3. Non-Storing Mode: Interaction between Leafs 1721 In this section is described the communication flow in Non Storing 1722 Mode (Non-SM) between, 1724 RPL-aware-leaf to RPL-aware-leaf 1726 RPL-aware-leaf to not-RPL-aware-leaf 1728 not-RPL-aware-leaf to RPL-aware-leaf 1730 not-RPL-aware-leaf to not-RPL-aware-leaf 1732 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1734 In this case the flow comprises: 1736 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1738 For example, a communication flow could be: Node F --> Node D --> 1739 Node B --> Node A (root) --> Node B --> Node E --> Node H 1740 6LR_ia is the intermediate router from source to the root In this 1741 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1742 packet goes through from 6LN to the root. 1744 6LR_id is the intermediate router from the root to the destination. 1745 In this case, "1 <= ia <= m", m is the number of the intermediate 1746 routers (6LR). 1748 This case involves only nodes in same RPL Domain. The originating 1749 node will add a RPI header to the original packet, and send the 1750 packet upwards. 1752 The originating node must put the RPI into an IPv6-in-IPv6 header 1753 addressed to the root, so that the 6LBR can remove that header. If 1754 it does not, then additional resources are wasted on the way down to 1755 carry the useless RPI option. 1757 The 6LBR will need to insert an RH3 header, which requires that it 1758 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1759 it was contained in an IPv6-in-IPv6 header addressed to it. 1760 Otherwise, there may be a RPI header buried inside the inner IP 1761 header, which should get ignored. 1763 Networks that use the RPL P2P extension [RFC6997] are essentially 1764 non-storing DODAGs and fall into this scenario or scenario 1765 Section 7.1.2, with the originating node acting as 6LBR. 1767 The Figure 19 shows the table that summarizes what headers are needed 1768 for this use case. 1770 +---------+------------+------------+------------+------------+------------+ 1771 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | 1772 | | src | | | | dst | 1773 +---------+------------+------------+------------+------------+------------+ 1774 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1775 | headers | (RPI1) | |(RH3-> 6LN, | | | 1776 | | | | RPI2) | | | 1777 +---------+------------+------------+------------+------------+------------+ 1778 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1779 | headers | | | (RPI1) | | (RH3, | 1780 | | | | | | RPI2) | 1781 +---------+------------+------------+------------+------------+------------+ 1782 | Re-added| -- | -- | -- | -- | -- | 1783 | headers | | | | | | 1784 +---------+------------+------------+------------+------------+------------+ 1785 | Modified| -- |IPv6-in-IPv | -- |IPv6-in-IPv6| -- | 1786 | headers | | (RPI1) | | (RPI2) | | 1787 +---------+------------+------------+------------+------------+------------+ 1788 |Untouched| -- | -- | -- | -- | -- | 1789 | headers | | | | | | 1790 +---------+------------+------------+------------+------------+------------+ 1792 Figure 19: Non Storing mode: Summary of the use of headers for RPL- 1793 aware-leaf to RPL-aware-leaf 1795 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1796 leaf 1798 In this case the flow comprises: 1800 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1802 For example, a communication flow could be: Node F --> Node D --> 1803 Node B --> Node A (root) --> Node B --> Node E --> Node G 1805 6LR_ia is the intermediate router from source to the root In this 1806 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1808 6LR_id is the intermediate router from the root to the destination. 1809 In this case, "1 <= ia <= m", m is the number of the intermediate 1810 routers (6LRs). 1812 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1813 which must be in an IPv6-in-IPv6 header addressed to the root so that 1814 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1815 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. 1817 The Figure 20 shows the table that summarizes what headers are needed 1818 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1820 +-----------+---------+---------+---------+---------+---------+------+ 1821 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | 1822 | | src | | | | | dst | 1823 | | | | | | | node | 1824 +-----------+---------+---------+---------+---------+---------+------+ 1825 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1826 | headers | (RPI1) | | (RH3, | | | | 1827 | | | | RPI2) | | | | 1828 +-----------+---------+---------+---------+---------+---------+------+ 1829 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1830 | headers | | | (RPI1) | | (RH3, | | 1831 | | | | | | RPI2) | | 1832 +-----------+---------+---------+---------+---------+---------+------+ 1833 | Re-added | -- | -- | -- | -- | -- | -- | 1834 | headers | | | | | | | 1835 +-----------+---------+---------+---------+---------+---------+------+ 1836 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1837 | headers | | (RPI1) | | (RH3, | | | 1838 | | | | | RPI2) | | | 1839 +-----------+---------+---------+---------+---------+---------+------+ 1840 | Untouched | -- | -- | -- | -- | -- | -- | 1841 | headers | | | | | | | 1842 +-----------+---------+---------+---------+---------+---------+------+ 1844 Figure 20: Non Storing mode: Summary of the use of headers from RPL- 1845 aware-leaf to not-RPL-aware-leaf. 1847 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1848 leaf 1850 In this case the flow comprises: 1852 not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1853 6LR_id --> 6LN 1855 For example, a communication flow could be: Node G --> Node E --> 1856 Node B --> Node A (root) --> Node B --> Node E --> Node H 1858 6LR_ia is the intermediate router from source to the root. In this 1859 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1861 6LR_id is the intermediate router from the root to the destination. 1862 In this case, "1 <= ia <= m", m is the number of the intermediate 1863 routers (6LR). 1865 This scenario is mostly identical to the previous one. The RPI is 1866 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1867 addressed to the root. The 6LBR will remove this RPI, and add it's 1868 own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). 1870 The Figure 21 shows the table that summarizes what headers are needed 1871 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1873 +-----------+------+---------+---------+---------+---------+---------+ 1874 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | 1875 | | src | | | | | dst | 1876 | | node | | | | | | 1877 +-----------+------+---------+---------+---------+---------+---------+ 1878 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1879 | headers | | (RPI1) | | (RH3, | | | 1880 | | | | | RPI2) | | | 1881 +-----------+------+---------+---------+---------+---------+---------+ 1882 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1883 | headers | | | | (RPI1) | | (RH3, | 1884 | | | | | | | RPI2) | 1885 +-----------+------+---------+---------+---------+---------+---------+ 1886 | Re-added | -- | | -- | -- | -- | -- | 1887 | headers | | | | | | | 1888 +-----------+------+---------+---------+---------+---------+---------+ 1889 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1890 | headers | | | (RPI1) | | (RH3, | | 1891 | | | | | | RPI2) | | 1892 +-----------+------+---------+---------+---------+---------+---------+ 1893 | Untouched | -- | | -- | -- | -- | -- | 1894 | headers | | | | | | | 1895 +-----------+------+---------+---------+---------+---------+---------+ 1897 Figure 21: Non Storing mode: Summary of the use of headers from not- 1898 RPL-aware-leaf to RPL-aware-leaf. 1900 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1901 aware-leaf 1903 In this case the flow comprises: 1905 not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1906 6LR_id --> not-RPL-aware (IPv6 dst) 1908 For example, a communication flow could be: Node G --> Node E --> 1909 Node B --> Node A (root) --> Node C --> Node J 1911 6LR_ia is the intermediate router from source to the root. In this 1912 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1913 6LR_id is the intermediate router from the root to the destination. 1914 In this case, "1 <= ia <= m", m is the number of the intermediate 1915 routers (6LR). 1917 This scenario is the combination of the previous two cases. 1919 The Figure 22 shows the table that summarizes what headers are needed 1920 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1922 +---------+------+-------+-------+---------+-------+---------+------+ 1923 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | 1924 | | src | | | | | | dst | 1925 | | node | | | | | | node | 1926 +---------+------+-------+-------+---------+-------+---------+------+ 1927 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 1928 | headers | | (RPI1)| | (RH3, | | | | 1929 | | | | | RPI2) | | | | 1930 +---------+------+-------+-------+---------+-------+---------+------+ 1931 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1932 | headers | | | | (RPI1) | | (RH3, | | 1933 | | | | | | | RPI2) | | 1934 +---------+------+-------+-------+---------+-------+---------+------+ 1935 | Re-added| -- | -- | -- | -- | -- | -- | -- | 1936 | headers | | | | | | | | 1937 +---------+------+-------+-------+---------+-------+---------+------+ 1938 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 1939 | headers | | | (RPI1)| | (RH3, | | | 1940 | | | | | | RPI2)| | | 1941 +---------+------+-------+-------+---------+-------+---------+------+ 1942 |Untouched| -- | -- | -- | -- | -- | -- | -- | 1943 | headers | | | | | | | | 1944 +---------+------+-------+-------+---------+-------+---------+------+ 1946 Figure 22: Non Storing mode: Summary of the use of headers from not- 1947 RPL-aware-leaf to not-RPL-aware-leaf 1949 8. Operational Considerations of supporting not-RPL-aware-leaves 1951 Roughly half of the situations described in this document involve 1952 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1953 further categories: ones that drop a packet that have RPI or RH3 1954 headers, and ones that continue to process a packet that has RPI and/ 1955 or RH3 headers. 1957 [RFC8200] provides for new rules that suggest that nodes that have 1958 not been configured (explicitly) to examine Hop-by-Hop headers, 1959 should ignore those headers, and continue processing the packet. 1960 Despite this, and despite the switch from 0x63 to 0x23, there may be 1961 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1962 drop packets that continue to have RPL artifacts in them. In 1963 general, such hosts can not be easily supported in RPL LLNs. 1965 There are some specific cases where it is possible to remove the RPL 1966 artifacts prior to forwarding the packet to the leaf host. The 1967 critical thing is that the artifacts have been inserted by the RPL 1968 root inside an IPv6-in-IPv6 header, and that the header has been 1969 addressed to the 6LR immediately prior to the leaf node. In that 1970 case, in the process of removing the IPv6-in-IPv6 header, the 1971 artifacts can also be removed. 1973 The above case occurs whenever traffic originates from the outside 1974 the LLN (the "Internet" cases above), and non-storing mode is used. 1975 In non-storing mode, the RPL root knows the exact topology (as it 1976 must be create the RH3 header), and therefore knows what the 6LR 1977 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 1978 to the leaf node G, or node C is the 6LR prior to the leaf node J. 1980 Traffic originating from the RPL root (such as when the data 1981 collection system is co-located on the RPL root), does not require an 1982 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1983 the root, and the root can insert the RPI and RH3 headers directly 1984 into the packet, as it is formed. Such a packet is slightly smaller, 1985 but only can be sent to nodes (whether RPL aware or not), that will 1986 tolerate the RPL artifacts. 1988 An operator that finds itself with a lot of traffic from the RPL root 1989 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1990 if the leaf is not tolerant of the RPL artifacts. Such an operator 1991 could otherwise omit this unnecessary header if it was certain of the 1992 properties of the leaf. 1994 As storing mode can not know the final path of the traffic, 1995 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1996 be supported. 1998 9. Operational considerations of introducing 0x23 2000 This section describes the operational considerations of introducing 2001 the new RPI value of 0x23. 2003 During bootstrapping the node gets the DIO with the information of 2004 RPL Option Type, indicating the new RPI in the DODAG Configuration 2005 Option Flag. The DODAG root is in charge to configure the current 2006 network to the new value, through DIO messages and when all the nodes 2007 are set with the new value. The DODAG should change to a new DODAG 2008 version. In case of rebooting, the node does not remember the RPL 2009 Option Type. Thus, the DIO is sent with a flag indicating the new 2010 RPI value. 2012 The DODAG Configuration option is contained in a RPL DIO message, 2013 which contains a unique DTSN counter. The leaf nodes respond to this 2014 message with DAO messages containing the same DTSN. This is a normal 2015 part of RPL routing; the RPL root therefore knows when the updated 2016 DODAG Configuration Option has been seen by all nodes. 2018 Before the migration happens, all the RPL-aware nodes should support 2019 both values . The migration procedure it is triggered when the DIO 2020 is sent with the flag indicating the new RPI value. Namely, it 2021 remains at 0x63 until it is sure that the network is capable of 0x23, 2022 then it abruptly change to 0x23. This options allows to send packets 2023 to not-RPL nodes, which should ignore the option and continue 2024 processing the packets. 2026 In case that a node join to a network that only process 0x63, it 2027 would produce a flag day as was mentioned previously. Indicating the 2028 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2029 flag day in a network. It is recommended that a network process both 2030 options to enable interoperability. 2032 10. IANA Considerations 2034 This document updates the registration made in [RFC6553] Destination 2035 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2036 Figure 23. 2038 [RFCXXXX] represents this document. 2040 Hex Value Binary Value 2041 act chg rest Description Reference 2042 --------- --- --- ------- ----------------- ---------- 2043 0x23 00 1 00011 RPL Option [RFCXXXX] 2044 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 2046 Figure 23: Option Type in RPL Option. 2048 DODAG Configuration option is updated as follows (Figure 24): 2050 +------------+-----------------+---------------+ 2051 | Bit number | Description | Reference | 2052 +------------+-----------------+---------------+ 2053 | 3 | RPI 0x23 enable | This document | 2054 +------------+-----------------+---------------+ 2056 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2057 day. 2059 11. Security Considerations 2061 The security considerations covered in [RFC6553] and [RFC6554] apply 2062 when the packets are in the RPL Domain. 2064 The IPv6-in-IPv6 mechanism described in this document is much more 2065 limited than the general mechanism described in [RFC2473]. The 2066 willingness of each node in the LLN to decapsulate packets and 2067 forward them could be exploited by nodes to disguise the origin of an 2068 attack. 2070 While a typical LLN may be a very poor origin for attack traffic (as 2071 the networks tend to be very slow, and the nodes often have very low 2072 duty cycles) given enough nodes, they could still have a significant 2073 impact, particularly if the target of the attack is targeting another 2074 LLN. Additionally, some uses of RPL involve large backbone ISP scale 2075 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2076 equipped with multiple 100Gb/s interfaces. 2078 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2079 LLN as described above will make sure that any attack that is mounted 2080 must originate from compromised nodes within the LLN. The use of 2081 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2082 alert the operator to the existence of the attack, as well as drop 2083 the attack traffic. As the RPL network is typically numbered from a 2084 single prefix, which is itself assigned by RPL, BCP38 filtering 2085 involves a single prefix comparison and should be trivial to 2086 automatically configure. 2088 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2089 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2090 communications between a new Pledge and the Join Registrar/ 2091 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2092 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2093 the RPL root to do careful filtering: it occurs only when the Join 2094 Coordinator is not co-located inside the RPL root. 2096 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2097 only be by a node within the LLN on another node within the LLN. 2098 Such an attack could, of course, be done directly. An attack of this 2099 kind is meaningful only if the source addresses are either fake or if 2100 the point is to amplify return traffic. Such an attack, could also 2101 be done without the use of IPv6-in-IPv6 headers using forged source 2102 addresses. If the attack requires bi-directional communication, then 2103 IPv6-in-IPv6 provides no advantages. 2105 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2106 about creating security issues. In the security section of 2107 [RFC2473], it was suggested that tunnel entry and exit points can be 2108 secured, via "Use IPsec". This recommendation is not practical for 2109 RPL networks. [RFC5406] goes into some detail on what additional 2110 details would be needed in order to "Use IPsec". Use of ESP would 2111 prevent RFC8183 compression (compression must occur before 2112 encryption), and RFC8183 compression is lossy in a way that prevents 2113 use of AH. These are minor issues. The major issue is how to 2114 establish trust enough such that IKEv2 could be used. This would 2115 require a system of certificates to be present in every single node, 2116 including any Internet nodes that might need to communicate with the 2117 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2119 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2120 IPv6 headers would in the general case scale with the square of the 2121 number of nodes. This is a lot of resource for a constrained nodes 2122 on a constrained network. In the end, the IPsec tunnels would be 2123 providing only BCP38-like origin authentication! Just doing BCP38 2124 origin filtering at the entry and exit of the LLN provides a similar 2125 level amount of security without all the scaling and trust problems 2126 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2128 An LLN with hostile nodes within it would not be protected against 2129 impersonation with the LLN by entry/exit filtering. 2131 The RH3 header usage described here can be abused in equivalent ways 2132 (to disguise the origin of traffic and attack other nodes) with an 2133 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2134 attacker's RH3 header will not be seen by the network until it 2135 reaches the end host, which will decapsulate it. An end-host should 2136 be suspicious about a RH3 header which has additional hops which have 2137 not yet been processed, and SHOULD ignore such a second RH3 header. 2139 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2140 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2141 will see the second RH3 header and MAY choose to discard the packet 2142 if the RH3 header has not been completely consumed. A consumed 2143 (inert) RH3 header could be present in a packet that flows from one 2144 LLN, crosses the Internet, and enters another LLN. As per the 2145 discussion in this document, such headers do not need to be removed. 2146 However, there is no case described in this document where an RH3 is 2147 inserted in a non-storing network on traffic that is leaving the LLN, 2148 but this document should not preclude such a future innovation. It 2149 should just be noted that an incoming RH3 must be fully consumed, or 2150 very carefully inspected. 2152 The RPI header, if permitted to enter the LLN, could be used by an 2153 attacker to change the priority of a packet by selecting a different 2154 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2155 It could also be that not all nodes are reachable in an LLN using the 2156 default instanceID, but a change of instanceID would permit an 2157 attacker to bypass such filtering. Like the RH3, a RPI header is to 2158 be inserted by the RPL root on traffic entering the LLN by first 2159 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2160 therefore will not be seen by the network. Upon reaching the 2161 destination node the RPI header has no further meaning and is just 2162 skipped; the presence of a second RPI header will have no meaning to 2163 the end node as the packet has already been identified as being at 2164 it's final destination. 2166 The RH3 and RPI headers could be abused by an attacker inside of the 2167 network to route packets on non-obvious ways, perhaps eluding 2168 observation. This usage is in fact part of [RFC6997] and can not be 2169 restricted at all. This is a feature, not a bug. 2171 [RFC7416] deals with many other threats to LLNs not directly related 2172 to the use of IPv6-in-IPv6 headers, and this document does not change 2173 that analysis. 2175 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2176 attack on another part of the LLN, while disguising the origin of the 2177 attack. The mechanism can even be abused to make it appear that the 2178 attack is coming from outside the LLN, and unless countered, this 2179 could be used to mount a Distributed Denial Of Service attack upon 2180 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2181 such attacks already seen in the real world. 2183 If an attack comes from inside of LLN, it can be alleviated with SAVI 2184 (Source Address Validation Improvement) using [RFC8505] with 2185 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2186 traffic with an address that is not registered, and the registration 2187 process checks for topological correctness. Notice that there is an 2188 L2 authentication in most of the cases. If an attack comes from 2189 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2190 but by construction, the RH3 can typically only address nodes within 2191 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2192 considered an attack (see RFC6554, section 3). 2194 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2195 through the RPL root to perform this attack. To counter, the RPL 2196 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2197 simpler solution), or it SHOULD walk the IP header extension chain 2198 until it can inspect the upper-layer-payload as described in 2199 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2200 on the source addresses of all IP headers that it examines in both 2201 directions. 2203 Note: there are some situations where a prefix will spread across 2204 multiple LLNs via mechanisms such as the one described in 2205 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2206 needs to take this into account, either by exchanging detailed 2207 routing information on each LLN, or by moving the BCP38 filtering 2208 further towards the Internet, so that the details of the multiple 2209 LLNs do not matter. 2211 12. Acknowledgments 2213 This work is done thanks to the grant by the Stand.ICT project. 2215 A special BIG thanks to C. M. Heard for the help with the 2216 Section 3. Much of the redaction in that section is based on his 2217 comments. 2219 Additionally, the authors would like to acknowledge the review, 2220 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2221 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2222 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2224 13. References 2226 13.1. Normative References 2228 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2229 Defeating Denial of Service Attacks which employ IP Source 2230 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2231 May 2000, . 2233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2234 Requirement Levels", BCP 14, RFC 2119, 2235 DOI 10.17487/RFC2119, March 1997, 2236 . 2238 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2239 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2240 2010, . 2242 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2243 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2244 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2245 Low-Power and Lossy Networks", RFC 6550, 2246 DOI 10.17487/RFC6550, March 2012, 2247 . 2249 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2250 Power and Lossy Networks (RPL) Option for Carrying RPL 2251 Information in Data-Plane Datagrams", RFC 6553, 2252 DOI 10.17487/RFC6553, March 2012, 2253 . 2255 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2256 Routing Header for Source Routes with the Routing Protocol 2257 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2258 DOI 10.17487/RFC6554, March 2012, 2259 . 2261 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2262 of IPv6 Extension Headers", RFC 7045, 2263 DOI 10.17487/RFC7045, December 2013, 2264 . 2266 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2267 "IPv6 over Low-Power Wireless Personal Area Network 2268 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2269 April 2017, . 2271 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2272 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2273 May 2017, . 2275 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2276 (IPv6) Specification", STD 86, RFC 8200, 2277 DOI 10.17487/RFC8200, July 2017, 2278 . 2280 13.2. Informative References 2282 [DDOS-KREBS] 2283 Goodin, D., "Record-breaking DDoS reportedly delivered by 2284 >145k hacked cameras", September 2016, 2285 . 2288 [I-D.ietf-6lo-ap-nd] 2289 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2290 "Address Protected Neighbor Discovery for Low-power and 2291 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2292 progress), April 2019. 2294 [I-D.ietf-6lo-backbone-router] 2295 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2296 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2297 in progress), February 2019. 2299 [I-D.ietf-6tisch-dtsecurity-secure-join] 2300 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2301 6tisch-dtsecurity-secure-join-01 (work in progress), 2302 February 2017. 2304 [I-D.ietf-anima-autonomic-control-plane] 2305 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2306 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2307 plane-19 (work in progress), March 2019. 2309 [I-D.ietf-anima-bootstrapping-keyinfra] 2310 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2311 S., and K. Watsen, "Bootstrapping Remote Secure Key 2312 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2313 keyinfra-20 (work in progress), May 2019. 2315 [I-D.ietf-intarea-tunnels] 2316 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2317 Architecture", draft-ietf-intarea-tunnels-09 (work in 2318 progress), July 2018. 2320 [I-D.thubert-roll-unaware-leaves] 2321 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2322 unaware-leaves-07 (work in progress), April 2019. 2324 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2325 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2326 December 1998, . 2328 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2329 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2330 December 1998, . 2332 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2333 Control Message Protocol (ICMPv6) for the Internet 2334 Protocol Version 6 (IPv6) Specification", STD 89, 2335 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2336 . 2338 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2339 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2340 February 2009, . 2342 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2343 Bormann, "Neighbor Discovery Optimization for IPv6 over 2344 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2345 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2346 . 2348 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2349 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2350 in Low-Power and Lossy Networks", RFC 6997, 2351 DOI 10.17487/RFC6997, August 2013, 2352 . 2354 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2355 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2356 2014, . 2358 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2359 and M. Richardson, Ed., "A Security Threat Analysis for 2360 the Routing Protocol for Low-Power and Lossy Networks 2361 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2362 . 2364 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2365 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2366 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2367 May 2017, . 2369 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2370 Perkins, "Registration Extensions for IPv6 over Low-Power 2371 Wireless Personal Area Network (6LoWPAN) Neighbor 2372 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2373 . 2375 Authors' Addresses 2377 Maria Ines Robles 2378 Aalto University 2379 Otaniemi 2380 Espoo 02150 2381 Finland 2383 Email: mariainesrobles@gmail.com 2385 Michael C. Richardson 2386 Sandelman Software Works 2387 470 Dawson Avenue 2388 Ottawa, ON K1Z 5V7 2389 CA 2391 Email: mcr+ietf@sandelman.ca 2392 URI: http://www.sandelman.ca/mcr/ 2394 Pascal Thubert 2395 Cisco Systems, Inc 2396 Village d'Entreprises Green Side 400, Avenue de Roumanille 2397 Batiment T3, Biot - Sophia Antipolis 06410 2398 France 2400 Email: pthubert@cisco.com