idnits 2.17.00 (12 Aug 2021) /tmp/idnits32633/draft-ietf-roll-useofrplinfo-20.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to directly say this. It does mention RFC6550 though, so this could be OK. -- The draft header indicates that this document updates RFC8138, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6553, but the abstract doesn't seem to directly say this. It does mention RFC6553 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 210 has weird spacing: '... act chg ...' == Line 244 has weird spacing: '... act chg ...' == Line 1741 has weird spacing: '... act chg ...' -- The document date (January 29, 2018) is 1573 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 1744, but not defined == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 1973, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-dao-projection' is defined on line 1994, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 7416 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-6man-rfc6434-bis has been published as RFC 8504 == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == 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 (-25) exists of draft-ietf-roll-dao-projection-02 Summary: 2 errors (**), 0 flaws (~~), 13 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 Ericsson 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: August 2, 2018 P. Thubert 7 Cisco 8 January 29, 2018 10 When to use RFC 6553, 6554 and IPv6-in-IPv6 11 draft-ietf-roll-useofrplinfo-20 13 Abstract 15 This document looks at different data flows through LLN (Low-Power 16 and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power 17 and Lossy Networks) is used to establish routing. The document 18 enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 19 encapsulation is required. This analysis provides the basis on which 20 to design efficient compression of these headers. Additionally, this 21 document updates the RFC 6553 adding a change to the RPL Option Type 22 and the RFC 6550 to indicate about this change. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 2, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology and Requirements Language . . . . . . . . . . . . 4 60 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5 61 3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5 62 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 63 3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6 64 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 65 Configuration Option Flag. . . . . . . . . . . . . . . . 7 66 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8 67 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14 70 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 15 71 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 16 72 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 16 73 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 17 74 6.2. Storing Mode: Interaction between Leaf and Internet . . . 18 75 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 18 76 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18 77 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 78 Internet . . . . . . . . . . . . . . . . . . . . . . 19 79 6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 80 leaf . . . . . . . . . . . . . . . . . . . . . . . . 20 81 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 21 82 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 83 leaf . . . . . . . . . . . . . . . . . . . . . . . . 21 84 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 85 aware-leaf . . . . . . . . . . . . . . . . . . . . . 22 86 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 87 aware-leaf . . . . . . . . . . . . . . . . . . . . . 23 88 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 89 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 24 90 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 25 91 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 26 92 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 27 93 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 27 94 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 95 leaf . . . . . . . . . . . . . . . . . . . . . . . . 28 96 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 97 root . . . . . . . . . . . . . . . . . . . . . . . . 29 98 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 30 99 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 100 Internet . . . . . . . . . . . . . . . . . . . . . . 30 101 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 102 leaf . . . . . . . . . . . . . . . . . . . . . . . . 31 103 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 104 Internet . . . . . . . . . . . . . . . . . . . . . . 32 105 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 106 aware-leaf . . . . . . . . . . . . . . . . . . . . . 33 107 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 34 108 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 109 aware-leaf . . . . . . . . . . . . . . . . . . . . . 34 110 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 111 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 36 112 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 113 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37 114 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 115 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 38 116 8. Observations about the cases . . . . . . . . . . . . . . . . 38 117 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 38 118 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 39 119 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 39 120 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 122 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 123 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 124 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 125 13.2. Informative References . . . . . . . . . . . . . . . . . 44 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 128 1. Introduction 130 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 131 [RFC6550] is a routing protocol for constrained networks. RFC 6553 132 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 133 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 134 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 135 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 136 RPL routing domain, particularly in non-storing mode. 138 These various items are referred to as RPL artifacts, and they are 139 seen on all of the data-plane traffic that occurs in RPL routed 140 networks; they do not in general appear on the RPL control plane 141 traffic at all which is mostly hop-by-hop traffic (one exception 142 being DAO messages in non-storing mode). 144 It has become clear from attempts to do multi-vendor 145 interoperability, and from a desire to compress as many of the above 146 artifacts as possible that not all implementors agree when artifacts 147 are necessary, or when they can be safely omitted, or removed. 149 An interim meeting went through the 24 cases defined here to discover 150 if there were any shortcuts, and this document is the result of that 151 discussion. This document clarifies what is the correct and the 152 incorrect behaviour. 154 The related document A Routing Header Dispatch for 6LoWPAN (6LoRH) 155 [RFC8138] defines a method to compress RPL Option information and 156 Routing Header type 3 [RFC6554], an efficient IP-in-IP technique, and 157 use cases proposed for the [Second6TischPlugtest] involving 6loRH. 159 2. Terminology and Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC 2119 [RFC2119]. 165 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 166 RPL, RPL Domain and ROLL. 168 RPL-node: A device which implements RPL, thus we can say that the 169 device is RPL-capable or RPL-aware. Please note that the device can 170 be found inside the LLN or outside LLN. In this document a RPL-node 171 which is a leaf of a DODAG is called RPL-aware-leaf. 173 RPL-not-capable: A device which does not implement RPL, thus we can 174 say that the device is not-RPL-aware. Please note that the device 175 can be found inside the LLN. In this document a not-RPL-aware node 176 which is a leaf of a DODAG is called not-RPL-aware-leaf. 178 pledge: a new device which seeks admission to a network. (from 179 [I-D.ietf-anima-bootstrapping-keyinfra]) 181 Join Registrar and Coordinator (JRC): a device which brings new nodes 182 (pledges) into a network. (from 183 [I-D.ietf-anima-bootstrapping-keyinfra]) 185 Flag day: A "flag day" is a procedure in which the network, or a part 186 of it, is changed during a planned outage, or suddenly, causing an 187 outage while the network recovers [RFC4192] 189 2.1. hop-by-hop IPv6-in-IPv6 headers 191 The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header 192 that originates from a node to an adjacent node, using the addresses 193 (usually the GUA or ULA, but could use the link-local addresses) of 194 each node. If the packet must traverse multiple hops, then it must 195 be decapsulated at each hop, and then re-encapsulated again in a 196 similar fashion. 198 3. Updates to RFC6553, RFC6550 and RFC 8138 200 3.1. Updates to RFC 6553 202 [RFC6553] states as showed below, that in the Option Type field of 203 the RPL Option header, the two high order bits MUST be set to '01' 204 and the third bit is equal to '1'. The first two bits indicate that 205 the IPv6 node MUST discard the packet if it doesn't recognize the 206 option type, and the third bit indicates that the Option Data may 207 change en route. The remaining bits serve as the option type. 209 Hex Value Binary Value 210 act chg rest Description Reference 211 --------- --- --- ------- ----------------- ---------- 212 0x63 01 1 00011 RPL Option [RFC6553] 214 Figure 1: Option Type in RPL Option. 216 Recent changes in [RFC8200] (section 4, page 8), states: "it is now 217 expected that nodes along a packet's delivery path only examine and 218 process the Hop-by-Hop Options header if explicitly configured to do 219 so". Processing of the Hop-by-Hop Options header (by IPv6 220 intermediate nodes) is now optional, but if they are configured to 221 process the header, and if such nodes encounter an option with the 222 first two bits set to 01, they will drop the packet (if they conform 223 to [RFC8200]). Host systems should do the same, irrespective of the 224 configuration. 226 Based on That, if an IPv6 (intermediate) node (RPL-not-capable) 227 receives a packet with an RPL Option, it should ignore the HBH RPL 228 option (skip over this option and continue processing the header). 230 Thus, this document updates the Option Type field to: the two high 231 order bits MUST be set to '00' and the third bit is equal to '1'. 232 The first two bits indicate that the IPv6 node MUST skip over this 233 option and continue processing the header ([RFC8200] Section 4.2) if 234 it doesn't recognize the option type, and the third bit continues to 235 be set to indicate that the Option Data may change en route. The 236 remaining bits serve as the option type and remain as 0x3. This 237 ensures that a packet that leaves the RPL domain of an LLN (or that 238 leaves the LLN entirely) will not be discarded when it contains the 239 [RFC6553] RPL Hop-by-Hop option known as RPI. 241 This is a significant update to [RFC6553]. 243 Hex Value Binary Value 244 act chg rest Description Reference 245 --------- --- --- ------- ----------------- ---------- 246 0x23 00 1 00011 RPL Option [RFCXXXX] 248 Figure 2: Revised Option Type in RPL Option. 250 This change creates a flag day for existing networks which are 251 currently using 0x63 as the RPI value. A move to 0x23 will not be 252 understood by those networks. It is suggested that implementations 253 accept both 0x63 and 0x23 when processing. 255 When forwarding packets, implementations SHOULD use the same value as 256 it was received (This is required because, RPI type code can not be 257 changed by [RFC8200]). It allows to the network to be incrementally 258 upgraded, and for the DODAG root to know which parts of the network 259 are upgraded. 261 When originating new packets, implementations SHOULD have an option 262 to determine which value to originate with, this option is controlled 263 by the DIO option described below. 265 A network which is switching from straight 6lowpan compression 266 mechanism to those described in [RFC8138] will experience a flag day 267 in the data compression anyway, and if possible this change can be 268 deployed at the same time. 270 3.2. Updates to RFC 8138 272 RPI-6LoRH header provides a compressed form for the RPL RPI 273 [RFC8138]. It should be considered when the Option Type in RPL 274 Option is decompressed, should take the value of 0x23 instead of 275 0x63. 277 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 278 Configuration Option Flag. 280 In order to avoid a flag day caused by lack of interoperation between 281 new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new 282 nodes and old nodes, the new nodes may be put into a compatibility 283 mode until all of the old nodes are replaced or upgraded. 285 This can be done via a DODAG Configuration Option flag which will 286 propogate through the network. Failure to receive this information 287 will cause new nodes to remain in compatibility mode, and originate 288 traffic with the old-RPI (0x63) value. 290 As stated in [RFC6550] the DODAG Configuration option is present in 291 DIO messages. The DODAG Configuration option distributes 292 configuration information. It is generally static, and does not 293 change within the DODAG. This information is configured at the DODAG 294 root and distributed throughout the DODAG with the DODAG 295 Configuration option. Nodes other than the DODAG root do not modify 296 this information when propagating the DODAG Configuration option. 298 The DODAG Configuration Option has a Flags field which is modified by 299 this document. Currently, the DODAG Configuration Option in 300 [RFC6550] is as follows. . 302 Flags: The 4-bits remaining unused in the Flags field are reserved 303 for flags. The field MUST be initialized to zero by the sender and 304 MUST be ignored by the receiver. 306 0 1 2 3 307 +-----------------+---------------------------------------------------+ 308 | Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. | 309 +---------------------------------------------------------------------+ 310 | DIOIntMin. | DIORedund. | MaxRankIncrease | 311 +-----------------+---------------------------------------------------+ 312 | MinHopRankIncrease | OCP | 313 +-----------------+---------------------------------------------------+ 314 |Reserved | Def. Lifetime | Lifetime Unit | 315 +-----------------+-----------------+---------------------------------+ 317 Figure 3: DODAG Configuration Option. 319 Bit number three of flag field in the DODAG Configuration option is 320 to be used as follows: 322 +------------+-----------------+---------------+ 323 | Bit number | Description | Reference | 324 +------------+-----------------+---------------+ 325 | 3 | RPI 0x23 enable | This document | 326 +------------+-----------------+---------------+ 328 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 329 day. 331 In case of rebooting, the node does not remember the flag. Thus, the 332 DIO is sent with flag indicating the new RPI value. 334 4. Sample/reference topology 336 A RPL network in general is composed of a 6LBR (6LoWPAN Border 337 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 338 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 339 (Destination Oriented Directed Acyclic Graph). 341 RPL defines the RPL Control messages (control plane), a new ICMPv6 342 [RFC4443] message with Type 155. DIS (DODAG Information 343 Solicitation), DIO (DODAG Information Object) and DAO (Destination 344 Advertisement Object) messages are all RPL Control messages but with 345 different Code values. A RPL Stack is showed in Figure 5. 347 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 348 it is fully stateful; in non-storing (RPL-NSM), it is fully source 349 routed. A RPL Instance is either fully storing or fully non-storing, 350 i.e. a RPL Instance with a combination of storing and non-storing 351 nodes is not supported with the current specifications at the time of 352 writing this document. 354 +--------------+ 355 | Upper Layers | 356 | | 357 +--------------+ 358 | RPL | 359 | | 360 +--------------+ 361 | ICMPv6 | 362 | | 363 +--------------+ 364 | IPv6 | 365 | | 366 +--------------+ 367 | 6LoWPAN | 368 | | 369 +--------------+ 370 | PHY-MAC | 371 | | 372 +--------------+ 374 Figure 5: RPL Stack. 376 +------------+ 377 | INTERNET ----------+ 378 | | | 379 +------------+ | 380 | 381 | 382 | 383 A | 384 +-------+ 385 |6LBR | 386 +-----------|(root) |-------+ 387 | +-------+ | 388 | | 389 | | 390 | | 391 | | 392 | B |C 393 +---|---+ +---|---+ 394 | 6LR | | 6LR | 395 +-------->| |--+ +--- ---+ 396 | +-------+ | | +-------+ | 397 | | | | 398 | | | | 399 | | | | 400 | | | | 401 | D | E | | 402 +-|-----+ +---|---+ | | 403 | 6LR | | 6LR | | | 404 | | +------ | | | 405 +---|---+ | +---|---+ | | 406 | | | | | 407 | | +--+ | | 408 | | | | | 409 | | | | | 410 | | | I | J | 411 F | | G | H | | 412 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 413 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 414 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 415 +-------+ +-------+ +------+ +-------+ +-------+ 417 Figure 6: A reference RPL Topology. 419 Figure 2 shows the reference RPL Topology for this document. The 420 letters above the nodes are there so that they may be referenced in 421 subsequent sections. In the figure, 6LR represents a full router 422 node. The 6LN is a RPL aware router, or host. 424 But, the 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I) 425 are RPL nodes with no children hosts. 427 The leafs marked as ~Raf "not-RPL aware leaf" (G and J) are devices 428 which do not speak RPL at all (not-RPL-aware), but uses Router- 429 Advertisements, 6LowPAN DAR/DAC and efficient-ND only to participate 430 in the network [RFC6775]. In the document these leafs (G and J) are 431 also refered to as an IPv6 node. 433 The 6LBR ("A") in the figure is the root of the Global DODAG. 435 5. Use cases 437 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 438 encapsulation are going to be analyzed for a number of representative 439 traffic flows. 441 This document assumes that the LLN is using the no-drop RPI option 442 (0x23). 444 The uses cases describe the communication between RPL-aware-nodes, 445 with the root (6LBR), and with Internet. This document also describe 446 the communication between nodes acting as leaves that do not 447 understand RPL, but are part of the LLN. We name these nodes as not- 448 RPL-aware-leaf. (e.g. Section 6.1.4 Flow from not-RPL-aware-leaf to 449 root) We describe also how is the communication inside of the LLN 450 when it has the final destination addressed outside of the LLN e.g. 451 with destination to Internet. (e.g. Section 6.2.3 Flow from not- 452 RPL-aware-leaf to Internet) 454 The uses cases comprise as follow: 456 Interaction between Leaf and Root: 458 RPL-aware-leaf to root 460 root to RPL-aware-leaf 462 not-RPL-aware-leaf to root 464 root to not-RPL-aware-leaf 466 Interaction between Leaf and Internet: 468 RPL-aware-leaf to Internet 469 Internet to RPL-aware-leaf 471 not-RPL-aware-leaf to Internet 473 Internet to not-RPL-aware-leaf 475 Interaction between Leafs: 477 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 479 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 481 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 483 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 485 This document is consistent with the rule that a Header cannot be 486 inserted or removed on the fly inside an IPv6 packet that is being 487 routed. This is a fundamental precept of the IPv6 architecture as 488 outlined in [RFC2460]. Extensions may not be added or removed except 489 by the sender or the receiver. 491 However, unlike [RFC6553], the Hop-by-Hop Option Header used for the 492 RPI artifact has the first two bits set to '00'. This means that the 493 RPI artifact will be ignored when received by a host or router that 494 does not understand that option ( Section 4.2 [RFC8200]). 496 This means that when the no-drop RPI option code 0x23 is used, a 497 packet that leaves the RPL domain of an LLN (or that leaves the LLN 498 entirely) will not be discarded when it contains the [RFC6553] RPL 499 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option MAY 500 be left in place even if the end host does not understand it. 502 NOTE: There is some possible security risk when the RPI information 503 is released to the Internet. At this point this is a theoretical 504 situation; no clear attack has been described. At worst, it is clear 505 that the RPI option would waste some network bandwidth when it 506 escapes. This is traded off against the savings in the LLN by not 507 having to encapsulate the packet in order to remove the artifact. 509 Despite being legal to leave the RPI artifact in place, an 510 intermediate router that needs to add an extension header (SHR3 or 511 RPI Option) MUST still encapsulate the packet in an (additional) 512 outer IP header. The new header is placed after this new outer IP 513 header. 515 A corollory is that an SHR3 or RPI Option can only be removed by an 516 intermediate router if it is placed in an encapsulating IPv6 Header, 517 which is addressed TO the intermediate router. When it does so, the 518 whole encapsulating header must be removed. (A replacement may be 519 added). This sometimes can result in outer IP headers being 520 addressed to the next hop router using link-local addresses. 522 Both RPI and RH3 headers may be modified in very specific ways by 523 routers on the path of the packet without the need to add to remove 524 an encapsulating header. Both headers were designed with this 525 modification in mind, and both the RPL RH and the RPL option are 526 marked mutable but recoverable: so an IPsec AH security header can be 527 applied across these headers, but it can not secure the values which 528 mutate. 530 RPI should be present in every single RPL data packet. There is one 531 exception in non-storing mode: when a packet is going down from the 532 root. In a downward non-storing mode, the entire route is written, 533 so there can be no loops by construction, nor any confusion about 534 which forwarding table to use (as the root has already made all 535 routing decisions). However, there are still cases, such as in 536 6tisch, where the instanceID portion of the RPI header may still be 537 needed to pick an appropriate priority or channel at each hop. 539 In the tables present in this document, the term "RPL aware leaf" is 540 has been shortened to "Raf", and "not-RPL aware leaf" has been 541 shortened to "~Raf" to make the table fit in available space. 543 The earlier examples are more extensive to make sure that the process 544 is clear, while later examples are more concise. 546 6. Storing mode 548 In storing mode (fully stateful), the sender can determine if the 549 destination is inside the LLN by looking if the destination address 550 is matched by the DIO's PIO option. 552 The following table itemizes which headers are needed in the 553 following scenarios, and indicates if the IP-in-IP header must be 554 inserted on a hop-by-hop basis, or when it can target the destination 555 node directly. There are these possible situations: hop-by-hop 556 necessary (indicated by "hop"), or destination address possible 557 (indicated by "dst"). In all cases hop by hop MAY be used. 559 In cases where no IP-in-IP header is needed, the column is left 560 blank. 562 In all cases the RPI headers are needed, since it identifies 563 inconsistencies (loops) in the routing topology. In all cases the 564 RH3 is not needed because we do not indicate the route in storing 565 mode. 567 In each case, 6LR_i are the intermediate routers from source to 568 destination. "1 <= i >= n", n is the number of routers (6LR) that 569 the packet go through from source (6LN) to destination. 571 The leaf can be a router 6LR or a host, both indicated as 6LN (see 572 Figure 6). 574 +---------------------+--------------+----------+--------------+ 575 | Interaction between | Use Case | IP-in-IP | IP-in-IP dst | 576 +---------------------+--------------+----------+--------------+ 577 | | Raf to root | No | -- | 578 + +--------------+----------+--------------+ 579 | Leaf - Root | root to Raf | No | -- | 580 + +--------------+----------+--------------+ 581 | | root to ~Raf | No | -- | 582 + +--------------+----------+--------------+ 583 | | ~Raf to root | Yes | root | 584 +---------------------+--------------+----------+--------------+ 585 | | Raf to Int | No | -- | 586 + +--------------+----------+--------------+ 587 | Leaf - Internet | Int to Raf | Yes | Raf | 588 + +--------------+----------+--------------+ 589 | | ~Raf to Int | Yes | root | 590 + +--------------+----------+--------------+ 591 | | Int to ~Raf | Yes | hop | 592 +---------------------+--------------+----------+--------------+ 593 | | Raf to Raf | No | -- | 594 + +--------------+----------+--------------+ 595 | | Raf to ~Raf | No | -- | 596 + Leaf - Leaf +--------------+----------+--------------+ 597 | | ~Raf to Raf | Yes | dst | 598 + +--------------+----------+--------------+ 599 | | ~Raf to ~Raf | Yes | hop | 600 +---------------------+--------------+----------+--------------+ 602 Figure 7: IP-in-IP encapsulation in Storing mode. 604 6.1. Storing Mode: Interaction between Leaf and Root 606 In this section we are going to describe the communication flow in 607 storing mode (SM) between, 608 RPL-aware-leaf to root 610 root to RPL-aware-leaf 612 not-RPL-aware-leaf to root 614 root to not-RPL-aware-leaf 616 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 618 In storing mode, RFC 6553 (RPI) is used to send RPL Information 619 instanceID and rank information. 621 As stated in Section 16.2 of [RFC6550] an RPL-aware-leaf node does 622 not generally issue DIO messages; a leaf node accepts DIO messages 623 from upstream. (When the inconsistency in routing occurs, a leaf 624 node will generate a DIO with an infinite rank, to fix it). It may 625 issue DAO and DIS messages though it generally ignores DAO and DIS 626 messages. 628 In this case the flow comprises: 630 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 632 For example, a communication flow could be: Node F --> Node E --> 633 Node B --> Node A root(6LBR) 635 As it was mentioned in this document 6LRs, 6LBR are always full- 636 fledged RPL routers. 638 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 639 (Node E) which decrements the rank in RPI and sends the packet up. 640 When the packet arrives at 6LBR (Node A), the RPI is removed and the 641 packet is processed. 643 No IP-in-IP header is required. 645 The RPI header can be removed by the 6LBR because the packet is 646 addressed to the 6LBR. The 6LN must know that it is communicating 647 with the 6LBR to make use of this scenario. The 6LN can know the 648 address of the 6LBR because it knows the address of the root via the 649 DODAGID in the DIO messages. 651 +-------------------+-----+-------+------+ 652 | Header | 6LN | 6LR_i | 6LBR | 653 +-------------------+-----+-------+------+ 654 | Inserted headers | RPI | -- | -- | 655 | Removed headers | -- | -- | RPI | 656 | Re-added headers | -- | -- | -- | 657 | Modified headers | -- | RPI | -- | 658 | Untouched headers | -- | -- | -- | 659 +-------------------+-----+-------+------+ 661 Storing: Summary of the use of headers from RPL-aware-leaf to root 663 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 665 In this case the flow comprises: 667 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 669 For example, a communication flow could be: Node A root(6LBR) --> 670 Node B --> Node D --> Node F 672 In this case the 6LBR inserts RPI header and sends the packet down, 673 the 6LR is going to increment the rank in RPI (it examines the 674 instanceID to identify the right forwarding table), the packet is 675 processed in the 6LN and the RPI removed. 677 No IP-in-IP header is required. 679 +-------------------+------+-------+------+ 680 | Header | 6LBR | 6LR_i | 6LN | 681 +-------------------+------+-------+------+ 682 | Inserted headers | RPI | -- | -- | 683 | Removed headers | -- | -- | RPI | 684 | Re-added headers | -- | -- | -- | 685 | Modified headers | -- | RPI | -- | 686 | Untouched headers | -- | -- | -- | 687 +-------------------+------+-------+------+ 689 Storing: Summary of the use of headers from root to RPL-aware-leaf 691 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 693 In this case the flow comprises: 695 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 697 For example, a communication flow could be: Node A root(6LBR) --> 698 Node B --> Node E --> Node G 699 As the RPI extension can be ignored by the not-RPL-aware leaf, this 700 situation is identical to the previous scenario. 702 +-------------------+------+-------+----------------+ 703 | Header | 6LBR | 6LR_i | IPv6 | 704 +-------------------+------+-------+----------------+ 705 | Inserted headers | RPI | -- | -- | 706 | Removed headers | -- | -- | -- | 707 | Re-added headers | -- | -- | -- | 708 | Modified headers | -- | RPI | -- | 709 | Untouched headers | -- | -- | RPI (Ignored) | 710 +-------------------+------+-------+----------------+ 712 Storing: Summary of the use of headers from root to not-RPL-aware- 713 leaf 715 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 717 In this case the flow comprises: 719 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 721 For example, a communication flow could be: Node G --> Node E --> 722 Node B --> Node A root(6LBR) 724 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 725 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 726 header. The IPv6-in-IPv6 header can be addressed to the next hop 727 (Node B), or to the root (Node A). The root removes the header and 728 processes the packet. 730 +------------+------+---------------+---------------+---------------+ 731 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 732 +------------+------+---------------+---------------+---------------+ 733 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 734 | headers | | | | | 735 | Removed | -- | -- | -- | IP-in-IP(RPI) | 736 | headers | | | | | 737 | Re-added | -- | -- | -- | -- | 738 | headers | | | | | 739 | Modified | -- | -- | IP-in-IP(RPI) | -- | 740 | headers | | | | | 741 | Untouched | -- | -- | -- | -- | 742 | headers | | | | | 743 +------------+------+---------------+---------------+---------------+ 745 Storing: Summary of the use of headers from not-RPL-aware-leaf to 746 root 748 6.2. Storing Mode: Interaction between Leaf and Internet 750 In this section we are going to describe the communication flow in 751 storing mode (SM) between, 753 RPL-aware-leaf to Internet 755 Internet to RPL-aware-leaf 757 not-RPL-aware-leaf to Internet 759 Internet to not-RPL-aware-leaf 761 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 763 RPL information from RFC 6553 MAY go out to Internet as it will be 764 ignored by nodes which have not been configured to be RPI aware. 766 In this case the flow comprises: 768 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 770 For example, the communication flow could be: Node F --> Node D --> 771 Node B --> Node A root(6LBR) --> Internet 773 No IP-in-IP header is required. 775 Note: In this use case we use a node as leaf, but this use case can 776 be also applicable to any RPL-node type (e.g. 6LR) 778 +-------------------+------+-------+------+----------------+ 779 | Header | 6LN | 6LR_i | 6LBR | Internet | 780 +-------------------+------+-------+------+----------------+ 781 | Inserted headers | RPI | -- | -- | -- | 782 | Removed headers | -- | -- | -- | -- | 783 | Re-added headers | -- | -- | -- | -- | 784 | Modified headers | -- | RPI | -- | -- | 785 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 786 +-------------------+------+-------+------+----------------+ 788 Storing: Summary of the use of headers from RPL-aware-leaf to 789 Internet 791 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 793 In this case the flow comprises: 795 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 796 For example, a communication flow could be: Internet --> Node A 797 root(6LBR) --> Node B --> Node D --> Node F 799 When the packet arrives from Internet to 6LBR the RPI header is added 800 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 801 rank in the RPI. When the packet arrives at 6LN the RPI header is 802 removed and the packet processed. 804 +----------+---------+--------------+---------------+---------------+ 805 | Header | Interne | 6LBR | 6LR_i | 6LN | 806 | | t | | | | 807 +----------+---------+--------------+---------------+---------------+ 808 | Inserted | -- | IP-in- | -- | -- | 809 | headers | | IP(RPI) | | | 810 | Removed | -- | -- | -- | IP-in-IP(RPI) | 811 | headers | | | | | 812 | Re-added | -- | -- | -- | -- | 813 | headers | | | | | 814 | Modified | -- | -- | IP-in-IP(RPI) | -- | 815 | headers | | | | | 816 | Untouche | -- | -- | -- | -- | 817 | d | | | | | 818 | headers | | | | | 819 +----------+---------+--------------+---------------+---------------+ 821 Storing: Summary of the use of headers from Internet to RPL-aware- 822 leaf 824 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 826 In this case the flow comprises: 828 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 829 Internet 831 For example, a communication flow could be: Node G --> Node E --> 832 Node B --> Node A root(6LBR) --> Internet 834 The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed 835 either to the root, or hop-by-hop such that the root can remove the 836 RPI header before passing upwards. The IP-in-IP addressed to the 837 root cause less processing overhead. On the other hand, with hop-by- 838 hop the intermediate routers can check the routing tables for a 839 better routing path, thus it could be more efficient and faster. 840 Implementation should decide wich approach to take. 842 The originating node will ideally leave the IPv6 flow label as zero 843 so that the packet can be better compressed through the LLN. The 844 6LBR will set the flow label of the packet to a non-zero value when 845 sending to the Internet. 847 +---------+-----+-------------+-------------+-------------+---------+ 848 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 849 | | 6 | | [i=2,..,n]_ | | t | 850 +---------+-----+-------------+-------------+-------------+---------+ 851 | Inserte | -- | IP-in- | -- | -- | -- | 852 | d | | IP(RPI) | | | | 853 | headers | | | | | | 854 | Removed | -- | -- | -- | IP-in- | -- | 855 | headers | | | | IP(RPI) | | 856 | Re- | -- | -- | -- | -- | -- | 857 | added | | | | | | 858 | headers | | | | | | 859 | Modifie | -- | -- | IP-in- | -- | -- | 860 | d | | | IP(RPI) | | | 861 | headers | | | | | | 862 | Untouch | -- | -- | -- | -- | -- | 863 | ed | | | | | | 864 | headers | | | | | | 865 +---------+-----+-------------+-------------+-------------+---------+ 867 Storing: Summary of the use of headers from not-RPL-aware-leaf to 868 Internet 870 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf 872 In this case the flow comprises: 874 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 876 For example, a communication flow could be: Internet --> Node A 877 root(6LBR) --> Node B --> Node E --> Node G 879 The 6LBR will have to add an RPI header within an IP-in-IP header. 880 The IP-in-IP is addressed to the not-RPL-aware-leaf, leaving the RPI 881 inside. 883 Note that there is a requirement that the final node be able to 884 remove one or more IPIP headers which are all addressed to it. 885 (EDNOTE: this should go into [I-D.ietf-6man-rfc6434-bis]) 887 The 6LBR MAY set the flow label on the inner IP-in-IP header to zero 888 in order to aid in compression. 890 +-----------+----------+---------------+---------------+------------+ 891 | Header | Internet | 6LBR | 6LR_i | IPv6 | 892 +-----------+----------+---------------+---------------+------------+ 893 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 894 | headers | | | | | 895 | Removed | -- | -- | -- | -- | 896 | headers | | | | | 897 | Re-added | -- | -- | -- | -- | 898 | headers | | | | | 899 | Modified | -- | -- | IP-in-IP(RPI) | -- | 900 | headers | | | | | 901 | Untouched | -- | -- | -- | RPI | 902 | headers | | | | (Ignored) | 903 +-----------+----------+---------------+---------------+------------+ 905 Storing: Summary of the use of headers from Internet to non-RPL- 906 aware-leaf 908 6.3. Storing Mode: Interaction between Leaf and Leaf 910 In this section we are going to describe the communication flow in 911 storing mode (SM) between, 913 RPL-aware-leaf to RPL-aware-leaf 915 RPL-aware-leaf to not-RPL-aware-leaf 917 not-RPL-aware-leaf to RPL-aware-leaf 919 not-RPL-aware-leaf to not-RPL-aware-leaf 921 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 923 In [RFC6550] RPL allows a simple one-hop optimization for both 924 storing and non-storing networks. A node may send a packet destined 925 to a one-hop neighbor directly to that node. See section 9 in 926 [RFC6550]. 928 When the nodes are not directly connected, then in storing mode, the 929 flow comprises: 931 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 933 For example, a communication flow could be: Node F --> Node D --> 934 Node B --> Node E --> Node H 936 6LR_ia (Node D) are the intermediate routers from source to the 937 common parent (6LR_x) (Node B) In this case, "1 <= ia >= n", n is the 938 number of routers (6LR) that the packet go through from 6LN (Node F) 939 to the common parent (6LR_x). 941 6LR_id (Node E) are the intermediate routers from the common parent 942 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 943 >= m", m is the number of routers (6LR) that the packet go through 944 from the common parent (6LR_x) to destination 6LN. 946 It is assume that the two nodes are in the same RPL Domain (that they 947 share the same DODAG root). At the common parent (Node B), the 948 direction of RPI is changed (from increasing to decreasing the rank). 950 While the 6LR nodes will update the RPI, no node needs to add or 951 remove the RPI, so no IP-in-IP headers are necessary. This may be 952 done regardless of where the destination is, as the included RPI will 953 be ignored by the receiver. 955 +---------------+--------+--------+---------------+--------+--------+ 956 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 957 | | src | | parent) | | dst | 958 +---------------+--------+--------+---------------+--------+--------+ 959 | Inserted | RPI | -- | -- | -- | -- | 960 | headers | | | | | | 961 | Removed | -- | -- | -- | -- | RPI | 962 | headers | | | | | | 963 | Re-added | -- | -- | -- | -- | -- | 964 | headers | | | | | | 965 | Modified | -- | RPI | RPI | RPI | -- | 966 | headers | | | | | | 967 | Untouched | -- | -- | -- | -- | -- | 968 | headers | | | | | | 969 +---------------+--------+--------+---------------+--------+--------+ 971 Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 972 aware-leaf 974 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 976 In this case the flow comprises: 978 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 979 6LN (IPv6) 981 For example, a communication flow could be: Node F --> Node D --> 982 Node B --> Node E --> Node G 984 6LR_ia are the intermediate routers from source (6LN) to the common 985 parent (6LR_x) In this case, "1 <= ia >= n", n is the number of 986 routers (6LR) that the packet go through from 6LN to the common 987 parent (6LR_x). 989 6LR_id (Node E) are the intermediate routers from the common parent 990 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 991 In this case, "1 <= id >= m", m is the number of routers (6LR) that 992 the packet go through from the common parent (6LR_x) to destination 993 6LN. 995 This situation is identical to the previous situation Section 6.3.1 997 +-----------+------+--------+---------------+--------+--------------+ 998 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 999 | | src | | parent) | | | 1000 +-----------+------+--------+---------------+--------+--------------+ 1001 | Inserted | RPI | -- | -- | -- | -- | 1002 | headers | | | | | | 1003 | Removed | -- | -- | -- | -- | RPI | 1004 | headers | | | | | | 1005 | Re-added | -- | -- | -- | -- | -- | 1006 | headers | | | | | | 1007 | Modified | -- | RPI | RPI | RPI | -- | 1008 | headers | | | | | | 1009 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1010 | headers | | | | | | 1011 +-----------+------+--------+---------------+--------+--------------+ 1013 Storing: Summary of the use of headers for RPL-aware-leaf to non-RPL- 1014 aware-leaf 1016 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1018 In this case the flow comprises: 1020 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1021 6LR_id --> 6LN 1023 For example, a communication flow could be: Node G --> Node E --> 1024 Node B --> Node D --> Node F 1026 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 1027 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In 1028 this case, "1 <= ia >= n", n is the number of routers (6LR) that the 1029 packet go through from source to the common parent. 1031 6LR_id (Node D) are the intermediate routers from the common parent 1032 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1033 >= m", m is the number of routers (6LR) that the packet go through 1034 from the common parent (6LR_x) to destination 6LN. 1036 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1037 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1038 header. The IP-in-IP header is addressed to the destination 6LN 1039 (Node F). 1041 +--------+------+------------+------------+------------+------------+ 1042 | Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN | 1043 | | | | parent | | | 1044 | | | | (6LRx) | | | 1045 +--------+------+------------+------------+------------+------------+ 1046 | Insert | -- | IP-in- | -- | -- | -- | 1047 | ed hea | | IP(RPI) | | | | 1048 | ders | | | | | | 1049 | Remove | -- | -- | -- | -- | IP-in- | 1050 | d head | | | | | IP(RPI) | 1051 | ers | | | | | | 1052 | Re- | -- | -- | -- | -- | -- | 1053 | added | | | | | | 1054 | header | | | | | | 1055 | s | | | | | | 1056 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1057 | ed hea | | | IP(RPI) | IP(RPI) | | 1058 | ders | | | | | | 1059 | Untouc | -- | -- | -- | -- | -- | 1060 | hed he | | | | | | 1061 | aders | | | | | | 1062 +--------+------+------------+------------+------------+------------+ 1064 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1065 RPL-aware-leaf 1067 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1068 leaf 1070 In this case the flow comprises: 1072 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not- 1073 RPL-aware 6LN (IPv6 dst) 1075 For example, a communication flow could be: Node G --> Node E --> 1076 Node B --> Node A (root) --> Node C --> Node J 1078 Internal nodes 6LR_ia (e.g: Node E or Node B) are the intermediate 1079 routers from the not-RPL-aware source (Node G) to the root (6LBR) 1080 (Node A). In this case, "1 < ia >= n", n is the number of routers 1081 (6LR) that the packet go through from IPv6 src to the root. 1083 6LR_id (C) are the intermediate routers from the root (Node A) to the 1084 destination Node J. In this case, "1 <= id >= m", m is the number of 1085 routers (6LR) that the packet go through from the root to destination 1086 (IPv6 dst). 1088 Note that this flow is identical to Section 6.3.3, except for where 1089 the IPIP header is inserted. 1091 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1092 G) and inserts the RPI header (RPIa), encapsulated in an IPv6-in-IPv6 1093 header. The IPv6-in-IPv6 header is addressed to the final 1094 destination. 1096 +----------+-----+-------------+--------------+--------------+------+ 1097 | Header | IPv | 6LR_1 | 6LR_ia | 6LR_m | IPv6 | 1098 | | 6 | | | | dst | 1099 | | src | | | | | 1100 +----------+-----+-------------+--------------+--------------+------+ 1101 | Inserted | -- | IP-in- | -- | -- | -- | 1102 | headers | | IP(RPI) | | | | 1103 | Removed | -- | -- | -- | -- | -- | 1104 | headers | | | | | | 1105 | Re-added | -- | -- | -- | -- | -- | 1106 | headers | | | | | | 1107 | Modified | -- | -- | IP-in- | IP-in- | -- | 1108 | headers | | | IP(RPI) | IP(RPI) | | 1109 | Untouche | -- | -- | -- | -- | -- | 1110 | d | | | | | | 1111 | headers | | | | | | 1112 +----------+-----+-------------+--------------+--------------+------+ 1114 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1115 non-RPL-aware-leaf 1117 7. Non Storing mode 1119 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1120 root) has complete knowledge about the connectivity of all DODAG 1121 nodes, and all traffic flows through the root node. Thus, there is 1122 no need for all nodes to know about the existence of non-RPL aware 1123 nodes. Only the 6LBR needs to act if compensation is necessary for 1124 non-RPL aware receivers. 1126 The following table summarizes what headers are needed in the 1127 following scenarios, and indicates when the RPI, RH3 and IP-in-IP 1128 header must be inserted. There are these possible situations: 1129 destination address possible (indicated by "dst"), to a 6LR, to a 6LN 1130 or to the root. In cases where no IP-in-IP header is needed, the 1131 column is left blank. 1133 The leaf can be a router 6LR or a host, both indicated as 6LN 1134 (Figure 3). 1136 +-----------------+--------------+-----+-----+----------+----------+ 1137 | Interaction | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP | 1138 | between | | | | | dst | 1139 +-----------------+--------------+-----+-----+----------+----------+ 1140 | | Raf to root | Yes | No | No | -- | 1141 + +--------------+-----+-----+----------+----------+ 1142 | Leaf - Root | root to Raf | Opt | Yes | No | -- | 1143 + +--------------+-----+-----+----------+----------+ 1144 | | root to ~Raf |no(1)| Yes | Yes | 6LR | 1145 + +--------------+-----+-----+----------+----------+ 1146 | | ~Raf to root | Yes | No | Yes | root | 1147 +-----------------+--------------+-----+-----+----------+----------+ 1148 | | Raf to Int | Yes | No | Yes | root | 1149 + +--------------+-----+-----+----------+----------+ 1150 | Leaf - Internet | Int to Raf |no(1)| Yes | Yes | dst | 1151 + +--------------+-----+-----+----------+----------+ 1152 | | ~Raf to Int | Yes | No | Yes | root | 1153 + +--------------+-----+-----+----------+----------+ 1154 | | Int to ~Raf |no(1)| Yes | Yes | 6LR | 1155 +-----------------+--------------+-----+-----+----------+----------+ 1156 | | Raf to Raf | Yes | Yes | Yes | root/dst | 1157 + +--------------+-----+-----+----------+----------+ 1158 | | Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1159 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1160 | | ~Raf to Raf | Yes | Yes | Yes | root/6LN | 1161 + +--------------+-----+-----+----------+----------+ 1162 | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1163 +-----------------+--------------+-----+-----+----------+----------+ 1165 (1)-6tisch networks may need the RPI information. 1167 Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP 1168 encapsulation. 1170 7.1. Non-Storing Mode: Interaction between Leaf and Root 1172 In this section we are going to describe the communication flow in 1173 Non Storing Mode (Non-SM) between, 1174 RPL-aware-leaf to root 1176 root to RPL-aware-leaf 1178 not-RPL-aware-leaf to root 1180 root to not-RPL-aware-leaf 1182 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1184 In non-storing mode the leaf node uses default routing to send 1185 traffic to the root. The RPI header must be included to avoid/detect 1186 loops. 1188 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1190 For example, a communication flow could be: Node F --> Node D --> 1191 Node B --> Node A (root) 1193 6LR_i are the intermediate routers from source to destination. In 1194 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1195 packet go through from source (6LN) to destination (6LBR). 1197 This situation is the same case as storing mode. 1199 +-------------------+-----+-------+------+ 1200 | Header | 6LN | 6LR_i | 6LBR | 1201 +-------------------+-----+-------+------+ 1202 | Inserted headers | RPI | -- | -- | 1203 | Removed headers | -- | -- | RPI | 1204 | Re-added headers | -- | -- | -- | 1205 | Modified headers | -- | RPI | -- | 1206 | Untouched headers | -- | -- | -- | 1207 +-------------------+-----+-------+------+ 1209 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1210 root 1212 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1214 In this case the flow comprises: 1216 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1218 For example, a communication flow could be: Node A (root) --> Node B 1219 --> Node D --> Node F 1220 6LR_i are the intermediate routers from source to destination. In 1221 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1222 packet go through from source (6LBR) to destination (6LN). 1224 The 6LBR will insert an RH3, and may optionally insert an RPI header. 1225 No IP-in-IP header is necessary as the traffic originates with an RPL 1226 aware node, the 6LBR. The destination is known to RPL-aware because, 1227 the root knows the whole topology in non-storing mode. 1229 +-------------------+-----------------+-------+----------+ 1230 | Header | 6LBR | 6LR_i | 6LN | 1231 +-------------------+-----------------+-------+----------+ 1232 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1233 | Removed headers | -- | -- | RH3,RPI | 1234 | Re-added headers | -- | -- | -- | 1235 | Modified headers | -- | RH3 | -- | 1236 | Untouched headers | -- | -- | -- | 1237 +-------------------+-----------------+-------+----------+ 1239 Non Storing: Summary of the use of headers from root to RPL-aware- 1240 leaf 1242 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1244 In this case the flow comprises: 1246 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1248 For example, a communication flow could be: Node A (root) --> Node B 1249 --> Node E --> Node G 1251 6LR_i are the intermediate routers from source to destination. In 1252 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1253 packet go through from source (6LBR) to destination (IPv6). 1255 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1256 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1257 but left there. If RPI is left present, the IPv6 node which does not 1258 understand it will ignore it (following 2460bis), thus encapsulation 1259 is not necesary. Due the complete knowledge of the topology at the 1260 root, the 6LBR may optionally address the IP-in-IP header to the last 1261 6LR, such that it is removed prior to the IPv6 node. 1263 +---------------+-------------+---------------+--------------+------+ 1264 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1265 +---------------+-------------+---------------+--------------+------+ 1266 | Inserted | (opt: RPI), | -- | -- | -- | 1267 | headers | RH3 | | | | 1268 | Removed | -- | RH3 | -- | -- | 1269 | headers | | | | | 1270 | Re-added | -- | -- | -- | -- | 1271 | headers | | | | | 1272 | Modified | -- | (opt: RPI), | (opt: RPI), | -- | 1273 | headers | | RH3 | RH3 | | 1274 | Untouched | -- | -- | -- | RPI | 1275 | headers | | | | | 1276 +---------------+-------------+---------------+--------------+------+ 1278 Non Storing: Summary of the use of headers from root to not-RPL- 1279 aware-leaf 1281 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1283 In this case the flow comprises: 1285 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1287 For example, a communication flow could be: Node G --> Node E --> 1288 Node B --> Node A (root) 1290 6LR_i are the intermediate routers from source to destination. In 1291 this case, "1 < i >= n", n is the number of routers (6LR) that the 1292 packet go through from source (IPv6) to destination (6LBR). For 1293 example, 6LR_1 (i=1) is the router that receives the packets from the 1294 IPv6 node. 1296 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1297 encapsulated in an IP-in-IP header, and is modified in the following 1298 6LRs. The RPI and entire packet is consumed by the root. 1300 +------------+------+---------------+---------------+---------------+ 1301 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 1302 +------------+------+---------------+---------------+---------------+ 1303 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 1304 | headers | | | | | 1305 | Removed | -- | -- | -- | IP-in-IP(RPI) | 1306 | headers | | | | | 1307 | Re-added | -- | -- | -- | -- | 1308 | headers | | | | | 1309 | Modified | -- | -- | IP-in-IP(RPI) | -- | 1310 | headers | | | | | 1311 | Untouched | -- | -- | -- | -- | 1312 | headers | | | | | 1313 +------------+------+---------------+---------------+---------------+ 1315 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1316 root 1318 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1320 This section will describe the communication flow in Non Storing Mode 1321 (Non-SM) between: 1323 RPL-aware-leaf to Internet 1325 Internet to RPL-aware-leaf 1327 not-RPL-aware-leaf to Internet 1329 Internet to not-RPL-aware-leaf 1331 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1333 In this case the flow comprises: 1335 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1337 For example, a communication flow could be: Node F --> Node D --> 1338 Node B --> Node A --> Internet 1340 6LR_i are the intermediate routers from source to destination. In 1341 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1342 packet go through from source (6LN) to 6LBR. 1344 This case is identical to storing-mode case. 1346 The IPv6 flow label should be set to zero to aid in compression, and 1347 the 6LBR will set it to a non-zero value when sending towards the 1348 Internet. 1350 +-------------------+------+-------+------+----------------+ 1351 | Header | 6LN | 6LR_i | 6LBR | Internet | 1352 +-------------------+------+-------+------+----------------+ 1353 | Inserted headers | RPI | -- | -- | -- | 1354 | Removed headers | -- | -- | -- | -- | 1355 | Re-added headers | -- | -- | -- | -- | 1356 | Modified headers | -- | RPI | -- | -- | 1357 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1358 +-------------------+------+-------+------+----------------+ 1360 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1361 Internet 1363 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1365 In this case the flow comprises: 1367 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1369 For example, a communication flow could be: Internet --> Node A 1370 (root) --> Node B --> Node D --> Node F 1372 6LR_i are the intermediate routers from source to destination. In 1373 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1374 packet go through from 6LBR to destination(6LN). 1376 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1377 address of the target node, it can address the IP-in-IP header to 1378 that node. The 6LBR will zero the flow label upon entry in order to 1379 aid compression. 1381 The RPI may be added or not as required by networks such as 6tisch. 1382 The RPI is unnecessary for loop detection. 1384 +----------+---------+--------------+---------------+---------------+ 1385 | Header | Interne | 6LBR | 6LR_i | 6LN | 1386 | | t | | | | 1387 +----------+---------+--------------+---------------+---------------+ 1388 | Inserted | -- | IP-in-IP (RH | -- | -- | 1389 | headers | | 3,opt:RPI) | | | 1390 | Removed | -- | -- | -- | IP-in-IP | 1391 | headers | | | | (RH3,opt:RPI) | 1392 | Re-added | -- | -- | -- | -- | 1393 | headers | | | | | 1394 | Modified | -- | -- | IP-in-IP | -- | 1395 | headers | | | (RH3,opt:RPI) | | 1396 | Untouche | -- | -- | -- | -- | 1397 | d | | | | | 1398 | headers | | | | | 1399 +----------+---------+--------------+---------------+---------------+ 1401 Non Storing: Summary of the use of headers from Internet to RPL- 1402 aware-leaf 1404 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1406 In this case the flow comprises: 1408 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1409 Internet 1411 For example, a communication flow could be: Node G --> Node E --> 1412 Node B --> Node A --> Internet 1414 6LR_i are the intermediate routers from source to destination. In 1415 this case, "1 < i >= n", n is the number of routers (6LR) that the 1416 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1418 In this case the flow label is recommended to be zero in the IPv6 1419 node. As RPL headers are added in the IPv6 node, the first 6LR 1420 (6LR_1) will add an RPI header inside a new IP-in-IP header. The IP- 1421 in-IP header will be addressed to the root. This case is identical 1422 to the storing-mode case (see Section 6.2.3). 1424 +-----------+------+-----------+-------------+-----------+----------+ 1425 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | 1426 | | | | [i=2,..,n]_ | | | 1427 +-----------+------+-----------+-------------+-----------+----------+ 1428 | Inserted | -- | IP-in-IP | -- | -- | -- | 1429 | headers | | (RPI) | | | | 1430 | Removed | -- | -- | -- | IP-in-IP | -- | 1431 | headers | | | | (RPI) | | 1432 | Re-added | -- | -- | -- | -- | -- | 1433 | headers | | | | | | 1434 | Modified | -- | -- | IP-in-IP | -- | -- | 1435 | headers | | | (RPI) | | | 1436 | Untouched | -- | -- | -- | -- | -- | 1437 | headers | | | | | | 1438 +-----------+------+-----------+-------------+-----------+----------+ 1440 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1441 Internet 1443 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1445 In this case the flow comprises: 1447 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1449 For example, a communication flow could be: Internet --> Node A 1450 (root) --> Node B --> Node E --> Node G 1452 6LR_i are the intermediate routers from source to destination. In 1453 this case, "1 < i >= n", n is the number of routers (6LR) that the 1454 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1456 The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR 1457 will know the path, and will recognize that the final node is not an 1458 RPL capable node as it will have received the connectivity DAO from 1459 the nearest 6LR. The 6LBR can therefore make the IP-in-IP header 1460 destination be the last 6LR. The 6LBR will set to zero the flow 1461 label upon entry in order to aid compression. 1463 +----------+---------+---------+-----------+-----------------+------+ 1464 | Header | Interne | 6LBR | 6LR_1 | 6LR_i(i=2,..,n) | IPv6 | 1465 | | t | | | | | 1466 +----------+---------+---------+-----------+-----------------+------+ 1467 | Inserted | -- | IP-in- | -- | -- | -- | 1468 | headers | | IP | | | | 1469 | | | (RH3, o | | | | 1470 | | | pt:RPI) | | | | 1471 | Removed | -- | -- | -- | IP-in-IP | -- | 1472 | headers | | | | (RH3,RPI) | | 1473 | Re-added | -- | -- | -- | -- | -- | 1474 | headers | | | | | | 1475 | Modified | -- | -- | IP-in-IP | IP-in-IP | -- | 1476 | headers | | | (RH3,RPI) | (RH3,RPI) | | 1477 | Untouche | -- | -- | -- | -- | RPI | 1478 | d | | | | | | 1479 | headers | | | | | | 1480 +----------+---------+---------+-----------+-----------------+------+ 1482 NonStoring: Summary of the use of headers from Internet to non-RPL- 1483 aware-leaf 1485 7.3. Non-Storing Mode: Interaction between Leafs 1487 In this section we are going to describe the communication flow in 1488 Non Storing Mode (Non-SM) between, 1490 RPL-aware-leaf to RPL-aware-leaf 1492 RPL-aware-leaf to not-RPL-aware-leaf 1494 not-RPL-aware-leaf to RPL-aware-leaf 1496 not-RPL-aware-leaf to not-RPL-aware-leaf 1498 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1500 In this case the flow comprises: 1502 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1504 For example, a communication flow could be: Node F --> Node D --> 1505 Node B --> Node A (root) --> Node B --> Node E --> Node H 1507 6LR_ia are the intermediate routers from source to the root In this 1508 case, "1 <= ia >= n", n is the number of routers (6LR) that the 1509 packet go through from 6LN to the root. 1511 6LR_id are the intermediate routers from the root to the destination. 1512 In this case, "1 <= ia >= m", m is the number of the intermediate 1513 routers (6LR). 1515 This case involves only nodes in same RPL Domain. The originating 1516 node will add an RPI header to the original packet, and send the 1517 packet upwards. 1519 The originating node SHOULD put the RPI into an IP-in-IP header 1520 addressed to the root, so that the 6LBR can remove that header. If 1521 it does not, then additional resources are wasted on the way down to 1522 carry the useless RPI option. 1524 The 6LBR will need to insert an RH3 header, which requires that it 1525 add an IP-in-IP header. It SHOULD be able to remove the RPI, as it 1526 was contained in an IP-in-IP header addressed to it. Otherwise, 1527 there MAY be an RPI header buried inside the inner IP header, which 1528 should get ignored. 1530 Networks that use the RPL P2P extension [RFC6997] are essentially 1531 non-storing DODAGs and fall into this scenario or scenario 1532 Section 7.1.2, with the originating node acting as 6LBR. 1534 +-----------+----------+--------+-------------+--------+------------+ 1535 | Header | 6LN src | 6LR_ia | 6LBR | 6LR_id | 6LN dst | 1536 +-----------+----------+--------+-------------+--------+------------+ 1537 | Inserted | IP-in-IP | -- | IP-in-IP | -- | -- | 1538 | headers | (RPI1) | | (RH3->6LN, | | | 1539 | | | | opt RPI2) | | | 1540 | Removed | -- | -- | IP-in-IP | -- | IP-in-IP | 1541 | headers | | | (RPI1) | | (RH3, opt | 1542 | | | | | | RPI2) | 1543 | Re-added | -- | -- | -- | -- | -- | 1544 | headers | | | | | | 1545 | Modified | -- | RPI1 | -- | RPI2 | -- | 1546 | headers | | | | | | 1547 | Untouched | -- | -- | -- | -- | -- | 1548 | headers | | | | | | 1549 +-----------+----------+--------+-------------+--------+------------+ 1551 Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 1552 aware-leaf 1554 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1555 leaf 1557 In this case the flow comprises: 1559 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1561 For example, a communication flow could be: Node F --> Node D --> 1562 Node B --> Node A (root) --> Node B --> Node E --> Node G 1564 6LR_ia are the intermediate routers from source to the root In this 1565 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1567 6LR_id are the intermediate routers from the root to the destination. 1568 In this case, "1 <= ia >= m", m is the number of the intermediate 1569 routers (6LR). 1571 As in the previous case, the 6LN will insert an RPI (RPI_1) header 1572 which MUST be in an IP-in-IP header addressed to the root so that the 1573 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a 1574 new IP-in-IP header addressed to the 6LN destination node. The RPI 1575 is optional from 6LBR to 6LR_id (RPI_2). 1577 +-----------+----------+----------+------------+------------+-------+ 1578 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1579 +-----------+----------+----------+------------+------------+-------+ 1580 | Inserted | IP-in-IP | -- | IP-in-IP | -- | -- | 1581 | headers | (RPI1) | | (RH3, opt | | | 1582 | | | | RPI_2) | | | 1583 | Removed | -- | -- | IP-in-IP | IP-in-IP | -- | 1584 | headers | | | (RPI_1) | (RH3, opt | | 1585 | | | | | RPI_2) | | 1586 | Re-added | -- | -- | -- | -- | -- | 1587 | headers | | | | | | 1588 | Modified | -- | IP-in-IP | -- | IP-in-IP | -- | 1589 | headers | | (RPI_1) | | (RH3, opt | | 1590 | | | | | RPI_2) | | 1591 | Untouched | -- | -- | -- | -- | opt | 1592 | headers | | | | | RPI_2 | 1593 +-----------+----------+----------+------------+------------+-------+ 1595 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1596 not-RPL-aware-leaf 1598 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1599 leaf 1601 In this case the flow comprises: 1603 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 1604 6LN 1606 For example, a communication flow could be: Node G --> Node E --> 1607 Node B --> Node A (root) --> Node B --> Node E --> Node H 1609 6LR_ia are the intermediate routers from source to the root. In this 1610 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1612 6LR_id are the intermediate routers from the root to the destination. 1613 In this case, "1 <= ia >= m", m is the number of the intermediate 1614 routers (6LR). 1616 This scenario is mostly identical to the previous one. The RPI is 1617 added by the first 6LR (6LR_1) inside an IP-in-IP header addressed to 1618 the root. The 6LBR will remove this RPI, and add it's own IP-in-IP 1619 header containing an RH3 header and optional RPI (RPI_2). 1621 +-----------+------+----------+-----------+------------+------------+ 1622 | Header | IPv6 | 6LR_1 | 6LBR | 6LR_id | 6LN | 1623 +-----------+------+----------+-----------+------------+------------+ 1624 | Inserted | -- | IP-in-IP | IP-in-IP | -- | -- | 1625 | headers | | (RPI_1) | (RH3, opt | | | 1626 | | | | RPI_2) | | | 1627 | Removed | -- | -- | IP-in-IP | -- | IP-in-IP | 1628 | headers | | | (RPI_1) | | (RH3, opt | 1629 | | | | | | RPI_2) | 1630 | Re-added | -- | -- | -- | -- | -- | 1631 | headers | | | | | | 1632 | Modified | -- | -- | -- | IP-in-IP | -- | 1633 | headers | | | | (RH3, opt | | 1634 | | | | | RPI_2) | | 1635 | Untouched | -- | -- | -- | -- | -- | 1636 | headers | | | | | | 1637 +-----------+------+----------+-----------+------------+------------+ 1639 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1640 RPL-aware-leaf 1642 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1643 aware-leaf 1645 In this case the flow comprises: 1647 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1648 not-RPL-aware (IPv6 dst) 1650 For example, a communication flow could be: Node G --> Node E --> 1651 Node B --> Node A (root) --> Node C --> Node J 1653 6LR_ia are the intermediate routers from source to the root. In this 1654 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1656 6LR_id are the intermediate routers from the root to the destination. 1657 In this case, "1 <= ia >= m", m is the number of the intermediate 1658 routers (6LR). 1660 This scenario is the combination of the previous two cases. 1662 +------------+-------+-----------+------------+-------------+-------+ 1663 | Header | IPv6 | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1664 | | src | | | | dst | 1665 +------------+-------+-----------+------------+-------------+-------+ 1666 | Inserted | -- | IP-in-IP | IP-in-IP | -- | -- | 1667 | headers | | (RPI_1) | (RH3) | | | 1668 | Removed | -- | -- | IP-in-IP | IP-in-IP | -- | 1669 | headers | | | (RPI_1) | (RH3, opt | | 1670 | | | | | RPI_2) | | 1671 | Re-added | -- | -- | -- | -- | -- | 1672 | headers | | | | | | 1673 | Modified | -- | -- | -- | -- | -- | 1674 | headers | | | | | | 1675 | Untouched | -- | -- | -- | -- | -- | 1676 | headers | | | | | | 1677 +------------+-------+-----------+------------+-------------+-------+ 1679 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1680 not-RPL-aware-leaf 1682 8. Observations about the cases 1684 8.1. Storing mode 1686 [RFC8138] shows that the hop-by-hop IP-in-IP header can be compressed 1687 using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header as described in 1688 Section 7 of the document. 1690 There are potential significant advantages to having a single code 1691 path that always processes IP-in-IP headers with no options. 1693 Thanks to the change of the RPI option type from 0x63 to 0x23, there 1694 is no longer any uncertainty about when to use an IP-in-IP header in 1695 the storing mode. A Hop-by-Hop Options Header containing the RPI 1696 option SHOULD always be added when 6LRs originate packets (without 1697 IP-in-IP headers), and IP-in-IP headers should always be added 1698 (addressed to the root when on the way up, to the end-host when on 1699 the way down) when a 6LR find that it needs to insert a Hop-by-Hop 1700 Options Header containing the RPI option. 1702 8.2. Non-Storing mode 1704 In the non-storing case, dealing with non-RPL aware leaf nodes is 1705 much easier as the 6LBR (DODAG root) has complete knowledge about the 1706 connectivity of all DODAG nodes, and all traffic flows through the 1707 root node. 1709 The 6LBR can recognize non-RPL aware leaf nodes because it will 1710 receive a DAO about that node from the 6LN immediately above that 1711 node. This means that the non-storing mode case can avoid ever using 1712 hop-by-hop IP-in-IP headers for traffic originating from the root to 1713 leafs. 1715 The non-storing mode case does not require the type change from 0x63 1716 to 0x23, as the root can always create the right packet. The type 1717 change does not adversely affect the non-storing case. 1719 9. 6LoRH Compression cases 1721 The [RFC8138] proposes a compression method for RPI, RH3 and IPv6-in- 1722 IPv6. 1724 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 1725 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 1726 an IP-in-IP and RPI compression headers. The type of this case is 1727 critical since IP-in-IP is encapsulating a RPI header. 1729 +--+-----+---+--------------+-----------+-------------+-------------+ 1730 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | 1731 +--+-----+---+--------------+-----------+-------------+-------------+ 1733 Figure 9: Critical IP-in-IP (RPI). 1735 10. IANA Considerations 1737 This document updates the registration made in [RFC6553] Destination 1738 Options and Hop-by-Hop Options registry from 0x63 to 0x23. 1740 Hex Value Binary Value 1741 act chg rest Description Reference 1742 --------- --- --- ------- ----------------- ---------- 1743 0x23 00 1 00011 RPL Option [RFCXXXX] 1744 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 1746 Figure 10: Option Type in RPL Option. 1748 The DODAG Configuration Option Flags in the DODAG Configuration 1749 option is updated as follows: 1751 +------------+-----------------+---------------+ 1752 | Bit number | Description | Reference | 1753 +------------+-----------------+---------------+ 1754 | 3 | RPI 0x23 enable | This document | 1755 +------------+-----------------+---------------+ 1757 Figure 11: DODAG Configuration Option Flag to indicate the RPI-flag- 1758 day. 1760 11. Security Considerations 1762 The security considerations covering of [RFC6553] and [RFC6554] apply 1763 when the packets get into RPL Domain. 1765 The IPIP mechanism described in this document is much more limited 1766 than the general mechanism described in [RFC2473]. The willingness 1767 of each node in the LLN to decapsulate packets and forward them could 1768 be exploited by nodes to disguise the origin of an attack. 1770 Nodes outside of the LLN will need to pass IPIP traffic through the 1771 RPL root to perform this attack. To counter, the RPL root SHOULD 1772 either restrict ingress of IPIP packets (the simpler solution), or it 1773 SHOULD do a deep packet inspection wherein it walks the IP header 1774 extension chain until it can inspect the upper-layer-payload as 1775 described in [RFC7045]. In particular, the RPL root SHOULD do BCP38 1776 ([RFC2827]) processing on the source addresses of all IP headers that 1777 it examines in both directions. 1779 Note: there are some situations where a prefix will spread across 1780 multiple LLNs via mechanisms such as described in 1781 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 1782 needs to take this into account. 1784 Nodes with the LLN can use the IPIP mechanism to mount an attack on 1785 another part of the LLN, while disguising the origin of the attack. 1786 The mechanism can even be abused to make it appear that the attack is 1787 coming from outside the LLN, and unless countered, this could be used 1788 to mount a Distributed Denial Of Service attack upon nodes elsewhere 1789 in the Internet. See [DDOS-KREBS] for an example of such attacks 1790 already seen in the real world. 1792 While a typical LLN may be a very poor origin for attack traffic (as 1793 the networks tend to be very slow, and the nodes often have very low 1794 duty cycles) given enough nodes, they could still have a significant 1795 impact, particularly if the attack was on another LLN! Additionally, 1796 some uses of RPL involve large backbone ISP scale equipment 1797 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1798 multiple 100Gb/s interfaces. 1800 Blocking or careful filtering of IPIP traffic entering the LLN as 1801 described above will make sure that any attack that is mounted must 1802 originate compromised nodes within the LLN. The use of BCP38 1803 filtering at the RPL root on egress traffic will both alert the 1804 operator to the existence of the attack, as well as drop the attack 1805 traffic. As the RPL network is typically numbered from a single 1806 prefix, which is itself assigned by RPL, BCP38 filtering involves a 1807 single prefix comparison and should be trivial to automatically 1808 configure. 1810 There are some scenarios where IPIP traffic SHOULD be allowed to pass 1811 through the RPL root, such as the IPIP mediated communications 1812 between a new Pledge and the Join Registrar/Coordinator (JRC) when 1813 using [I-D.ietf-anima-bootstrapping-keyinfra] and 1814 [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the 1815 RPL root to do careful filtering: it occurs only when the Join 1816 Coordinator is not co-located inside the RPL root. 1818 With the above precautions, an attack using IPIP tunnels will be by a 1819 node within the LLN on another node within the LLN. Such an attack 1820 could, of course, be done directly. An attack of this kind is 1821 meaningful only if the source addresses are either fake or if the 1822 point is to amplify return traffic. Such an attack, could also be 1823 done without the use of IPIP headers using forged source addresses. 1824 If the attack requires bi-directional communication, then IPIP 1825 provides no advantages. 1827 [RFC2473] suggests that tunnel entry and exit points can be secured, 1828 via the "Use IPsec". This solution has all the problems that 1829 [RFC5406] goes into. In an LLN such a solution would degenerate into 1830 every node having a tunnel with every other node. It would provide a 1831 small amount of origin address authentication at a very high cost; 1832 doing BCP38 at every node (linking layer-3 addresses to layer-2 1833 addresses, and to already present layer-2 cryptographic mechanisms) 1834 would be cheaper should RPL be run in an environment where hostile 1835 nodes are likely to be a part of the LLN. 1837 The RH3 header usage described here can be abused in equivalent ways 1838 with an IPIP header to add the needed RH3 header. As such, the 1839 attacker's RH3 header will not be seen by the network until it 1840 reaches the end host, which will decapsulate it. An end-host SHOULD 1841 be suspicious about a RH3 header which has additional hops which have 1842 not yet been processed, and SHOULD ignore such a second RH3 header. 1844 In addition, the LLN will likely use [RFC8138] to compress the IPIP 1845 and RH3 headers. As such, the compressor at the RPL-root will see 1846 the second RH3 header and MAY choose to discard the packet if the RH3 1847 header has not been completely consumed. A consumed (inert) RH3 1848 header could be present in a packet that flows from one LLN, crosses 1849 the Internet, and enters another LLN. As per the discussion in this 1850 document, such headers do not need to be removed. However, there is 1851 no case described in this document where an RH3 is inserted in a non- 1852 storing network on traffic that is leaving the LLN, but this document 1853 SHOULD NOT preclude such a future innovation. It should just be 1854 noted that an incoming RH3 must be fully consumed, or very carefully 1855 inspected. 1857 The RPI header, if permitted to enter the LLN, could be used by an 1858 attacker to change the priority of a packet by selecting a different 1859 RPL instanceID, perhaps one with a higher energy cost, for instance. 1860 It could also be that not all nodes are reachable in an LLN using the 1861 default instanceID, but a change of instanceID would permit an 1862 attacker to bypass such filtering. Like the RH3, an RPI header is to 1863 be inserted by the RPL root on traffic entering the LLN by first 1864 inserting an IPIP header. The attacker's RPI header therefore will 1865 not be seen by the network. Upon reaching the destination node the 1866 RPI header has no further meaning and is just skipped; the presence 1867 of a second RPI header will have no meaning to the end node as the 1868 packet has already been identified as being at it's final 1869 destination. 1871 The RH3 and RPI headers could be abused by an attacker inside of the 1872 network to route packets on non-obvious ways, perhaps eluding 1873 observation. This usage is in fact part of [RFC6997] and can not be 1874 restricted at all. This is a feature, not a bug. 1876 [RFC7416] deals with many other threats to LLNs not directly related 1877 to the use of IPIP headers, and this document does not change that 1878 analysis. 1880 12. Acknowledgments 1882 This work is partially funded by the FP7 Marie Curie Initial Training 1883 Network (ITN) METRICS project (grant agreement No. 607728). 1885 The authors would like to acknowledge the review, feedback, and 1886 comments of (alphabetical order): Robert Cragie, Simon Duquennoy, 1887 Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias 1888 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 1890 13. References 1892 13.1. Normative References 1894 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1895 Requirement Levels", BCP 14, RFC 2119, 1896 DOI 10.17487/RFC2119, March 1997, 1897 . 1899 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1900 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1901 December 1998, . 1903 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1904 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1905 December 1998, . 1907 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1908 Defeating Denial of Service Attacks which employ IP Source 1909 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1910 May 2000, . 1912 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1913 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1914 February 2009, . 1916 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1917 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1918 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1919 Low-Power and Lossy Networks", RFC 6550, 1920 DOI 10.17487/RFC6550, March 2012, 1921 . 1923 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1924 Power and Lossy Networks (RPL) Option for Carrying RPL 1925 Information in Data-Plane Datagrams", RFC 6553, 1926 DOI 10.17487/RFC6553, March 2012, 1927 . 1929 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1930 Routing Header for Source Routes with the Routing Protocol 1931 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1932 DOI 10.17487/RFC6554, March 2012, 1933 . 1935 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1936 of IPv6 Extension Headers", RFC 7045, 1937 DOI 10.17487/RFC7045, December 2013, 1938 . 1940 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1941 and M. Richardson, Ed., "A Security Threat Analysis for 1942 the Routing Protocol for Low-Power and Lossy Networks 1943 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1944 . 1946 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 1947 "IPv6 over Low-Power Wireless Personal Area Network 1948 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 1949 April 2017, . 1951 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1952 (IPv6) Specification", STD 86, RFC 8200, 1953 DOI 10.17487/RFC8200, July 2017, 1954 . 1956 13.2. Informative References 1958 [DDOS-KREBS] 1959 Goodin, D., "Record-breaking DDoS reportedly delivered by 1960 >145k hacked cameras", September 2016, 1961 . 1964 [I-D.ietf-6lo-backbone-router] 1965 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 1966 backbone-router-05 (work in progress), January 2018. 1968 [I-D.ietf-6man-rfc6434-bis] 1969 Chown, T., Loughney, J., and T. Winters, "IPv6 Node 1970 Requirements", draft-ietf-6man-rfc6434-bis-02 (work in 1971 progress), October 2017. 1973 [I-D.ietf-6tisch-architecture] 1974 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1975 of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work 1976 in progress), November 2017. 1978 [I-D.ietf-6tisch-dtsecurity-secure-join] 1979 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 1980 6tisch-dtsecurity-secure-join-01 (work in progress), 1981 February 2017. 1983 [I-D.ietf-anima-autonomic-control-plane] 1984 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1985 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1986 plane-13 (work in progress), December 2017. 1988 [I-D.ietf-anima-bootstrapping-keyinfra] 1989 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1990 S., and K. Watsen, "Bootstrapping Remote Secure Key 1991 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1992 keyinfra-09 (work in progress), October 2017. 1994 [I-D.ietf-roll-dao-projection] 1995 Thubert, P. and J. Pylakutty, "Root initiated routing 1996 state in RPL", draft-ietf-roll-dao-projection-02 (work in 1997 progress), September 2017. 1999 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2000 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2001 DOI 10.17487/RFC4192, September 2005, 2002 . 2004 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2005 Control Message Protocol (ICMPv6) for the Internet 2006 Protocol Version 6 (IPv6) Specification", STD 89, 2007 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2008 . 2010 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2011 Bormann, "Neighbor Discovery Optimization for IPv6 over 2012 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2013 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2014 . 2016 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2017 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2018 in Low-Power and Lossy Networks", RFC 6997, 2019 DOI 10.17487/RFC6997, August 2013, 2020 . 2022 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2023 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2024 2014, . 2026 [Second6TischPlugtest] 2027 "2nd 6Tisch Plugtest", . 2030 Authors' Addresses 2032 Maria Ines Robles 2033 Ericsson 2034 Hirsalantie 11 2035 Jorvas 02420 2036 Finland 2038 Email: maria.ines.robles@ericsson.com 2040 Michael C. Richardson 2041 Sandelman Software Works 2042 470 Dawson Avenue 2043 Ottawa, ON K1Z 5V7 2044 CA 2046 Email: mcr+ietf@sandelman.ca 2047 URI: http://www.sandelman.ca/mcr/ 2049 Pascal Thubert 2050 Cisco Systems, Inc 2051 Village d'Entreprises Green Side 400, Avenue de Roumanille 2052 Batiment T3, Biot - Sophia Antipolis 06410 2053 France 2055 Email: pthubert@cisco.com