idnits 2.17.00 (12 Aug 2021) /tmp/idnits8765/draft-ietf-roll-useofrplinfo-28.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 2024 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 17, 2019) is 1100 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 2027, but not defined -- Looks like a reference, but probably isn't: '1' on line 1700 -- Looks like a reference, but probably isn't: '2' on line 1027 == 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 18, 2019 P. Thubert 7 Cisco 8 May 17, 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-28 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 18, 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 As the rank information in the RPI artifact is changed at each hop, 632 it will typically be zero when it arrives at the DODAG root. The 633 DODAG root MUST force it to zero when passing the packet out to the 634 Internet. The Internet will therefore not see any SenderRank 635 information. 637 Despite being legal to leave the RPI artifact in place, an 638 intermediate router that needs to add an extension header (e.g. RH3 639 or RPI Option) MUST still encapsulate the packet in an (additional) 640 outer IP header. The new header is placed after this new outer IP 641 header. 643 A corollary is that an RH3 or RPI Option can only be removed by an 644 intermediate router if it is placed in an encapsulating IPv6 Header, 645 which is addressed TO the intermediate router. When it does so, the 646 whole encapsulating header must be removed. (A replacement may be 647 added). This sometimes can result in outer IP headers being 648 addressed to the next hop router using link-local address. 650 Both RPI and RH3 headers may be modified in very specific ways by 651 routers on the path of the packet without the need to add and remove 652 an encapsulating header. Both headers were designed with this 653 modification in mind, and both the RPL RH3 and the RPL option are 654 marked mutable but recoverable: so an IPsec AH security header can be 655 applied across these headers, but it can not secure the values which 656 mutate. 658 RPI MUST be present in every single RPL data packet. 660 Prior to [RFC8138], there was significant interest in removing the 661 RPI for downward flows in non-storing mode. The exception covered a 662 very small number of cases, and causes significant interoperability 663 challenges, yet costed significant code and testing complexity. The 664 ability to compress the RPI down to three bytes or less removes much 665 of the pressure to optimize this any further 666 [I-D.ietf-anima-autonomic-control-plane]. 668 The earlier examples are more extensive to make sure that the process 669 is clear, while later examples are more concise. 671 6. Storing mode 673 In storing mode (SM) (fully stateful), the sender can determine if 674 the destination is inside the LLN by looking if the destination 675 address is matched by the DIO's Prefix Information Option (PIO) 676 option. 678 The following table (Figure 7) itemizes which headers are needed in 679 each of the following scenarios. It indicates if the IPv6-in-IPv6 680 header that is added, must be addressed to the final destination (the 681 Raf node that is the target(tgt)), to the "root" or if a hop-by-hop 682 header must be added (indicated by "hop"). 684 In cases where no IPv6-in-IPv6 header is needed, the column states as 685 "No". If the IPv6-in-IPv6 header is needed is a "must". 687 In all cases the RPI headers are needed, since it identifies 688 inconsistencies (loops) in the routing topology. In all cases the 689 RH3 is not needed because it is not used in storing mode. 691 In each case, 6LR_i is the intermediate router from source to 692 destination. "1 <= i <= n", n is the number of routers (6LR) that 693 the packet goes through from source (6LN) to destination. 695 The leaf can be a router 6LR or a host, both indicated as 6LN. The 696 root refers to the 6LBR (see Figure 6). 698 +---------------------+--------------+------------+------------------+ 699 | Interaction between | Use Case |IPv6-in-IPv6| IPv6-in-IPv6 dst | 700 +---------------------+--------------+------------+------------------+ 701 | | Raf to root | No | No | 702 + +--------------+------------+------------------+ 703 | Leaf - Root | root to Raf | No | No | 704 + +--------------+------------+------------------+ 705 | | root to ~Raf | No | No | 706 + +--------------+------------+------------------+ 707 | | ~Raf to root | must | root | 708 +---------------------+--------------+------------+------------------+ 709 | | Raf to Int | No | No | 710 + +--------------+------------+------------------+ 711 | Leaf - Internet | Int to Raf | must | Raf (tgt) | 712 + +--------------+------------+------------------+ 713 | | ~Raf to Int | must | root | 714 + +--------------+------------+------------------+ 715 | | Int to ~Raf | must | hop | 716 +---------------------+--------------+------------+------------------+ 717 | | Raf to Raf | No | No | 718 + +--------------+------------+------------------+ 719 | | Raf to ~Raf | No | No | 720 + Leaf - Leaf +--------------+------------+------------------+ 721 | | ~Raf to Raf | must | Raf (tgt) | 722 + +--------------+------------+------------------+ 723 | | ~Raf to ~Raf | must | hop | 724 +---------------------+--------------+------------+------------------+ 726 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 728 6.1. Storing Mode: Interaction between Leaf and Root 730 In this section is described the communication flow in storing mode 731 (SM) between, 733 RPL-aware-leaf to root 735 root to RPL-aware-leaf 737 not-RPL-aware-leaf to root 739 root to not-RPL-aware-leaf 741 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 743 In storing mode, RFC 6553 (RPI) is used to send RPL Information 744 instanceID and rank information. 746 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 747 generally issue DIO messages; a leaf node accepts DIO messages from 748 upstream. (When the inconsistency in routing occurs, a leaf node 749 will generate a DIO with an infinite rank, to fix it). It may issue 750 DAO and DIS messages though it generally ignores DAO and DIS 751 messages. 753 In this case the flow comprises: 755 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 757 For example, a communication flow could be: Node F --> Node D --> 758 Node B --> Node A root(6LBR) 760 As it was mentioned in this document 6LRs, 6LBR are always full- 761 fledged RPL routers. 763 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 764 (Node E) which decrements the rank in RPI and sends the packet up. 765 When the packet arrives at 6LBR (Node A), the RPI is removed and the 766 packet is processed. 768 No IPv6-in-IPv6 header is required. 770 The RPI header can be removed by the 6LBR because the packet is 771 addressed to the 6LBR. The 6LN must know that it is communicating 772 with the 6LBR to make use of this scenario. The 6LN can know the 773 address of the 6LBR because it knows the address of the root via the 774 DODAGID in the DIO messages. 776 The Table 1 summarizes what headers are needed for this use case. 778 +-------------------+---------+-------+----------+ 779 | Header | 6LN src | 6LR_i | 6LBR dst | 780 +-------------------+---------+-------+----------+ 781 | Inserted headers | RPI | -- | -- | 782 | Removed headers | -- | -- | RPI | 783 | Re-added headers | -- | -- | -- | 784 | Modified headers | -- | RPI | -- | 785 | Untouched headers | -- | -- | -- | 786 +-------------------+---------+-------+----------+ 788 Table 1: Storing mode: Summary of the use of headers from RPL-aware- 789 leaf to root 791 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 793 In this case the flow comprises: 795 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 797 For example, a communication flow could be: Node A root(6LBR) --> 798 Node B --> Node D --> Node F 800 In this case the 6LBR inserts RPI header and sends the packet down, 801 the 6LR is going to increment the rank in RPI (it examines the 802 instanceID to identify the right forwarding table), the packet is 803 processed in the 6LN and the RPI removed. 805 No IPv6-in-IPv6 header is required. 807 The Table 2 summarizes what headers are needed for this use case. 809 +-------------------+------+-------+------+ 810 | Header | 6LBR | 6LR_i | 6LN | 811 +-------------------+------+-------+------+ 812 | Inserted headers | RPI | -- | -- | 813 | Removed headers | -- | -- | RPI | 814 | Re-added headers | -- | -- | -- | 815 | Modified headers | -- | RPI | -- | 816 | Untouched headers | -- | -- | -- | 817 +-------------------+------+-------+------+ 819 Table 2: Storing mode: Summary of the use of headers from root to 820 RPL-aware-leaf 822 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 824 In this case the flow comprises: 826 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 828 For example, a communication flow could be: Node A root(6LBR) --> 829 Node B --> Node E --> Node G 831 As the RPI extension can be ignored by the not-RPL-aware leaf, this 832 situation is identical to the previous scenario. 834 The Table 3 summarizes what headers are needed for this use case. 836 +-------------------+----------+-------+----------------+ 837 | Header | 6LBR src | 6LR_i | IPv6 dst node | 838 +-------------------+----------+-------+----------------+ 839 | Inserted headers | RPI | -- | -- | 840 | Removed headers | -- | -- | -- | 841 | Re-added headers | -- | -- | -- | 842 | Modified headers | -- | RPI | -- | 843 | Untouched headers | -- | -- | RPI (Ignored) | 844 +-------------------+----------+-------+----------------+ 846 Table 3: Storing mode: Summary of the use of headers from root to 847 not-RPL-aware-leaf 849 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 851 In this case the flow comprises: 853 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 855 For example, a communication flow could be: Node G --> Node E --> 856 Node B --> Node A root(6LBR) 858 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 859 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 860 header. The IPv6-in-IPv6 header can be addressed to the next hop 861 (Node B), or to the root (Node A). The root removes the header and 862 processes the packet. 864 The Figure 8 shows the table that summarizes what headers are needed 865 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 867 +-----------+------+--------------+-----------------+--------------------+ 868 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 869 | | src | | | | 870 | | node | | | | 871 +-----------+------+--------------+-----------------+--------------------+ 872 | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | 873 | headers | | | | | 874 +-----------+------+--------------+-----------------+--------------------+ 875 | Removed | -- | -- | -- | IP6-IP6(RPI)[1][2] | 876 | headers | | | | | 877 +-----------+------+--------------+-----------------+--------------------+ 878 | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | 879 | headers | | | | | 880 +-----------+------+--------------+-----------------+--------------------+ 881 | Modified | -- | -- | IP6-IP6(RPI)[2] | -- | 882 | headers | | | | | 883 +-----------+------+--------------+-----------------+--------------------+ 884 | Untouched | -- | -- | -- | -- | 885 | headers | | | | | 886 +-----------+------+--------------+-----------------+--------------------+ 888 Figure 8: Storing mode: Summary of the use of headers from not-RPL- 889 aware-leaf to root. [[1] Case where the IPv6-in-IPv6 header is 890 addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 891 header is addressed to the root (Node A). 893 6.2. Storing Mode: Interaction between Leaf and Internet. 895 In this section is described the communication flow in storing mode 896 (SM) between, 898 RPL-aware-leaf to Internet 900 Internet to RPL-aware-leaf 902 not-RPL-aware-leaf to Internet 904 Internet to not-RPL-aware-leaf 906 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 908 RPL information from RFC 6553 may go out to Internet as it will be 909 ignored by nodes which have not been configured to be RPI aware. 911 In this case the flow comprises: 913 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 914 For example, the communication flow could be: Node F --> Node D --> 915 Node B --> Node A root(6LBR) --> Internet 917 No IPv6-in-IPv6 header is required. 919 Note: In this use case it is used a node as leaf, but this use case 920 can be also applicable to any RPL-node type (e.g. 6LR) 922 The Table 4 summarizes what headers are needed for this use case. 924 +-------------------+---------+-------+------+----------------+ 925 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 926 +-------------------+---------+-------+------+----------------+ 927 | Inserted headers | RPI | -- | -- | -- | 928 | Removed headers | -- | -- | -- | -- | 929 | Re-added headers | -- | -- | -- | -- | 930 | Modified headers | -- | RPI | -- | -- | 931 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 932 +-------------------+---------+-------+------+----------------+ 934 Table 4: Storing mode: Summary of the use of headers from RPL-aware- 935 leaf to Internet 937 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 939 In this case the flow comprises: 941 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 943 For example, a communication flow could be: Internet --> Node A 944 root(6LBR) --> Node B --> Node D --> Node F 946 When the packet arrives from Internet to 6LBR the RPI header is added 947 in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination 948 address set to the 6LR) and sent to 6LR, which modifies the rank in 949 the RPI. When the packet arrives at 6LN the RPI header is removed 950 and the packet processed. 952 The Figure 9 shows the table that summarizes what headers are needed 953 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 955 +-----------+----------+--------------+--------------+------------------+ 956 | Header | Internet | 6LBR | 6LR_i | 6LN dst | 957 | | src | | | | 958 +-----------+----------+--------------+--------------+------------------+ 959 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 960 | headers | | | | | 961 +-----------+----------+--------------+--------------+------------------+ 962 | Removed | -- | -- | -- | IP6-IP6(RPI) | 963 | headers | | | | | 964 +-----------+----------+--------------+--------------+------------------+ 965 | Re-added | -- | -- | -- | -- | 966 | headers | | | | | 967 +-----------+----------+--------------+--------------+------------------+ 968 | Modified | -- | -- | IP6-IP6(RPI) | -- | 969 | headers | | | | | 970 +-----------+----------+--------------+--------------+------------------+ 971 | Untouched | -- | -- | -- | -- | 972 | headers | | | | | 973 +-----------+----------+--------------+--------------+------------------+ 975 Figure 9: Storing mode: Summary of the use of headers from Internet 976 to RPL-aware-leaf. 978 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 980 In this case the flow comprises: 982 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 983 Internet 985 For example, a communication flow could be: Node G --> Node E --> 986 Node B --> Node A root(6LBR) --> Internet 988 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 989 either to the root, or hop-by-hop such that the root can remove the 990 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 991 root cause less processing overhead. On the other hand, with hop-by- 992 hop the intermediate routers can check the routing tables for a 993 better routing path, thus it could be more efficient and faster. 994 Implementation should decide which approach to take. 996 The originating node will ideally leave the IPv6 flow label as zero 997 so that the packet can be better compressed through the LLN. The 998 6LBR will set the flow label of the packet to a non-zero value when 999 sending to the Internet. 1001 The Figure 10 shows the table that summarizes what headers are needed 1002 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1004 +---------+-------+------------+--------------+-------------+--------+ 1005 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR |Internet| 1006 | | src | | [i=2,...,n] | | dst | 1007 | | node | | | | | 1008 +---------+-------+------------+--------------+-------------+--------+ 1009 | Inserted| -- |IP6-IP6(RPI)| IP6-IP6(RPI) | -- | -- | 1010 | headers | | | [2] | | | 1011 +---------+-------+------------+--------------+-------------+--------+ 1012 | Removed | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI)| -- | 1013 | headers | | | [2] | [1][2] | | 1014 +---------+-------+------------+--------------+-------------+--------+ 1015 | Re-added| -- | -- | -- | -- | -- | 1016 | headers | | | | | | 1017 +---------+-------+------------+--------------+-------------+--------+ 1018 | Modified| -- | -- | IP6-IP6(RPI) | -- | -- | 1019 | headers | | | [1] | | | 1020 +---------+-------+------------+--------------+-------------+--------+ 1021 |Untouched| -- | -- | -- | -- | -- | 1022 | headers | | | | | | 1023 +---------+-------+------------+--------------+-------------+--------+ 1025 Figure 10: Storing mode: Summary of the use of headers from not-RPL- 1026 aware-leaf to Internet. [1] Case when packet is addressed to the 1027 root. [2] Case when the packet is addressed hop-by-hop. 1029 6.2.4. SM: Example of Flow from Internet to not-RPL-aware-leaf. 1031 In this case the flow comprises: 1033 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1035 For example, a communication flow could be: Internet --> Node A 1036 root(6LBR) --> Node B --> Node E --> Node G 1038 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 1039 header. The IPv6-in-IPv6 is addressed hop-by-hop. 1041 The final node should be able to remove one or more IPv6-in-IPv6 1042 headers which are all addressed to it. The final node does not 1043 process the RPI, the node ignores the RPI. Furhter details about 1044 this are mentioned in [I-D.thubert-roll-unaware-leaves], which 1045 specifies RPL routing for a 6LN acting as a plain host and not aware 1046 of RPL. 1048 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 1049 zero in order to aid in compression. 1051 The Figure 11 shows the table that summarizes what headers are needed 1052 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1054 +-----------+----------+--------------+--------------+--------------+ 1055 | Header | Internet | 6LBR | 6LR_i |IPv6 dst node | 1056 | | src | | | | 1057 +-----------+----------+--------------+--------------+--------------+ 1058 | Inserted | -- | IP6-IP6(RPI) | -- | -- | 1059 | headers | | | | | 1060 +-----------+----------+--------------+--------------+--------------+ 1061 | Removed | -- | -- | | IP6-IP6(RPI)| 1062 | headers | | | | RPI Ignored | 1063 +-----------+----------+--------------+--------------+--------------+ 1064 | Re-added | -- | -- | -- | -- | 1065 | headers | | | | | 1066 +-----------+----------+--------------+--------------+--------------+ 1067 | Modified | -- | -- | IP6-IP6(RPI) | -- | 1068 | headers | | | | | 1069 +-----------+----------+--------------+--------------+--------------+ 1070 | Untouched | -- | -- | -- | -- | 1071 | headers | | | | | 1072 +-----------+----------+--------------+--------------+--------------+ 1074 Figure 11: Storing mode: Summary of the use of headers from Internet 1075 to not-RPL-aware-leaf. 1077 6.3. Storing Mode: Interaction between Leaf and Leaf 1079 In this section is described the communication flow in storing mode 1080 (SM) between, 1082 RPL-aware-leaf to RPL-aware-leaf 1084 RPL-aware-leaf to not-RPL-aware-leaf 1086 not-RPL-aware-leaf to RPL-aware-leaf 1088 not-RPL-aware-leaf to not-RPL-aware-leaf 1090 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1092 In [RFC6550] RPL allows a simple one-hop optimization for both 1093 storing and non-storing networks. A node may send a packet destined 1094 to a one-hop neighbor directly to that node. See section 9 in 1095 [RFC6550]. 1097 When the nodes are not directly connected, then in storing mode, the 1098 flow comprises: 1100 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1102 For example, a communication flow could be: Node F --> Node D --> 1103 Node B --> Node E --> Node H 1105 6LR_ia (Node D) is the intermediate router from source to the common 1106 parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the number 1107 of routers (6LR) that the packet goes through from 6LN (Node F) to 1108 the common parent (6LR_x). 1110 6LR_id (Node E) is the intermediate router from the common parent 1111 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1112 <= m", m is the number of routers (6LR) that the packet goes through 1113 from the common parent (6LR_x) to destination 6LN. 1115 It is assumed that the two nodes are in the same RPL Domain (that 1116 they share the same DODAG root). At the common parent (Node B), the 1117 direction of RPI is changed (from increasing to decreasing the rank). 1119 While the 6LR nodes will update the RPI, no node needs to add or 1120 remove the RPI, so no IPv6-in-IPv6 headers are necessary. 1122 The Table 5 summarizes what headers are needed for this use case. 1124 +---------------+--------+--------+---------------+--------+--------+ 1125 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1126 | | src | | parent) | | dst | 1127 +---------------+--------+--------+---------------+--------+--------+ 1128 | Inserted | RPI | -- | -- | -- | -- | 1129 | headers | | | | | | 1130 | Removed | -- | -- | -- | -- | RPI | 1131 | headers | | | | | | 1132 | Re-added | -- | -- | -- | -- | -- | 1133 | headers | | | | | | 1134 | Modified | -- | RPI | RPI | RPI | -- | 1135 | headers | | | | | | 1136 | Untouched | -- | -- | -- | -- | -- | 1137 | headers | | | | | | 1138 +---------------+--------+--------+---------------+--------+--------+ 1140 Table 5: Storing mode: Summary of the use of headers for RPL-aware- 1141 leaf to RPL-aware-leaf 1143 6.3.2. SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 1145 In this case the flow comprises: 1147 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1148 6LN (IPv6) 1150 For example, a communication flow could be: Node F --> Node D --> 1151 Node B --> Node E --> Node G 1153 6LR_ia is the intermediate router from source (6LN) to the common 1154 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1155 routers (6LR) that the packet goes through from 6LN to the common 1156 parent (6LR_x). 1158 6LR_id (Node E) is the intermediate router from the common parent 1159 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1160 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1161 the packet goes through from the common parent (6LR_x) to destination 1162 6LN. 1164 This situation is identical to the previous situation Section 6.3.1 1166 The Table 6 summarizes what headers are needed for this use case. 1168 +-----------+------+--------+---------------+--------+--------------+ 1169 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 dst | 1170 | | src | | parent) | | node | 1171 +-----------+------+--------+---------------+--------+--------------+ 1172 | Inserted | RPI | -- | -- | -- | -- | 1173 | headers | | | | | | 1174 | Removed | -- | -- | -- | -- | -- | 1175 | headers | | | | | | 1176 | Re-added | -- | -- | -- | -- | -- | 1177 | headers | | | | | | 1178 | Modified | -- | RPI | RPI | RPI | -- | 1179 | headers | | | | | | 1180 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1181 | headers | | | | | | 1182 +-----------+------+--------+---------------+--------+--------------+ 1184 Table 6: Storing mode: Summary of the use of headers for RPL-aware- 1185 leaf to not-RPL-aware-leaf 1187 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1189 In this case the flow comprises: 1191 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1192 6LR_id --> 6LN 1193 For example, a communication flow could be: Node G --> Node E --> 1194 Node B --> Node D --> Node F 1196 6LR_ia (Node E) is the intermediate router from source (not-RPL-aware 1197 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In this 1198 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1199 packet ges through from source to the common parent. 1201 6LR_id (Node D) is the intermediate router from the common parent 1202 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1203 <= m", m is the number of routers (6LR) that the packet goes through 1204 from the common parent (6LR_x) to destination 6LN. 1206 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1207 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1208 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1209 (Node F). 1211 The Figure 12 shows the table that summarizes what headers are needed 1212 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1214 +----------+-----+--------------+--------------+--------------+------------+ 1215 | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | 1216 | |src | | Parent | | dst | 1217 | |node | | (6LRx) | | | 1218 +----------+-----+--------------+--------------+--------------+------------+ 1219 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1220 | headers | | | | | | 1221 +----------+-----+--------------+--------------+--------------+------------+ 1222 | Removed | -- | -- | -- | -- |IP6-IP6(RPI)| 1223 | headers | | | | | | 1224 +----------+-----+--------------+--------------+--------------+------------+ 1225 | Re-added | -- | -- | -- | -- | -- | 1226 | headers | | | | | | 1227 +----------+-----+--------------+--------------+--------------+------------+ 1228 | Modified | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- | 1229 | headers | | | | | | 1230 +----------+-----+--------------+--------------+--------------+------------+ 1231 |Untouched | -- | -- | -- | -- | -- | 1232 | headers | | | | | | 1233 +----------+-----+--------------+--------------+--------------+------------+ 1235 Figure 12: Storing mode: Summary of the use of headers from not-RPL- 1236 aware-leaf to RPL-aware-leaf. 1238 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1239 leaf 1241 In this case the flow comprises: 1243 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id 1244 --> not-RPL-aware 6LN (IPv6 dst) 1246 For example, a communication flow could be: Node G --> Node E --> 1247 Node B --> Node A (root) --> Node C --> Node J 1249 Internal nodes 6LR_ia (e.g: Node E or Node B) is the intermediate 1250 router from the not-RPL-aware source (Node G) to the root (6LBR) 1251 (Node A). In this case, "1 < ia <= n", n is the number of routers 1252 (6LR) that the packet goes through from IPv6 src to the root. 1254 6LR_id (C) is the intermediate router from the root (Node A) to the 1255 destination Node J. In this case, "1 <= id <= m", m is the number of 1256 routers (6LR) that the packet goes through from the root to 1257 destination (IPv6 dst). 1259 The RPI is ignored at the IPv6 dst node. 1261 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1262 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1263 header. The IPv6-in-IPv6 header is addressed hop-by-hop. 1265 The Figure 13 shows the table that summarizes what headers are needed 1266 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1268 +---------+------+-------+-------+---------+-------+-------+ 1269 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | IPv6 | 1270 | | src | | | | | dst | 1271 | | node | | | | | node | 1272 +---------+------+-------+-------+---------+-------+-------+ 1273 | Inserted| -- |IP6-IP6| -- | | -- | -- | 1274 | headers | | (RPI )| | | | | 1275 | | | | | | | | 1276 +---------+------+-------+-------+---------+-------+-------+ 1277 | Removed | -- | -- | -- | | -- |IP6-IP6| 1278 | headers | | | | | |(RPI) | 1279 | | | | | | | RPI | 1280 | | | | | | |Ignored| 1281 +---------+------+-------+-------+---------+-------+-------+ 1282 | Re-added| -- | -- | -- | -- | -- | -- | 1283 | headers | | | | | | | 1284 +---------+------+-------+-------+---------+-------+-------+ 1285 | Modified| -- | -- |IP6-IP6| IP6-IP6 |IP6-IP6| -- | 1286 | headers | | | (RPI) | (RPI) | (RPI) | | 1287 | | | | | | | | 1288 +---------+------+-------+-------+---------+-------+-------+ 1289 |Untouched| -- | -- | -- | -- | -- | -- | 1290 | headers | | | | | | | 1291 +---------+------+-------+-------+---------+-------+-------+ 1293 Figure 13: Storing mode: Summary of the use of headers from not-RPL- 1294 aware-leaf to not-RPL-aware-leaf 1296 7. Non Storing mode 1298 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1299 root) has complete knowledge about the connectivity of all DODAG 1300 nodes, and all traffic flows through the root node. Thus, there is 1301 no need for all nodes to know about the existence of not-RPL aware 1302 nodes. Only the 6LBR needs to act if compensation is necessary for 1303 not-RPL aware receivers. 1305 The following table (Figure 14) summarizes what headers are needed in 1306 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1307 IPv6 header are to be inserted. It depicts the target destination 1308 address possible (indicated by "Raf"), to a 6LR (parent of a 6LN) or 1309 to the root. In cases where no IPv6-in-IPv6 header is needed, the 1310 column states as "No". There is no expectation on RPL that RPI can 1311 be omitted, because it is needed for routing, quality of service and 1312 compression. This specification expects that is always a RPI 1313 Present. 1315 The leaf can be a router 6LR or a host, both indicated as 6LN 1316 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1317 where the RPI header may still be needed for the instanceID to be 1318 available for priority/channel selection at each hop. 1320 +-----------------+--------------+-----+-----+------------+------------+ 1321 | Interaction | Use Case | RPI | RH3 |IPv6-in-IPv6|IPv6-in-IPv6| 1322 | between | | | | | dst | 1323 +-----------------+--------------+-----+-----+------------+------------+ 1324 | | Raf to root | Yes | No | No | No | 1325 + +--------------+-----+-----+------------+------------+ 1326 | Leaf - Root | root to Raf | Yes | Yes | No | No | 1327 + +--------------+-----+-----+------------+------------+ 1328 | | root to ~Raf | Yes | Yes | must | 6LR | 1329 | | | (1) | | | | 1330 + +--------------+-----+-----+------------+------------+ 1331 | | ~Raf to root | Yes | No | must | root | 1332 +-----------------+--------------+-----+-----+------------+------------+ 1333 | | Raf to Int | Yes | No | No | No | 1334 + +--------------+-----+-----+------------+------------+ 1335 | Leaf - Internet | Int to Raf | Yes | Yes | must | Raf | 1336 + +--------------+-----+-----+------------+------------+ 1337 | | ~Raf to Int | Yes | No | must | root | 1338 + +--------------+-----+-----+------------+------------+ 1339 | | Int to ~Raf | Yes | Yes | must | 6LR | 1340 +-----------------+--------------+-----+-----+------------+------------+ 1341 | | Raf to Raf | Yes | Yes | must | root/Raf | 1342 + +--------------+-----+-----+------------+------------+ 1343 | | Raf to ~Raf | Yes | Yes | must | root/6LR | 1344 + Leaf - Leaf +--------------+-----+-----+------------+------------+ 1345 | | ~Raf to Raf | Yes | Yes | must | root/Raf | 1346 + +--------------+-----+-----+------------+------------+ 1347 | | ~Raf to ~Raf | Yes | Yes | must | root/6LR | 1348 +-----------------+--------------+-----+-----+------------+------------+ 1350 Figure 14: Table that shows headers needed in Non-Storing mode: RPI, 1351 RH3, IPv6-in-IPv6 encapsulation. 1353 7.1. Non-Storing Mode: Interaction between Leaf and Root 1355 In this section is described the communication flow in Non Storing 1356 Mode (Non-SM) between, 1358 RPL-aware-leaf to root 1360 root to RPL-aware-leaf 1362 not-RPL-aware-leaf to root 1363 root to not-RPL-aware-leaf 1365 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1367 In non-storing mode the leaf node uses default routing to send 1368 traffic to the root. The RPI header must be included since it 1369 contains the rank information, which is used to avoid/detect loops. 1371 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1373 For example, a communication flow could be: Node F --> Node D --> 1374 Node B --> Node A (root) 1376 6LR_i is the intermediate router from source to destination. In this 1377 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1378 goes through from source (6LN) to destination (6LBR). 1380 This situation is the same case as storing mode. 1382 The Table 7 summarizes what headers are needed for this use case. 1384 +-------------------+---------+-------+----------+ 1385 | Header | 6LN src | 6LR_i | 6LBR dst | 1386 +-------------------+---------+-------+----------+ 1387 | Inserted headers | RPI | -- | -- | 1388 | Removed headers | -- | -- | RPI | 1389 | Re-added headers | -- | -- | -- | 1390 | Modified headers | -- | RPI | -- | 1391 | Untouched headers | -- | -- | -- | 1392 +-------------------+---------+-------+----------+ 1394 Table 7: Non Storing mode: Summary of the use of headers from RPL- 1395 aware-leaf to root 1397 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1399 In this case the flow comprises: 1401 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1403 For example, a communication flow could be: Node A (root) --> Node B 1404 --> Node D --> Node F 1406 6LR_i is the intermediate router from source to destination. In this 1407 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1408 goes through from source (6LBR) to destination (6LN). 1410 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1411 necessary as the traffic originates with an RPL aware node, the 6LBR. 1412 The destination is known to be RPL-aware because the root knows the 1413 whole topology in non-storing mode. 1415 The Table 8 summarizes what headers are needed for this use case. 1417 +-------------------+----------+-----------+-----------+ 1418 | Header | 6LBR src | 6LR_i | 6LN dst | 1419 +-------------------+----------+-----------+-----------+ 1420 | Inserted headers | RPI, RH3 | -- | -- | 1421 | Removed headers | -- | -- | RH3, RPI | 1422 | Re-added headers | -- | -- | -- | 1423 | Modified headers | -- | RPI, RH3 | -- | 1424 | Untouched headers | -- | -- | -- | 1425 +-------------------+----------+-----------+-----------+ 1427 Table 8: Non Storing mode: Summary of the use of headers from root to 1428 RPL-aware-leaf 1430 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1432 In this case the flow comprises: 1434 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1436 For example, a communication flow could be: Node A (root) --> Node B 1437 --> Node E --> Node G 1439 6LR_i is the intermediate router from source to destination. In this 1440 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1441 goes through from source (6LBR) to destination (IPv6). 1443 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1444 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1445 but left there. As the RPI is added, then the IPv6 node which does 1446 not understand the RPI, will ignore it (following RFC8200), thus 1447 encapsulation is not necessary. 1449 The Figure 15 depicts the table that summarizes what headers are 1450 needed for this use case. 1452 +-----------+----------+--------------+----------------+----------+ 1453 | Header | 6LBR | 6LR_i | 6LR_n | IPv6 | 1454 | | | i=(1,..,n-1) | | dst | 1455 | | | | | node | 1456 +-----------+----------+--------------+----------------+----------+ 1457 | Inserted | RPI, RH3 | -- | -- | -- | 1458 | headers | | | | | 1459 +-----------+----------+--------------+----------------+----------+ 1460 | Removed | -- | -- | | -- | 1461 | headers | | | | | 1462 +-----------+----------+--------------+----------------+----------+ 1463 | Re-added | -- | -- | -- | -- | 1464 | headers | | | | | 1465 +-----------+----------+--------------+----------------+----------+ 1466 | Modified | -- | RPI, RH3 | RPI, | -- | 1467 | headers | | | RH3(consumed) | | 1468 +-----------+----------+--------------+----------------+----------+ 1469 | Untouched | -- | -- | -- | RPI, RH3 | 1470 | headers | | | | (both | 1471 | | | | | ignored) | 1472 +-----------+----------+--------------+----------------+----------+ 1474 Figure 15: Non Storing mode: Summary of the use of headers from root 1475 to not-RPL-aware-leaf 1477 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1479 In this case the flow comprises: 1481 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1483 For example, a communication flow could be: Node G --> Node E --> 1484 Node B --> Node A (root) 1486 6LR_i is the intermediate router from source to destination. In this 1487 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1488 goes through from source (IPv6) to destination (6LBR). For example, 1489 6LR_1 (i=1) is the router that receives the packets from the IPv6 1490 node. 1492 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1493 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1494 following 6LRs. The RPI and entire packet is consumed by the root. 1496 The Figure 16 shows the table that summarizes what headers are needed 1497 for this use case. 1499 +----------+------+-------------------+------------------+-----------------+ 1500 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | 1501 | | src | | | | 1502 | | node | | | | 1503 +----------+------+-------------------+------------------+-----------------+ 1504 | Inserted | -- | IPv6-in-IPv6(RPI) | -- | -- | 1505 | headers | | | | | 1506 +----------+------+-------------------+------------------+-----------------+ 1507 | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| 1508 | headers | | | | | 1509 +----------+------+-------------------+------------------+-----------------+ 1510 | Re-added | -- | -- | -- | -- | 1511 | headers | | | | | 1512 +----------+------+-------------------+------------------+-----------------+ 1513 | Modified | -- | -- | IPv6-in-IPv6(RPI)| -- | 1514 | headers | | | | | 1515 +----------+------+-------------------+------------------+-----------------+ 1516 |Untouched | -- | -- | -- | -- | 1517 | headers | | | | | 1518 +----------+------+-------------------+------------------+-----------------+ 1520 Figure 16: Non Storing mode: Summary of the use of headers from not- 1521 RPL-aware-leaf to root 1523 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1525 This section will describe the communication flow in Non Storing Mode 1526 (Non-SM) between: 1528 RPL-aware-leaf to Internet 1530 Internet to RPL-aware-leaf 1532 not-RPL-aware-leaf to Internet 1534 Internet to not-RPL-aware-leaf 1536 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1538 In this case the flow comprises: 1540 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1542 For example, a communication flow could be: Node F --> Node D --> 1543 Node B --> Node A --> Internet 1544 6LR_i is the intermediate router from source to destination. In this 1545 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1546 goes through from source (6LN) to 6LBR. 1548 This case is identical to storing-mode case. 1550 The IPv6 flow label should be set to zero to aid in compression, and 1551 the 6LBR will set it to a non-zero value when sending towards the 1552 Internet. 1554 The Table 9 summarizes what headers are needed for this use case. 1556 +-------------------+---------+-------+------+----------------+ 1557 | Header | 6LN src | 6LR_i | 6LBR | Internet dst | 1558 +-------------------+---------+-------+------+----------------+ 1559 | Inserted headers | RPI | -- | -- | -- | 1560 | Removed headers | -- | -- | -- | -- | 1561 | Re-added headers | -- | -- | -- | -- | 1562 | Modified headers | -- | RPI | -- | -- | 1563 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1564 +-------------------+---------+-------+------+----------------+ 1566 Table 9: Non Storing mode: Summary of the use of headers from RPL- 1567 aware-leaf to Internet 1569 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1571 In this case the flow comprises: 1573 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1575 For example, a communication flow could be: Internet --> Node A 1576 (root) --> Node B --> Node D --> Node F 1578 6LR_i is the intermediate router from source to destination. In this 1579 case, "1 <= i <= n", n is the number of routers (6LR) that the packet 1580 goes through from 6LBR to destination(6LN). 1582 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1583 address of the target node, it can address the IPv6-in-IPv6 header to 1584 that node. The 6LBR will zero the flow label upon entry in order to 1585 aid compression. 1587 The Table 10 summarizes what headers are needed for this use case. 1589 +-----------+----------+--------------+--------------+--------------+ 1590 | Header | Internet | 6LBR | 6LR_i | 6LN src | 1591 | | dst | | | | 1592 +-----------+----------+--------------+--------------+--------------+ 1593 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1594 | headers | | (RH3,RPI) | | | 1595 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1596 | headers | | | | (RH3,RPI) | 1597 | Re-added | -- | -- | -- | -- | 1598 | headers | | | | | 1599 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1600 | headers | | | (RH3,RPI) | | 1601 | Untouched | -- | -- | -- | -- | 1602 | headers | | | | | 1603 +-----------+----------+--------------+--------------+--------------+ 1605 Table 10: Non Storing mode: Summary of the use of headers from 1606 Internet to RPL-aware-leaf 1608 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1610 In this case the flow comprises: 1612 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1613 Internet 1615 For example, a communication flow could be: Node G --> Node E --> 1616 Node B --> Node A --> Internet 1618 6LR_i is the intermediate router from source to destination. In this 1619 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1620 goes through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1622 In this case the flow label is recommended to be zero in the IPv6 1623 node. As RPL headers are added in the IPv6 node packet, the first 1624 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1625 The IPv6-in-IPv6 header will be addressed to the root. This case is 1626 identical to the storing-mode case (see Section 6.2.3). 1628 The Figure 17 shows the table that summarizes what headers are needed 1629 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1631 +-----------+------+--------------+--------------+--------------+----------+ 1632 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | 1633 | | src | | [i=2,..,n] | | dst | 1634 | | node | | | | | 1635 +-----------+------+--------------+--------------+--------------+----------+ 1636 | Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | 1637 | headers | | | | | | 1638 +-----------+------+--------------+--------------+--------------+----------+ 1639 | Removed | -- | -- | -- | IP6-IP6(RPI) | -- | 1640 | headers | | | | | | 1641 +-----------+------+--------------+--------------+--------------+----------+ 1642 | Re-added | -- | -- | -- | -- | -- | 1643 | headers | | | | | | 1644 +-----------+------+--------------+--------------+--------------+----------+ 1645 | Modified | -- | -- | IP6-IP6(RPI) | -- | -- | 1646 | headers | | | | | | 1647 +-----------+------+--------------+--------------+--------------+----------+ 1648 | Untouched | -- | -- | -- | -- | -- | 1649 | headers | | | | | | 1650 +-----------+------+--------------+--------------+--------------+----------+ 1652 Figure 17: Non Storing mode: Summary of the use of headers from not- 1653 RPL-aware-leaf to Internet 1655 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1657 In this case the flow comprises: 1659 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1661 For example, a communication flow could be: Internet --> Node A 1662 (root) --> Node B --> Node E --> Node G 1664 6LR_i is the intermediate router from source to destination. In this 1665 case, "1 < i <= n", n is the number of routers (6LR) that the packet 1666 goes through from 6LBR to not-RPL-aware-leaf (IPv6). 1668 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1669 6LBR will know the path, and will recognize that the final node is 1670 not an RPL capable node as it will have received the connectivity DAO 1671 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1672 header destination be the last 6LR. The 6LBR will set to zero the 1673 flow label upon entry in order to aid compression. 1675 The Figure 18 shows the table that summarizes what headers are needed 1676 for this use case. 1678 +-----------+--------+--------------+--------------+--------------+------+ 1679 | Header |Internet| 6LBR | 6LR_1 | 6lR_i | IPv6 | 1680 | | src | | | (i=2,...,n) | dst | 1681 | | | | | | node | 1682 +-----------+--------+--------------+--------------+--------------+------+ 1683 | Inserted | -- | IPv6-in-IPv6 | -- | -- | -- | 1684 | headers | | (RH3,RPI) | | | | 1685 +-----------+--------+--------------+--------------+--------------+------+ 1686 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1687 | headers | | | | (RH3,RPI)[1] | | 1688 +-----------+--------+--------------+--------------+--------------+------+ 1689 | Re-added | -- | -- | -- | -- | -- | 1690 | headers | | | | | | 1691 +-----------+--------+--------------+--------------+--------------+------+ 1692 | Modified | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1693 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1694 +-----------+--------+--------------+--------------+--------------+------+ 1695 | Untouched | -- | -- | -- | -- | -- | 1696 | headers | | | | | | 1697 +-----------+--------+--------------+--------------+--------------+------+ 1699 Figure 18: Non-Storing mode: Summary of the use of headers from 1700 Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node. 1702 7.3. Non-Storing Mode: Interaction between Leafs 1704 In this section is described the communication flow in Non Storing 1705 Mode (Non-SM) between, 1707 RPL-aware-leaf to RPL-aware-leaf 1709 RPL-aware-leaf to not-RPL-aware-leaf 1711 not-RPL-aware-leaf to RPL-aware-leaf 1713 not-RPL-aware-leaf to not-RPL-aware-leaf 1715 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1717 In this case the flow comprises: 1719 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1721 For example, a communication flow could be: Node F --> Node D --> 1722 Node B --> Node A (root) --> Node B --> Node E --> Node H 1723 6LR_ia is the intermediate router from source to the root In this 1724 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1725 packet goes through from 6LN to the root. 1727 6LR_id is the intermediate router from the root to the destination. 1728 In this case, "1 <= ia <= m", m is the number of the intermediate 1729 routers (6LR). 1731 This case involves only nodes in same RPL Domain. The originating 1732 node will add a RPI header to the original packet, and send the 1733 packet upwards. 1735 The originating node must put the RPI into an IPv6-in-IPv6 header 1736 addressed to the root, so that the 6LBR can remove that header. If 1737 it does not, then additional resources are wasted on the way down to 1738 carry the useless RPI option. 1740 The 6LBR will need to insert an RH3 header, which requires that it 1741 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1742 it was contained in an IPv6-in-IPv6 header addressed to it. 1743 Otherwise, there may be a RPI header buried inside the inner IP 1744 header, which should get ignored. 1746 Networks that use the RPL P2P extension [RFC6997] are essentially 1747 non-storing DODAGs and fall into this scenario or scenario 1748 Section 7.1.2, with the originating node acting as 6LBR. 1750 The Figure 19 shows the table that summarizes what headers are needed 1751 for this use case. 1753 +---------+------------+----------+------------+------------+------------+ 1754 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | 1755 | | src | | | | dst | 1756 +---------+------------+----------+------------+------------+------------+ 1757 | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | 1758 | headers | (RPI1) | |(RH3-> 6LN, | | | 1759 | | | | RPI2) | | | 1760 +---------+------------+----------+------------+------------+------------+ 1761 | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| 1762 | headers | | | (RPI1) | | (RH3, | 1763 | | | | | | RPI2) | 1764 +---------+------------+----------+------------+------------+------------+ 1765 | Re-added| -- | -- | -- | -- | -- | 1766 | headers | | | | | | 1767 +---------+------------+----------+------------+------------+------------+ 1768 | Modified| -- |IP6-in-IP6| -- |IPv6-in-IPv6| -- | 1769 | headers | | (RPI1) | | (RPI2) | | 1770 +---------+------------+----------+------------+------------+------------+ 1771 |Untouched| -- | -- | -- | -- | -- | 1772 | headers | | | | | | 1773 +---------+------------+----------+------------+------------+------------+ 1775 Figure 19: Non Storing mode: Summary of the use of headers for RPL- 1776 aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6. 1778 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1779 leaf 1781 In this case the flow comprises: 1783 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1785 For example, a communication flow could be: Node F --> Node D --> 1786 Node B --> Node A (root) --> Node B --> Node E --> Node G 1788 6LR_ia is the intermediate router from source to the root In this 1789 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1791 6LR_id is the intermediate router from the root to the destination. 1792 In this case, "1 <= ia <= m", m is the number of the intermediate 1793 routers (6LRs). 1795 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1796 which must be in an IPv6-in-IPv6 header addressed to the root so that 1797 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1798 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. 1800 The Figure 20 shows the table that summarizes what headers are needed 1801 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1803 +-----------+---------+---------+---------+---------+---------+------+ 1804 | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LR_m | IPv6 | 1805 | | src | | | | | dst | 1806 | | | | | | | node | 1807 +-----------+---------+---------+---------+---------+---------+------+ 1808 | Inserted | IP6-IP6 | | IP6-IP6 | -- | -- | -- | 1809 | headers | (RPI1) | | (RH3, | | | | 1810 | | | | RPI2) | | | | 1811 +-----------+---------+---------+---------+---------+---------+------+ 1812 | Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1813 | headers | | | (RPI1) | | (RH3, | | 1814 | | | | | | RPI2) | | 1815 +-----------+---------+---------+---------+---------+---------+------+ 1816 | Re-added | -- | -- | -- | -- | -- | -- | 1817 | headers | | | | | | | 1818 +-----------+---------+---------+---------+---------+---------+------+ 1819 | Modified | -- | IP6-IP6 | -- | IP6-IP6 | | -- | 1820 | headers | | (RPI1) | | (RH3, | | | 1821 | | | | | RPI2) | | | 1822 +-----------+---------+---------+---------+---------+---------+------+ 1823 | Untouched | -- | -- | -- | -- | -- | -- | 1824 | headers | | | | | | | 1825 +-----------+---------+---------+---------+---------+---------+------+ 1827 Figure 20: Non Storing mode: Summary of the use of headers from RPL- 1828 aware-leaf to not-RPL-aware-leaf. 1830 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1831 leaf 1833 In this case the flow comprises: 1835 not-RPL-aware 6LN (IPv6) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1836 6LR_id --> 6LN 1838 For example, a communication flow could be: Node G --> Node E --> 1839 Node B --> Node A (root) --> Node B --> Node E --> Node H 1841 6LR_ia is the intermediate router from source to the root. In this 1842 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1844 6LR_id is the intermediate router from the root to the destination. 1845 In this case, "1 <= ia <= m", m is the number of the intermediate 1846 routers (6LR). 1848 This scenario is mostly identical to the previous one. The RPI is 1849 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1850 addressed to the root. The 6LBR will remove this RPI, and add it's 1851 own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI_2). 1853 The Figure 21 shows the table that summarizes what headers are needed 1854 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1856 +-----------+------+---------+---------+---------+---------+---------+ 1857 | Header | IPv6 | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LN | 1858 | | src | | | | | dst | 1859 | | node | | | | | | 1860 +-----------+------+---------+---------+---------+---------+---------+ 1861 | Inserted | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- | 1862 | headers | | (RPI1) | | (RH3, | | | 1863 | | | | | RPI2) | | | 1864 +-----------+------+---------+---------+---------+---------+---------+ 1865 | Removed | -- | | -- | IP6-IP6 | -- | IP6-IP6 | 1866 | headers | | | | (RPI1) | | (RH3, | 1867 | | | | | | | RPI2) | 1868 +-----------+------+---------+---------+---------+---------+---------+ 1869 | Re-added | -- | | -- | -- | -- | -- | 1870 | headers | | | | | | | 1871 +-----------+------+---------+---------+---------+---------+---------+ 1872 | Modified | -- | | IP6-IP6 | -- | IP6-IP6 | -- | 1873 | headers | | | (RPI1) | | (RH3, | | 1874 | | | | | | RPI2) | | 1875 +-----------+------+---------+---------+---------+---------+---------+ 1876 | Untouched | -- | | -- | -- | -- | -- | 1877 | headers | | | | | | | 1878 +-----------+------+---------+---------+---------+---------+---------+ 1880 Figure 21: Non Storing mode: Summary of the use of headers from not- 1881 RPL-aware-leaf to RPL-aware-leaf. 1883 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1884 aware-leaf 1886 In this case the flow comprises: 1888 not-RPL-aware 6LN (IPv6 src) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 1889 6LR_id --> not-RPL-aware (IPv6 dst) 1891 For example, a communication flow could be: Node G --> Node E --> 1892 Node B --> Node A (root) --> Node C --> Node J 1894 6LR_ia is the intermediate router from source to the root. In this 1895 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1896 6LR_id is the intermediate router from the root to the destination. 1897 In this case, "1 <= ia <= m", m is the number of the intermediate 1898 routers (6LR). 1900 This scenario is the combination of the previous two cases. 1902 The Figure 22 shows the table that summarizes what headers are needed 1903 for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. 1905 +---------+------+-------+-------+---------+-------+---------+------+ 1906 | Header | IPv6 | 6LR_1 | 6LR_ia| 6LBR |6LR_id | 6LR_m | IPv6 | 1907 | | src | | | | | | dst | 1908 | | node | | | | | | node | 1909 +---------+------+-------+-------+---------+-------+---------+------+ 1910 | Inserted| -- |IP6-IP6| -- | IP6-IP6 | -- | -- | -- | 1911 | headers | | (RPI1)| | (RH3, | | | | 1912 | | | | | RPI2) | | | | 1913 +---------+------+-------+-------+---------+-------+---------+------+ 1914 | Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- | 1915 | headers | | | | (RPI1) | | (RH3, | | 1916 | | | | | | | RPI2) | | 1917 +---------+------+-------+-------+---------+-------+---------+------+ 1918 | Re-added| -- | -- | -- | -- | -- | -- | -- | 1919 | headers | | | | | | | | 1920 +---------+------+-------+-------+---------+-------+---------+------+ 1921 | Modified| -- | -- |IP6-IP6| -- |IP6-IP6| -- | -- | 1922 | headers | | | (RPI1)| | (RH3, | | | 1923 | | | | | | RPI2)| | | 1924 +---------+------+-------+-------+---------+-------+---------+------+ 1925 |Untouched| -- | -- | -- | -- | -- | -- | -- | 1926 | headers | | | | | | | | 1927 +---------+------+-------+-------+---------+-------+---------+------+ 1929 Figure 22: Non Storing mode: Summary of the use of headers from not- 1930 RPL-aware-leaf to not-RPL-aware-leaf 1932 8. Operational Considerations of supporting not-RPL-aware-leaves 1934 Roughly half of the situations described in this document involve 1935 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1936 further categories: ones that drop a packet that have RPI or RH3 1937 headers, and ones that continue to process a packet that has RPI and/ 1938 or RH3 headers. 1940 [RFC8200] provides for new rules that suggest that nodes that have 1941 not been configured (explicitly) to examine Hop-by-Hop headers, 1942 should ignore those headers, and continue processing the packet. 1943 Despite this, and despite the switch from 0x63 to 0x23, there may be 1944 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1945 drop packets that continue to have RPL artifacts in them. In 1946 general, such hosts can not be easily supported in RPL LLNs. 1948 There are some specific cases where it is possible to remove the RPL 1949 artifacts prior to forwarding the packet to the leaf host. The 1950 critical thing is that the artifacts have been inserted by the RPL 1951 root inside an IPv6-in-IPv6 header, and that the header has been 1952 addressed to the 6LR immediately prior to the leaf node. In that 1953 case, in the process of removing the IPv6-in-IPv6 header, the 1954 artifacts can also be removed. 1956 The above case occurs whenever traffic originates from the outside 1957 the LLN (the "Internet" cases above), and non-storing mode is used. 1958 In non-storing mode, the RPL root knows the exact topology (as it 1959 must be create the RH3 header), and therefore knows what the 6LR 1960 prior to the leaf. For example, in Figure 5, node E is the 6LR prior 1961 to the leaf node G, or node C is the 6LR prior to the leaf node J. 1963 Traffic originating from the RPL root (such as when the data 1964 collection system is co-located on the RPL root), does not require an 1965 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1966 the root, and the root can insert the RPI and RH3 headers directly 1967 into the packet, as it is formed. Such a packet is slightly smaller, 1968 but only can be sent to nodes (whether RPL aware or not), that will 1969 tolerate the RPL artifacts. 1971 An operator that finds itself with a lot of traffic from the RPL root 1972 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1973 if the leaf is not tolerant of the RPL artifacts. Such an operator 1974 could otherwise omit this unnecessary header if it was certain of the 1975 properties of the leaf. 1977 As storing mode can not know the final path of the traffic, 1978 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1979 be supported. 1981 9. Operational considerations of introducing 0x23 1983 This section describes the operational considerations of introducing 1984 the new RPI value of 0x23. 1986 During bootstrapping the node gets the DIO with the information of 1987 RPL Option Type, indicating the new RPI in the DODAG Configuration 1988 Option Flag. The DODAG root is in charge to configure the current 1989 network to the new value, through DIO messages and when all the nodes 1990 are set with the new value. The DODAG should change to a new DODAG 1991 version. In case of rebooting, the node does not remember the RPL 1992 Option Type. Thus, the DIO is sent with a flag indicating the new 1993 RPI value. 1995 The DODAG Configuration option is contained in a RPL DIO message, 1996 which contains a unique DTSN counter. The leaf nodes respond to this 1997 message with DAO messages containing the same DTSN. This is a normal 1998 part of RPL routing; the RPL root therefore knows when the updated 1999 DODAG Configuration Option has been seen by all nodes. 2001 Before the migration happens, all the RPL-aware nodes should support 2002 both values . The migration procedure it is triggered when the DIO 2003 is sent with the flag indicating the new RPI value. Namely, it 2004 remains at 0x63 until it is sure that the network is capable of 0x23, 2005 then it abruptly change to 0x23. This options allows to send packets 2006 to not-RPL nodes, which should ignore the option and continue 2007 processing the packets. 2009 In case that a node join to a network that only process 0x63, it 2010 would produce a flag day as was mentioned previously. Indicating the 2011 new RPI in the DODAG Configuration Option Flag is a way to avoid the 2012 flag day in a network. It is recommended that a network process both 2013 options to enable interoperability. 2015 10. IANA Considerations 2017 This document updates the registration made in [RFC6553] Destination 2018 Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in 2019 Figure 23. 2021 [RFCXXXX] represents this document. 2023 Hex Value Binary Value 2024 act chg rest Description Reference 2025 --------- --- --- ------- ----------------- ---------- 2026 0x23 00 1 00011 RPL Option [RFCXXXX] 2027 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 2029 Figure 23: Option Type in RPL Option. 2031 DODAG Configuration option is updated as follows (Figure 24): 2033 +------------+-----------------+---------------+ 2034 | Bit number | Description | Reference | 2035 +------------+-----------------+---------------+ 2036 | 3 | RPI 0x23 enable | This document | 2037 +------------+-----------------+---------------+ 2039 Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- 2040 day. 2042 11. Security Considerations 2044 The security considerations covered in [RFC6553] and [RFC6554] apply 2045 when the packets are in the RPL Domain. 2047 The IPv6-in-IPv6 mechanism described in this document is much more 2048 limited than the general mechanism described in [RFC2473]. The 2049 willingness of each node in the LLN to decapsulate packets and 2050 forward them could be exploited by nodes to disguise the origin of an 2051 attack. 2053 While a typical LLN may be a very poor origin for attack traffic (as 2054 the networks tend to be very slow, and the nodes often have very low 2055 duty cycles) given enough nodes, they could still have a significant 2056 impact, particularly if the target of the attack is targeting another 2057 LLN. Additionally, some uses of RPL involve large backbone ISP scale 2058 equipment [I-D.ietf-anima-autonomic-control-plane], which may be 2059 equipped with multiple 100Gb/s interfaces. 2061 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 2062 LLN as described above will make sure that any attack that is mounted 2063 must originate from compromised nodes within the LLN. The use of 2064 BCP38 [BCP38] filtering at the RPL root on egress traffic will both 2065 alert the operator to the existence of the attack, as well as drop 2066 the attack traffic. As the RPL network is typically numbered from a 2067 single prefix, which is itself assigned by RPL, BCP38 filtering 2068 involves a single prefix comparison and should be trivial to 2069 automatically configure. 2071 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2072 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2073 communications between a new Pledge and the Join Registrar/ 2074 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2075 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2076 the RPL root to do careful filtering: it occurs only when the Join 2077 Coordinator is not co-located inside the RPL root. 2079 With the above precautions, an attack using IPv6-in-IPv6 tunnels can 2080 only be by a node within the LLN on another node within the LLN. 2081 Such an attack could, of course, be done directly. An attack of this 2082 kind is meaningful only if the source addresses are either fake or if 2083 the point is to amplify return traffic. Such an attack, could also 2084 be done without the use of IPv6-in-IPv6 headers using forged source 2085 addresses. If the attack requires bi-directional communication, then 2086 IPv6-in-IPv6 provides no advantages. 2088 Whenever IPv6-in-IPv6 headers are being proposed, there is a concern 2089 about creating security issues. In the security section of 2090 [RFC2473], it was suggested that tunnel entry and exit points can be 2091 secured, via "Use IPsec". This recommendation is not practical for 2092 RPL networks. [RFC5406] goes into some detail on what additional 2093 details would be needed in order to "Use IPsec". Use of ESP would 2094 prevent RFC8183 compression (compression must occur before 2095 encryption), and RFC8183 compression is lossy in a way that prevents 2096 use of AH. These are minor issues. The major issue is how to 2097 establish trust enough such that IKEv2 could be used. This would 2098 require a system of certificates to be present in every single node, 2099 including any Internet nodes that might need to communicate with the 2100 LLN. Thus, "Use IPsec" requires a global PKI in the general case. 2102 More significantly, the use of IPsec tunnels to protect the IPv6-in- 2103 IPv6 headers would in the general case scale with the square of the 2104 number of nodes. This is a lot of resource for a constrained nodes 2105 on a constrained network. In the end, the IPsec tunnels would be 2106 providing only BCP38-like origin authentication! Just doing BCP38 2107 origin filtering at the entry and exit of the LLN provides a similar 2108 level amount of security without all the scaling and trust problems 2109 of using IPsec as RFC2473 suggested. IPsec is not recommended. 2111 An LLN with hostile nodes within it would not be protected against 2112 impersonation with the LLN by entry/exit filtering. 2114 The RH3 header usage described here can be abused in equivalent ways 2115 (to disguise the origin of traffic and attack other nodes) with an 2116 IPv6-in-IPv6 header to add the needed RH3 header. As such, the 2117 attacker's RH3 header will not be seen by the network until it 2118 reaches the end host, which will decapsulate it. An end-host should 2119 be suspicious about a RH3 header which has additional hops which have 2120 not yet been processed, and SHOULD ignore such a second RH3 header. 2122 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2123 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2124 will see the second RH3 header and MAY choose to discard the packet 2125 if the RH3 header has not been completely consumed. A consumed 2126 (inert) RH3 header could be present in a packet that flows from one 2127 LLN, crosses the Internet, and enters another LLN. As per the 2128 discussion in this document, such headers do not need to be removed. 2129 However, there is no case described in this document where an RH3 is 2130 inserted in a non-storing network on traffic that is leaving the LLN, 2131 but this document should not preclude such a future innovation. It 2132 should just be noted that an incoming RH3 must be fully consumed, or 2133 very carefully inspected. 2135 The RPI header, if permitted to enter the LLN, could be used by an 2136 attacker to change the priority of a packet by selecting a different 2137 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2138 It could also be that not all nodes are reachable in an LLN using the 2139 default instanceID, but a change of instanceID would permit an 2140 attacker to bypass such filtering. Like the RH3, a RPI header is to 2141 be inserted by the RPL root on traffic entering the LLN by first 2142 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2143 therefore will not be seen by the network. Upon reaching the 2144 destination node the RPI header has no further meaning and is just 2145 skipped; the presence of a second RPI header will have no meaning to 2146 the end node as the packet has already been identified as being at 2147 it's final destination. 2149 The RH3 and RPI headers could be abused by an attacker inside of the 2150 network to route packets on non-obvious ways, perhaps eluding 2151 observation. This usage is in fact part of [RFC6997] and can not be 2152 restricted at all. This is a feature, not a bug. 2154 [RFC7416] deals with many other threats to LLNs not directly related 2155 to the use of IPv6-in-IPv6 headers, and this document does not change 2156 that analysis. 2158 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2159 attack on another part of the LLN, while disguising the origin of the 2160 attack. The mechanism can even be abused to make it appear that the 2161 attack is coming from outside the LLN, and unless countered, this 2162 could be used to mount a Distributed Denial Of Service attack upon 2163 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2164 such attacks already seen in the real world. 2166 If an attack comes from inside of LLN, it can be alleviated with SAVI 2167 (Source Address Validation Improvement) using [RFC8505] with 2168 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source 2169 traffic with an address that is not registered, and the registration 2170 process checks for topological correctness. Notice that there is an 2171 L2 authentication in most of the cases. If an attack comes from 2172 outside LLN IPv6-in- IPv6 can be used to hide inner routing headers, 2173 but by construction, the RH3 can typically only address nodes within 2174 the LLN. That is, a RH3 with a CmprI less than 8 , should be 2175 considered an attack (see RFC6554, section 3). 2177 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2178 through the RPL root to perform this attack. To counter, the RPL 2179 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2180 simpler solution), or it SHOULD walk the IP header extension chain 2181 until it can inspect the upper-layer-payload as described in 2182 [RFC7045]. In particular, the RPL root SHOULD do [BCP38] processing 2183 on the source addresses of all IP headers that it examines in both 2184 directions. 2186 Note: there are some situations where a prefix will spread across 2187 multiple LLNs via mechanisms such as the one described in 2188 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2189 needs to take this into account, either by exchanging detailed 2190 routing information on each LLN, or by moving the BCP38 filtering 2191 further towards the Internet, so that the details of the multiple 2192 LLNs do not matter. 2194 12. Acknowledgments 2196 This work is done thanks to the grant by the Stand.ICT project. 2198 A special BIG thanks to C. M. Heard for the help with the 2199 Section 3. Much of the redaction in that section is based on his 2200 comments. 2202 Additionally, the authors would like to acknowledge the review, 2203 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2204 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2205 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2207 13. References 2209 13.1. Normative References 2211 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2212 Defeating Denial of Service Attacks which employ IP Source 2213 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2214 May 2000, . 2216 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2217 Requirement Levels", BCP 14, RFC 2119, 2218 DOI 10.17487/RFC2119, March 1997, 2219 . 2221 [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion 2222 Notification", RFC 6040, DOI 10.17487/RFC6040, November 2223 2010, . 2225 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2226 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2227 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2228 Low-Power and Lossy Networks", RFC 6550, 2229 DOI 10.17487/RFC6550, March 2012, 2230 . 2232 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2233 Power and Lossy Networks (RPL) Option for Carrying RPL 2234 Information in Data-Plane Datagrams", RFC 6553, 2235 DOI 10.17487/RFC6553, March 2012, 2236 . 2238 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2239 Routing Header for Source Routes with the Routing Protocol 2240 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2241 DOI 10.17487/RFC6554, March 2012, 2242 . 2244 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2245 of IPv6 Extension Headers", RFC 7045, 2246 DOI 10.17487/RFC7045, December 2013, 2247 . 2249 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2250 "IPv6 over Low-Power Wireless Personal Area Network 2251 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2252 April 2017, . 2254 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2255 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2256 May 2017, . 2258 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2259 (IPv6) Specification", STD 86, RFC 8200, 2260 DOI 10.17487/RFC8200, July 2017, 2261 . 2263 13.2. Informative References 2265 [DDOS-KREBS] 2266 Goodin, D., "Record-breaking DDoS reportedly delivered by 2267 >145k hacked cameras", September 2016, 2268 . 2271 [I-D.ietf-6lo-ap-nd] 2272 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2273 "Address Protected Neighbor Discovery for Low-power and 2274 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2275 progress), April 2019. 2277 [I-D.ietf-6lo-backbone-router] 2278 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2279 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2280 in progress), February 2019. 2282 [I-D.ietf-6tisch-dtsecurity-secure-join] 2283 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2284 6tisch-dtsecurity-secure-join-01 (work in progress), 2285 February 2017. 2287 [I-D.ietf-anima-autonomic-control-plane] 2288 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2289 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2290 plane-19 (work in progress), March 2019. 2292 [I-D.ietf-anima-bootstrapping-keyinfra] 2293 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2294 S., and K. Watsen, "Bootstrapping Remote Secure Key 2295 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2296 keyinfra-20 (work in progress), May 2019. 2298 [I-D.ietf-intarea-tunnels] 2299 Touch, J. and M. Townsley, "IP Tunnels in the Internet 2300 Architecture", draft-ietf-intarea-tunnels-09 (work in 2301 progress), July 2018. 2303 [I-D.thubert-roll-unaware-leaves] 2304 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2305 unaware-leaves-07 (work in progress), April 2019. 2307 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2308 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 2309 December 1998, . 2311 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2312 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2313 December 1998, . 2315 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2316 Control Message Protocol (ICMPv6) for the Internet 2317 Protocol Version 6 (IPv6) Specification", STD 89, 2318 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2319 . 2321 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2322 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2323 February 2009, . 2325 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2326 Bormann, "Neighbor Discovery Optimization for IPv6 over 2327 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2328 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2329 . 2331 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2332 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2333 in Low-Power and Lossy Networks", RFC 6997, 2334 DOI 10.17487/RFC6997, August 2013, 2335 . 2337 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2338 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2339 2014, . 2341 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2342 and M. Richardson, Ed., "A Security Threat Analysis for 2343 the Routing Protocol for Low-Power and Lossy Networks 2344 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2345 . 2347 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2348 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2349 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2350 May 2017, . 2352 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2353 Perkins, "Registration Extensions for IPv6 over Low-Power 2354 Wireless Personal Area Network (6LoWPAN) Neighbor 2355 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2356 . 2358 Authors' Addresses 2360 Maria Ines Robles 2361 Aalto University 2362 Otaniemi 2363 Espoo 02150 2364 Finland 2366 Email: mariainesrobles@gmail.com 2368 Michael C. Richardson 2369 Sandelman Software Works 2370 470 Dawson Avenue 2371 Ottawa, ON K1Z 5V7 2372 CA 2374 Email: mcr+ietf@sandelman.ca 2375 URI: http://www.sandelman.ca/mcr/ 2377 Pascal Thubert 2378 Cisco Systems, Inc 2379 Village d'Entreprises Green Side 400, Avenue de Roumanille 2380 Batiment T3, Biot - Sophia Antipolis 06410 2381 France 2383 Email: pthubert@cisco.com