idnits 2.17.1 draft-ietf-roll-useofrplinfo-16.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 directly say this. It does mention RFC6550 though, so this could be OK. -- 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 209 has weird spacing: '... act chg ...' == Line 242 has weird spacing: '... act chg ...' == Line 1760 has weird spacing: '... act chg ...' -- The document date (July 3, 2017) is 2460 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 1763, but not defined == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 1973, but no explicit reference was found in the text -- 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: A later version (-20) exists of draft-ietf-6lo-backbone-router-03 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-11 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-06 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-06 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-01 Summary: 3 errors (**), 0 flaws (~~), 11 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: January 4, 2018 P. Thubert 7 Cisco 8 July 3, 2017 10 When to use RFC 6553, 6554 and IPv6-in-IPv6 11 draft-ietf-roll-useofrplinfo-16 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 http://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 January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 and RFC 6550 . . . . . . . . . . . . . . . 5 62 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 63 3.2. Updates to RFC 6550 . . . . . . . . . . . . . . . . . . . 6 64 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 7 65 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13 68 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 14 69 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 15 70 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 15 71 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16 72 6.2. Storing Mode: Interaction between Leaf and Internet . . . 17 73 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 17 74 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18 75 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 76 Internet . . . . . . . . . . . . . . . . . . . . . . 19 77 6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 78 leaf . . . . . . . . . . . . . . . . . . . . . . . . 20 79 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 21 80 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 81 leaf . . . . . . . . . . . . . . . . . . . . . . . . 21 82 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 83 aware-leaf . . . . . . . . . . . . . . . . . . . . . 22 84 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 85 aware-leaf . . . . . . . . . . . . . . . . . . . . . 23 86 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 87 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 24 88 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 26 89 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 27 90 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 28 91 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 28 92 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 93 leaf . . . . . . . . . . . . . . . . . . . . . . . . 29 94 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 95 root . . . . . . . . . . . . . . . . . . . . . . . . 30 96 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 31 97 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 98 Internet . . . . . . . . . . . . . . . . . . . . . . 31 99 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 100 leaf . . . . . . . . . . . . . . . . . . . . . . . . 32 101 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 102 Internet . . . . . . . . . . . . . . . . . . . . . . 33 103 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 104 aware-leaf . . . . . . . . . . . . . . . . . . . . . 34 105 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 35 106 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 107 aware-leaf . . . . . . . . . . . . . . . . . . . . . 35 108 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 109 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37 110 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 111 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38 112 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 113 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39 114 8. Observations about the cases . . . . . . . . . . . . . . . . 40 115 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40 116 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41 117 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 119 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 120 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 121 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 122 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 123 13.2. Informative References . . . . . . . . . . . . . . . . . 46 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 126 1. Introduction 128 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 129 [RFC6550] is a routing protocol for constrained networks. RFC 6553 130 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 131 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 132 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 133 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 134 RPL routing domain, particularly in non-storing mode. 136 These various items are referred to as RPL artifacts, and they are 137 seen on all of the data-plane traffic that occurs in RPL routed 138 networks; they do not in general appear on the RPL control plane 139 traffic at all which is mostly hop-by-hop traffic (one exception 140 being DAO messages in non-storing mode). 142 It has become clear from attempts to do multi-vendor 143 interoperability, and from a desire to compress as many of the above 144 artifacts as possible that not all implementors agree when artifacts 145 are necessary, or when they can be safely omitted, or removed. 147 An interim meeting went through the 24 cases defined here to discover 148 if there were any shortcuts, and this document is the result of that 149 discussion. This document clarify what is correct and incorrect 150 behaviour. 152 The related document A Routing Header Dispatch for 6LoWPAN (6LoRH) 153 [I-D.ietf-roll-routing-dispatch] defines a method to compress RPL 154 Option information and Routing Header type 3 [RFC6554], an efficient 155 IP-in-IP technique, and use cases proposed for the 156 [Second6TischPlugtest] involving 6loRH. 158 2. Terminology and Requirements Language 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 164 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 165 RPL, RPL Domain and ROLL. 167 RPL-node: It is device which implements RPL, thus we can say that the 168 device is RPL-capable or RPL-aware. Please note that the device can 169 be found inside the LLN or outside LLN. In this document a RPL-node 170 which is a leaf of a DODAG is called RPL-aware-leaf. 172 RPL-not-capable: It is device which do not implement RPL, thus we can 173 say that the device is not-RPL-aware. Please note that the device 174 can be found inside the LLN. In this document a not-RPL-aware node 175 which is a leaf of a DODAG is called not-RPL-aware-leaf. 177 pledge: a new device which seeks admission to a network. (from 178 [I-D.ietf-anima-bootstrapping-keyinfra]) 180 Join Registrar and Coordinator (JRC): a device which brings new nodes 181 (pledges) into a network. (from 182 [I-D.ietf-anima-bootstrapping-keyinfra]) 184 Flag day: A "flag day" is a procedure in which the network, or a part 185 of it, is changed during a planned outage, or suddenly, causing an 186 outage while the network recovers [RFC4192] 188 2.1. hop-by-hop IPv6-in-IPv6 headers 190 The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header 191 that originates from a node to an adjacent node, using the addresses 192 (usually the GUA or ULA, but could use the link-local addresses) of 193 each node. If the packet must traverse multiple hops, then it must 194 be decapsulated at each hop, and then re-encapsulated again in a 195 similar fashion. 197 3. Updates to RFC6553 and RFC 6550 199 3.1. Updates to RFC 6553 201 [RFC6553] states as showed below, that in the Option Type field of 202 the RPL Option header, the two high order bits MUST be set to '01' 203 and the third bit is equal to '1'. The first two bits indicate that 204 the IPv6 node MUST discard the packet if it doesn't recognize the 205 option type, and the third bit indicates that the Option Data may 206 change en route. The remaining bits serve as the option type. 208 Hex Value Binary Value 209 act chg rest Description Reference 210 --------- --- --- ------- ----------------- ---------- 211 0x63 01 1 00011 RPL Option [RFC6553] 213 Figure 1: Option Type in RPL Option. 215 Recent changes in [I-D.ietf-6man-rfc2460bis], state: "it is now 216 expected that nodes along a packet's delivery path only examine and 217 process the Hop-by-Hop Options header if explicitly configured to do 218 so". Processing of the Hop-by-Hop Options header (by IPv6 219 intermediate nodes) is now optional, but if they are configured to 220 process the header, and if such nodes encounter an option with the 221 first two bits set to 01, they will drop the packet (if they conform 222 [I-D.ietf-6man-rfc2460bis]). The hosts should do the same, 223 irrespective of the configuration. 225 Based on That, if an IPv6 (intermediate) node (RPL-not-capable) 226 receives a packet with an RPL Option, it should ignore the HBH RPL 227 option (skip over this option and continue processing the header). 229 Thus, this document updates the Option Type field to: the two high 230 order bits MUST be set to '00' and the third bit is equal to '1'. 231 The first two bits indicate that the IPv6 node MUST skip over this 232 option and continue processing the header 233 (Section 4.2.[I-D.ietf-6man-rfc2460bis] ) if it doesn't recognize the 234 option type, and the third bit continues to be set to indicate that 235 the Option Data may change en route. The remaining bits serve as the 236 option type and remain as 0x3. This ensures that a packet that 237 leaves the RPL domain of an LLN (or that leaves the LLN entirely) 238 will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop 239 option known as RPI. This is an update to [RFC6553]. 241 Hex Value Binary Value 242 act chg rest Description Reference 243 --------- --- --- ------- ----------------- ---------- 244 0x23 00 1 00011 RPL Option [RFCXXXX] 246 Figure 2: Proposed change to the Option Type in RPL Option. 248 This change creates a flag day for existing networks which are 249 currently using 0x63 as the RPI value. A move to 0x23 will not be 250 understood by those networks. It is suggested that implementations 251 accept both 0x63 and 0x23 when processing. When forwarding packets, 252 implementations SHOULD use the same value as it was received. When 253 originating new packets, implementations SHOULD have an option to 254 determine which value to originate with, this option is controlled by 255 the DIO option described below. 257 A network which is switching from straight 6lowpan compression 258 mechanism to those described in [I-D.ietf-roll-routing-dispatch] will 259 experience a flag day in the data compression anyway, and if possible 260 this change can be deployed at the same time. 262 3.2. Updates to RFC 6550 264 In order to avoid a flag day caused by lack of interoperation between 265 new RPI (0x23) and old RPI (0x63) nodes, the new nodes need to be 266 told that there are old RPI nodes present. This can be done via a 267 new DIO Option which will propogate through the network. Failure to 268 receive this flag will cause dual mode nodes to originate traffic 269 with the old-RPI (0x63) value. 271 DIO Option: 0x05 RPI 0x23 enable MCRXXX 273 Flags: 8-bit unused field reserved for flags. The field MUST be 274 initialized to zero by the sender and MUST be ignored by the 275 receiver. 277 We propose to use a bit flag as follows: 279 +----+----+----+----+----+----+----+----+ 280 | | | | | | | | | 281 | | | | | | | | FR | 282 | | | | | | | | | 283 +----+----+----+----+----+----+----+----+ 285 Figure 3: A DIO Flag to indicate the RPI-flag-day. 287 FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option 288 field is set to "00", values of 0 indicates that RPL Option field is 289 set to "01" 291 4. Sample/reference topology 293 A RPL network in general is composed of a 6LBR (6LoWPAN Border 294 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 295 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 296 (Destination Oriented Directed Acyclic Graph). 298 RPL defines the RPL Control messages (control plane), a new ICMPv6 299 [RFC4443] message with Type 155. DIS (DODAG Information 300 Solicitation), DIO (DODAG Information Object) and DAO (Destination 301 Advertisement Object) messages are all RPL Control messages but with 302 different Code values. A RPL Stack is showed in Figure 1. 304 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 305 it is fully stateful or an in non-storing (RPL-NSM), it is fully 306 source routed. A RPL Instance is either fully storing or fully non- 307 storing, i.e. a RPL Instance with a combination of storing and non- 308 storing nodes is not supported with the current specifications at the 309 time of writing this document. 311 +--------------+ 312 | Upper Layers | 313 | | 314 +--------------+ 315 | RPL | 316 | | 317 +--------------+ 318 | ICMPv6 | 319 | | 320 +--------------+ 321 | IPv6 | 322 | | 323 +--------------+ 324 | 6LoWPAN | 325 | | 326 +--------------+ 327 | PHY-MAC | 328 | | 329 +--------------+ 331 Figure 4: RPL Stack. 333 +------------+ 334 | INTERNET ----------+ 335 | | | 336 +------------+ | 337 | 338 | 339 | 340 A | 341 +-------+ 342 |6LBR | 343 +-----------|(root) |-------+ 344 | +-------+ | 345 | | 346 | | 347 | | 348 | | 349 | B |C 350 +---|---+ +---|---+ 351 | 6LR | | 6LR | 352 +-------->| |--+ +--- ---+ 353 | +-------+ | | +-------+ | 354 | | | | 355 | | | | 356 | | | | 357 | | | | 358 | D | E | | 359 +-|-----+ +---|---+ | | 360 | 6LR | | 6LR | | | 361 | | +------ | | | 362 +---|---+ | +---|---+ | | 363 | | | | | 364 | | +--+ | | 365 | | | | | 366 | | | | | 367 | | | I | J | 368 F | | G | H | | 369 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 370 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 371 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 372 +-------+ +-------+ +------+ +-------+ +-------+ 374 Figure 5: A reference RPL Topology. 376 Figure 2 shows the reference RPL Topology for this document. The 377 letters above the nodes are there so that they may be referenced in 378 subsequent sections. In the figure, a 6LR is a router. A 6LN can be 379 a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked 380 as (F and I) are RPL hosts that does not have forwarding capability. 381 The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL 382 aware leaf" (G and J) are devices which do not speak RPL at all (not- 383 RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and 384 efficient-ND only to participate in the network [RFC6775]. In the 385 document these leafs (G and J) are often named IPv6 node. The 6LBR 386 in the figure is the root of the Global DODAG. 388 5. Use cases 390 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 391 encapsulation is going to be analyzed for a number of representative 392 traffic flows. 394 This document assumes that the LLN is using the no-drop RPI option 395 (0x23). 397 The uses cases describe the communication between RPL-aware-nodes, 398 with the root (6LBR), and with Internet. This document also describe 399 the communication between nodes acting as leaf that does not 400 understand RPL and they are part of hte LLN. We name these nodes as 401 not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to 402 root) We describe also how is the communication inside of the LLN 403 when it has the final destination addressed outside of the LLN e.g. 404 with destination to Internet. (e.g. section 5.7- Flow from not-RPL- 405 aware-leaf to Internet) 407 The uses cases comprise as follow: 409 Interaction between Leaf and Root: 411 RPL-aware-leaf to root 413 root to RPL-aware-leaf 415 not-RPL-aware-leaf to root 417 root to not-RPL-aware-leaf 419 Interaction between Leaf and Internet: 421 RPL-aware-leaf to Internet 423 Internet to RPL-aware-leaf 425 not-RPL-aware-leaf to Internet 426 Internet to not-RPL-aware-leaf 428 Interaction between Leafs: 430 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 432 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 434 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 436 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 438 This document assumes the rule that a Header cannot be inserted or 439 removed on the fly inside an IPv6 packet that is being routed. This 440 is a fundamental precept of the IPv6 architecture as outlined in 441 [RFC2460]. Extensions may not be added or removed except by the 442 sender or the receiver. 444 But, options in the Hop-by-Hop Option Header whose option type has 445 the first two bits set to '00' MUST ignored when received by a host 446 or router that does not understand that option ( Section 4.2 447 [I-D.ietf-6man-rfc2460bis]). 449 This means that when the no-drop RPI option code 0x23 is used, a 450 packet that leaves the RPL domain of an LLN (or that leaves the LLN 451 entirely) will not be discarded when it contains the [RFC6553] RPL 452 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option MAY 453 be left in place even if the end host does not understand it. 455 NOTE: There is some possible security risk when the RPI information 456 is released to the Internet. At this point this is a theoretical 457 situation. It is clear that the RPI option would waste some network 458 bandwidth when it escapes. 460 An intermediate router that needs to add an extension header (SHR3 or 461 RPI Option) must encapsulate the packet in an (additional) outer IP 462 header. The new header can be placed is placed after this new outer 463 IP header. 465 A corollory is that an SHR3 or RPI Option can only be removed by an 466 intermediate router if it is placed in an encapsulating IPv6 Header, 467 which is addressed to the intermediate router. When it does so, the 468 whole encapsulating header must be removed. (A replacement may be 469 added). This sometimes can result in outer IP headers being 470 addressed to the next hop router using link-local addresses. 472 Both RPI and RH3 headers may be modified in very specific ways by 473 routers on the path of the packet without the need to add to remove 474 an encapsulating header. Both headers were designed with this 475 modification in mind, and both the RPL RH and the RPL option are 476 marked mutable but recoverable: so an IPsec AH security header can be 477 applied across these headers, but it can not secure the values which 478 mutate. 480 RPI should be present in every single RPL data packet. There is one 481 exception in non-storing mode: when a packet is going down from the 482 root. In a downward non-storing mode, the entire route is written, 483 so there can be no loops by construction, nor any confusion about 484 which forwarding table to use (as the root has already made all 485 routing decisions). There still may be cases (such as in 6tisch) 486 where the instanceID portion of the RPI header may still be needed to 487 pick an appropriate priority or channel at each hop. 489 In the tables present in this document, the term "RPL aware leaf" is 490 has been shortened to "Raf", and "not-RPL aware leaf" has been 491 shortened to "~Raf" to make the table fit in available space. 493 The earlier examples are more extensive to make sure that the process 494 is clear, while later examples are more concise. 496 6. Storing mode 498 In storing mode (fully stateful), the sender can determine if the 499 destination is inside the LLN by looking if the destination address 500 is matched by the DIO's PIO option. 502 The following table summarizes what headers are needed in the 503 following scenarios, and indicates when the IP-in-IP header must be 504 inserted on a hop-by-hop basis, and when it can target the 505 destination node directly. There are these possible situations: hop- 506 by-hop necessary (indicated by "hop"), or destination address 507 possible (indicated by "dst"). In all cases hop by hop can be used. 508 In cases where no IP-in-IP header is needed, the column is left 509 blank. 511 In all cases the RPI headers are needed, since it identifies 512 inconsistencies (loops) in the routing topology. In all cases the 513 RH3 is not need because we do not indicate the route in storing mode. 515 The leaf can be a router 6LR or a host, both indicated as 6LN 516 (Figure 2). 518 +---------------------+--------------+----------+--------------+ 519 | Interaction between | Use Case | IP-in-IP | IP-in-IP dst | 520 +---------------------+--------------+----------+--------------+ 521 | | Raf to root | No | -- | 522 + +--------------+----------+--------------+ 523 | Leaf - Root | root to Raf | No | -- | 524 + +--------------+----------+--------------+ 525 | | root to ~Raf | No | -- | 526 + +--------------+----------+--------------+ 527 | | ~Raf to root | Yes | root | 528 +---------------------+--------------+----------+--------------+ 529 | | Raf to Int | No | -- | 530 + +--------------+----------+--------------+ 531 | Leaf - Internet | Int to Raf | Yes | Raf | 532 + +--------------+----------+--------------+ 533 | | ~Raf to Int | Yes | root | 534 + +--------------+----------+--------------+ 535 | | Int to ~Raf | Yes | hop | 536 +---------------------+--------------+----------+--------------+ 537 | | Raf to Raf | No | -- | 538 + +--------------+----------+--------------+ 539 | | Raf to ~Raf | No | -- | 540 + Leaf - Leaf +--------------+----------+--------------+ 541 | | ~Raf to Raf | Yes | dst | 542 + +--------------+----------+--------------+ 543 | | ~Raf to ~Raf | Yes | hop | 544 +---------------------+--------------+----------+--------------+ 546 Figure 6: IP-in-IP encapsulation in Storing mode. 548 6.1. Storing Mode: Interaction between Leaf and Root 550 In this section we are going to describe the communication flow in 551 storing mode (SM) between, 553 RPL-aware-leaf to root 555 root to RPL-aware-leaf 557 not-RPL-aware-leaf to root 559 root to not-RPL-aware-leaf 561 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 563 In storing mode, RFC 6553 (RPI) is used to send RPL Information 564 instanceID and rank information. 566 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does 567 not generally issue DIO messages; a leaf node accepts DIO messages 568 from upstream. (When the inconsistency in routing occurs, a leaf 569 node will generate a DIO with an infinite rank, to fix it). It may 570 issue DAO and DIS messages though it generally ignores DAO and DIS 571 messages. 573 In this case the flow comprises: 575 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 577 For example, the communication flow would be: Node F --> Node E --> 578 Node B --> Node A root(6LBR) 580 6LR_i (Node E and Node B) are the intermediate routers from source to 581 destination. In this case, "1 <= i >= n", n is the number of routers 582 (6LR) that the packet go through from source (6LN) to destination 583 (6LBR). 585 As it was mentioned In this document 6LRs, 6LBR are always full- 586 fledge RPL routers. 588 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 589 (Node E) which decrements the rank in RPI and sends the packet up. 590 When the packet arrives at 6LBR (Node A), the RPI is removed and the 591 packet is processed. 593 No IP-in-IP header is required. 595 The RPI header can be removed by the 6LBR because the packet is 596 addressed to the 6LBR. The 6LN must know that it is communicating 597 with the 6LBR to make use of this scenario. The 6LN can know the 598 address of the 6LBR because it knows the address of the root via the 599 DODAGID in the DIO messages. 601 +-------------------+-----+-------+------+ 602 | Header | 6LN | 6LR_i | 6LBR | 603 +-------------------+-----+-------+------+ 604 | Inserted headers | RPI | -- | -- | 605 | Removed headers | -- | -- | RPI | 606 | Re-added headers | -- | -- | -- | 607 | Modified headers | -- | RPI | -- | 608 | Untouched headers | -- | -- | -- | 609 +-------------------+-----+-------+------+ 611 Storing: Summary of the use of headers from RPL-aware-leaf to root 613 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 615 In this case the flow comprises: 617 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 619 For example, the communication flow would be: Node A root(6LBR) --> 620 Node B --> Node D --> Node F 622 6LR_i are the intermediate routers from source to destination. In 623 this case, "1 <= i >= n", n is the number of routers (6LR) that the 624 packet go through from source (6LBR) to destination (6LN). 626 In this case the 6LBR inserts RPI header and sends the packet down, 627 the 6LR is going to increment the rank in RPI (examines instanceID 628 for multiple tables), the packet is processed in 6LN and RPI removed. 630 No IP-in-IP header is required. 632 +-------------------+------+-------+------+ 633 | Header | 6LBR | 6LR_i | 6LN | 634 +-------------------+------+-------+------+ 635 | Inserted headers | RPI | -- | -- | 636 | Removed headers | -- | -- | RPI | 637 | Re-added headers | -- | -- | -- | 638 | Modified headers | -- | RPI | -- | 639 | Untouched headers | -- | -- | -- | 640 +-------------------+------+-------+------+ 642 Storing: Summary of the use of headers from root to RPL-aware-leaf 644 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 646 In this case the flow comprises: 648 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 649 For example, the communication flow would be: Node A root(6LBR) --> 650 Node B --> Node E --> Node G 652 6LR_i are the intermediate routers from source to destination. In 653 this case, "1 <= i >= n", n is the number of routers (6LR) that the 654 packet go through from source (6LBR) to destination (IPv6). 656 As the RPI extension can be ignored by the not-RPL-aware leaf, this 657 situation is identical to the previous scenario. 659 +-------------------+------+-------+----------------+ 660 | Header | 6LBR | 6LR_i | IPv6 | 661 +-------------------+------+-------+----------------+ 662 | Inserted headers | RPI | -- | -- | 663 | Removed headers | -- | -- | -- | 664 | Re-added headers | -- | -- | -- | 665 | Modified headers | -- | RPI | -- | 666 | Untouched headers | -- | -- | RPI (Ignored) | 667 +-------------------+------+-------+----------------+ 669 Storing: Summary of the use of headers from root to not-RPL-aware- 670 leaf 672 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 674 In this case the flow comprises: 676 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 678 For example, the communication flow would be: Node G --> Node E --> 679 Node B --> Node A root(6LBR) 681 6LR_i are the intermediate routers from source to destination. In 682 this case, "1 < i >= n", n is the number of routers (6LR) that the 683 packet go through from source (IPv6) to destination (6LBR). For 684 example, 6LR_1 (i=1) is the router that receives the packets from the 685 IPv6 node (Node G). 687 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 688 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 689 header. The IPv6-in-IPv6 header can be addressed to the next hop 690 (Node B), or to the root (Node A). The root removes the header and 691 processes the packet. 693 +------------+------+---------------+---------------+---------------+ 694 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 695 +------------+------+---------------+---------------+---------------+ 696 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 697 | headers | | | | | 698 | Removed | -- | -- | -- | IP-in-IP(RPI) | 699 | headers | | | | | 700 | Re-added | -- | -- | -- | -- | 701 | headers | | | | | 702 | Modified | -- | -- | IP-in-IP(RPI) | -- | 703 | headers | | | | | 704 | Untouched | -- | -- | -- | -- | 705 | headers | | | | | 706 +------------+------+---------------+---------------+---------------+ 708 Storing: Summary of the use of headers from not-RPL-aware-leaf to 709 root 711 6.2. Storing Mode: Interaction between Leaf and Internet 713 In this section we are going to describe the communication flow in 714 storing mode (SM) between, 716 RPL-aware-leaf to Internet 718 Internet to RPL-aware-leaf 720 not-RPL-aware-leaf to Internet 722 Internet to not-RPL-aware-leaf 724 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 726 RPL information from RFC 6553 MAY go out to Internet as it will be 727 ignored by nodes which have not been configured to be RPI aware. 729 In this case the flow comprises: 731 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 733 For example, the communication flow could be: Node F --> Node D --> 734 Node B --> Node A root(6LBR) --> Internet 736 6LR_i are the intermediate routers from source to destination. In 737 this case, "1 <= i >= n", n is the number of routers (6LR) that the 738 packet go through from source (6LN) to 6LBR. 740 No IP-in-IP header is required. 742 Note: In this use case we use a node as leaf, but this use case can 743 be also applicable to any RPL-node type (e.g. 6LR) 745 +-------------------+------+-------+------+----------------+ 746 | Header | 6LN | 6LR_i | 6LBR | Internet | 747 +-------------------+------+-------+------+----------------+ 748 | Inserted headers | RPI | -- | -- | -- | 749 | Removed headers | -- | -- | -- | -- | 750 | Re-added headers | -- | -- | -- | -- | 751 | Modified headers | -- | RPI | -- | -- | 752 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 753 +-------------------+------+-------+------+----------------+ 755 Storing: Summary of the use of headers from RPL-aware-leaf to 756 Internet 758 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 760 In this case the flow comprises: 762 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 764 For example, the communication flow could be: Internet --> Node A 765 root(6LBR) --> Node B --> Node D --> Node F 767 6LR_i are the intermediate routers from source to destination. In 768 this case, "1 <= i >= n", n is the number of routers (6LR) that the 769 packet go through from 6LBR to destination(6LN). 771 When the packet arrives from Internet to 6LBR the RPI header is added 772 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 773 rank in the RPI. When the packet arrives at 6LN the RPI header is 774 removed and the packet processed. 776 +----------+---------+--------------+---------------+---------------+ 777 | Header | Interne | 6LBR | 6LR_i | 6LN | 778 | | t | | | | 779 +----------+---------+--------------+---------------+---------------+ 780 | Inserted | -- | IP-in- | -- | -- | 781 | headers | | IP(RPI) | | | 782 | Removed | -- | -- | -- | IP-in-IP(RPI) | 783 | headers | | | | | 784 | Re-added | -- | -- | -- | -- | 785 | headers | | | | | 786 | Modified | -- | -- | IP-in-IP(RPI) | -- | 787 | headers | | | | | 788 | Untouche | -- | -- | -- | -- | 789 | d | | | | | 790 | headers | | | | | 791 +----------+---------+--------------+---------------+---------------+ 793 Storing: Summary of the use of headers from Internet to RPL-aware- 794 leaf 796 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 798 In this case the flow comprises: 800 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 801 Internet 803 For example, the communication flow could be: Node G --> Node E --> 804 Node B --> Node A root(6LBR) --> Internet 806 6LR_i are the intermediate routers from source to destination. In 807 this case, "1 < i >= n", n is the number of routers (6LR) that the 808 packet go through from source(IPv6) to 6LBR. 810 The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed 811 either to the root, or hop-by-hop such that the root can remove the 812 RPI header before passing upwards. 814 The originating node will ideally leave the IPv6 flow label as zero 815 so that the packet can be better compressed through the LLN. The 816 6LBR will set the flow label of the packet to a non-zero value when 817 sending to the Internet. 819 +---------+-----+-------------+-------------+-------------+---------+ 820 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 821 | | 6 | | [i=2,..,n]_ | | t | 822 +---------+-----+-------------+-------------+-------------+---------+ 823 | Inserte | -- | IP-in- | -- | -- | -- | 824 | d | | IP(RPI) | | | | 825 | headers | | | | | | 826 | Removed | -- | -- | -- | IP-in- | -- | 827 | headers | | | | IP(RPI) | | 828 | Re- | -- | -- | -- | -- | -- | 829 | added | | | | | | 830 | headers | | | | | | 831 | Modifie | -- | -- | IP-in- | -- | -- | 832 | d | | | IP(RPI) | | | 833 | headers | | | | | | 834 | Untouch | -- | -- | -- | -- | -- | 835 | ed | | | | | | 836 | headers | | | | | | 837 +---------+-----+-------------+-------------+-------------+---------+ 839 Storing: Summary of the use of headers from not-RPL-aware-leaf to 840 Internet 842 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf 844 In this case the flow comprises: 846 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 848 For example, the communication flow could be: Internet --> Node A 849 root(6LBR) --> Node B --> Node E --> Node G 851 6LR_i are the intermediate routers from source to destination. In 852 this case, "1 < i >= n", n is the number of routers (6LR) that the 853 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i 854 updates the rank in the RPI. 856 The 6LBR will have to add an RPI header within an IP-in-IP header. 857 The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the 858 RPI inside. 860 The 6LBR MAY set the flow label on the inner IP-in-IP header to zero 861 in order to aid in compression. 863 +-----------+----------+---------------+---------------+------------+ 864 | Header | Internet | 6LBR | 6LR_i | IPv6 | 865 +-----------+----------+---------------+---------------+------------+ 866 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 867 | headers | | | | | 868 | Removed | -- | -- | -- | -- | 869 | headers | | | | | 870 | Re-added | -- | -- | -- | -- | 871 | headers | | | | | 872 | Modified | -- | -- | IP-in-IP(RPI) | -- | 873 | headers | | | | | 874 | Untouched | -- | -- | -- | RPI | 875 | headers | | | | (Ignored) | 876 +-----------+----------+---------------+---------------+------------+ 878 Storing: Summary of the use of headers from Internet to non-RPL- 879 aware-leaf 881 6.3. Storing Mode: Interaction between Leaf and Leaf 883 In this section we are going to describe the communication flow in 884 storing mode (SM) between, 886 RPL-aware-leaf to RPL-aware-leaf 888 RPL-aware-leaf to not-RPL-aware-leaf 890 not-RPL-aware-leaf to RPL-aware-leaf 892 not-RPL-aware-leaf to not-RPL-aware-leaf 894 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 896 In [RFC6550] RPL allows a simple one-hop optimization for both 897 storing and non-storing networks. A node may send a packet destined 898 to a one-hop neighbor directly to that node. Section 9 in [RFC6550]. 900 In this case the flow comprises: 902 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 904 For example, the communication flow could be: Node F --> Node D --> 905 Node B --> Node E --> Node H 907 6LR_ia (Node D) are the intermediate routers from source to the 908 common parent (6LR_x) (Node B) In this case, "1 <= ia >= n", n is the 909 number of routers (6LR) that the packet go through from 6LN (Node F) 910 to the common parent (6LR_x). 912 6LR_id (Node E) are the intermediate routers from the common parent 913 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 914 >= m", m is the number of routers (6LR) that the packet go through 915 from the common parent (6LR_x) to destination 6LN. 917 This case is assumed in the same RPL Domain. In the common parent 918 (Node B), the direction of RPI is changed (from increasing to 919 decreasing the rank). 921 While the 6LR nodes will update the RPI, no node needs to add or 922 remove the RPI, so no IP-in-IP headers are necessary. This may be 923 done regardless of where the destination is, as the included RPI will 924 be ignored by the receiver. 926 +---------------+--------+--------+---------------+--------+--------+ 927 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 928 | | src | | parent) | | dst | 929 +---------------+--------+--------+---------------+--------+--------+ 930 | Inserted | RPI | -- | -- | -- | -- | 931 | headers | | | | | | 932 | Removed | -- | -- | -- | -- | RPI | 933 | headers | | | | | | 934 | Re-added | -- | -- | -- | -- | -- | 935 | headers | | | | | | 936 | Modified | -- | RPI | RPI | RPI | -- | 937 | headers | | | | | | 938 | Untouched | -- | -- | -- | -- | -- | 939 | headers | | | | | | 940 +---------------+--------+--------+---------------+--------+--------+ 942 Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 943 aware-leaf 945 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 947 In this case the flow comprises: 949 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 950 6LN (IPv6) 952 For example, the communication flow could be: Node F --> Node D --> 953 Node B --> Node E --> Node G 955 6LR_ia are the intermediate routers from source (6LN) to the common 956 parent (6LR_x) In this case, "1 <= ia >= n", n is the number of 957 routers (6LR) that the packet go through from 6LN to the common 958 parent (6LR_x). 960 6LR_id (Node E) are the intermediate routers from the common parent 961 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 962 In this case, "1 <= id >= m", m is the number of routers (6LR) that 963 the packet go through from the common parent (6LR_x) to destination 964 6LN. 966 This situation is identical to the previous situation Section 6.3.1 968 +-----------+------+--------+---------------+--------+--------------+ 969 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 970 | | src | | parent) | | | 971 +-----------+------+--------+---------------+--------+--------------+ 972 | Inserted | RPI | -- | -- | -- | -- | 973 | headers | | | | | | 974 | Removed | -- | -- | -- | -- | RPI | 975 | headers | | | | | | 976 | Re-added | -- | -- | -- | -- | -- | 977 | headers | | | | | | 978 | Modified | -- | RPI | RPI | RPI | -- | 979 | headers | | | | | | 980 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 981 | headers | | | | | | 982 +-----------+------+--------+---------------+--------+--------------+ 984 Storing: Summary of the use of headers for RPL-aware-leaf to non-RPL- 985 aware-leaf 987 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 989 In this case the flow comprises: 991 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 992 6LR_id --> 6LN 994 For example, the communication flow could be: Node G --> Node E --> 995 Node B --> Node D --> Node F 997 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 998 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B) In 999 this case, "1 <= ia >= n", n is the number of routers (6LR) that the 1000 packet go through from source to the common parent. 1002 6LR_id (Node D) are the intermediate routers from the common parent 1003 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1004 >= m", m is the number of routers (6LR) that the packet go through 1005 from the common parent (6LR_x) to destination 6LN. 1007 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1008 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1009 header. The IP-in-IP header is addressed to the destination 6LN 1010 (Node F). 1012 +--------+------+------------+------------+------------+------------+ 1013 | Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN | 1014 | | | | parent | | | 1015 | | | | (6LRx) | | | 1016 +--------+------+------------+------------+------------+------------+ 1017 | Insert | -- | IP-in- | -- | -- | -- | 1018 | ed hea | | IP(RPI) | | | | 1019 | ders | | | | | | 1020 | Remove | -- | -- | -- | -- | IP-in- | 1021 | d head | | | | | IP(RPI) | 1022 | ers | | | | | | 1023 | Re- | -- | -- | -- | -- | -- | 1024 | added | | | | | | 1025 | header | | | | | | 1026 | s | | | | | | 1027 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1028 | ed hea | | | IP(RPI) | IP(RPI) | | 1029 | ders | | | | | | 1030 | Untouc | -- | -- | -- | -- | -- | 1031 | hed he | | | | | | 1032 | aders | | | | | | 1033 +--------+------+------------+------------+------------+------------+ 1035 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1036 RPL-aware-leaf 1038 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1039 leaf 1041 In this case the flow comprises: 1043 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> root (6LBR) --> 1044 6LR_id --> not-RPL-aware 6LN (IPv6 dst) 1046 For example, the communication flow could be: Node G --> Node E --> 1047 Node B --> Node A (root) --> Node C --> Node J 1049 Internet 6LR_ia (Node E and Node B) are the intermediate routers from 1050 source (not-RPL-aware 6LN (IPv6 src))(Node G) to the root (6LBR) 1051 (Node A) In this case, "1 < ia >= n", n is the number of routers 1052 (6LR) that the packet go through from IPv6 src to the root. 1054 6LR_id (C) are the intermediate routers from the root (Node A) to 1055 destination (IPv6 dst) (Node J). In this case, "1 <= id >= m", m is 1056 the number of routers (6LR) that the packet go through from the root 1057 to destination (IPv6 dst). 1059 This flow is identical to Section 6.3.3 1061 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1062 G) and inserts the RPI header (RPIa) encapsulated in IPv6-in-IPv6 1063 header. The IPv6-in-IPv6 header is addressed to the 6LBR. The 6LBR 1064 remove the IPv6-in-IPv6 header and insert another one (RPIb) with 1065 destination to 6LR_m (Node C) node. 1067 One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is 1068 that now all the packets will go through the 6LBR, even though there 1069 exists a shorter P2P path to the destination 6LN in storing mode. 1070 One possible solution is given by the work in 1071 [I-D.ietf-roll-dao-projection]. Once we have route projection, the 1072 root can find that this traffic deserves optimization (based on 1073 volume and path length, or additional knowledge on that particular 1074 flow) and project a DAO into 6LR_1. 1076 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1077 | Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv | 1078 | r | 6 | | | | | 6 | 1079 | | src | | | | | dst | 1080 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1081 | Inser | -- | IP-in- | -- | IP-in- | -- | -- | 1082 | ted h | | IP(RPI_a) | | IP(RPI_b) | | | 1083 | eader | | | | | | | 1084 | s | | | | | | | 1085 | Remov | -- | -- | -- | -- | -- | -- | 1086 | ed he | | | | | | | 1087 | aders | | | | | | | 1088 | Re- | -- | -- | -- | -- | IP-in- | -- | 1089 | added | | | | | IP(RPI_b) | | 1090 | heade | | | | | | | 1091 | rs | | | | | | | 1092 | Modif | -- | -- | IP-in- | -- | IP-in- | -- | 1093 | ied h | | | IP(RPI_a) | | IP(RPI_b) | | 1094 | eader | | | | | | | 1095 | s | | | | | | | 1096 | Untou | -- | -- | -- | -- | -- | -- | 1097 | ched | | | | | | | 1098 | heade | | | | | | | 1099 | rs | | | | | | | 1100 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1102 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1103 non-RPL-aware-leaf 1105 7. Non Storing mode 1107 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1108 root) has complete knowledge about the connectivity of all DODAG 1109 nodes, and all traffic flows through the root node. Thus, there is 1110 no need for all nodes to know about the existence of non-RPL aware 1111 nodes. Only the 6LBR needs to change when there are non-RPL aware 1112 nodes. 1114 The following table summarizes what headers are needed in the 1115 following scenarios, and indicates when the RPI, RH3 and IP-in-IP 1116 header must be inserted. There are these possible situations: 1117 destination address possible (indicated by "dst"), to a 6LR, to a 6LN 1118 or to the root. In cases where no IP-in-IP header is needed, the 1119 column is left blank. 1121 The leaf can be a router 6LR or a host, both indicated as 6LN 1122 (Figure 3). 1124 +-----------------+--------------+-----+-----+----------+----------+ 1125 | Interaction | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP | 1126 | between | | | | | dst | 1127 +-----------------+--------------+-----+-----+----------+----------+ 1128 | | Raf to root | Yes | No | No | -- | 1129 + +--------------+-----+-----+----------+----------+ 1130 | Leaf - Root | root to Raf | Opt | Yes | No | -- | 1131 + +--------------+-----+-----+----------+----------+ 1132 | | root to ~Raf | No | Yes | Yes | 6LR | 1133 + +--------------+-----+-----+----------+----------+ 1134 | | ~Raf to root | Yes | No | Yes | root | 1135 +-----------------+--------------+-----+-----+----------+----------+ 1136 | | Raf to Int | Yes | No | Yes | root | 1137 + +--------------+-----+-----+----------+----------+ 1138 | Leaf - Internet | Int to Raf | Opt | Yes | Yes | dst | 1139 + +--------------+-----+-----+----------+----------+ 1140 | | ~Raf to Int | Yes | No | Yes | root | 1141 + +--------------+-----+-----+----------+----------+ 1142 | | Int to ~Raf | Opt | Yes | Yes | 6LR | 1143 +-----------------+--------------+-----+-----+----------+----------+ 1144 | | Raf to Raf | Yes | Yes | Yes | root/dst | 1145 + +--------------+-----+-----+----------+----------+ 1146 | | Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1147 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1148 | | ~Raf to Raf | Yes | Yes | Yes | root/6LN | 1149 + +--------------+-----+-----+----------+----------+ 1150 | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1151 +-----------------+--------------+-----+-----+----------+----------+ 1153 Figure 7: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP 1154 encapsulation. 1156 7.1. Non-Storing Mode: Interaction between Leaf and Root 1158 In this section we are going to describe the communication flow in 1159 Non Storing Mode (Non-SM) between, 1161 RPL-aware-leaf to root 1163 root to RPL-aware-leaf 1165 not-RPL-aware-leaf to root 1167 root to not-RPL-aware-leaf 1169 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1171 In non-storing mode the leaf node uses default routing to send 1172 traffic to the root. The RPI header must be included to avoid/detect 1173 loops. 1175 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1177 For example, the communication flow could be: Node F --> Node D --> 1178 Node B --> Node A (root) 1180 6LR_i are the intermediate routers from source to destination. In 1181 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1182 packet go through from source (6LN) to destination (6LBR). 1184 This situation is the same case as storing mode. 1186 +-------------------+-----+-------+------+ 1187 | Header | 6LN | 6LR_i | 6LBR | 1188 +-------------------+-----+-------+------+ 1189 | Inserted headers | RPI | -- | -- | 1190 | Removed headers | -- | -- | RPI | 1191 | Re-added headers | -- | -- | -- | 1192 | Modified headers | -- | RPI | -- | 1193 | Untouched headers | -- | -- | -- | 1194 +-------------------+-----+-------+------+ 1196 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1197 root 1199 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf 1201 In this case the flow comprises: 1203 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1205 For example, the communication flow could be: Node A (root) --> Node 1206 B --> Node D --> Node F 1208 6LR_i are the intermediate routers from source to destination. In 1209 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1210 packet go through from source (6LBR) to destination (6LN). 1212 The 6LBR will insert an RH3, and may optionally insert an RPI header. 1213 No IP-in-IP header is necessary as the traffic originates with an RPL 1214 aware node, the 6LBR. The destination is known to RPL-aware because, 1215 the root knows the whole topology in non-storing mode. 1217 +-------------------+-----------------+-------+----------+ 1218 | Header | 6LBR | 6LR_i | 6LN | 1219 +-------------------+-----------------+-------+----------+ 1220 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1221 | Removed headers | -- | -- | RH3,RPI | 1222 | Re-added headers | -- | -- | -- | 1223 | Modified headers | -- | RH3 | -- | 1224 | Untouched headers | -- | -- | -- | 1225 +-------------------+-----------------+-------+----------+ 1227 Non Storing: Summary of the use of headers from root to RPL-aware- 1228 leaf 1230 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1232 In this case the flow comprises: 1234 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1236 For example, the communication flow could be: Node A (root) --> Node 1237 B --> Node E --> Node G 1239 6LR_i are the intermediate routers from source to destination. In 1240 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1241 packet go through from source (6LBR) to destination (IPv6). 1243 In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR_1 1244 and so on) and it is fully consumed in the last 6LR (6LR_n), but left 1245 there. If RPI is left present, the IPv6 node which does not 1246 understand it will ignore it (following 2460bis), thus encapsulation 1247 is not necesary. Due the complete knowledge of the topology at the 1248 root, the 6LBR is able to address the IP-in-IP header to the last 1249 6LR. 1251 +---------------+-------------+---------------+--------------+------+ 1252 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1253 +---------------+-------------+---------------+--------------+------+ 1254 | Inserted | (opt: RPI), | -- | -- | -- | 1255 | headers | RH3 | | | | 1256 | Removed | -- | RH3 | -- | -- | 1257 | headers | | | | | 1258 | Re-added | -- | -- | -- | -- | 1259 | headers | | | | | 1260 | Modified | -- | (opt: RPI), | (opt: RPI), | -- | 1261 | headers | | RH3 | RH3 | | 1262 | Untouched | -- | -- | -- | RPI | 1263 | headers | | | | | 1264 +---------------+-------------+---------------+--------------+------+ 1266 Non Storing: Summary of the use of headers from root to not-RPL- 1267 aware-leaf 1269 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1271 In this case the flow comprises: 1273 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1275 For example, the communication flow could be: Node G --> Node E --> 1276 Node B --> Node A (root) 1278 6LR_i are the intermediate routers from source to destination. In 1279 this case, "1 < i >= n", n is the number of routers (6LR) that the 1280 packet go through from source (IPv6) to destination (6LBR). For 1281 example, 6LR_1 (i=1) is the router that receives the packets from the 1282 IPv6 node. 1284 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1285 encapsulated in an IP-in-IP header, and is modified in the followings 1286 6LRs. The RPI and entire packet is consumed by the root. 1288 +------------+------+---------------+---------------+---------------+ 1289 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 1290 +------------+------+---------------+---------------+---------------+ 1291 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 1292 | headers | | | | | 1293 | Removed | -- | -- | -- | IP-in-IP(RPI) | 1294 | headers | | | | | 1295 | Re-added | -- | -- | -- | -- | 1296 | headers | | | | | 1297 | Modified | -- | -- | IP-in-IP(RPI) | -- | 1298 | headers | | | | | 1299 | Untouched | -- | -- | -- | -- | 1300 | headers | | | | | 1301 +------------+------+---------------+---------------+---------------+ 1303 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1304 root 1306 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1308 In this section we are going to describe the communication flow in 1309 Non Storing Mode (Non-SM) between, 1311 RPL-aware-leaf to Internet 1313 Internet to RPL-aware-leaf 1315 not-RPL-aware-leaf to Internet 1317 Internet to not-RPL-aware-leaf 1319 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1321 In this case the flow comprises: 1323 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1325 For example, the communication flow could be: Node F --> Node D --> 1326 Node B --> Node A --> Internet 1328 6LR_i are the intermediate routers from source to destination. In 1329 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1330 packet go through from source (6LN) to 6LBR. 1332 This case is identical to storing-mode case. 1334 The IPv6 flow label should be set to zero to aid in compression, and 1335 the 6LBR will set it to a non-zero value when sending towards the 1336 Internet. 1338 +-------------------+------+-------+------+----------------+ 1339 | Header | 6LN | 6LR_i | 6LBR | Internet | 1340 +-------------------+------+-------+------+----------------+ 1341 | Inserted headers | RPI | -- | -- | -- | 1342 | Removed headers | -- | -- | -- | -- | 1343 | Re-added headers | -- | -- | -- | -- | 1344 | Modified headers | -- | RPI | -- | -- | 1345 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1346 +-------------------+------+-------+------+----------------+ 1348 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1349 Internet 1351 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1353 In this case the flow comprises: 1355 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1357 For example, the communication flow could be: Internet --> Node A 1358 (root) --> Node B --> Node D --> Node F 1360 6LR_i are the intermediate routers from source to destination. In 1361 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1362 packet go through from 6LBR to destination(6LN). 1364 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1365 address of the target node, it can address the IP-in-IP header to 1366 that node. The 6LBR will zero the flow label upon entry in order to 1367 aid compression. 1369 The RPI may be added or not, it is optional. 1371 +--------+-------+----------------+----------------+----------------+ 1372 | Header | Inter | 6LBR | 6LR_i | 6LN | 1373 | | net | | | | 1374 +--------+-------+----------------+----------------+----------------+ 1375 | Insert | -- | IP-in-IP(RH3,o | -- | -- | 1376 | ed hea | | pt:RPI) | | | 1377 | ders | | | | | 1378 | Remove | -- | -- | -- | IP-in-IP(RH3,o | 1379 | d head | | | | pt:RPI) | 1380 | ers | | | | | 1381 | Re- | -- | -- | -- | -- | 1382 | added | | | | | 1383 | header | | | | | 1384 | s | | | | | 1385 | Modifi | -- | -- | IP-in-IP(RH3,o | -- | 1386 | ed hea | | | pt:RPI) | | 1387 | ders | | | | | 1388 | Untouc | -- | -- | -- | -- | 1389 | hed he | | | | | 1390 | aders | | | | | 1391 +--------+-------+----------------+----------------+----------------+ 1393 Non Storing: Summary of the use of headers from Internet to RPL- 1394 aware-leaf 1396 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1398 In this case the flow comprises: 1400 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1401 Internet 1403 For example, the communication flow could be: Node G --> Node E --> 1404 Node B --> Node A --> Internet 1406 6LR_i are the intermediate routers from source to destination. In 1407 this case, "1 < i >= n", n is the number of routers (6LR) that the 1408 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1410 In this case the flow label is recommended to be zero in the IPv6 1411 node. As RPL headers are added in the IPv6 node, the first 6LR 1412 (6LR_1) will add an RPI header inside a new IP-in-IP header. The IP- 1413 in-IP header will be addressed to the root. This case is identical 1414 to the storing-mode case (Section 5.7). 1416 +---------+-----+-------------+-------------+-------------+---------+ 1417 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 1418 | | 6 | | [i=2,..,n]_ | | t | 1419 +---------+-----+-------------+-------------+-------------+---------+ 1420 | Inserte | -- | IP-in- | -- | -- | -- | 1421 | d | | IP(RPI) | | | | 1422 | headers | | | | | | 1423 | Removed | -- | -- | -- | IP-in- | -- | 1424 | headers | | | | IP(RPI) | | 1425 | Re- | -- | -- | -- | -- | -- | 1426 | added | | | | | | 1427 | headers | | | | | | 1428 | Modifie | -- | -- | IP-in- | -- | -- | 1429 | d | | | IP(RPI) | | | 1430 | headers | | | | | | 1431 | Untouch | -- | -- | -- | -- | -- | 1432 | ed | | | | | | 1433 | headers | | | | | | 1434 +---------+-----+-------------+-------------+-------------+---------+ 1436 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1437 Internet 1439 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1441 In this case the flow comprises: 1443 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1445 For example, the communication flow could be: Internet --> Node A 1446 (root) --> Node B --> Node E --> Node G 1448 6LR_i are the intermediate routers from source to destination. In 1449 this case, "1 < i >= n", n is the number of routers (6LR) that the 1450 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1452 The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR 1453 will know the path, and will recognize that the final node is not an 1454 RPL capable node as it will have received the connectivity DAO from 1455 the nearest 6LR. The 6LBR can therefore make the IP-in-IP header 1456 destination be the last 6LR. The 6LBR will set to zero the flow 1457 label upon entry in order to aid compression. 1459 +--------+-------+----------------+------------+-------------+------+ 1460 | Header | Inter | 6LBR | 6LR_1 | 6LR_i(i=2,. | IPv6 | 1461 | | net | | | .,n) | | 1462 +--------+-------+----------------+------------+-------------+------+ 1463 | Insert | -- | IP-in-IP(RH3,o | -- | -- | -- | 1464 | ed hea | | pt:RPI) | | | | 1465 | ders | | | | | | 1466 | Remove | -- | -- | -- | IP-in- | -- | 1467 | d head | | | | IP(RH3, | | 1468 | ers | | | | RPI) | | 1469 | Re- | -- | -- | -- | -- | -- | 1470 | added | | | | | | 1471 | header | | | | | | 1472 | s | | | | | | 1473 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1474 | ed hea | | | IP(RH3, | IP(RH3, | | 1475 | ders | | | RPI) | RPI) | | 1476 | Untouc | -- | -- | -- | -- | RPI | 1477 | hed he | | | | | | 1478 | aders | | | | | | 1479 +--------+-------+----------------+------------+-------------+------+ 1481 NonStoring: Summary of the use of headers from Internet to non-RPL- 1482 aware-leaf 1484 7.3. Non-Storing Mode: Interaction between Leafs 1486 In this section we are going to describe the communication flow in 1487 Non Storing Mode (Non-SM) between, 1489 RPL-aware-leaf to RPL-aware-leaf 1491 RPL-aware-leaf to not-RPL-aware-leaf 1493 not-RPL-aware-leaf to RPL-aware-leaf 1495 not-RPL-aware-leaf to not-RPL-aware-leaf 1497 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1499 In this case the flow comprises: 1501 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1503 For example, the communication flow could be: Node F --> Node D --> 1504 Node B --> Node A (root) --> Node B --> Node E --> Node H 1505 6LR_ia are the intermediate routers from source to the root In this 1506 case, "1 <= ia >= n", n is the number of routers (6LR) that the 1507 packet go through from 6LN to the root. 1509 6LR_id are the intermediate routers from the root to the destination. 1510 In this case, "1 <= ia >= m", m is the number of the intermediate 1511 routers (6LR). 1513 This case involves only nodes in same RPL Domain. The originating 1514 node will add an RPI header to the original packet, and send the 1515 packet upwards. 1517 The originating node SHOULD put the RPI into an IP-in-IP header 1518 addressed to the root, so that the 6LBR can remove that header. If 1519 it does not, then additional resources are wasted on the way down to 1520 carry the useless RPI option. 1522 The 6LBR will need to insert an RH3 header, which requires that it 1523 add an IP-in-IP header. It SHOULD be able to remove the RPI, as it 1524 was contained in an IP-in-IP header addressed to it. Otherwise, 1525 there MAY be an RPI header buried inside the inner IP header, which 1526 should get ignored. 1528 Networks that use the RPL P2P extension [RFC6997] are essentially 1529 non-storing DODAGs and fall into this scenario or scenario 1530 Section 7.1.2, with the originating node acting as 6LBR. 1532 +---------+-------------+------+--------------+-------+-------------+ 1533 | Header | 6LN src | 6LR_ | 6LBR | 6LR_i | 6LN dst | 1534 | | | ia | | d | | 1535 +---------+-------------+------+--------------+-------+-------------+ 1536 | Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- | 1537 | d | IP(RPI1) | | to 6LN, opt | | | 1538 | headers | | | RPI2) | | | 1539 | Removed | -- | -- | IP-in- | -- | IP-in- | 1540 | headers | | | IP(RPI1) | | IP(RH3, opt | 1541 | | | | | | RPI2) | 1542 | Re- | -- | -- | -- | -- | -- | 1543 | added | | | | | | 1544 | headers | | | | | | 1545 | Modifie | -- | RPI1 | -- | RPI2 | -- | 1546 | d | | | | | | 1547 | headers | | | | | | 1548 | Untouch | -- | -- | -- | -- | -- | 1549 | ed | | | | | | 1550 | headers | | | | | | 1551 +---------+-------------+------+--------------+-------+-------------+ 1553 Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 1554 aware-leaf 1556 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1557 leaf 1559 In this case the flow comprises: 1561 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1563 For example, the communication flow could be: Node F --> Node D --> 1564 Node B --> Node A (root) --> Node B --> Node E --> Node G 1566 6LR_ia are the intermediate routers from source to the root In this 1567 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1569 6LR_id are the intermediate routers from the root to the destination. 1570 In this case, "1 <= ia >= m", m is the number of the intermediate 1571 routers (6LR). 1573 As in the previous case, the 6LN will insert an RPI (RPI_1) header 1574 which MUST be in an IP-in-IP header addressed to the root so that the 1575 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a 1576 new IP-in-IP header addressed to the 6LN destination node. The RPI 1577 is optional from 6LBR to 6LR_id (RPI_2). 1579 +--------+-----------+------------+-------------+------------+------+ 1580 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1581 +--------+-----------+------------+-------------+------------+------+ 1582 | Insert | IP-in- | -- | IP-in- | -- | -- | 1583 | ed hea | IP(RPI1) | | IP(RH3, opt | | | 1584 | ders | | | RPI_2) | | | 1585 | Remove | -- | -- | IP-in- | IP-in- | -- | 1586 | d head | | | IP(RPI_1) | IP(RH3, | | 1587 | ers | | | | opt RPI_2) | | 1588 | Re- | -- | -- | -- | -- | -- | 1589 | added | | | | | | 1590 | header | | | | | | 1591 | s | | | | | | 1592 | Modifi | -- | IP-in- | -- | IP-in- | -- | 1593 | ed hea | | IP(RPI_1) | | IP(RH3, | | 1594 | ders | | | | opt RPI_2) | | 1595 | Untouc | -- | -- | -- | -- | opt | 1596 | hed he | | | | | RPI_ | 1597 | aders | | | | | 2 | 1598 +--------+-----------+------------+-------------+------------+------+ 1600 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1601 not-RPL-aware-leaf 1603 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1604 leaf 1606 In this case the flow comprises: 1608 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 1609 6LN 1611 For example, the communication flow could be: Node G --> Node E --> 1612 Node B --> Node A (root) --> Node B --> Node E --> Node H 1614 6LR_ia are the intermediate routers from source to the root In this 1615 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1617 6LR_id are the intermediate routers from the root to the destination. 1618 In this case, "1 <= ia >= m", m is the number of the intermediate 1619 routers (6LR). 1621 This scenario is mostly identical to the previous one. The RPI is 1622 added by the first 6LR (6LR_1) inside an IP-in-IP header addressed to 1623 the root. The 6LBR will remove this RPI, and add it's own IP-in-IP 1624 header containing an RH3 header and optional RPI (RPI_2). 1626 +--------+-----+------------+-------------+------------+------------+ 1627 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN | 1628 | | 6 | | | | | 1629 +--------+-----+------------+-------------+------------+------------+ 1630 | Insert | -- | IP-in- | IP-in- | -- | -- | 1631 | ed hea | | IP(RPI_1) | IP(RH3, opt | | | 1632 | ders | | | RPI_2) | | | 1633 | Remove | -- | -- | IP-in- | -- | IP-in- | 1634 | d head | | | IP(RPI_1) | | IP(RH3, | 1635 | ers | | | | | opt RPI_2) | 1636 | Re- | -- | -- | -- | -- | -- | 1637 | added | | | | | | 1638 | header | | | | | | 1639 | s | | | | | | 1640 | Modifi | -- | -- | -- | IP-in- | -- | 1641 | ed hea | | | | IP(RH3, | | 1642 | ders | | | | opt RPI_2) | | 1643 | Untouc | -- | -- | -- | -- | -- | 1644 | hed he | | | | | | 1645 | aders | | | | | | 1646 +--------+-----+------------+-------------+------------+------------+ 1648 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1649 RPL-aware-leaf 1651 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1652 aware-leaf 1654 In this case the flow comprises: 1656 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1657 not-RPL-aware (IPv6 dst) 1659 For example, the communication flow could be: Node G --> Node E --> 1660 Node B --> Node A (root) --> Node C --> Node J 1662 6LR_ia are the intermediate routers from source to the root In this 1663 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1665 6LR_id are the intermediate routers from the root to the destination. 1666 In this case, "1 <= ia >= m", m is the number of the intermediate 1667 routers (6LR). 1669 This scenario is the combination of the previous two cases. 1671 +---------+-----+--------------+---------------+-------------+------+ 1672 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1673 | | 6 | | | | dst | 1674 | | src | | | | | 1675 +---------+-----+--------------+---------------+-------------+------+ 1676 | Inserte | -- | IP-in- | IP-in-IP(RH3) | -- | -- | 1677 | d | | IP(RPI_1) | | | | 1678 | headers | | | | | | 1679 | Removed | -- | -- | IP-in- | IP-in- | -- | 1680 | headers | | | IP(RPI_1) | IP(RH3, opt | | 1681 | | | | | RPI_2) | | 1682 | Re- | -- | -- | -- | -- | -- | 1683 | added | | | | | | 1684 | headers | | | | | | 1685 | Modifie | -- | -- | -- | -- | -- | 1686 | d | | | | | | 1687 | headers | | | | | | 1688 | Untouch | -- | -- | -- | -- | -- | 1689 | ed | | | | | | 1690 | headers | | | | | | 1691 +---------+-----+--------------+---------------+-------------+------+ 1693 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1694 not-RPL-aware-leaf 1696 8. Observations about the cases 1698 8.1. Storing mode 1700 [I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP 1701 header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header 1702 as described in Section 7 of the document. 1704 There are potential significant advantages to having a single code 1705 path that always processes IP-in-IP headers with no options. 1707 Thanks to the change of the RPI option type from 0x63 to 0x23, there 1708 is no longer any uncertainty about when to use an IP-in-IP header in 1709 the storing mode. A Hop-by-Hop Options Header containing the RPI 1710 option SHOULD always be added when 6LRs originate packets (without 1711 IP-in-IP headers), and IP-in-IP headers should always be added 1712 (addressed to the root when on the way up, to the end-host when on 1713 the way down) when a 6LR find that it needs to insert a Hop-by-Hop 1714 Options Header containing the RPI option. 1716 In order to support the above two cases with full generality, the 1717 different situations (always do IP-in-IP vs never use IP-in-IP) 1718 should be signaled in the RPL protocol itself. 1720 8.2. Non-Storing mode 1722 In the non-storing case, dealing with non-RPL aware leaf nodes is 1723 much easier as the 6LBR (DODAG root) has complete knowledge about the 1724 connectivity of all DODAG nodes, and all traffic flows through the 1725 root node. 1727 The 6LBR can recognize non-RPL aware leaf nodes because it will 1728 receive a DAO about that node from the 6LN immediately above that 1729 node. This means that the non-storing mode case can avoid ever using 1730 hop-by-hop IP-in-IP headers. 1732 Unlike in the storing mode case, there is no need for all nodes to 1733 know about the existence of non-RPL aware nodes. Only the 6LBR needs 1734 to change when there are non-RPL aware nodes. Further, in the non- 1735 storing case, the 6LBR is informed by the DAOs when there are non-RPL 1736 aware nodes. 1738 9. 6LoRH Compression cases 1740 The [I-D.ietf-roll-routing-dispatch] proposes a compression method 1741 for RPI, RH3 and IPv6-in-IPv6. 1743 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 1744 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 1745 an IP-in-IP and RPI compression headers. The type of this case is 1746 critical since IP-in-IP is encapsulating a RPI header. 1748 +--+-----+---+--------------+-----------+-------------+-------------+ 1749 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | 1750 +--+-----+---+--------------+-----------+-------------+-------------+ 1752 Figure 8: Critical IP-in-IP (RPI). 1754 10. IANA Considerations 1756 This document updates the registration made in [RFC6553] Destination 1757 Options and Hop-by-Hop Options registry from 0x63 to 0x23. 1759 Hex Value Binary Value 1760 act chg rest Description Reference 1761 --------- --- --- ------- ----------------- ---------- 1762 0x23 00 1 00011 RPL Option [RFCXXXX] 1763 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 1765 Figure 9: Option Type in RPL Option. 1767 Todo: Add the Updates to RFC 6550. 1769 11. Security Considerations 1771 The security considerations covering of [RFC6553] and [RFC6554] apply 1772 when the packets get into RPL Domain. 1774 The IPIP mechanism described in this document is much more limited 1775 than the general mechanism described in [RFC2473]. The willingness 1776 of each node in the LLN to decapsulate packets and forward them could 1777 be exploited by nodes to disguise the origin of an attack. 1779 Nodes outside of the LLN will need to pass IPIP traffic through the 1780 RPL root to perform this attack. To counter, the RPL root SHOULD 1781 either restrict ingress of IPIP packets (the simpler solution), or it 1782 SHOULD do a deep packet inspection wherein it walks the IP header 1783 extension chain until it can inspect the upper-layer-payload as 1784 described in [RFC7045]. In particular, the RPL root SHOULD do BCP38 1785 ([RFC2827]) processing on the source addresses of all IP headers that 1786 it examines in both directions. 1788 Note: there are some situations where a prefix will spread across 1789 multiple LLNs via mechanisms such as described in 1790 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 1791 needs to take this into account. 1793 Nodes with the LLN can use the IPIP mechanism to mount an attack on 1794 another part of the LLN, while disguising the origin of the attack. 1795 The mechanism can even be abused to make it appear that the attack is 1796 coming from outside the LLN, and unless countered, this could be used 1797 to mount a Distributed Denial Of Service attack upon nodes elsewhere 1798 in the Internet. See [DDOS-KREBS] for an example of such attacks 1799 already seen in the real world. 1801 While a typical LLN may be a very poor origin for attack traffic (as 1802 the networks tend to be very slow, and the nodes often have very low 1803 duty cycles) given enough nodes, they could still have a significant 1804 impact, particularly if the attack was on another LLN! Additionally, 1805 some uses of RPL involve large backbone ISP scale equipment 1807 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1808 multiple 100Gb/s interfaces. 1810 Blocking or careful filtering of IPIP traffic entering the LLN as 1811 described above will make sure that any attack that is mounted must 1812 originate compromised nodes within the LLN. The use of BCP38 1813 filtering at the RPL root on egress traffic will both alert the 1814 operator to the existence of the attack, as well as drop the attack 1815 traffic. As the RPL network is typically numbered from a single 1816 prefix, which is itself assigned by RPL, BCP38 filtering involves a 1817 single prefix comparison and should be trivial to automatically 1818 configure. 1820 There are some scenarios where IPIP traffic SHOULD be allowed to pass 1821 through the RPL root, such as the IPIP mediated communications 1822 between a new Pledge and the Join Registrar/Coordinator (JRC) when 1823 using [I-D.ietf-anima-bootstrapping-keyinfra] and 1824 [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the 1825 RPL root to do careful filtering: it occurs only when the Join 1826 Coordinator is not co-located inside the RPL root. 1828 With the above precautions, an attack using IPIP tunnels will be by a 1829 node within the LLN on another node within the LLN. Such an attack 1830 could, of course, be done directly. An attack of this kind is 1831 meaningful only if the source addresses are either fake or if the 1832 point is to amplify return traffic. Such an attack, could also be 1833 done without the use of IPIP headers using forged source addresses. 1834 If the attack requires bi-directional communication, then IPIP 1835 provides no advantages. 1837 [RFC2473] suggests that tunnel entry and exit points can be secured, 1838 via the "Use IPsec". This solution has all the problems that 1839 [RFC5406] goes into. In an LLN such a solution would degenerate into 1840 every node having a tunnel with every other node. It would provide a 1841 small amount of origin address authentication at a very high cost; 1842 doing BCP38 at every node (linking layer-3 addresses to layer-2 1843 addresses, and to already present layer-2 cryptographic mechanisms) 1844 would be cheaper should RPL be run in an environment where hostile 1845 nodes are likely to be a part of the LLN. 1847 The RH3 header usage described here can be abused in equivalent ways 1848 with an IPIP header to add the needed RH3 header. As such, the 1849 attacker's RH3 header will not be seen by the network until it 1850 reaches the end host, which will decapsulate it. An end-host SHOULD 1851 be suspicious about a RH3 header which has additional hops which have 1852 not yet been processed, and SHOULD ignore such a second RH3 header. 1854 In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch] 1855 to compress the IPIP and RH3 headers. As such, the compressor at the 1856 RPL-root will see the second RH3 header and MAY choose to discard the 1857 packet if the RH3 header has not been completely consumed. A 1858 consumed (inert) RH3 header could be present in a packet that flows 1859 from one LLN, crosses the Internet, and enters another LLN. As per 1860 the discussion in this document, such headers do not need to be 1861 removed. However, there is no case described in this document where 1862 an RH3 is inserted in a non-storing network on traffic that is 1863 leaving the LLN, but this document SHOULD NOT preclude such a future 1864 innovation. It should just be noted that an incoming RH3 must be 1865 fully consumed, or very carefully inspected. 1867 The RPI header, if permitted to enter the LLN, could be used by an 1868 attacker to change the priority of a packet by selecting a different 1869 RPL instanceID, perhaps one with a higher energy cost, for instance. 1870 It could also be that not all nodes are reachable in an LLN using the 1871 default instanceID, but a change of instanceID would permit an 1872 attacker to bypass such filtering. Like the RH3, an RPI header is to 1873 be inserted by the RPL root on traffic entering the LLN by first 1874 inserting an IPIP header. The attacker's RPI header therefore will 1875 not be seen by the network. Upon reaching the destination node the 1876 RPI header has no further meaning and is just skipped; the presence 1877 of a second RPI header will have no meaning to the end node as the 1878 packet has already been identified as being at it's final 1879 destination. 1881 The RH3 and RPI headers could be abused by an attacker inside of the 1882 network to route packets on non-obvious ways, perhaps eluding 1883 observation. This usage is in fact part of [RFC6997] and can not be 1884 restricted at all. This is a feature, not a bug. 1886 [RFC7416] deals with many other threats to LLNs not directly related 1887 to the use of IPIP headers, and this document does not change that 1888 analysis. 1890 12. Acknowledgments 1892 This work is partially funded by the FP7 Marie Curie Initial Training 1893 Network (ITN) METRICS project (grant agreement No. 607728). 1895 The authors would like to acknowledge the review, feedback, and 1896 comments of (alphabetical order): Robert Cragie, Simon Duquennoy, 1897 Cenk Guendogan, C. M. Heard, Rahul Jadhav, Peter van der Stok, 1898 Xavier Vilajosana and Thomas Watteyne. 1900 13. References 1902 13.1. Normative References 1904 [I-D.ietf-6man-rfc2460bis] 1905 Deering, S. and R. Hinden, "Internet Protocol, Version 6 1906 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 1907 in progress), May 2017. 1909 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1910 Requirement Levels", BCP 14, RFC 2119, 1911 DOI 10.17487/RFC2119, March 1997, 1912 . 1914 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1915 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1916 December 1998, . 1918 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1919 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1920 December 1998, . 1922 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1923 Defeating Denial of Service Attacks which employ IP Source 1924 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1925 May 2000, . 1927 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1928 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1929 February 2009, . 1931 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1932 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1933 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1934 Low-Power and Lossy Networks", RFC 6550, 1935 DOI 10.17487/RFC6550, March 2012, 1936 . 1938 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1939 Power and Lossy Networks (RPL) Option for Carrying RPL 1940 Information in Data-Plane Datagrams", RFC 6553, 1941 DOI 10.17487/RFC6553, March 2012, 1942 . 1944 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1945 Routing Header for Source Routes with the Routing Protocol 1946 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1947 DOI 10.17487/RFC6554, March 2012, 1948 . 1950 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1951 of IPv6 Extension Headers", RFC 7045, 1952 DOI 10.17487/RFC7045, December 2013, 1953 . 1955 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1956 and M. Richardson, Ed., "A Security Threat Analysis for 1957 the Routing Protocol for Low-Power and Lossy Networks 1958 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 1959 . 1961 13.2. Informative References 1963 [DDOS-KREBS] 1964 Goodin, D., "Record-breaking DDoS reportedly delivered by 1965 >145k hacked cameras", September 2016, 1966 . 1969 [I-D.ietf-6lo-backbone-router] 1970 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 1971 backbone-router-03 (work in progress), January 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-11 (work 1976 in progress), January 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 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 1985 Control Plane", draft-ietf-anima-autonomic-control- 1986 plane-06 (work in progress), March 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-06 (work in progress), May 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-01 (work in 1997 progress), March 2017. 1999 [I-D.ietf-roll-routing-dispatch] 2000 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 2001 "6LoWPAN Routing Header", draft-ietf-roll-routing- 2002 dispatch-05 (work in progress), October 2016. 2004 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2005 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2006 DOI 10.17487/RFC4192, September 2005, 2007 . 2009 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2010 Control Message Protocol (ICMPv6) for the Internet 2011 Protocol Version 6 (IPv6) Specification", RFC 4443, 2012 DOI 10.17487/RFC4443, March 2006, 2013 . 2015 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2016 Bormann, "Neighbor Discovery Optimization for IPv6 over 2017 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2018 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2019 . 2021 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2022 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2023 in Low-Power and Lossy Networks", RFC 6997, 2024 DOI 10.17487/RFC6997, August 2013, 2025 . 2027 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2028 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2029 2014, . 2031 [Second6TischPlugtest] 2032 "2nd 6Tisch Plugtest", . 2035 Authors' Addresses 2037 Maria Ines Robles 2038 Ericsson 2039 Hirsalantie 11 2040 Jorvas 02420 2041 Finland 2043 Email: maria.ines.robles@ericsson.com 2045 Michael C. Richardson 2046 Sandelman Software Works 2047 470 Dawson Avenue 2048 Ottawa, ON K1Z 5V7 2049 CA 2051 Email: mcr+ietf@sandelman.ca 2052 URI: http://www.sandelman.ca/mcr/ 2054 Pascal Thubert 2055 Cisco Systems, Inc 2056 Village d'Entreprises Green Side 400, Avenue de Roumanille 2057 Batiment T3, Biot - Sophia Antipolis 06410 2058 France 2060 Email: pthubert@cisco.com