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