idnits 2.17.00 (12 Aug 2021) /tmp/idnits23891/draft-ietf-roll-useofrplinfo-15.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 27 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC6550, 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 -- The document date (June 29, 2017) is 1787 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) == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 1956, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-rfc2460bis has been published as RFC 8200 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc2460bis' ** 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-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-01 == Outdated reference: draft-ietf-roll-routing-dispatch has been published as RFC 8138 Summary: 3 errors (**), 0 flaws (~~), 9 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 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: December 31, 2017 P. Thubert 7 Cisco 8 June 29, 2017 10 When to use RFC 6553, 6554 and IPv6-in-IPv6 11 draft-ietf-roll-useofrplinfo-15 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. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 31, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology and Requirements Language . . . . . . . . . . . . 4 58 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4 59 3. Updates to RFC6553 and RFC 6550 . . . . . . . . . . . . . . . 5 60 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 61 3.2. Updates to RFC 6550 . . . . . . . . . . . . . . . . . . . 6 62 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 6 63 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 11 65 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 12 66 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 13 67 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 14 68 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 14 69 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 15 70 6.2. Storing Mode: Interaction between Leaf and Internet . . . 16 71 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 16 72 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 17 73 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 74 Internet . . . . . . . . . . . . . . . . . . . . . . 18 75 6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 76 leaf . . . . . . . . . . . . . . . . . . . . . . . . 19 77 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 20 78 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 79 leaf . . . . . . . . . . . . . . . . . . . . . . . . 20 80 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 81 aware-leaf . . . . . . . . . . . . . . . . . . . . . 21 82 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 83 aware-leaf . . . . . . . . . . . . . . . . . . . . . 22 84 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 85 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 23 86 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 25 87 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 26 88 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 27 89 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 27 90 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 91 leaf . . . . . . . . . . . . . . . . . . . . . . . . 28 92 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 93 root . . . . . . . . . . . . . . . . . . . . . . . . 29 94 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 30 95 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 96 Internet . . . . . . . . . . . . . . . . . . . . . . 30 98 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 99 leaf . . . . . . . . . . . . . . . . . . . . . . . . 31 100 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 101 Internet . . . . . . . . . . . . . . . . . . . . . . 32 102 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 103 aware-leaf . . . . . . . . . . . . . . . . . . . . . 33 104 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 34 105 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 106 aware-leaf . . . . . . . . . . . . . . . . . . . . . 34 107 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 108 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 36 109 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 110 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37 111 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 112 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 38 113 8. Observations about the cases . . . . . . . . . . . . . . . . 39 114 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 39 115 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 40 116 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 40 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 118 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 119 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 121 13.1. Normative References . . . . . . . . . . . . . . . . . . 43 122 13.2. Informative References . . . . . . . . . . . . . . . . . 44 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 125 1. Introduction 127 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 128 [RFC6550] is a routing protocol for constrained networks. RFC 6553 129 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 130 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 131 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 132 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 133 RPL routing domain, particularly in non-storing mode. 135 These various items are referred to as RPL artifacts, and they are 136 seen on all of the data-plane traffic that occurs in RPL routed 137 networks; they do not in general appear on the RPL control plane 138 traffic at all which is mostly hop-by-hop traffic (one exception 139 being DAO messages in non-storing mode). 141 It has become clear from attempts to do multi-vendor 142 interoperability, and from a desire to compress as many of the above 143 artifacts as possible that not all implementors agree when artifacts 144 are necessary, or when they can be safely omitted, or removed. 146 An interim meeting went through the 24 cases defined here to discover 147 if there were any shortcuts, and this document is the result of that 148 discussion. This document clarify what is correct and incorrect 149 behaviour. 151 The related document A Routing Header Dispatch for 6LoWPAN (6LoRH) 152 [I-D.ietf-roll-routing-dispatch] defines a method to compress RPL 153 Option information and Routing Header type 3 [RFC6554], an efficient 154 IP-in-IP technique, and use cases proposed for the 155 [Second6TischPlugtest] involving 6loRH. 157 2. Terminology and Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 164 RPL, RPL Domain and ROLL. 166 RPL-node: It is device which implements RPL, thus we can say that the 167 device is RPL-capable or RPL-aware. Please note that the device can 168 be found inside the LLN or outside LLN. In this document a RPL-node 169 which is a leaf of a DODAG is called RPL-aware-leaf. 171 RPL-not-capable: It is device which do not implement RPL, thus we can 172 say that the device is not-RPL-aware. Please note that the device 173 can be found inside the LLN. In this document a not-RPL-aware node 174 which is a leaf of a DODAG is called not-RPL-aware-leaf. 176 pledge: a new device which seeks admission to a network. (from 177 [I-D.ietf-anima-bootstrapping-keyinfra]) 179 Join Registrar and Coordinator (JRC): a device which brings new nodes 180 (pledges) into a network. (from 181 [I-D.ietf-anima-bootstrapping-keyinfra]) 183 Flag day: A "flag day" is a procedure in which the network, or a part 184 of it, is changed during a planned outage, or suddenly, causing an 185 outage while the network recovers [RFC4192] 187 2.1. hop-by-hop IPv6-in-IPv6 headers 189 The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header 190 that originates from a node to an adjacent node, using the addresses 191 (usually the GUA or ULA, but could use the link-local addresses) of 192 each node. If the packet must traverse multiple hops, then it must 193 be decapsulated at each hop, and then re-encapsulated again in a 194 similar fashion. 196 3. Updates to RFC6553 and RFC 6550 198 3.1. Updates to RFC 6553 200 [RFC6553] states that in the Option Type field of the RPL Option 201 header, the two high order bits MUST be set to '01' and the third bit 202 is equal to '1'. The first two bits indicate that the IPv6 node MUST 203 discard the packet if it doesn't recognize the option type, and the 204 third bit indicates that the Option Data may change en route. The 205 remaining bits serve as the option type. 207 Recent changes in [I-D.ietf-6man-rfc2460bis], state: "it is now 208 expected that nodes along a packet's delivery path only examine and 209 process the Hop-by-Hop Options header if explicitly configured to do 210 so". That means that nodes that do not understand a particular Hop- 211 by-Hop Option in a received packet are unlikely to be configured to 212 process it. 214 Thus, if an IPv6 node (RPL-not-capable) receives a packet with an RPL 215 Option, it should ignore the HBH option. To further solidify the 216 desire for the RPL options to be ignored, this document updates the 217 Option Type field to: the two high order bits MUST be set to '00' and 218 the third bit is equal to '1'. 220 These two high order bits indicate that the IPv6 node MUST skip over 221 this option and continue processing the header if it doesn't 222 recognize the option type. 224 The third bit continues to be set to indicate that the Option Data 225 may change en route. The remaining bits serve as the option type and 226 remain as 0x3. This an update to [RFC6553]. 228 This change creates a flag day for existing networks which are 229 currently using 0x63 as the RPI value. A move to 0x43 will not be 230 understood by those networks. It is suggested that implementations 231 accept both 0x63 and 0x43 when processing. When forwarding packets, 232 implementations SHOULD use the same value as we received. When 233 originating new packets, implementations SHOULD have an option to 234 determine which value to originate with, this option is controlled by 235 the DAO option described below. 237 A network which is switching from straight 6lowpan compression 238 mechanism to those described in [I-D.ietf-roll-routing-dispatch] will 239 experience a flag day in the data compression anyway, and if possible 240 this change can be deployed at the same time. 242 In general, any packet that leaves the RPL domain of an LLN (or 243 leaves the LLN entirely) will NOT be discarded, when it has the 244 [RFC6553] RPL Option Header known as the RPI or [RFC6554] SRH3 245 Extension Header (S)RH3. Because of [I-D.ietf-6man-rfc2460bis] the 246 RPI Hop-by-Hop option MAY be left in place even if the end host does 247 not understand it. 249 3.2. Updates to RFC 6550 251 In order to avoid a flag day caused by lack of interoperation between 252 new RPI (0x43) and old RPI (0x63) nodes, the new nodes need to be 253 told that there are old RPI nodes present. This can be done via a 254 new DIO Option which will propogate through the network. Failure to 255 receive this flag will cause dual mode nodes to originate traffic 256 with the old-RPI (0x63) value. 258 DIO Option: 0x05 RPI 0x43 enable MCRXXX 260 Flags: 8-bit unused field reserved for flags. The field MUST be 261 initialized to zero by the sender and MUST be ignored by the 262 receiver. 264 We propose to use a bit flag as follows: 266 +----+----+----+----+----+----+----+----+ 267 | | | | | | | | | 268 | | | | | | | | FR | 269 | | | | | | | | | 270 +----+----+----+----+----+----+----+----+ 272 Figure 1: A DIO Flag to indicate the RPI-flag-day. 274 FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option 275 field is set to "00", values of 0 indicates that RPL Option field is 276 set to "01" 278 4. Sample/reference topology 280 A RPL network is composed of a 6LBR (6LoWPAN Border Router), Backbone 281 Router (6BBR), 6LR (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf 282 logically organized in a DODAG structure. (Destination Oriented 283 Directed Acyclic Graph). 285 RPL defines the RPL Control messages (control plane), a new ICMPv6 286 [RFC4443] message with Type 155. DIS (DODAG Information 287 Solicitation), DIO (DODAG Information Object) and DAO (Destination 288 Advertisement Object) messages are all RPL Control messages but with 289 different Code values. A RPL Stack is showed in Figure 1. 291 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 292 it is fully stateful or an in non-storing (RPL-NSM), it is fully 293 source routed. A RPL Instance is either fully storing or fully non- 294 storing, i.e. a RPL Instance with a combination of storing and non- 295 storing nodes is not supported with the current specifications at the 296 time of writing this document. 298 +--------------+ 299 | Upper Layers | 300 | | 301 +--------------+ 302 | RPL | 303 | | 304 +--------------+ 305 | ICMPv6 | 306 | | 307 +--------------+ 308 | IPv6 | 309 | | 310 +--------------+ 311 | 6LoWPAN | 312 | | 313 +--------------+ 314 | PHY-MAC | 315 | | 316 +--------------+ 318 Figure 2: RPL Stack. 320 +------------+ 321 | INTERNET ----------+ 322 | | | 323 +------------+ | 324 | 325 | 326 | 327 A | 328 +-------+ 329 |6LBR | 330 +-----------|(root) |-------+ 331 | +-------+ | 332 | | 333 | | 334 | | 335 | | 336 | B |C 337 +---|---+ +---|---+ 338 | 6LR | | 6LR | 339 +-------->| |--+ +--- ---+ 340 | +-------+ | | +-------+ | 341 | | | | 342 | | | | 343 | | | | 344 | | | | 345 | D | E | | 346 +-|-----+ +---|---+ | | 347 | 6LR | | 6LR | | | 348 | | +------ | | | 349 +---|---+ | +---|---+ | | 350 | | | | | 351 | | +--+ | | 352 | | | | | 353 | | | | | 354 | | | I | J | 355 F | | G | H | | 356 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 357 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 358 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 359 +-------+ +-------+ +------+ +-------+ +-------+ 361 Figure 3: A reference RPL Topology. 363 Figure 2 shows the reference RPL Topology for this document. The 364 letters above the nodes are there so that they may be referenced in 365 subsequent sections. In the figure, a 6LR is a router. A 6LN can be 366 a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked 367 as (F and I) are RPL hosts that does not have forwarding capability. 368 The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL 369 aware leaf" (G and J) are devices which do not speak RPL at all (not- 370 RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and 371 efficient-ND only to participate in the network [RFC6775]. In the 372 document these leafs (G and J) are often named IPv6 node. The 6LBR 373 in the figure is the root of the Global DODAG. 375 5. Use cases 377 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 378 encapsulation is going to be analyzed for a number of representative 379 traffic flows. 381 While this document assumes the HbH changes in 382 [I-D.ietf-6man-rfc2460bis] proceed, and/or that the LLN is using the 383 no-drop RPI option (0x43). 385 The uses cases describe the communication between RPL-aware-nodes, 386 with the root (6LBR), and with Internet. This document also describe 387 the communication between nodes acting as leaf that does not 388 understand RPL and they are part of hte LLN. We name these nodes as 389 not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to 390 root) We describe also how is the communication inside of the LLN 391 when it has the final destination addressed outside of the LLN e.g. 392 with destination to Internet. (e.g. section 5.7- Flow from not-RPL- 393 aware-leaf to Internet) 395 The uses cases comprise as follow: 397 Interaction between Leaf and Root: 399 RPL-aware-leaf to root 401 root to RPL-aware-leaf 403 not-RPL-aware-leaf to root 405 root to not-RPL-aware-leaf 407 Interaction between Leaf and Internet: 409 RPL-aware-leaf to Internet 411 Internet to RPL-aware-leaf 413 not-RPL-aware-leaf to Internet 414 Internet to not-RPL-aware-leaf 416 Interaction between Leafs: 418 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 420 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 422 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 424 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 426 This document assumes the rule that a Header cannot be inserted or 427 removed on the fly inside an IPv6 packet that is being routed. This 428 is a fundamental precept of the IPv6 architecture as outlined in 429 [RFC2460]. Extensions may not be added or removed except by the 430 sender or the receiver. 432 But, options in the Hop-by-Hop option which are marked with option 433 type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD 434 be ignored when received by a host or router which does not 435 understand that option. 437 This means that in general, any packet that leaves the RPL domain of 438 an LLN (or leaves the LLN entirely) will NOT be discarded, when it 439 has the [RFC6553] RPL Option Header known as the RPI or [RFC6554] 440 SRH3 Extension Header (S)RH3. 442 The recent change to the second of these rules means that the RPI 443 Hop-by-Hop option MAY be left in place even if the end host does not 444 understand it. 446 NOTE: There is some possible security risk when the RPI information 447 is released to the Internet. At this point this is a theoretical 448 situation. It is clear that the RPI option would waste some network 449 bandwidth when it escapes. 451 An intermediate router that needs to add an extension header (SHR3 or 452 RPI Option) must encapsulate the packet in an (additional) outer IP 453 header. The new header can be placed is placed after this new outer 454 IP header. 456 A corollory is that an SHR3 or RPI Option can only be removed by an 457 intermediate router if it is placed in an encapsulating IPv6 Header, 458 which is addressed to the intermediate router. When it does so, the 459 whole encapsulating header must be removed. (A replacement may be 460 added). This sometimes can result in outer IP headers being 461 addressed to the next hop router using link-local addresses. 463 Both RPI and RH3 headers may be modified in very specific ways by 464 routers on the path of the packet without the need to add to remove 465 an encapsulating header. Both headers were designed with this 466 modification in mind, and both the RPL RH and the RPL option are 467 marked mutable but recoverable: so an IPsec AH security header can be 468 applied across these headers, but it can not secure the values which 469 mutate. 471 RPI should be present in every single RPL data packet. There is one 472 exception in non-storing mode: when a packet is going down from the 473 root. In a downward non-storing mode, the entire route is written, 474 so there can be no loops by construction, nor any confusion about 475 which forwarding table to use (as the root has already made all 476 routing decisions). There still may be cases (such as in 6tisch) 477 where the instanceID portion of the RPI header may still be needed to 478 pick an appropriate priority or channel at each hop. 480 In the tables present in this document, the term "RPL aware leaf" is 481 has been shortened to "Raf", and "not-RPL aware leaf" has been 482 shortened to "~Raf" to make the table fit in available space. 484 The earlier examples are more extensive to make sure that the process 485 is clear, while later examples are more concise. 487 6. Storing mode 489 In storing mode (fully stateful), the sender cannot determine whether 490 the destination is RPL-capable and thus would need an IP-in-IP 491 header. The IP-in-IP header needs to be addressed on a hop-by-hop 492 basis so that the last 6LR can remove the RPI header. Additionally, 493 The sender can determine if the destination is inside the LLN by 494 looking if the destination address is matched by the DIO's PIO 495 option. 497 The following table summarizes what headers are needed in the 498 following scenarios, and indicates when the IP-in-IP header must be 499 inserted on a hop-by-hop basis, and when it can target the 500 destination node directly. There are these possible situations: hop- 501 by-hop necessary (indicated by "hop"), or destination address 502 possible (indicated by "dst"). In all cases hop by hop can be used. 503 In cases where no IP-in-IP header is needed, the column is left 504 blank. 506 In all cases the RPI headers are needed, since it identifies 507 inconsistencies (loops) in the routing topology. In all cases the 508 RH3 is not need because we do not indicate the route in storing mode. 510 The leaf can be a router 6LR or a host, both indicated as 6LN 511 (Figure 2). 513 +---------------------+--------------+----------+--------------+ 514 | Interaction between | Use Case | IP-in-IP | IP-in-IP dst | 515 +---------------------+--------------+----------+--------------+ 516 | | Raf to root | No | -- | 517 + +--------------+----------+--------------+ 518 | Leaf - Root | root to Raf | No | -- | 519 + +--------------+----------+--------------+ 520 | | root to ~Raf | No | -- | 521 + +--------------+----------+--------------+ 522 | | ~Raf to root | Yes | root | 523 +---------------------+--------------+----------+--------------+ 524 | | Raf to Int | No | -- | 525 + +--------------+----------+--------------+ 526 | Leaf - Internet | Int to Raf | Yes | Raf | 527 + +--------------+----------+--------------+ 528 | | ~Raf to Int | Yes | root | 529 + +--------------+----------+--------------+ 530 | | Int to ~Raf | Yes | hop | 531 +---------------------+--------------+----------+--------------+ 532 | | Raf to Raf | No | -- | 533 + +--------------+----------+--------------+ 534 | | Raf to ~Raf | No | -- | 535 + Leaf - Leaf +--------------+----------+--------------+ 536 | | ~Raf to Raf | Yes | dst | 537 + +--------------+----------+--------------+ 538 | | ~Raf to ~Raf | Yes | hop | 539 +---------------------+--------------+----------+--------------+ 541 Figure 4: IP-in-IP encapsulation in Storing mode. 543 6.1. Storing Mode: Interaction between Leaf and Root 545 In this section we are going to describe the communication flow in 546 storing mode (SM) between, 548 RPL-aware-leaf to root 550 root to RPL-aware-leaf 552 not-RPL-aware-leaf to root 554 root to not-RPL-aware-leaf 556 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 558 In storing mode, RFC 6553 (RPI) is used to send RPL Information 559 instanceID and rank information. 561 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does 562 not generally issue DIO messages; a leaf node accepts DIO messages 563 from upstream. (When the inconsistency in routing occurs, a leaf 564 node will generate a DIO with an infinite rank, to fix it). It may 565 issue DAO and DIS messages though it generally ignores DAO and DIS 566 messages. 568 In this case the flow comprises: 570 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 572 For example, the communication flow would be: Node F --> Node E --> 573 Node B --> Node A root(6LBR) 575 6LR_i (Node E and Node B) are the intermediate routers from source to 576 destination. In this case, "1 <= i >= n", n is the number of routers 577 (6LR) that the packet go through from source (6LN) to destination 578 (6LBR). 580 As it was mentioned In this document 6LRs, 6LBR are always full- 581 fledge RPL routers. 583 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 584 (Node E) which decrements the rank in RPI and sends the packet up. 585 When the packet arrives at 6LBR (Node A), the RPI is removed and the 586 packet is processed. 588 No IP-in-IP header is required. 590 The RPI header can be removed by the 6LBR because the packet is 591 addressed to the 6LBR. The 6LN must know that it is communicating 592 with the 6LBR to make use of this scenario. The 6LN can know the 593 address of the 6LBR because it knows the address of the root via the 594 DODAGID in the DIO messages. 596 +-------------------+-----+-------+------+ 597 | Header | 6LN | 6LR_i | 6LBR | 598 +-------------------+-----+-------+------+ 599 | Inserted headers | RPI | -- | -- | 600 | Removed headers | -- | -- | RPI | 601 | Re-added headers | -- | -- | -- | 602 | Modified headers | -- | RPI | -- | 603 | Untouched headers | -- | -- | -- | 604 +-------------------+-----+-------+------+ 606 Storing: Summary of the use of headers from RPL-aware-leaf to root 608 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 610 In this case the flow comprises: 612 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 614 For example, the communication flow would be: Node A root(6LBR) --> 615 Node B --> Node D --> Node F 617 6LR_i are the intermediate routers from source to destination. In 618 this case, "1 <= i >= n", n is the number of routers (6LR) that the 619 packet go through from source (6LBR) to destination (6LN). 621 In this case the 6LBR inserts RPI header and sends the packet down, 622 the 6LR is going to increment the rank in RPI (examines instanceID 623 for multiple tables), the packet is processed in 6LN and RPI removed. 625 No IP-in-IP header is required. 627 +-------------------+------+-------+------+ 628 | Header | 6LBR | 6LR_i | 6LN | 629 +-------------------+------+-------+------+ 630 | Inserted headers | RPI | -- | -- | 631 | Removed headers | -- | -- | RPI | 632 | Re-added headers | -- | -- | -- | 633 | Modified headers | -- | RPI | -- | 634 | Untouched headers | -- | -- | -- | 635 +-------------------+------+-------+------+ 637 Storing: Summary of the use of headers from root to RPL-aware-leaf 639 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 641 In this case the flow comprises: 643 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 644 For example, the communication flow would be: Node A root(6LBR) --> 645 Node B --> Node E --> Node G 647 6LR_i are the intermediate routers from source to destination. In 648 this case, "1 <= i >= n", n is the number of routers (6LR) that the 649 packet go through from source (6LBR) to destination (IPv6). 651 As the RPI extension can be ignored by the not-RPL-aware leaf, this 652 situation is identical to the previous scenario. 654 +-------------------+------+-------+----------------+ 655 | Header | 6LBR | 6LR_i | IPv6 | 656 +-------------------+------+-------+----------------+ 657 | Inserted headers | RPI | -- | -- | 658 | Removed headers | -- | -- | -- | 659 | Re-added headers | -- | -- | -- | 660 | Modified headers | -- | RPI | -- | 661 | Untouched headers | -- | -- | RPI (Ignored) | 662 +-------------------+------+-------+----------------+ 664 Storing: Summary of the use of headers from root to not-RPL-aware- 665 leaf 667 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 669 In this case the flow comprises: 671 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 673 For example, the communication flow would be: Node G --> Node E --> 674 Node B --> Node A root(6LBR) 676 6LR_i are the intermediate routers from source to destination. In 677 this case, "1 < i >= n", n is the number of routers (6LR) that the 678 packet go through from source (IPv6) to destination (6LBR). For 679 example, 6LR_1 (i=1) is the router that receives the packets from the 680 IPv6 node (Node G). 682 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 683 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 684 header. The IPv6-in-IPv6 header can be addressed to the next hop 685 (Node B), or to the root (Node A). The root removes the header and 686 processes the packet. 688 +------------+------+---------------+---------------+---------------+ 689 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 690 +------------+------+---------------+---------------+---------------+ 691 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 692 | headers | | | | | 693 | Removed | -- | -- | -- | IP-in-IP(RPI) | 694 | headers | | | | | 695 | Re-added | -- | -- | -- | -- | 696 | headers | | | | | 697 | Modified | -- | -- | IP-in-IP(RPI) | -- | 698 | headers | | | | | 699 | Untouched | -- | -- | -- | -- | 700 | headers | | | | | 701 +------------+------+---------------+---------------+---------------+ 703 Storing: Summary of the use of headers from not-RPL-aware-leaf to 704 root 706 6.2. Storing Mode: Interaction between Leaf and Internet 708 In this section we are going to describe the communication flow in 709 storing mode (SM) between, 711 RPL-aware-leaf to Internet 713 Internet to RPL-aware-leaf 715 not-RPL-aware-leaf to Internet 717 Internet to not-RPL-aware-leaf 719 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 721 RPL information from RFC 6553 MAY go out to Internet as it will be 722 ignored by nodes which have not been configured to be RPI aware. 724 In this case the flow comprises: 726 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 728 For example, the communication flow could be: Node F --> Node D --> 729 Node B --> Node A root(6LBR) --> Internet 731 6LR_i are the intermediate routers from source to destination. In 732 this case, "1 <= i >= n", n is the number of routers (6LR) that the 733 packet go through from source (6LN) to 6LBR. 735 No IP-in-IP header is required. 737 Note: In this use case we use a node as leaf, but this use case can 738 be also applicable to any RPL-node type (e.g. 6LR) 740 +-------------------+------+-------+------+----------------+ 741 | Header | 6LN | 6LR_i | 6LBR | Internet | 742 +-------------------+------+-------+------+----------------+ 743 | Inserted headers | RPI | -- | -- | -- | 744 | Removed headers | -- | -- | -- | -- | 745 | Re-added headers | -- | -- | -- | -- | 746 | Modified headers | -- | RPI | -- | -- | 747 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 748 +-------------------+------+-------+------+----------------+ 750 Storing: Summary of the use of headers from RPL-aware-leaf to 751 Internet 753 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 755 In this case the flow comprises: 757 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 759 For example, the communication flow could be: Internet --> Node A 760 root(6LBR) --> Node B --> Node D --> Node F 762 6LR_i are the intermediate routers from source to destination. In 763 this case, "1 <= i >= n", n is the number of routers (6LR) that the 764 packet go through from 6LBR to destination(6LN). 766 When the packet arrives from Internet to 6LBR the RPI header is added 767 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 768 rank in the RPI. When the packet arrives at 6LN the RPI header is 769 removed and the packet processed. 771 +----------+---------+--------------+---------------+---------------+ 772 | Header | Interne | 6LBR | 6LR_i | 6LN | 773 | | t | | | | 774 +----------+---------+--------------+---------------+---------------+ 775 | Inserted | -- | IP-in- | -- | -- | 776 | headers | | IP(RPI) | | | 777 | Removed | -- | -- | -- | IP-in-IP(RPI) | 778 | headers | | | | | 779 | Re-added | -- | -- | -- | -- | 780 | headers | | | | | 781 | Modified | -- | -- | IP-in-IP(RPI) | -- | 782 | headers | | | | | 783 | Untouche | -- | -- | -- | -- | 784 | d | | | | | 785 | headers | | | | | 786 +----------+---------+--------------+---------------+---------------+ 788 Storing: Summary of the use of headers from Internet to RPL-aware- 789 leaf 791 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 793 In this case the flow comprises: 795 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 796 Internet 798 For example, the communication flow could be: Node G --> Node E --> 799 Node B --> Node A root(6LBR) --> Internet 801 6LR_i are the intermediate routers from source to destination. In 802 this case, "1 < i >= n", n is the number of routers (6LR) that the 803 packet go through from source(IPv6) to 6LBR. 805 The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed 806 either to the root, or hop-by-hop such that the root can remove the 807 RPI header before passing upwards. 809 The originating node will ideally leave the IPv6 flow label as zero 810 so that the packet can be better compressed through the LLN. The 811 6LBR will set the flow label of the packet to a non-zero value when 812 sending to the Internet. 814 +---------+-----+-------------+-------------+-------------+---------+ 815 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 816 | | 6 | | [i=2,..,n]_ | | t | 817 +---------+-----+-------------+-------------+-------------+---------+ 818 | Inserte | -- | IP-in- | -- | -- | -- | 819 | d | | IP(RPI) | | | | 820 | headers | | | | | | 821 | Removed | -- | -- | -- | IP-in- | -- | 822 | headers | | | | IP(RPI) | | 823 | Re- | -- | -- | -- | -- | -- | 824 | added | | | | | | 825 | headers | | | | | | 826 | Modifie | -- | -- | IP-in- | -- | -- | 827 | d | | | IP(RPI) | | | 828 | headers | | | | | | 829 | Untouch | -- | -- | -- | -- | -- | 830 | ed | | | | | | 831 | headers | | | | | | 832 +---------+-----+-------------+-------------+-------------+---------+ 834 Storing: Summary of the use of headers from not-RPL-aware-leaf to 835 Internet 837 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf 839 In this case the flow comprises: 841 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 843 For example, the communication flow could be: Internet --> Node A 844 root(6LBR) --> Node B --> Node E --> Node G 846 6LR_i are the intermediate routers from source to destination. In 847 this case, "1 < i >= n", n is the number of routers (6LR) that the 848 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i 849 updates the rank in the RPI. 851 The 6LBR will have to add an RPI header within an IP-in-IP header. 852 The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the 853 RPI inside. 855 The 6LBR MAY set the flow label on the inner IP-in-IP header to zero 856 in order to aid in compression. 858 +-----------+----------+---------------+---------------+------------+ 859 | Header | Internet | 6LBR | 6LR_i | IPv6 | 860 +-----------+----------+---------------+---------------+------------+ 861 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 862 | headers | | | | | 863 | Removed | -- | -- | -- | -- | 864 | headers | | | | | 865 | Re-added | -- | -- | -- | -- | 866 | headers | | | | | 867 | Modified | -- | -- | IP-in-IP(RPI) | -- | 868 | headers | | | | | 869 | Untouched | -- | -- | -- | RPI | 870 | headers | | | | (Ignored) | 871 +-----------+----------+---------------+---------------+------------+ 873 Storing: Summary of the use of headers from Internet to non-RPL- 874 aware-leaf 876 6.3. Storing Mode: Interaction between Leaf and Leaf 878 In this section we are going to describe the communication flow in 879 storing mode (SM) between, 881 RPL-aware-leaf to RPL-aware-leaf 883 RPL-aware-leaf to not-RPL-aware-leaf 885 not-RPL-aware-leaf to RPL-aware-leaf 887 not-RPL-aware-leaf to not-RPL-aware-leaf 889 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 891 In [RFC6550] RPL allows a simple one-hop optimization for both 892 storing and non-storing networks. A node may send a packet destined 893 to a one-hop neighbor directly to that node. Section 9 in [RFC6550]. 895 In this case the flow comprises: 897 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 899 For example, the communication flow could be: Node F --> Node D --> 900 Node B --> Node E --> Node H 902 6LR_ia (Node D) are the intermediate routers from source to the 903 common parent (6LR_x) (Node B) In this case, "1 <= ia >= n", n is the 904 number of routers (6LR) that the packet go through from 6LN (Node F) 905 to the common parent (6LR_x). 907 6LR_id (Node E) are the intermediate routers from the common parent 908 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 909 >= m", m is the number of routers (6LR) that the packet go through 910 from the common parent (6LR_x) to destination 6LN. 912 This case is assumed in the same RPL Domain. In the common parent 913 (Node B), the direction of RPI is changed (from increasing to 914 decreasing the rank). 916 While the 6LR nodes will update the RPI, no node needs to add or 917 remove the RPI, so no IP-in-IP headers are necessary. This may be 918 done regardless of where the destination is, as the included RPI will 919 be ignored by the receiver. 921 +---------------+--------+--------+---------------+--------+--------+ 922 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 923 | | src | | parent) | | dst | 924 +---------------+--------+--------+---------------+--------+--------+ 925 | Inserted | RPI | -- | -- | -- | -- | 926 | headers | | | | | | 927 | Removed | -- | -- | -- | -- | RPI | 928 | headers | | | | | | 929 | Re-added | -- | -- | -- | -- | -- | 930 | headers | | | | | | 931 | Modified | -- | RPI | RPI | RPI | -- | 932 | headers | | | | | | 933 | Untouched | -- | -- | -- | -- | -- | 934 | headers | | | | | | 935 +---------------+--------+--------+---------------+--------+--------+ 937 Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 938 aware-leaf 940 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 942 In this case the flow comprises: 944 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 945 6LN (IPv6) 947 For example, the communication flow could be: Node F --> Node D --> 948 Node B --> Node E --> Node G 950 6LR_ia are the intermediate routers from source (6LN) to the common 951 parent (6LR_x) In this case, "1 <= ia >= n", n is the number of 952 routers (6LR) that the packet go through from 6LN to the common 953 parent (6LR_x). 955 6LR_id (Node E) are the intermediate routers from the common parent 956 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 957 In this case, "1 <= id >= m", m is the number of routers (6LR) that 958 the packet go through from the common parent (6LR_x) to destination 959 6LN. 961 This situation is identical to the previous situation Section 6.3.1 963 +-----------+------+--------+---------------+--------+--------------+ 964 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 965 | | src | | parent) | | | 966 +-----------+------+--------+---------------+--------+--------------+ 967 | Inserted | RPI | -- | -- | -- | -- | 968 | headers | | | | | | 969 | Removed | -- | -- | -- | -- | RPI | 970 | headers | | | | | | 971 | Re-added | -- | -- | -- | -- | -- | 972 | headers | | | | | | 973 | Modified | -- | RPI | RPI | RPI | -- | 974 | headers | | | | | | 975 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 976 | headers | | | | | | 977 +-----------+------+--------+---------------+--------+--------------+ 979 Storing: Summary of the use of headers for RPL-aware-leaf to non-RPL- 980 aware-leaf 982 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 984 In this case the flow comprises: 986 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 987 6LR_id --> 6LN 989 For example, the communication flow could be: Node G --> Node E --> 990 Node B --> Node D --> Node F 992 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 993 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B) In 994 this case, "1 <= ia >= n", n is the number of routers (6LR) that the 995 packet go through from source to the common parent. 997 6LR_id (Node D) are the intermediate routers from the common parent 998 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 999 >= m", m is the number of routers (6LR) that the packet go through 1000 from the common parent (6LR_x) to destination 6LN. 1002 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1003 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1004 header. The IP-in-IP header is addressed to the destination 6LN 1005 (Node F). 1007 +--------+------+------------+------------+------------+------------+ 1008 | Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN | 1009 | | | | parent | | | 1010 | | | | (6LRx) | | | 1011 +--------+------+------------+------------+------------+------------+ 1012 | Insert | -- | IP-in- | -- | -- | -- | 1013 | ed hea | | IP(RPI) | | | | 1014 | ders | | | | | | 1015 | Remove | -- | -- | -- | -- | IP-in- | 1016 | d head | | | | | IP(RPI) | 1017 | ers | | | | | | 1018 | Re- | -- | -- | -- | -- | -- | 1019 | added | | | | | | 1020 | header | | | | | | 1021 | s | | | | | | 1022 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1023 | ed hea | | | IP(RPI) | IP(RPI) | | 1024 | ders | | | | | | 1025 | Untouc | -- | -- | -- | -- | -- | 1026 | hed he | | | | | | 1027 | aders | | | | | | 1028 +--------+------+------------+------------+------------+------------+ 1030 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1031 RPL-aware-leaf 1033 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1034 leaf 1036 In this case the flow comprises: 1038 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> root (6LBR) --> 1039 6LR_id --> not-RPL-aware 6LN (IPv6 dst) 1041 For example, the communication flow could be: Node G --> Node E --> 1042 Node B --> Node A (root) --> Node C --> Node J 1044 Internet 6LR_ia (Node E and Node B) are the intermediate routers from 1045 source (not-RPL-aware 6LN (IPv6 src))(Node G) to the root (6LBR) 1046 (Node A) In this case, "1 < ia >= n", n is the number of routers 1047 (6LR) that the packet go through from IPv6 src to the root. 1049 6LR_id (C) are the intermediate routers from the root (Node A) to 1050 destination (IPv6 dst) (Node J). In this case, "1 <= id >= m", m is 1051 the number of routers (6LR) that the packet go through from the root 1052 to destination (IPv6 dst). 1054 This flow is identical to Section 6.3.3 1056 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1057 G) and inserts the RPI header (RPIa) encapsulated in IPv6-in-IPv6 1058 header. The IPv6-in-IPv6 header is addressed to the 6LBR. The 6LBR 1059 remove the IPv6-in-IPv6 header and insert another one (RPIb) with 1060 destination to 6LR_m (Node C) node. 1062 One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is 1063 that now all the packets will go through the 6LBR, even though there 1064 exists a shorter P2P path to the destination 6LN in storing mode. 1065 One possible solution is given by the work in 1066 [I-D.ietf-roll-dao-projection]. Once we have route projection, the 1067 root can find that this traffic deserves optimization (based on 1068 volume and path length, or additional knowledge on that particular 1069 flow) and project a DAO into 6LR_1. 1071 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1072 | Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv | 1073 | r | 6 | | | | | 6 | 1074 | | src | | | | | dst | 1075 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1076 | Inser | -- | IP-in- | -- | IP-in- | -- | -- | 1077 | ted h | | IP(RPI_a) | | IP(RPI_b) | | | 1078 | eader | | | | | | | 1079 | s | | | | | | | 1080 | Remov | -- | -- | -- | -- | -- | -- | 1081 | ed he | | | | | | | 1082 | aders | | | | | | | 1083 | Re- | -- | -- | -- | -- | IP-in- | -- | 1084 | added | | | | | IP(RPI_b) | | 1085 | heade | | | | | | | 1086 | rs | | | | | | | 1087 | Modif | -- | -- | IP-in- | -- | IP-in- | -- | 1088 | ied h | | | IP(RPI_a) | | IP(RPI_b) | | 1089 | eader | | | | | | | 1090 | s | | | | | | | 1091 | Untou | -- | -- | -- | -- | -- | -- | 1092 | ched | | | | | | | 1093 | heade | | | | | | | 1094 | rs | | | | | | | 1095 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1097 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1098 non-RPL-aware-leaf 1100 7. Non Storing mode 1102 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1103 root) has complete knowledge about the connectivity of all DODAG 1104 nodes, and all traffic flows through the root node. Thus, there is 1105 no need for all nodes to know about the existence of non-RPL aware 1106 nodes. Only the 6LBR needs to change when there are non-RPL aware 1107 nodes. 1109 The following table summarizes what headers are needed in the 1110 following scenarios, and indicates when the RPI, RH3 and IP-in-IP 1111 header must be inserted. There are these possible situations: 1112 destination address possible (indicated by "dst"), to a 6LR, to a 6LN 1113 or to the root. In cases where no IP-in-IP header is needed, the 1114 column is left blank. 1116 The leaf can be a router 6LR or a host, both indicated as 6LN 1117 (Figure 3). 1119 +-----------------+--------------+-----+-----+----------+----------+ 1120 | Interaction | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP | 1121 | between | | | | | dst | 1122 +-----------------+--------------+-----+-----+----------+----------+ 1123 | | Raf to root | Yes | No | No | -- | 1124 + +--------------+-----+-----+----------+----------+ 1125 | Leaf - Root | root to Raf | Opt | Yes | No | -- | 1126 + +--------------+-----+-----+----------+----------+ 1127 | | root to ~Raf | No | Yes | Yes | 6LR | 1128 + +--------------+-----+-----+----------+----------+ 1129 | | ~Raf to root | Yes | No | Yes | root | 1130 +-----------------+--------------+-----+-----+----------+----------+ 1131 | | Raf to Int | Yes | No | Yes | root | 1132 + +--------------+-----+-----+----------+----------+ 1133 | Leaf - Internet | Int to Raf | Opt | Yes | Yes | dst | 1134 + +--------------+-----+-----+----------+----------+ 1135 | | ~Raf to Int | Yes | No | Yes | root | 1136 + +--------------+-----+-----+----------+----------+ 1137 | | Int to ~Raf | Opt | Yes | Yes | 6LR | 1138 +-----------------+--------------+-----+-----+----------+----------+ 1139 | | Raf to Raf | Yes | Yes | Yes | root/dst | 1140 + +--------------+-----+-----+----------+----------+ 1141 | | Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1142 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1143 | | ~Raf to Raf | Yes | Yes | Yes | root/6LN | 1144 + +--------------+-----+-----+----------+----------+ 1145 | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1146 +-----------------+--------------+-----+-----+----------+----------+ 1148 Figure 5: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP 1149 encapsulation. 1151 7.1. Non-Storing Mode: Interaction between Leaf and Root 1153 In this section we are going to describe the communication flow in 1154 Non Storing Mode (Non-SM) between, 1156 RPL-aware-leaf to root 1158 root to RPL-aware-leaf 1160 not-RPL-aware-leaf to root 1162 root to not-RPL-aware-leaf 1164 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1166 In non-storing mode the leaf node uses default routing to send 1167 traffic to the root. The RPI header must be included to avoid/detect 1168 loops. 1170 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1172 For example, the communication flow could be: Node F --> Node D --> 1173 Node B --> Node A (root) 1175 6LR_i are the intermediate routers from source to destination. In 1176 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1177 packet go through from source (6LN) to destination (6LBR). 1179 This situation is the same case as storing mode. 1181 +-------------------+-----+-------+------+ 1182 | Header | 6LN | 6LR_i | 6LBR | 1183 +-------------------+-----+-------+------+ 1184 | Inserted headers | RPI | -- | -- | 1185 | Removed headers | -- | -- | RPI | 1186 | Re-added headers | -- | -- | -- | 1187 | Modified headers | -- | RPI | -- | 1188 | Untouched headers | -- | -- | -- | 1189 +-------------------+-----+-------+------+ 1191 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1192 root 1194 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf 1196 In this case the flow comprises: 1198 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1200 For example, the communication flow could be: Node A (root) --> Node 1201 B --> Node D --> Node F 1203 6LR_i are the intermediate routers from source to destination. In 1204 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1205 packet go through from source (6LBR) to destination (6LN). 1207 The 6LBR will insert an RH3, and may optionally insert an RPI header. 1208 No IP-in-IP header is necessary as the traffic originates with an RPL 1209 aware node, the 6LBR. The destination is known to RPL-aware because, 1210 the root knows the whole topology in non-storing mode. 1212 +-------------------+-----------------+-------+----------+ 1213 | Header | 6LBR | 6LR_i | 6LN | 1214 +-------------------+-----------------+-------+----------+ 1215 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1216 | Removed headers | -- | -- | RH3,RPI | 1217 | Re-added headers | -- | -- | -- | 1218 | Modified headers | -- | RH3 | -- | 1219 | Untouched headers | -- | -- | -- | 1220 +-------------------+-----------------+-------+----------+ 1222 Non Storing: Summary of the use of headers from root to RPL-aware- 1223 leaf 1225 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1227 In this case the flow comprises: 1229 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1231 For example, the communication flow could be: Node A (root) --> Node 1232 B --> Node E --> Node G 1234 6LR_i are the intermediate routers from source to destination. In 1235 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1236 packet go through from source (6LBR) to destination (IPv6). 1238 In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR_1 1239 and so on) and it is fully consumed in the last 6LR (6LR_n), but left 1240 there. If RPI is left present, the IPv6 node which does not 1241 understand it will ignore it (following 2460bis), thus encapsulation 1242 is not necesary. Due the complete knowledge of the topology at the 1243 root, the 6LBR is able to address the IP-in-IP header to the last 1244 6LR. 1246 +---------------+-------------+---------------+--------------+------+ 1247 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1248 +---------------+-------------+---------------+--------------+------+ 1249 | Inserted | (opt: RPI), | -- | -- | -- | 1250 | headers | RH3 | | | | 1251 | Removed | -- | RH3 | -- | -- | 1252 | headers | | | | | 1253 | Re-added | -- | -- | -- | -- | 1254 | headers | | | | | 1255 | Modified | -- | (opt: RPI), | (opt: RPI), | -- | 1256 | headers | | RH3 | RH3 | | 1257 | Untouched | -- | -- | -- | RPI | 1258 | headers | | | | | 1259 +---------------+-------------+---------------+--------------+------+ 1261 Non Storing: Summary of the use of headers from root to not-RPL- 1262 aware-leaf 1264 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1266 In this case the flow comprises: 1268 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1270 For example, the communication flow could be: Node G --> Node E --> 1271 Node B --> Node A (root) 1273 6LR_i are the intermediate routers from source to destination. In 1274 this case, "1 < i >= n", n is the number of routers (6LR) that the 1275 packet go through from source (IPv6) to destination (6LBR). For 1276 example, 6LR_1 (i=1) is the router that receives the packets from the 1277 IPv6 node. 1279 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1280 encapsulated in an IP-in-IP header, and is modified in the followings 1281 6LRs. The RPI and entire packet is consumed by the root. 1283 +------------+------+---------------+---------------+---------------+ 1284 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 1285 +------------+------+---------------+---------------+---------------+ 1286 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 1287 | headers | | | | | 1288 | Removed | -- | -- | -- | IP-in-IP(RPI) | 1289 | headers | | | | | 1290 | Re-added | -- | -- | -- | -- | 1291 | headers | | | | | 1292 | Modified | -- | -- | IP-in-IP(RPI) | -- | 1293 | headers | | | | | 1294 | Untouched | -- | -- | -- | -- | 1295 | headers | | | | | 1296 +------------+------+---------------+---------------+---------------+ 1298 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1299 root 1301 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1303 In this section we are going to describe the communication flow in 1304 Non Storing Mode (Non-SM) between, 1306 RPL-aware-leaf to Internet 1308 Internet to RPL-aware-leaf 1310 not-RPL-aware-leaf to Internet 1312 Internet to not-RPL-aware-leaf 1314 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1316 In this case the flow comprises: 1318 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1320 For example, the communication flow could be: Node F --> Node D --> 1321 Node B --> Node A --> Internet 1323 6LR_i are the intermediate routers from source to destination. In 1324 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1325 packet go through from source (6LN) to 6LBR. 1327 This case is identical to storing-mode case. 1329 The IPv6 flow label should be set to zero to aid in compression, and 1330 the 6LBR will set it to a non-zero value when sending towards the 1331 Internet. 1333 +-------------------+------+-------+------+----------------+ 1334 | Header | 6LN | 6LR_i | 6LBR | Internet | 1335 +-------------------+------+-------+------+----------------+ 1336 | Inserted headers | RPI | -- | -- | -- | 1337 | Removed headers | -- | -- | -- | -- | 1338 | Re-added headers | -- | -- | -- | -- | 1339 | Modified headers | -- | RPI | -- | -- | 1340 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1341 +-------------------+------+-------+------+----------------+ 1343 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1344 Internet 1346 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1348 In this case the flow comprises: 1350 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1352 For example, the communication flow could be: Internet --> Node A 1353 (root) --> Node B --> Node D --> Node F 1355 6LR_i are the intermediate routers from source to destination. In 1356 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1357 packet go through from 6LBR to destination(6LN). 1359 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1360 address of the target node, it can address the IP-in-IP header to 1361 that node. The 6LBR will zero the flow label upon entry in order to 1362 aid compression. 1364 The RPI may be added or not, it is optional. 1366 +--------+-------+----------------+----------------+----------------+ 1367 | Header | Inter | 6LBR | 6LR_i | 6LN | 1368 | | net | | | | 1369 +--------+-------+----------------+----------------+----------------+ 1370 | Insert | -- | IP-in-IP(RH3,o | -- | -- | 1371 | ed hea | | pt:RPI) | | | 1372 | ders | | | | | 1373 | Remove | -- | -- | -- | IP-in-IP(RH3,o | 1374 | d head | | | | pt:RPI) | 1375 | ers | | | | | 1376 | Re- | -- | -- | -- | -- | 1377 | added | | | | | 1378 | header | | | | | 1379 | s | | | | | 1380 | Modifi | -- | -- | IP-in-IP(RH3,o | -- | 1381 | ed hea | | | pt:RPI) | | 1382 | ders | | | | | 1383 | Untouc | -- | -- | -- | -- | 1384 | hed he | | | | | 1385 | aders | | | | | 1386 +--------+-------+----------------+----------------+----------------+ 1388 Non Storing: Summary of the use of headers from Internet to RPL- 1389 aware-leaf 1391 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1393 In this case the flow comprises: 1395 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1396 Internet 1398 For example, the communication flow could be: Node G --> Node E --> 1399 Node B --> Node A --> Internet 1401 6LR_i are the intermediate routers from source to destination. In 1402 this case, "1 < i >= n", n is the number of routers (6LR) that the 1403 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1405 In this case the flow label is recommended to be zero in the IPv6 1406 node. As RPL headers are added in the IPv6 node, the first 6LR 1407 (6LR_1) will add an RPI header inside a new IP-in-IP header. The IP- 1408 in-IP header will be addressed to the root. This case is identical 1409 to the storing-mode case (Section 5.7). 1411 +---------+-----+-------------+-------------+-------------+---------+ 1412 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 1413 | | 6 | | [i=2,..,n]_ | | t | 1414 +---------+-----+-------------+-------------+-------------+---------+ 1415 | Inserte | -- | IP-in- | -- | -- | -- | 1416 | d | | IP(RPI) | | | | 1417 | headers | | | | | | 1418 | Removed | -- | -- | -- | IP-in- | -- | 1419 | headers | | | | IP(RPI) | | 1420 | Re- | -- | -- | -- | -- | -- | 1421 | added | | | | | | 1422 | headers | | | | | | 1423 | Modifie | -- | -- | IP-in- | -- | -- | 1424 | d | | | IP(RPI) | | | 1425 | headers | | | | | | 1426 | Untouch | -- | -- | -- | -- | -- | 1427 | ed | | | | | | 1428 | headers | | | | | | 1429 +---------+-----+-------------+-------------+-------------+---------+ 1431 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1432 Internet 1434 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1436 In this case the flow comprises: 1438 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1440 For example, the communication flow could be: Internet --> Node A 1441 (root) --> Node B --> Node E --> Node G 1443 6LR_i are the intermediate routers from source to destination. In 1444 this case, "1 < i >= n", n is the number of routers (6LR) that the 1445 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1447 The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR 1448 will know the path, and will recognize that the final node is not an 1449 RPL capable node as it will have received the connectivity DAO from 1450 the nearest 6LR. The 6LBR can therefore make the IP-in-IP header 1451 destination be the last 6LR. The 6LBR will set to zero the flow 1452 label upon entry in order to aid compression. 1454 +--------+-------+----------------+------------+-------------+------+ 1455 | Header | Inter | 6LBR | 6LR_1 | 6LR_i(i=2,. | IPv6 | 1456 | | net | | | .,n) | | 1457 +--------+-------+----------------+------------+-------------+------+ 1458 | Insert | -- | IP-in-IP(RH3,o | -- | -- | -- | 1459 | ed hea | | pt:RPI) | | | | 1460 | ders | | | | | | 1461 | Remove | -- | -- | -- | IP-in- | -- | 1462 | d head | | | | IP(RH3, | | 1463 | ers | | | | RPI) | | 1464 | Re- | -- | -- | -- | -- | -- | 1465 | added | | | | | | 1466 | header | | | | | | 1467 | s | | | | | | 1468 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1469 | ed hea | | | IP(RH3, | IP(RH3, | | 1470 | ders | | | RPI) | RPI) | | 1471 | Untouc | -- | -- | -- | -- | RPI | 1472 | hed he | | | | | | 1473 | aders | | | | | | 1474 +--------+-------+----------------+------------+-------------+------+ 1476 NonStoring: Summary of the use of headers from Internet to non-RPL- 1477 aware-leaf 1479 7.3. Non-Storing Mode: Interaction between Leafs 1481 In this section we are going to describe the communication flow in 1482 Non Storing Mode (Non-SM) between, 1484 RPL-aware-leaf to RPL-aware-leaf 1486 RPL-aware-leaf to not-RPL-aware-leaf 1488 not-RPL-aware-leaf to RPL-aware-leaf 1490 not-RPL-aware-leaf to not-RPL-aware-leaf 1492 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1494 In this case the flow comprises: 1496 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1498 For example, the communication flow could be: Node F --> Node D --> 1499 Node B --> Node A (root) --> Node B --> Node E --> Node H 1500 6LR_ia are the intermediate routers from source to the root In this 1501 case, "1 <= ia >= n", n is the number of routers (6LR) that the 1502 packet go through from 6LN to the root. 1504 6LR_id are the intermediate routers from the root to the destination. 1505 In this case, "1 <= ia >= m", m is the number of the intermediate 1506 routers (6LR). 1508 This case involves only nodes in same RPL Domain. The originating 1509 node will add an RPI header to the original packet, and send the 1510 packet upwards. 1512 The originating node SHOULD put the RPI into an IP-in-IP header 1513 addressed to the root, so that the 6LBR can remove that header. If 1514 it does not, then additional resources are wasted on the way down to 1515 carry the useless RPI option. 1517 The 6LBR will need to insert an RH3 header, which requires that it 1518 add an IP-in-IP header. It SHOULD be able to remove the RPI, as it 1519 was contained in an IP-in-IP header addressed to it. Otherwise, 1520 there MAY be an RPI header buried inside the inner IP header, which 1521 should get ignored. 1523 Networks that use the RPL P2P extension [RFC6997] are essentially 1524 non-storing DODAGs and fall into this scenario or scenario 1525 Section 7.1.2, with the originating node acting as 6LBR. 1527 +---------+-------------+------+--------------+-------+-------------+ 1528 | Header | 6LN src | 6LR_ | 6LBR | 6LR_i | 6LN dst | 1529 | | | ia | | d | | 1530 +---------+-------------+------+--------------+-------+-------------+ 1531 | Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- | 1532 | d | IP(RPI1) | | to 6LN, opt | | | 1533 | headers | | | RPI2) | | | 1534 | Removed | -- | -- | IP-in- | -- | IP-in- | 1535 | headers | | | IP(RPI1) | | IP(RH3, opt | 1536 | | | | | | RPI2) | 1537 | Re- | -- | -- | -- | -- | -- | 1538 | added | | | | | | 1539 | headers | | | | | | 1540 | Modifie | -- | RPI1 | -- | RPI2 | -- | 1541 | d | | | | | | 1542 | headers | | | | | | 1543 | Untouch | -- | -- | -- | -- | -- | 1544 | ed | | | | | | 1545 | headers | | | | | | 1546 +---------+-------------+------+--------------+-------+-------------+ 1548 Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 1549 aware-leaf 1551 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1552 leaf 1554 In this case the flow comprises: 1556 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1558 For example, the communication flow could be: Node F --> Node D --> 1559 Node B --> Node A (root) --> Node B --> Node E --> Node G 1561 6LR_ia are the intermediate routers from source to the root In this 1562 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1564 6LR_id are the intermediate routers from the root to the destination. 1565 In this case, "1 <= ia >= m", m is the number of the intermediate 1566 routers (6LR). 1568 As in the previous case, the 6LN will insert an RPI (RPI_1) header 1569 which MUST be in an IP-in-IP header addressed to the root so that the 1570 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a 1571 new IP-in-IP header addressed to the 6LN destination node. The RPI 1572 is optional from 6LBR to 6LR_id (RPI_2). 1574 +--------+-----------+------------+-------------+------------+------+ 1575 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1576 +--------+-----------+------------+-------------+------------+------+ 1577 | Insert | IP-in- | -- | IP-in- | -- | -- | 1578 | ed hea | IP(RPI1) | | IP(RH3, opt | | | 1579 | ders | | | RPI_2) | | | 1580 | Remove | -- | -- | IP-in- | IP-in- | -- | 1581 | d head | | | IP(RPI_1) | IP(RH3, | | 1582 | ers | | | | opt RPI_2) | | 1583 | Re- | -- | -- | -- | -- | -- | 1584 | added | | | | | | 1585 | header | | | | | | 1586 | s | | | | | | 1587 | Modifi | -- | IP-in- | -- | IP-in- | -- | 1588 | ed hea | | IP(RPI_1) | | IP(RH3, | | 1589 | ders | | | | opt RPI_2) | | 1590 | Untouc | -- | -- | -- | -- | opt | 1591 | hed he | | | | | RPI_ | 1592 | aders | | | | | 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, the 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 | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN | 1623 | | 6 | | | | | 1624 +--------+-----+------------+-------------+------------+------------+ 1625 | Insert | -- | IP-in- | IP-in- | -- | -- | 1626 | ed hea | | IP(RPI_1) | IP(RH3, opt | | | 1627 | ders | | | RPI_2) | | | 1628 | Remove | -- | -- | IP-in- | -- | IP-in- | 1629 | d head | | | IP(RPI_1) | | IP(RH3, | 1630 | ers | | | | | opt RPI_2) | 1631 | Re- | -- | -- | -- | -- | -- | 1632 | added | | | | | | 1633 | header | | | | | | 1634 | s | | | | | | 1635 | Modifi | -- | -- | -- | IP-in- | -- | 1636 | ed hea | | | | IP(RH3, | | 1637 | ders | | | | opt RPI_2) | | 1638 | Untouc | -- | -- | -- | -- | -- | 1639 | hed he | | | | | | 1640 | aders | | | | | | 1641 +--------+-----+------------+-------------+------------+------------+ 1643 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1644 RPL-aware-leaf 1646 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1647 aware-leaf 1649 In this case the flow comprises: 1651 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1652 not-RPL-aware (IPv6 dst) 1654 For example, the communication flow could be: Node G --> Node E --> 1655 Node B --> Node A (root) --> Node C --> Node J 1657 6LR_ia are the intermediate routers from source to the root In this 1658 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1660 6LR_id are the intermediate routers from the root to the destination. 1661 In this case, "1 <= ia >= m", m is the number of the intermediate 1662 routers (6LR). 1664 This scenario is the combination of the previous two cases. 1666 +---------+-----+--------------+---------------+-------------+------+ 1667 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1668 | | 6 | | | | dst | 1669 | | src | | | | | 1670 +---------+-----+--------------+---------------+-------------+------+ 1671 | Inserte | -- | IP-in- | IP-in-IP(RH3) | -- | -- | 1672 | d | | IP(RPI_1) | | | | 1673 | headers | | | | | | 1674 | Removed | -- | -- | IP-in- | IP-in- | -- | 1675 | headers | | | IP(RPI_1) | IP(RH3, opt | | 1676 | | | | | RPI_2) | | 1677 | Re- | -- | -- | -- | -- | -- | 1678 | added | | | | | | 1679 | headers | | | | | | 1680 | Modifie | -- | -- | -- | -- | -- | 1681 | d | | | | | | 1682 | headers | | | | | | 1683 | Untouch | -- | -- | -- | -- | -- | 1684 | ed | | | | | | 1685 | headers | | | | | | 1686 +---------+-----+--------------+---------------+-------------+------+ 1688 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1689 not-RPL-aware-leaf 1691 8. Observations about the cases 1693 8.1. Storing mode 1695 [I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP 1696 header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header 1697 as described in Section 7 of the document. 1699 There are potential significant advantages to having a single code 1700 path that always processes IP-in-IP headers with no options. 1702 Thanks to the relaxation of the RFC2460 rule about discarding unknown 1703 Hop-by-Hop options, there is no longer any uncertainty about when to 1704 use an IPIP header in the storing mode case. The RPI header SHOULD 1705 always be added when 6LRs originate packets (without IPIP headers), 1706 and IPIP headers should always be added (addressed to the root when 1707 on the way up, to the end-host when on the way down) when a 6LR finds 1708 it needs to insert an RPI header. 1710 In order to support the above two cases with full generality, the 1711 different situations (always do IP-in-IP vs never use IP-in-IP) 1712 should be signaled in the RPL protocol itself. 1714 8.2. Non-Storing mode 1716 In the non-storing case, dealing with non-RPL aware leaf nodes is 1717 much easier as the 6LBR (DODAG root) has complete knowledge about the 1718 connectivity of all DODAG nodes, and all traffic flows through the 1719 root node. 1721 The 6LBR can recognize non-RPL aware leaf nodes because it will 1722 receive a DAO about that node from the 6LN immediately above that 1723 node. This means that the non-storing mode case can avoid ever using 1724 hop-by-hop IP-in-IP headers. 1726 Unlike in the storing mode case, there is no need for all nodes to 1727 know about the existence of non-RPL aware nodes. Only the 6LBR needs 1728 to change when there are non-RPL aware nodes. Further, in the non- 1729 storing case, the 6LBR is informed by the DAOs when there are non-RPL 1730 aware nodes. 1732 9. 6LoRH Compression cases 1734 The [I-D.ietf-roll-routing-dispatch] proposes a compression method 1735 for RPI, RH3 and IPv6-in-IPv6. 1737 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 1738 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 1739 an IP-in-IP and RPI compression headers. The type of this case is 1740 critical since IP-in-IP is encapsulating a RPI header. 1742 +--+-----+---+--------------+-----------+-------------+-------------+ 1743 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | 1744 +--+-----+---+--------------+-----------+-------------+-------------+ 1746 Figure 6: Critical IP-in-IP (RPI). 1748 10. IANA Considerations 1750 This document updates the registration made in [RFC6553] to the IPv6 1751 Hop-by-Hop Registry from 0x43 to 0x63. 1753 11. Security Considerations 1755 The security considerations covering of [RFC6553] and [RFC6554] apply 1756 when the packets get into RPL Domain. 1758 The IPIP mechanism described in this document is much more limited 1759 than the general mechanism described in [RFC2473]. The willingness 1760 of each node in the LLN to decapsulate packets and forward them could 1761 be exploited by nodes to disguise the origin of an attack. 1763 Nodes outside of the LLN will need to pass IPIP traffic through the 1764 RPL root to perform this attack. To counter, the RPL root SHOULD 1765 either restrict ingress of IPIP packets (the simpler solution), or it 1766 SHOULD do a deep packet inspection wherein it walks the IP header 1767 extension chain until it can inspect the upper-layer-payload as 1768 described in [RFC7045]. In particular, the RPL root SHOULD do BCP38 1769 ([RFC2827]) processing on the source addresses of all IP headers that 1770 it examines in both directions. 1772 Note: there are some situations where a prefix will spread across 1773 multiple LLNs via mechanisms such as described in 1774 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 1775 needs to take this into account. 1777 Nodes with the LLN can use the IPIP mechanism to mount an attack on 1778 another part of the LLN, while disguising the origin of the attack. 1779 The mechanism can even be abused to make it appear that the attack is 1780 coming from outside the LLN, and unless countered, this could be used 1781 to mount a Distributed Denial Of Service attack upon nodes elsewhere 1782 in the Internet. See [DDOS-KREBS] for an example of such attacks 1783 already seen in the real world. 1785 While a typical LLN may be a very poor origin for attack traffic (as 1786 the networks tend to be very slow, and the nodes often have very low 1787 duty cycles) given enough nodes, they could still have a significant 1788 impact, particularly if the attack was on another LLN! Additionally, 1789 some uses of RPL involve large backbone ISP scale equipment 1790 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1791 multiple 100Gb/s interfaces. 1793 Blocking or careful filtering of IPIP traffic entering the LLN as 1794 described above will make sure that any attack that is mounted must 1795 originate compromised nodes within the LLN. The use of BCP38 1796 filtering at the RPL root on egress traffic will both alert the 1797 operator to the existence of the attack, as well as drop the attack 1798 traffic. As the RPL network is typically numbered from a single 1799 prefix, which is itself assigned by RPL, BCP38 filtering involves a 1800 single prefix comparison and should be trivial to automatically 1801 configure. 1803 There are some scenarios where IPIP traffic SHOULD be allowed to pass 1804 through the RPL root, such as the IPIP mediated communications 1805 between a new Pledge and the Join Registrar/Coordinator (JRC) when 1806 using [I-D.ietf-anima-bootstrapping-keyinfra] and 1807 [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the 1808 RPL root to do careful filtering: it occurs only when the Join 1809 Coordinator is not co-located inside the RPL root. 1811 With the above precautions, an attack using IPIP tunnels will be by a 1812 node within the LLN on another node within the LLN. Such an attack 1813 could, of course, be done directly. An attack of this kind is 1814 meaningful only if the source addresses are either fake or if the 1815 point is to amplify return traffic. Such an attack, could also be 1816 done without the use of IPIP headers using forged source addresses. 1817 If the attack requires bi-directional communication, then IPIP 1818 provides no advantages. 1820 [RFC2473] suggests that tunnel entry and exit points can be secured, 1821 via the "Use IPsec". This solution has all the problems that 1822 [RFC5406] goes into. In an LLN such a solution would degenerate into 1823 every node having a tunnel with every other node. It would provide a 1824 small amount of origin address authentication at a very high cost; 1825 doing BCP38 at every node (linking layer-3 addresses to layer-2 1826 addresses, and to already present layer-2 cryptographic mechanisms) 1827 would be cheaper should RPL be run in an environment where hostile 1828 nodes are likely to be a part of the LLN. 1830 The RH3 header usage described here can be abused in equivalent ways 1831 with an IPIP header to add the needed RH3 header. As such, the 1832 attacker's RH3 header will not be seen by the network until it 1833 reaches the end host, which will decapsulate it. An end-host SHOULD 1834 be suspicious about a RH3 header which has additional hops which have 1835 not yet been processed, and SHOULD ignore such a second RH3 header. 1837 In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch] 1838 to compress the IPIP and RH3 headers. As such, the compressor at the 1839 RPL-root will see the second RH3 header and MAY choose to discard the 1840 packet if the RH3 header has not been completely consumed. A 1841 consumed (inert) RH3 header could be present in a packet that flows 1842 from one LLN, crosses the Internet, and enters another LLN. As per 1843 the discussion in this document, such headers do not need to be 1844 removed. However, there is no case described in this document where 1845 an RH3 is inserted in a non-storing network on traffic that is 1846 leaving the LLN, but this document SHOULD NOT preclude such a future 1847 innovation. It should just be noted that an incoming RH3 must be 1848 fully consumed, or very carefully inspected. 1850 The RPI header, if permitted to enter the LLN, could be used by an 1851 attacker to change the priority of a packet by selecting a different 1852 RPL instanceID, perhaps one with a higher energy cost, for instance. 1853 It could also be that not all nodes are reachable in an LLN using the 1854 default instanceID, but a change of instanceID would permit an 1855 attacker to bypass such filtering. Like the RH3, an RPI header is to 1856 be inserted by the RPL root on traffic entering the LLN by first 1857 inserting an IPIP header. The attacker's RPI header therefore will 1858 not be seen by the network. Upon reaching the destination node the 1859 RPI header has no further meaning and is just skipped; the presence 1860 of a second RPI header will have no meaning to the end node as the 1861 packet has already been identified as being at it's final 1862 destination. 1864 The RH3 and RPI headers could be abused by an attacker inside of the 1865 network to route packets on non-obvious ways, perhaps eluding 1866 observation. This usage is in fact part of [RFC6997] and can not be 1867 restricted at all. This is a feature, not a bug. 1869 [RFC7416] deals with many other threats to LLNs not directly related 1870 to the use of IPIP headers, and this document does not change that 1871 analysis. 1873 12. Acknowledgments 1875 This work is partially funded by the FP7 Marie Curie Initial Training 1876 Network (ITN) METRICS project (grant agreement No. 607728). 1878 The authors would like to acknowledge the review, feedback, and 1879 comments of (alphabetical order): Robert Cragie, Simon Duquennoy, 1880 Cenk Guendogan, C. M. Heard, Rahul Jadhav, Peter van der Stok, 1881 Xavier Vilajosana and Thomas Watteyne. 1883 13. References 1885 13.1. Normative References 1887 [I-D.ietf-6man-rfc2460bis] 1888 Deering, S. and R. Hinden, "Internet Protocol, Version 6 1889 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 1890 in progress), May 2017. 1892 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1893 Requirement Levels", BCP 14, RFC 2119, 1894 DOI 10.17487/RFC2119, March 1997, 1895 . 1897 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1898 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1899 December 1998, . 1901 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1902 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1903 December 1998, . 1905 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1906 Defeating Denial of Service Attacks which employ IP Source 1907 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1908 May 2000, . 1910 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1911 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1912 February 2009, . 1914 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1915 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1916 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1917 Low-Power and Lossy Networks", RFC 6550, 1918 DOI 10.17487/RFC6550, March 2012, 1919 . 1921 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1922 Power and Lossy Networks (RPL) Option for Carrying RPL 1923 Information in Data-Plane Datagrams", RFC 6553, 1924 DOI 10.17487/RFC6553, March 2012, 1925 . 1927 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1928 Routing Header for Source Routes with the Routing Protocol 1929 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1930 DOI 10.17487/RFC6554, March 2012, 1931 . 1933 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1934 of IPv6 Extension Headers", RFC 7045, 1935 DOI 10.17487/RFC7045, December 2013, 1936 . 1938 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1939 and M. Richardson, Ed., "A Security Threat Analysis for 1940 the Routing Protocol for Low-Power and Lossy Networks 1941 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1942 . 1944 13.2. Informative References 1946 [DDOS-KREBS] 1947 Goodin, D., "Record-breaking DDoS reportedly delivered by 1948 >145k hacked cameras", September 2016, 1949 . 1952 [I-D.ietf-6lo-backbone-router] 1953 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 1954 backbone-router-03 (work in progress), January 2017. 1956 [I-D.ietf-6tisch-architecture] 1957 Thubert, P., "An Architecture for IPv6 over the TSCH mode 1958 of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work 1959 in progress), January 2017. 1961 [I-D.ietf-6tisch-dtsecurity-secure-join] 1962 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 1963 6tisch-dtsecurity-secure-join-01 (work in progress), 1964 February 2017. 1966 [I-D.ietf-anima-autonomic-control-plane] 1967 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 1968 Control Plane", draft-ietf-anima-autonomic-control- 1969 plane-06 (work in progress), March 2017. 1971 [I-D.ietf-anima-bootstrapping-keyinfra] 1972 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1973 S., and K. Watsen, "Bootstrapping Remote Secure Key 1974 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1975 keyinfra-06 (work in progress), May 2017. 1977 [I-D.ietf-roll-dao-projection] 1978 Thubert, P. and J. Pylakutty, "Root initiated routing 1979 state in RPL", draft-ietf-roll-dao-projection-01 (work in 1980 progress), March 2017. 1982 [I-D.ietf-roll-routing-dispatch] 1983 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 1984 "6LoWPAN Routing Header", draft-ietf-roll-routing- 1985 dispatch-05 (work in progress), October 2016. 1987 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1988 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1989 DOI 10.17487/RFC4192, September 2005, 1990 . 1992 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 1993 Control Message Protocol (ICMPv6) for the Internet 1994 Protocol Version 6 (IPv6) Specification", RFC 4443, 1995 DOI 10.17487/RFC4443, March 2006, 1996 . 1998 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1999 Bormann, "Neighbor Discovery Optimization for IPv6 over 2000 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2001 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2002 . 2004 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2005 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2006 in Low-Power and Lossy Networks", RFC 6997, 2007 DOI 10.17487/RFC6997, August 2013, 2008 . 2010 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2011 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2012 2014, . 2014 [Second6TischPlugtest] 2015 "2nd 6Tisch Plugtest", . 2018 Authors' Addresses 2020 Maria Ines Robles 2021 Ericsson 2022 Hirsalantie 11 2023 Jorvas 02420 2024 Finland 2026 Email: maria.ines.robles@ericsson.com 2028 Michael C. Richardson 2029 Sandelman Software Works 2030 470 Dawson Avenue 2031 Ottawa, ON K1Z 5V7 2032 CA 2034 Email: mcr+ietf@sandelman.ca 2035 URI: http://www.sandelman.ca/mcr/ 2037 Pascal Thubert 2038 Cisco Systems, Inc 2039 Village d'Entreprises Green Side 400, Avenue de Roumanille 2040 Batiment T3, Biot - Sophia Antipolis 06410 2041 France 2043 Email: pthubert@cisco.com