idnits 2.17.00 (12 Aug 2021) /tmp/idnits10601/draft-ietf-roll-useofrplinfo-17.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 37 instances of too long lines in the document, the longest one being 12 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 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 211 has weird spacing: '... act chg ...' == Line 244 has weird spacing: '... act chg ...' == Line 1793 has weird spacing: '... act chg ...' -- The document date (October 27, 2017) is 1667 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 1796, but not defined == Unused Reference: 'I-D.ietf-6tisch-architecture' is defined on line 2020, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-rfc2460bis has been published as RFC 8200 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-6man-rfc2460bis' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 7416 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == Outdated reference: draft-ietf-6tisch-architecture has been published as RFC 9030 == Outdated reference: draft-ietf-anima-autonomic-control-plane has been published as RFC 8994 == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 == Outdated reference: A later version (-25) exists of draft-ietf-roll-dao-projection-02 == Outdated reference: draft-ietf-roll-routing-dispatch has been published as RFC 8138 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 5 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: April 30, 2018 P. Thubert 7 Cisco 8 October 27, 2017 10 When to use RFC 6553, 6554 and IPv6-in-IPv6 11 draft-ietf-roll-useofrplinfo-17 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 April 30, 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 . 18 77 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 78 Internet . . . . . . . . . . . . . . . . . . . . . . 19 79 6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 80 leaf . . . . . . . . . . . . . . . . . . . . . . . . 20 81 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 21 82 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 83 leaf . . . . . . . . . . . . . . . . . . . . . . . . 21 84 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 85 aware-leaf . . . . . . . . . . . . . . . . . . . . . 22 86 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 87 aware-leaf . . . . . . . . . . . . . . . . . . . . . 23 88 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 89 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 24 90 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 26 91 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 27 92 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 28 93 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 28 94 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 95 leaf . . . . . . . . . . . . . . . . . . . . . . . . 29 96 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 97 root . . . . . . . . . . . . . . . . . . . . . . . . 30 98 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 31 99 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 100 Internet . . . . . . . . . . . . . . . . . . . . . . 31 101 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 102 leaf . . . . . . . . . . . . . . . . . . . . . . . . 32 103 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 104 Internet . . . . . . . . . . . . . . . . . . . . . . 33 105 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 106 aware-leaf . . . . . . . . . . . . . . . . . . . . . 34 107 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 35 108 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 109 aware-leaf . . . . . . . . . . . . . . . . . . . . . 35 110 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 111 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37 112 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 113 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38 114 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 115 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39 116 8. Observations about the cases . . . . . . . . . . . . . . . . 40 117 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40 118 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41 119 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41 120 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 121 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 122 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 123 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 124 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 125 13.2. Informative References . . . . . . . . . . . . . . . . . 46 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 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 [I-D.ietf-roll-routing-dispatch] defines a method to compress RPL 156 Option information and Routing Header type 3 [RFC6554], an efficient 157 IP-in-IP technique, and use cases proposed for the 158 [Second6TischPlugtest] involving 6loRH. 160 2. Terminology and Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 167 RPL, RPL Domain and ROLL. 169 RPL-node: It is device which implements RPL, thus we can say that the 170 device is RPL-capable or RPL-aware. Please note that the device can 171 be found inside the LLN or outside LLN. In this document a RPL-node 172 which is a leaf of a DODAG is called RPL-aware-leaf. 174 RPL-not-capable: It is device which does not implement RPL, thus we 175 can say that the device is not-RPL-aware. Please note that the 176 device can be found inside the LLN. In this document a not-RPL-aware 177 node which is a leaf of a DODAG is called not-RPL-aware-leaf. 179 pledge: a new device which seeks admission to a network. (from 180 [I-D.ietf-anima-bootstrapping-keyinfra]) 182 Join Registrar and Coordinator (JRC): a device which brings new nodes 183 (pledges) into a network. (from 184 [I-D.ietf-anima-bootstrapping-keyinfra]) 186 Flag day: A "flag day" is a procedure in which the network, or a part 187 of it, is changed during a planned outage, or suddenly, causing an 188 outage while the network recovers [RFC4192] 190 2.1. hop-by-hop IPv6-in-IPv6 headers 192 The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header 193 that originates from a node to an adjacent node, using the addresses 194 (usually the GUA or ULA, but could use the link-local addresses) of 195 each node. If the packet must traverse multiple hops, then it must 196 be decapsulated at each hop, and then re-encapsulated again in a 197 similar fashion. 199 3. Updates to RFC6553, RFC6550 and RFC 8138 201 3.1. Updates to RFC 6553 203 [RFC6553] states as showed below, that in the Option Type field of 204 the RPL Option header, the two high order bits MUST be set to '01' 205 and the third bit is equal to '1'. The first two bits indicate that 206 the IPv6 node MUST discard the packet if it doesn't recognize the 207 option type, and the third bit indicates that the Option Data may 208 change en route. The remaining bits serve as the option type. 210 Hex Value Binary Value 211 act chg rest Description Reference 212 --------- --- --- ------- ----------------- ---------- 213 0x63 01 1 00011 RPL Option [RFC6553] 215 Figure 1: Option Type in RPL Option. 217 Recent changes in [I-D.ietf-6man-rfc2460bis], state: "it is now 218 expected that nodes along a packet's delivery path only examine and 219 process the Hop-by-Hop Options header if explicitly configured to do 220 so". Processing of the Hop-by-Hop Options header (by IPv6 221 intermediate nodes) is now optional, but if they are configured to 222 process the header, and if such nodes encounter an option with the 223 first two bits set to 01, they will drop the packet (if they conform 224 [I-D.ietf-6man-rfc2460bis]). The hosts should do the same, 225 irrespective of the configuration. 227 Based on That, if an IPv6 (intermediate) node (RPL-not-capable) 228 receives a packet with an RPL Option, it should ignore the HBH RPL 229 option (skip over this option and continue processing the header). 231 Thus, this document updates the Option Type field to: the two high 232 order bits MUST be set to '00' and the third bit is equal to '1'. 233 The first two bits indicate that the IPv6 node MUST skip over this 234 option and continue processing the header 235 (Section 4.2.[I-D.ietf-6man-rfc2460bis] ) if it doesn't recognize the 236 option type, and the third bit continues to be set to indicate that 237 the Option Data may change en route. The remaining bits serve as the 238 option type and remain as 0x3. This ensures that a packet that 239 leaves the RPL domain of an LLN (or that leaves the LLN entirely) 240 will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop 241 option known as RPI. This is an 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: Proposed change to the 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 [I-D.ietf-roll-routing-dispatch] will 261 experience a flag day in the data compression anyway, and if possible 262 this change can be 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, the new nodes need to be 276 told that there are old RPI nodes present. This can be done via the 277 DODAG Configuration Option flag which will propogate through the 278 network. Failure to receive this information will cause dual mode 279 nodes to originate traffic with the old-RPI (0x63) value. 281 As states in [RFC6550] the DODAG Configuration option is present in 282 DIO messages. the DODAG Configuration option distribute 283 configuration information which is generally static and unchanging 284 within the DODAG. This information is configured at the DODAG root 285 and distributed throughout the DODAG with the DODAG Configuration 286 option. Nodes other than the DODAG root must not modify this 287 information when propagating the DODAG Configuration option. 289 The DODAG Configuration Option is as follow. We are interested in 290 the Flag field. The remaining fields states as defined in [RFC6550]. 292 Flags: The 4-bits remaining unused in the Flags field are reserved 293 for flags. The field MUST be initialized to zero by the sender and 294 MUST be ignored by the receiver. 296 0 1 2 3 297 +-----------------+---------------------------------------------------+ 298 | Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. | 299 +---------------------------------------------------------------------+ 300 | DIOIntMin. | DIORedund. | MaxRankIncrease | 301 +-----------------+---------------------------------------------------+ 302 | MinHopRankIncrease | OCP | 303 +-----------------+---------------------------------------------------+ 304 |Reserved | Def. Lifetime | Lifetime Unit | 305 +-----------------+-----------------+---------------------------------+ 307 Figure 3: DODAG Configuration Option. 309 We propose to use the flag in the DODAG Configuration option as 310 follows: 312 +------------+-----------------+---------------+ 313 | Bit number | Description | Reference | 314 +------------+-----------------+---------------+ 315 | 3 | RPI 0x23 enable | This document | 316 +------------+-----------------+---------------+ 318 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 319 day. 321 In case of rebooting, the DIO is sent with flag indicating the new 322 RPI value. 324 4. Sample/reference topology 326 A RPL network in general is composed of a 6LBR (6LoWPAN Border 327 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 328 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 329 (Destination Oriented Directed Acyclic Graph). 331 RPL defines the RPL Control messages (control plane), a new ICMPv6 332 [RFC4443] message with Type 155. DIS (DODAG Information 333 Solicitation), DIO (DODAG Information Object) and DAO (Destination 334 Advertisement Object) messages are all RPL Control messages but with 335 different Code values. A RPL Stack is showed in Figure 1. 337 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 338 it is fully stateful or an in non-storing (RPL-NSM), it is fully 339 source routed. A RPL Instance is either fully storing or fully non- 340 storing, i.e. a RPL Instance with a combination of storing and non- 341 storing nodes is not supported with the current specifications at the 342 time of writing this document. 344 +--------------+ 345 | Upper Layers | 346 | | 347 +--------------+ 348 | RPL | 349 | | 350 +--------------+ 351 | ICMPv6 | 352 | | 353 +--------------+ 354 | IPv6 | 355 | | 356 +--------------+ 357 | 6LoWPAN | 358 | | 359 +--------------+ 360 | PHY-MAC | 361 | | 362 +--------------+ 364 Figure 5: RPL Stack. 366 +------------+ 367 | INTERNET ----------+ 368 | | | 369 +------------+ | 370 | 371 | 372 | 373 A | 374 +-------+ 375 |6LBR | 376 +-----------|(root) |-------+ 377 | +-------+ | 378 | | 379 | | 380 | | 381 | | 382 | B |C 383 +---|---+ +---|---+ 384 | 6LR | | 6LR | 385 +-------->| |--+ +--- ---+ 386 | +-------+ | | +-------+ | 387 | | | | 388 | | | | 389 | | | | 390 | | | | 391 | D | E | | 392 +-|-----+ +---|---+ | | 393 | 6LR | | 6LR | | | 394 | | +------ | | | 395 +---|---+ | +---|---+ | | 396 | | | | | 397 | | +--+ | | 398 | | | | | 399 | | | | | 400 | | | I | J | 401 F | | G | H | | 402 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 403 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 404 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 405 +-------+ +-------+ +------+ +-------+ +-------+ 407 Figure 6: A reference RPL Topology. 409 Figure 2 shows the reference RPL Topology for this document. The 410 letters above the nodes are there so that they may be referenced in 411 subsequent sections. In the figure, a 6LR is a router. A 6LN can be 412 a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked 413 as (F and I) are RPL hosts that does not have forwarding capability. 414 The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL 415 aware leaf" (G and J) are devices which do not speak RPL at all (not- 416 RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and 417 efficient-ND only to participate in the network [RFC6775]. In the 418 document these leafs (G and J) are often named IPv6 node. The 6LBR 419 in the figure is the root of the Global DODAG. 421 5. Use cases 423 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 424 encapsulation is going to be analyzed for a number of representative 425 traffic flows. 427 This document assumes that the LLN is using the no-drop RPI option 428 (0x23). 430 The uses cases describe the communication between RPL-aware-nodes, 431 with the root (6LBR), and with Internet. This document also describe 432 the communication between nodes acting as leaf that does not 433 understand RPL and they are part of hte LLN. We name these nodes as 434 not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to 435 root) We describe also how is the communication inside of the LLN 436 when it has the final destination addressed outside of the LLN e.g. 437 with destination to Internet. (e.g. section 5.7- Flow from not-RPL- 438 aware-leaf to Internet) 440 The uses cases comprise as follow: 442 Interaction between Leaf and Root: 444 RPL-aware-leaf to root 446 root to RPL-aware-leaf 448 not-RPL-aware-leaf to root 450 root to not-RPL-aware-leaf 452 Interaction between Leaf and Internet: 454 RPL-aware-leaf to Internet 456 Internet to RPL-aware-leaf 458 not-RPL-aware-leaf to Internet 459 Internet to not-RPL-aware-leaf 461 Interaction between Leafs: 463 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 465 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 467 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 469 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 471 This document assumes the rule that a Header cannot be inserted or 472 removed on the fly inside an IPv6 packet that is being routed. This 473 is a fundamental precept of the IPv6 architecture as outlined in 474 [RFC2460]. Extensions may not be added or removed except by the 475 sender or the receiver. 477 But, options in the Hop-by-Hop Option Header whose option type has 478 the first two bits set to '00' MUST ignored when received by a host 479 or router that does not understand that option ( Section 4.2 480 [I-D.ietf-6man-rfc2460bis]). 482 This means that when the no-drop RPI option code 0x23 is used, a 483 packet that leaves the RPL domain of an LLN (or that leaves the LLN 484 entirely) will not be discarded when it contains the [RFC6553] RPL 485 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option MAY 486 be left in place even if the end host does not understand it. 488 NOTE: There is some possible security risk when the RPI information 489 is released to the Internet. At this point this is a theoretical 490 situation. It is clear that the RPI option would waste some network 491 bandwidth when it escapes. 493 An intermediate router that needs to add an extension header (SHR3 or 494 RPI Option) must encapsulate the packet in an (additional) outer IP 495 header. The new header can be placed is placed after this new outer 496 IP header. 498 A corollory is that an SHR3 or RPI Option can only be removed by an 499 intermediate router if it is placed in an encapsulating IPv6 Header, 500 which is addressed to the intermediate router. When it does so, the 501 whole encapsulating header must be removed. (A replacement may be 502 added). This sometimes can result in outer IP headers being 503 addressed to the next hop router using link-local addresses. 505 Both RPI and RH3 headers may be modified in very specific ways by 506 routers on the path of the packet without the need to add to remove 507 an encapsulating header. Both headers were designed with this 508 modification in mind, and both the RPL RH and the RPL option are 509 marked mutable but recoverable: so an IPsec AH security header can be 510 applied across these headers, but it can not secure the values which 511 mutate. 513 RPI should be present in every single RPL data packet. There is one 514 exception in non-storing mode: when a packet is going down from the 515 root. In a downward non-storing mode, the entire route is written, 516 so there can be no loops by construction, nor any confusion about 517 which forwarding table to use (as the root has already made all 518 routing decisions). There still may be cases (such as in 6tisch) 519 where the instanceID portion of the RPI header may still be needed to 520 pick an appropriate priority or channel at each hop. 522 In the tables present in this document, the term "RPL aware leaf" is 523 has been shortened to "Raf", and "not-RPL aware leaf" has been 524 shortened to "~Raf" to make the table fit in available space. 526 The earlier examples are more extensive to make sure that the process 527 is clear, while later examples are more concise. 529 6. Storing mode 531 In storing mode (fully stateful), the sender can determine if the 532 destination is inside the LLN by looking if the destination address 533 is matched by the DIO's PIO option. 535 The following table summarizes what headers are needed in the 536 following scenarios, and indicates when the IP-in-IP header must be 537 inserted on a hop-by-hop basis, and when it can target the 538 destination node directly. There are these possible situations: hop- 539 by-hop necessary (indicated by "hop"), or destination address 540 possible (indicated by "dst"). In all cases hop by hop can be used. 541 In cases where no IP-in-IP header is needed, the column is left 542 blank. 544 In all cases the RPI headers are needed, since it identifies 545 inconsistencies (loops) in the routing topology. In all cases the 546 RH3 is not need because we do not indicate the route in storing mode. 548 The leaf can be a router 6LR or a host, both indicated as 6LN 549 (Figure 2). 551 +---------------------+--------------+----------+--------------+ 552 | Interaction between | Use Case | IP-in-IP | IP-in-IP dst | 553 +---------------------+--------------+----------+--------------+ 554 | | Raf to root | No | -- | 555 + +--------------+----------+--------------+ 556 | Leaf - Root | root to Raf | No | -- | 557 + +--------------+----------+--------------+ 558 | | root to ~Raf | No | -- | 559 + +--------------+----------+--------------+ 560 | | ~Raf to root | Yes | root | 561 +---------------------+--------------+----------+--------------+ 562 | | Raf to Int | No | -- | 563 + +--------------+----------+--------------+ 564 | Leaf - Internet | Int to Raf | Yes | Raf | 565 + +--------------+----------+--------------+ 566 | | ~Raf to Int | Yes | root | 567 + +--------------+----------+--------------+ 568 | | Int to ~Raf | Yes | hop | 569 +---------------------+--------------+----------+--------------+ 570 | | Raf to Raf | No | -- | 571 + +--------------+----------+--------------+ 572 | | Raf to ~Raf | No | -- | 573 + Leaf - Leaf +--------------+----------+--------------+ 574 | | ~Raf to Raf | Yes | dst | 575 + +--------------+----------+--------------+ 576 | | ~Raf to ~Raf | Yes | hop | 577 +---------------------+--------------+----------+--------------+ 579 Figure 7: IP-in-IP encapsulation in Storing mode. 581 6.1. Storing Mode: Interaction between Leaf and Root 583 In this section we are going to describe the communication flow in 584 storing mode (SM) between, 586 RPL-aware-leaf to root 588 root to RPL-aware-leaf 590 not-RPL-aware-leaf to root 592 root to not-RPL-aware-leaf 594 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 596 In storing mode, RFC 6553 (RPI) is used to send RPL Information 597 instanceID and rank information. 599 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does 600 not generally issue DIO messages; a leaf node accepts DIO messages 601 from upstream. (When the inconsistency in routing occurs, a leaf 602 node will generate a DIO with an infinite rank, to fix it). It may 603 issue DAO and DIS messages though it generally ignores DAO and DIS 604 messages. 606 In this case the flow comprises: 608 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 610 For example, the communication flow would be: Node F --> Node E --> 611 Node B --> Node A root(6LBR) 613 6LR_i (Node E and Node B) are the intermediate routers from source to 614 destination. In this case, "1 <= i >= n", n is the number of routers 615 (6LR) that the packet go through from source (6LN) to destination 616 (6LBR). 618 As it was mentioned In this document 6LRs, 6LBR are always full- 619 fledge RPL routers. 621 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 622 (Node E) which decrements the rank in RPI and sends the packet up. 623 When the packet arrives at 6LBR (Node A), the RPI is removed and the 624 packet is processed. 626 No IP-in-IP header is required. 628 The RPI header can be removed by the 6LBR because the packet is 629 addressed to the 6LBR. The 6LN must know that it is communicating 630 with the 6LBR to make use of this scenario. The 6LN can know the 631 address of the 6LBR because it knows the address of the root via the 632 DODAGID in the DIO messages. 634 +-------------------+-----+-------+------+ 635 | Header | 6LN | 6LR_i | 6LBR | 636 +-------------------+-----+-------+------+ 637 | Inserted headers | RPI | -- | -- | 638 | Removed headers | -- | -- | RPI | 639 | Re-added headers | -- | -- | -- | 640 | Modified headers | -- | RPI | -- | 641 | Untouched headers | -- | -- | -- | 642 +-------------------+-----+-------+------+ 644 Storing: Summary of the use of headers from RPL-aware-leaf to root 646 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 648 In this case the flow comprises: 650 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 652 For example, the communication flow would be: Node A root(6LBR) --> 653 Node B --> Node D --> Node F 655 6LR_i are the intermediate routers from source to destination. In 656 this case, "1 <= i >= n", n is the number of routers (6LR) that the 657 packet go through from source (6LBR) to destination (6LN). 659 In this case the 6LBR inserts RPI header and sends the packet down, 660 the 6LR is going to increment the rank in RPI (examines instanceID 661 for multiple tables), the packet is processed in 6LN and RPI removed. 663 No IP-in-IP header is required. 665 +-------------------+------+-------+------+ 666 | Header | 6LBR | 6LR_i | 6LN | 667 +-------------------+------+-------+------+ 668 | Inserted headers | RPI | -- | -- | 669 | Removed headers | -- | -- | RPI | 670 | Re-added headers | -- | -- | -- | 671 | Modified headers | -- | RPI | -- | 672 | Untouched headers | -- | -- | -- | 673 +-------------------+------+-------+------+ 675 Storing: Summary of the use of headers from root to RPL-aware-leaf 677 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 679 In this case the flow comprises: 681 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 682 For example, the communication flow would be: Node A root(6LBR) --> 683 Node B --> Node E --> Node G 685 6LR_i are the intermediate routers from source to destination. In 686 this case, "1 <= i >= n", n is the number of routers (6LR) that the 687 packet go through from source (6LBR) to destination (IPv6). 689 As the RPI extension can be ignored by the not-RPL-aware leaf, this 690 situation is identical to the previous scenario. 692 +-------------------+------+-------+----------------+ 693 | Header | 6LBR | 6LR_i | IPv6 | 694 +-------------------+------+-------+----------------+ 695 | Inserted headers | RPI | -- | -- | 696 | Removed headers | -- | -- | -- | 697 | Re-added headers | -- | -- | -- | 698 | Modified headers | -- | RPI | -- | 699 | Untouched headers | -- | -- | RPI (Ignored) | 700 +-------------------+------+-------+----------------+ 702 Storing: Summary of the use of headers from root to not-RPL-aware- 703 leaf 705 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 707 In this case the flow comprises: 709 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 711 For example, the communication flow would be: Node G --> Node E --> 712 Node B --> Node A root(6LBR) 714 6LR_i are the intermediate routers from source to destination. In 715 this case, "1 < i >= n", n is the number of routers (6LR) that the 716 packet go through from source (IPv6) to destination (6LBR). For 717 example, 6LR_1 (i=1) is the router that receives the packets from the 718 IPv6 node (Node G). 720 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 721 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 722 header. The IPv6-in-IPv6 header can be addressed to the next hop 723 (Node B), or to the root (Node A). The root removes the header and 724 processes the packet. 726 +------------+------+---------------+---------------+---------------+ 727 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 728 +------------+------+---------------+---------------+---------------+ 729 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 730 | headers | | | | | 731 | Removed | -- | -- | -- | IP-in-IP(RPI) | 732 | headers | | | | | 733 | Re-added | -- | -- | -- | -- | 734 | headers | | | | | 735 | Modified | -- | -- | IP-in-IP(RPI) | -- | 736 | headers | | | | | 737 | Untouched | -- | -- | -- | -- | 738 | headers | | | | | 739 +------------+------+---------------+---------------+---------------+ 741 Storing: Summary of the use of headers from not-RPL-aware-leaf to 742 root 744 6.2. Storing Mode: Interaction between Leaf and Internet 746 In this section we are going to describe the communication flow in 747 storing mode (SM) between, 749 RPL-aware-leaf to Internet 751 Internet to RPL-aware-leaf 753 not-RPL-aware-leaf to Internet 755 Internet to not-RPL-aware-leaf 757 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 759 RPL information from RFC 6553 MAY go out to Internet as it will be 760 ignored by nodes which have not been configured to be RPI aware. 762 In this case the flow comprises: 764 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 766 For example, the communication flow could be: Node F --> Node D --> 767 Node B --> Node A root(6LBR) --> Internet 769 6LR_i are the intermediate routers from source to destination. In 770 this case, "1 <= i >= n", n is the number of routers (6LR) that the 771 packet go through from source (6LN) to 6LBR. 773 No IP-in-IP header is required. 775 Note: In this use case we use a node as leaf, but this use case can 776 be also applicable to any RPL-node type (e.g. 6LR) 778 +-------------------+------+-------+------+----------------+ 779 | Header | 6LN | 6LR_i | 6LBR | Internet | 780 +-------------------+------+-------+------+----------------+ 781 | Inserted headers | RPI | -- | -- | -- | 782 | Removed headers | -- | -- | -- | -- | 783 | Re-added headers | -- | -- | -- | -- | 784 | Modified headers | -- | RPI | -- | -- | 785 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 786 +-------------------+------+-------+------+----------------+ 788 Storing: Summary of the use of headers from RPL-aware-leaf to 789 Internet 791 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 793 In this case the flow comprises: 795 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 797 For example, the communication flow could be: Internet --> Node A 798 root(6LBR) --> Node B --> Node D --> Node F 800 6LR_i are the intermediate routers from source to destination. In 801 this case, "1 <= i >= n", n is the number of routers (6LR) that the 802 packet go through from 6LBR to destination(6LN). 804 When the packet arrives from Internet to 6LBR the RPI header is added 805 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 806 rank in the RPI. When the packet arrives at 6LN the RPI header is 807 removed and the packet processed. 809 +----------+---------+--------------+---------------+---------------+ 810 | Header | Interne | 6LBR | 6LR_i | 6LN | 811 | | t | | | | 812 +----------+---------+--------------+---------------+---------------+ 813 | Inserted | -- | IP-in- | -- | -- | 814 | headers | | IP(RPI) | | | 815 | Removed | -- | -- | -- | IP-in-IP(RPI) | 816 | headers | | | | | 817 | Re-added | -- | -- | -- | -- | 818 | headers | | | | | 819 | Modified | -- | -- | IP-in-IP(RPI) | -- | 820 | headers | | | | | 821 | Untouche | -- | -- | -- | -- | 822 | d | | | | | 823 | headers | | | | | 824 +----------+---------+--------------+---------------+---------------+ 826 Storing: Summary of the use of headers from Internet to RPL-aware- 827 leaf 829 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 831 In this case the flow comprises: 833 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 834 Internet 836 For example, the communication flow could be: Node G --> Node E --> 837 Node B --> Node A root(6LBR) --> Internet 839 6LR_i are the intermediate routers from source to destination. In 840 this case, "1 < i >= n", n is the number of routers (6LR) that the 841 packet go through from source(IPv6) to 6LBR. 843 The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed 844 either to the root, or hop-by-hop such that the root can remove the 845 RPI header before passing upwards. 847 The originating node will ideally leave the IPv6 flow label as zero 848 so that the packet can be better compressed through the LLN. The 849 6LBR will set the flow label of the packet to a non-zero value when 850 sending to the Internet. 852 +---------+-----+-------------+-------------+-------------+---------+ 853 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 854 | | 6 | | [i=2,..,n]_ | | t | 855 +---------+-----+-------------+-------------+-------------+---------+ 856 | Inserte | -- | IP-in- | -- | -- | -- | 857 | d | | IP(RPI) | | | | 858 | headers | | | | | | 859 | Removed | -- | -- | -- | IP-in- | -- | 860 | headers | | | | IP(RPI) | | 861 | Re- | -- | -- | -- | -- | -- | 862 | added | | | | | | 863 | headers | | | | | | 864 | Modifie | -- | -- | IP-in- | -- | -- | 865 | d | | | IP(RPI) | | | 866 | headers | | | | | | 867 | Untouch | -- | -- | -- | -- | -- | 868 | ed | | | | | | 869 | headers | | | | | | 870 +---------+-----+-------------+-------------+-------------+---------+ 872 Storing: Summary of the use of headers from not-RPL-aware-leaf to 873 Internet 875 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf 877 In this case the flow comprises: 879 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 881 For example, the communication flow could be: Internet --> Node A 882 root(6LBR) --> Node B --> Node E --> Node G 884 6LR_i are the intermediate routers from source to destination. In 885 this case, "1 < i >= n", n is the number of routers (6LR) that the 886 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 6LR_i 887 updates the rank in the RPI. 889 The 6LBR will have to add an RPI header within an IP-in-IP header. 890 The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the 891 RPI inside. 893 The 6LBR MAY set the flow label on the inner IP-in-IP header to zero 894 in order to aid in compression. 896 +-----------+----------+---------------+---------------+------------+ 897 | Header | Internet | 6LBR | 6LR_i | IPv6 | 898 +-----------+----------+---------------+---------------+------------+ 899 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 900 | headers | | | | | 901 | Removed | -- | -- | -- | -- | 902 | headers | | | | | 903 | Re-added | -- | -- | -- | -- | 904 | headers | | | | | 905 | Modified | -- | -- | IP-in-IP(RPI) | -- | 906 | headers | | | | | 907 | Untouched | -- | -- | -- | RPI | 908 | headers | | | | (Ignored) | 909 +-----------+----------+---------------+---------------+------------+ 911 Storing: Summary of the use of headers from Internet to non-RPL- 912 aware-leaf 914 6.3. Storing Mode: Interaction between Leaf and Leaf 916 In this section we are going to describe the communication flow in 917 storing mode (SM) between, 919 RPL-aware-leaf to RPL-aware-leaf 921 RPL-aware-leaf to not-RPL-aware-leaf 923 not-RPL-aware-leaf to RPL-aware-leaf 925 not-RPL-aware-leaf to not-RPL-aware-leaf 927 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 929 In [RFC6550] RPL allows a simple one-hop optimization for both 930 storing and non-storing networks. A node may send a packet destined 931 to a one-hop neighbor directly to that node. Section 9 in [RFC6550]. 933 In this case the flow comprises: 935 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 937 For example, the communication flow could be: Node F --> Node D --> 938 Node B --> Node E --> Node H 940 6LR_ia (Node D) are the intermediate routers from source to the 941 common parent (6LR_x) (Node B) In this case, "1 <= ia >= n", n is the 942 number of routers (6LR) that the packet go through from 6LN (Node F) 943 to the common parent (6LR_x). 945 6LR_id (Node E) are the intermediate routers from the common parent 946 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 947 >= m", m is the number of routers (6LR) that the packet go through 948 from the common parent (6LR_x) to destination 6LN. 950 This case is assumed in the same RPL Domain. In the common parent 951 (Node B), the direction of RPI is changed (from increasing to 952 decreasing the rank). 954 While the 6LR nodes will update the RPI, no node needs to add or 955 remove the RPI, so no IP-in-IP headers are necessary. This may be 956 done regardless of where the destination is, as the included RPI will 957 be ignored by the receiver. 959 +---------------+--------+--------+---------------+--------+--------+ 960 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 961 | | src | | parent) | | dst | 962 +---------------+--------+--------+---------------+--------+--------+ 963 | Inserted | RPI | -- | -- | -- | -- | 964 | headers | | | | | | 965 | Removed | -- | -- | -- | -- | RPI | 966 | headers | | | | | | 967 | Re-added | -- | -- | -- | -- | -- | 968 | headers | | | | | | 969 | Modified | -- | RPI | RPI | RPI | -- | 970 | headers | | | | | | 971 | Untouched | -- | -- | -- | -- | -- | 972 | headers | | | | | | 973 +---------------+--------+--------+---------------+--------+--------+ 975 Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 976 aware-leaf 978 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 980 In this case the flow comprises: 982 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 983 6LN (IPv6) 985 For example, the communication flow could be: Node F --> Node D --> 986 Node B --> Node E --> Node G 988 6LR_ia are the intermediate routers from source (6LN) to the common 989 parent (6LR_x) In this case, "1 <= ia >= n", n is the number of 990 routers (6LR) that the packet go through from 6LN to the common 991 parent (6LR_x). 993 6LR_id (Node E) are the intermediate routers from the common parent 994 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 995 In this case, "1 <= id >= m", m is the number of routers (6LR) that 996 the packet go through from the common parent (6LR_x) to destination 997 6LN. 999 This situation is identical to the previous situation Section 6.3.1 1001 +-----------+------+--------+---------------+--------+--------------+ 1002 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 1003 | | src | | parent) | | | 1004 +-----------+------+--------+---------------+--------+--------------+ 1005 | Inserted | RPI | -- | -- | -- | -- | 1006 | headers | | | | | | 1007 | Removed | -- | -- | -- | -- | RPI | 1008 | headers | | | | | | 1009 | Re-added | -- | -- | -- | -- | -- | 1010 | headers | | | | | | 1011 | Modified | -- | RPI | RPI | RPI | -- | 1012 | headers | | | | | | 1013 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1014 | headers | | | | | | 1015 +-----------+------+--------+---------------+--------+--------------+ 1017 Storing: Summary of the use of headers for RPL-aware-leaf to non-RPL- 1018 aware-leaf 1020 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1022 In this case the flow comprises: 1024 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1025 6LR_id --> 6LN 1027 For example, the communication flow could be: Node G --> Node E --> 1028 Node B --> Node D --> Node F 1030 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 1031 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B) In 1032 this case, "1 <= ia >= n", n is the number of routers (6LR) that the 1033 packet go through from source to the common parent. 1035 6LR_id (Node D) are the intermediate routers from the common parent 1036 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1037 >= m", m is the number of routers (6LR) that the packet go through 1038 from the common parent (6LR_x) to destination 6LN. 1040 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1041 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1042 header. The IP-in-IP header is addressed to the destination 6LN 1043 (Node F). 1045 +--------+------+------------+------------+------------+------------+ 1046 | Header | IPv6 | 6LR_ia | common | 6LR_id | 6LN | 1047 | | | | parent | | | 1048 | | | | (6LRx) | | | 1049 +--------+------+------------+------------+------------+------------+ 1050 | Insert | -- | IP-in- | -- | -- | -- | 1051 | ed hea | | IP(RPI) | | | | 1052 | ders | | | | | | 1053 | Remove | -- | -- | -- | -- | IP-in- | 1054 | d head | | | | | IP(RPI) | 1055 | ers | | | | | | 1056 | Re- | -- | -- | -- | -- | -- | 1057 | added | | | | | | 1058 | header | | | | | | 1059 | s | | | | | | 1060 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1061 | ed hea | | | IP(RPI) | IP(RPI) | | 1062 | ders | | | | | | 1063 | Untouc | -- | -- | -- | -- | -- | 1064 | hed he | | | | | | 1065 | aders | | | | | | 1066 +--------+------+------------+------------+------------+------------+ 1068 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1069 RPL-aware-leaf 1071 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1072 leaf 1074 In this case the flow comprises: 1076 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> root (6LBR) --> 1077 6LR_id --> not-RPL-aware 6LN (IPv6 dst) 1079 For example, the communication flow could be: Node G --> Node E --> 1080 Node B --> Node A (root) --> Node C --> Node J 1082 Internet 6LR_ia (Node E and Node B) are the intermediate routers from 1083 source (not-RPL-aware 6LN (IPv6 src))(Node G) to the root (6LBR) 1084 (Node A) In this case, "1 < ia >= n", n is the number of routers 1085 (6LR) that the packet go through from IPv6 src to the root. 1087 6LR_id (C) are the intermediate routers from the root (Node A) to 1088 destination (IPv6 dst) (Node J). In this case, "1 <= id >= m", m is 1089 the number of routers (6LR) that the packet go through from the root 1090 to destination (IPv6 dst). 1092 This flow is identical to Section 6.3.3 1094 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1095 G) and inserts the RPI header (RPIa) encapsulated in IPv6-in-IPv6 1096 header. The IPv6-in-IPv6 header is addressed to the 6LBR. The 6LBR 1097 remove the IPv6-in-IPv6 header and insert another one (RPIb) with 1098 destination to 6LR_m (Node C) node. 1100 One of the side-effects of inserting IP-in-IP RPI header at 6LR_1, is 1101 that now all the packets will go through the 6LBR, even though there 1102 exists a shorter P2P path to the destination 6LN in storing mode. 1103 One possible solution is given by the work in 1104 [I-D.ietf-roll-dao-projection]. Once we have route projection, the 1105 root can find that this traffic deserves optimization (based on 1106 volume and path length, or additional knowledge on that particular 1107 flow) and project a DAO into 6LR_1. 1109 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1110 | Heade | IPv | 6LR_1 | 6LR_ia | 6LBR | 6LR_m | IPv | 1111 | r | 6 | | | | | 6 | 1112 | | src | | | | | dst | 1113 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1114 | Inser | -- | IP-in- | -- | IP-in- | -- | -- | 1115 | ted h | | IP(RPI_a) | | IP(RPI_b) | | | 1116 | eader | | | | | | | 1117 | s | | | | | | | 1118 | Remov | -- | -- | -- | -- | -- | -- | 1119 | ed he | | | | | | | 1120 | aders | | | | | | | 1121 | Re- | -- | -- | -- | -- | IP-in- | -- | 1122 | added | | | | | IP(RPI_b) | | 1123 | heade | | | | | | | 1124 | rs | | | | | | | 1125 | Modif | -- | -- | IP-in- | -- | IP-in- | -- | 1126 | ied h | | | IP(RPI_a) | | IP(RPI_b) | | 1127 | eader | | | | | | | 1128 | s | | | | | | | 1129 | Untou | -- | -- | -- | -- | -- | -- | 1130 | ched | | | | | | | 1131 | heade | | | | | | | 1132 | rs | | | | | | | 1133 +-------+-----+-----------+-----------+-----------+-----------+-----+ 1135 Storing: Summary of the use of headers from not-RPL-aware-leaf to 1136 non-RPL-aware-leaf 1138 7. Non Storing mode 1140 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1141 root) has complete knowledge about the connectivity of all DODAG 1142 nodes, and all traffic flows through the root node. Thus, there is 1143 no need for all nodes to know about the existence of non-RPL aware 1144 nodes. Only the 6LBR needs to change when there are non-RPL aware 1145 nodes. 1147 The following table summarizes what headers are needed in the 1148 following scenarios, and indicates when the RPI, RH3 and IP-in-IP 1149 header must be inserted. There are these possible situations: 1150 destination address possible (indicated by "dst"), to a 6LR, to a 6LN 1151 or to the root. In cases where no IP-in-IP header is needed, the 1152 column is left blank. 1154 The leaf can be a router 6LR or a host, both indicated as 6LN 1155 (Figure 3). 1157 +-----------------+--------------+-----+-----+----------+----------+ 1158 | Interaction | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP | 1159 | between | | | | | dst | 1160 +-----------------+--------------+-----+-----+----------+----------+ 1161 | | Raf to root | Yes | No | No | -- | 1162 + +--------------+-----+-----+----------+----------+ 1163 | Leaf - Root | root to Raf | Opt | Yes | No | -- | 1164 + +--------------+-----+-----+----------+----------+ 1165 | | root to ~Raf | No | Yes | Yes | 6LR | 1166 + +--------------+-----+-----+----------+----------+ 1167 | | ~Raf to root | Yes | No | Yes | root | 1168 +-----------------+--------------+-----+-----+----------+----------+ 1169 | | Raf to Int | Yes | No | Yes | root | 1170 + +--------------+-----+-----+----------+----------+ 1171 | Leaf - Internet | Int to Raf | Opt | Yes | Yes | dst | 1172 + +--------------+-----+-----+----------+----------+ 1173 | | ~Raf to Int | Yes | No | Yes | root | 1174 + +--------------+-----+-----+----------+----------+ 1175 | | Int to ~Raf | Opt | Yes | Yes | 6LR | 1176 +-----------------+--------------+-----+-----+----------+----------+ 1177 | | Raf to Raf | Yes | Yes | Yes | root/dst | 1178 + +--------------+-----+-----+----------+----------+ 1179 | | Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1180 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1181 | | ~Raf to Raf | Yes | Yes | Yes | root/6LN | 1182 + +--------------+-----+-----+----------+----------+ 1183 | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR | 1184 +-----------------+--------------+-----+-----+----------+----------+ 1186 Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP 1187 encapsulation. 1189 7.1. Non-Storing Mode: Interaction between Leaf and Root 1191 In this section we are going to describe the communication flow in 1192 Non Storing Mode (Non-SM) between, 1194 RPL-aware-leaf to root 1196 root to RPL-aware-leaf 1198 not-RPL-aware-leaf to root 1200 root to not-RPL-aware-leaf 1202 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1204 In non-storing mode the leaf node uses default routing to send 1205 traffic to the root. The RPI header must be included to avoid/detect 1206 loops. 1208 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1210 For example, the communication flow could be: Node F --> Node D --> 1211 Node B --> Node A (root) 1213 6LR_i are the intermediate routers from source to destination. In 1214 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1215 packet go through from source (6LN) to destination (6LBR). 1217 This situation is the same case as storing mode. 1219 +-------------------+-----+-------+------+ 1220 | Header | 6LN | 6LR_i | 6LBR | 1221 +-------------------+-----+-------+------+ 1222 | Inserted headers | RPI | -- | -- | 1223 | Removed headers | -- | -- | RPI | 1224 | Re-added headers | -- | -- | -- | 1225 | Modified headers | -- | RPI | -- | 1226 | Untouched headers | -- | -- | -- | 1227 +-------------------+-----+-------+------+ 1229 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1230 root 1232 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf 1234 In this case the flow comprises: 1236 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1238 For example, the communication flow could be: Node A (root) --> Node 1239 B --> Node D --> Node F 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 (6LN). 1245 The 6LBR will insert an RH3, and may optionally insert an RPI header. 1246 No IP-in-IP header is necessary as the traffic originates with an RPL 1247 aware node, the 6LBR. The destination is known to RPL-aware because, 1248 the root knows the whole topology in non-storing mode. 1250 +-------------------+-----------------+-------+----------+ 1251 | Header | 6LBR | 6LR_i | 6LN | 1252 +-------------------+-----------------+-------+----------+ 1253 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1254 | Removed headers | -- | -- | RH3,RPI | 1255 | Re-added headers | -- | -- | -- | 1256 | Modified headers | -- | RH3 | -- | 1257 | Untouched headers | -- | -- | -- | 1258 +-------------------+-----------------+-------+----------+ 1260 Non Storing: Summary of the use of headers from root to RPL-aware- 1261 leaf 1263 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1265 In this case the flow comprises: 1267 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1269 For example, the communication flow could be: Node A (root) --> Node 1270 B --> Node E --> Node G 1272 6LR_i are the intermediate routers from source to destination. In 1273 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1274 packet go through from source (6LBR) to destination (IPv6). 1276 In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR_1 1277 and so on) and it is fully consumed in the last 6LR (6LR_n), but left 1278 there. If RPI is left present, the IPv6 node which does not 1279 understand it will ignore it (following 2460bis), thus encapsulation 1280 is not necesary. Due the complete knowledge of the topology at the 1281 root, the 6LBR is able to address the IP-in-IP header to the last 1282 6LR. 1284 +---------------+-------------+---------------+--------------+------+ 1285 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1286 +---------------+-------------+---------------+--------------+------+ 1287 | Inserted | (opt: RPI), | -- | -- | -- | 1288 | headers | RH3 | | | | 1289 | Removed | -- | RH3 | -- | -- | 1290 | headers | | | | | 1291 | Re-added | -- | -- | -- | -- | 1292 | headers | | | | | 1293 | Modified | -- | (opt: RPI), | (opt: RPI), | -- | 1294 | headers | | RH3 | RH3 | | 1295 | Untouched | -- | -- | -- | RPI | 1296 | headers | | | | | 1297 +---------------+-------------+---------------+--------------+------+ 1299 Non Storing: Summary of the use of headers from root to not-RPL- 1300 aware-leaf 1302 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1304 In this case the flow comprises: 1306 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1308 For example, the communication flow could be: Node G --> Node E --> 1309 Node B --> Node A (root) 1311 6LR_i are the intermediate routers from source to destination. In 1312 this case, "1 < i >= n", n is the number of routers (6LR) that the 1313 packet go through from source (IPv6) to destination (6LBR). For 1314 example, 6LR_1 (i=1) is the router that receives the packets from the 1315 IPv6 node. 1317 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1318 encapsulated in an IP-in-IP header, and is modified in the followings 1319 6LRs. The RPI and entire packet is consumed by the root. 1321 +------------+------+---------------+---------------+---------------+ 1322 | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | 1323 +------------+------+---------------+---------------+---------------+ 1324 | Inserted | -- | IP-in-IP(RPI) | -- | -- | 1325 | headers | | | | | 1326 | Removed | -- | -- | -- | IP-in-IP(RPI) | 1327 | headers | | | | | 1328 | Re-added | -- | -- | -- | -- | 1329 | headers | | | | | 1330 | Modified | -- | -- | IP-in-IP(RPI) | -- | 1331 | headers | | | | | 1332 | Untouched | -- | -- | -- | -- | 1333 | headers | | | | | 1334 +------------+------+---------------+---------------+---------------+ 1336 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1337 root 1339 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1341 In this section we are going to describe the communication flow in 1342 Non Storing Mode (Non-SM) between, 1344 RPL-aware-leaf to Internet 1346 Internet to RPL-aware-leaf 1348 not-RPL-aware-leaf to Internet 1350 Internet to not-RPL-aware-leaf 1352 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1354 In this case the flow comprises: 1356 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1358 For example, the communication flow could be: Node F --> Node D --> 1359 Node B --> Node A --> Internet 1361 6LR_i are the intermediate routers from source to destination. In 1362 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1363 packet go through from source (6LN) to 6LBR. 1365 This case is identical to storing-mode case. 1367 The IPv6 flow label should be set to zero to aid in compression, and 1368 the 6LBR will set it to a non-zero value when sending towards the 1369 Internet. 1371 +-------------------+------+-------+------+----------------+ 1372 | Header | 6LN | 6LR_i | 6LBR | Internet | 1373 +-------------------+------+-------+------+----------------+ 1374 | Inserted headers | RPI | -- | -- | -- | 1375 | Removed headers | -- | -- | -- | -- | 1376 | Re-added headers | -- | -- | -- | -- | 1377 | Modified headers | -- | RPI | -- | -- | 1378 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1379 +-------------------+------+-------+------+----------------+ 1381 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1382 Internet 1384 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1386 In this case the flow comprises: 1388 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1390 For example, the communication flow could be: Internet --> Node A 1391 (root) --> Node B --> Node D --> Node F 1393 6LR_i are the intermediate routers from source to destination. In 1394 this case, "1 <= i >= n", n is the number of routers (6LR) that the 1395 packet go through from 6LBR to destination(6LN). 1397 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1398 address of the target node, it can address the IP-in-IP header to 1399 that node. The 6LBR will zero the flow label upon entry in order to 1400 aid compression. 1402 The RPI may be added or not, it is optional. 1404 +--------+-------+----------------+----------------+----------------+ 1405 | Header | Inter | 6LBR | 6LR_i | 6LN | 1406 | | net | | | | 1407 +--------+-------+----------------+----------------+----------------+ 1408 | Insert | -- | IP-in-IP(RH3,o | -- | -- | 1409 | ed hea | | pt:RPI) | | | 1410 | ders | | | | | 1411 | Remove | -- | -- | -- | IP-in-IP(RH3,o | 1412 | d head | | | | pt:RPI) | 1413 | ers | | | | | 1414 | Re- | -- | -- | -- | -- | 1415 | added | | | | | 1416 | header | | | | | 1417 | s | | | | | 1418 | Modifi | -- | -- | IP-in-IP(RH3,o | -- | 1419 | ed hea | | | pt:RPI) | | 1420 | ders | | | | | 1421 | Untouc | -- | -- | -- | -- | 1422 | hed he | | | | | 1423 | aders | | | | | 1424 +--------+-------+----------------+----------------+----------------+ 1426 Non Storing: Summary of the use of headers from Internet to RPL- 1427 aware-leaf 1429 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1431 In this case the flow comprises: 1433 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1434 Internet 1436 For example, the communication flow could be: Node G --> Node E --> 1437 Node B --> Node A --> Internet 1439 6LR_i are the intermediate routers from source to destination. In 1440 this case, "1 < i >= n", n is the number of routers (6LR) that the 1441 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1443 In this case the flow label is recommended to be zero in the IPv6 1444 node. As RPL headers are added in the IPv6 node, the first 6LR 1445 (6LR_1) will add an RPI header inside a new IP-in-IP header. The IP- 1446 in-IP header will be addressed to the root. This case is identical 1447 to the storing-mode case (Section 5.7). 1449 +---------+-----+-------------+-------------+-------------+---------+ 1450 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | 1451 | | 6 | | [i=2,..,n]_ | | t | 1452 +---------+-----+-------------+-------------+-------------+---------+ 1453 | Inserte | -- | IP-in- | -- | -- | -- | 1454 | d | | IP(RPI) | | | | 1455 | headers | | | | | | 1456 | Removed | -- | -- | -- | IP-in- | -- | 1457 | headers | | | | IP(RPI) | | 1458 | Re- | -- | -- | -- | -- | -- | 1459 | added | | | | | | 1460 | headers | | | | | | 1461 | Modifie | -- | -- | IP-in- | -- | -- | 1462 | d | | | IP(RPI) | | | 1463 | headers | | | | | | 1464 | Untouch | -- | -- | -- | -- | -- | 1465 | ed | | | | | | 1466 | headers | | | | | | 1467 +---------+-----+-------------+-------------+-------------+---------+ 1469 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1470 Internet 1472 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1474 In this case the flow comprises: 1476 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1478 For example, the communication flow could be: Internet --> Node A 1479 (root) --> Node B --> Node E --> Node G 1481 6LR_i are the intermediate routers from source to destination. In 1482 this case, "1 < i >= n", n is the number of routers (6LR) that the 1483 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1485 The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR 1486 will know the path, and will recognize that the final node is not an 1487 RPL capable node as it will have received the connectivity DAO from 1488 the nearest 6LR. The 6LBR can therefore make the IP-in-IP header 1489 destination be the last 6LR. The 6LBR will set to zero the flow 1490 label upon entry in order to aid compression. 1492 +--------+-------+----------------+------------+-------------+------+ 1493 | Header | Inter | 6LBR | 6LR_1 | 6LR_i(i=2,. | IPv6 | 1494 | | net | | | .,n) | | 1495 +--------+-------+----------------+------------+-------------+------+ 1496 | Insert | -- | IP-in-IP(RH3,o | -- | -- | -- | 1497 | ed hea | | pt:RPI) | | | | 1498 | ders | | | | | | 1499 | Remove | -- | -- | -- | IP-in- | -- | 1500 | d head | | | | IP(RH3, | | 1501 | ers | | | | RPI) | | 1502 | Re- | -- | -- | -- | -- | -- | 1503 | added | | | | | | 1504 | header | | | | | | 1505 | s | | | | | | 1506 | Modifi | -- | -- | IP-in- | IP-in- | -- | 1507 | ed hea | | | IP(RH3, | IP(RH3, | | 1508 | ders | | | RPI) | RPI) | | 1509 | Untouc | -- | -- | -- | -- | RPI | 1510 | hed he | | | | | | 1511 | aders | | | | | | 1512 +--------+-------+----------------+------------+-------------+------+ 1514 NonStoring: Summary of the use of headers from Internet to non-RPL- 1515 aware-leaf 1517 7.3. Non-Storing Mode: Interaction between Leafs 1519 In this section we are going to describe the communication flow in 1520 Non Storing Mode (Non-SM) between, 1522 RPL-aware-leaf to RPL-aware-leaf 1524 RPL-aware-leaf to not-RPL-aware-leaf 1526 not-RPL-aware-leaf to RPL-aware-leaf 1528 not-RPL-aware-leaf to not-RPL-aware-leaf 1530 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1532 In this case the flow comprises: 1534 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1536 For example, the communication flow could be: Node F --> Node D --> 1537 Node B --> Node A (root) --> Node B --> Node E --> Node H 1538 6LR_ia are the intermediate routers from source to the root In this 1539 case, "1 <= ia >= n", n is the number of routers (6LR) that the 1540 packet go through from 6LN to the root. 1542 6LR_id are the intermediate routers from the root to the destination. 1543 In this case, "1 <= ia >= m", m is the number of the intermediate 1544 routers (6LR). 1546 This case involves only nodes in same RPL Domain. The originating 1547 node will add an RPI header to the original packet, and send the 1548 packet upwards. 1550 The originating node SHOULD put the RPI into an IP-in-IP header 1551 addressed to the root, so that the 6LBR can remove that header. If 1552 it does not, then additional resources are wasted on the way down to 1553 carry the useless RPI option. 1555 The 6LBR will need to insert an RH3 header, which requires that it 1556 add an IP-in-IP header. It SHOULD be able to remove the RPI, as it 1557 was contained in an IP-in-IP header addressed to it. Otherwise, 1558 there MAY be an RPI header buried inside the inner IP header, which 1559 should get ignored. 1561 Networks that use the RPL P2P extension [RFC6997] are essentially 1562 non-storing DODAGs and fall into this scenario or scenario 1563 Section 7.1.2, with the originating node acting as 6LBR. 1565 +---------+-------------+------+--------------+-------+-------------+ 1566 | Header | 6LN src | 6LR_ | 6LBR | 6LR_i | 6LN dst | 1567 | | | ia | | d | | 1568 +---------+-------------+------+--------------+-------+-------------+ 1569 | Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- | 1570 | d | IP(RPI1) | | to 6LN, opt | | | 1571 | headers | | | RPI2) | | | 1572 | Removed | -- | -- | IP-in- | -- | IP-in- | 1573 | headers | | | IP(RPI1) | | IP(RH3, opt | 1574 | | | | | | RPI2) | 1575 | Re- | -- | -- | -- | -- | -- | 1576 | added | | | | | | 1577 | headers | | | | | | 1578 | Modifie | -- | RPI1 | -- | RPI2 | -- | 1579 | d | | | | | | 1580 | headers | | | | | | 1581 | Untouch | -- | -- | -- | -- | -- | 1582 | ed | | | | | | 1583 | headers | | | | | | 1584 +---------+-------------+------+--------------+-------+-------------+ 1586 Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- 1587 aware-leaf 1589 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1590 leaf 1592 In this case the flow comprises: 1594 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1596 For example, the communication flow could be: Node F --> Node D --> 1597 Node B --> Node A (root) --> Node B --> Node E --> Node G 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 As in the previous case, the 6LN will insert an RPI (RPI_1) header 1607 which MUST be in an IP-in-IP header addressed to the root so that the 1608 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a 1609 new IP-in-IP header addressed to the 6LN destination node. The RPI 1610 is optional from 6LBR to 6LR_id (RPI_2). 1612 +--------+-----------+------------+-------------+------------+------+ 1613 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1614 +--------+-----------+------------+-------------+------------+------+ 1615 | Insert | IP-in- | -- | IP-in- | -- | -- | 1616 | ed hea | IP(RPI1) | | IP(RH3, opt | | | 1617 | ders | | | RPI_2) | | | 1618 | Remove | -- | -- | IP-in- | IP-in- | -- | 1619 | d head | | | IP(RPI_1) | IP(RH3, | | 1620 | ers | | | | opt RPI_2) | | 1621 | Re- | -- | -- | -- | -- | -- | 1622 | added | | | | | | 1623 | header | | | | | | 1624 | s | | | | | | 1625 | Modifi | -- | IP-in- | -- | IP-in- | -- | 1626 | ed hea | | IP(RPI_1) | | IP(RH3, | | 1627 | ders | | | | opt RPI_2) | | 1628 | Untouc | -- | -- | -- | -- | opt | 1629 | hed he | | | | | RPI_ | 1630 | aders | | | | | 2 | 1631 +--------+-----------+------------+-------------+------------+------+ 1633 Non Storing: Summary of the use of headers from RPL-aware-leaf to 1634 not-RPL-aware-leaf 1636 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1637 leaf 1639 In this case the flow comprises: 1641 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 1642 6LN 1644 For example, the communication flow could be: Node G --> Node E --> 1645 Node B --> Node A (root) --> Node B --> Node E --> Node H 1647 6LR_ia are the intermediate routers from source to the root In this 1648 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1650 6LR_id are the intermediate routers from the root to the destination. 1651 In this case, "1 <= ia >= m", m is the number of the intermediate 1652 routers (6LR). 1654 This scenario is mostly identical to the previous one. The RPI is 1655 added by the first 6LR (6LR_1) inside an IP-in-IP header addressed to 1656 the root. The 6LBR will remove this RPI, and add it's own IP-in-IP 1657 header containing an RH3 header and optional RPI (RPI_2). 1659 +--------+-----+------------+-------------+------------+------------+ 1660 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN | 1661 | | 6 | | | | | 1662 +--------+-----+------------+-------------+------------+------------+ 1663 | Insert | -- | IP-in- | IP-in- | -- | -- | 1664 | ed hea | | IP(RPI_1) | IP(RH3, opt | | | 1665 | ders | | | RPI_2) | | | 1666 | Remove | -- | -- | IP-in- | -- | IP-in- | 1667 | d head | | | IP(RPI_1) | | IP(RH3, | 1668 | ers | | | | | opt RPI_2) | 1669 | Re- | -- | -- | -- | -- | -- | 1670 | added | | | | | | 1671 | header | | | | | | 1672 | s | | | | | | 1673 | Modifi | -- | -- | -- | IP-in- | -- | 1674 | ed hea | | | | IP(RH3, | | 1675 | ders | | | | opt RPI_2) | | 1676 | Untouc | -- | -- | -- | -- | -- | 1677 | hed he | | | | | | 1678 | aders | | | | | | 1679 +--------+-----+------------+-------------+------------+------------+ 1681 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1682 RPL-aware-leaf 1684 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1685 aware-leaf 1687 In this case the flow comprises: 1689 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1690 not-RPL-aware (IPv6 dst) 1692 For example, the communication flow could be: Node G --> Node E --> 1693 Node B --> Node A (root) --> Node C --> Node J 1695 6LR_ia are the intermediate routers from source to the root In this 1696 case, "1 <= ia >= n", n is the number of intermediate routers (6LR) 1698 6LR_id are the intermediate routers from the root to the destination. 1699 In this case, "1 <= ia >= m", m is the number of the intermediate 1700 routers (6LR). 1702 This scenario is the combination of the previous two cases. 1704 +---------+-----+--------------+---------------+-------------+------+ 1705 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1706 | | 6 | | | | dst | 1707 | | src | | | | | 1708 +---------+-----+--------------+---------------+-------------+------+ 1709 | Inserte | -- | IP-in- | IP-in-IP(RH3) | -- | -- | 1710 | d | | IP(RPI_1) | | | | 1711 | headers | | | | | | 1712 | Removed | -- | -- | IP-in- | IP-in- | -- | 1713 | headers | | | IP(RPI_1) | IP(RH3, opt | | 1714 | | | | | RPI_2) | | 1715 | Re- | -- | -- | -- | -- | -- | 1716 | added | | | | | | 1717 | headers | | | | | | 1718 | Modifie | -- | -- | -- | -- | -- | 1719 | d | | | | | | 1720 | headers | | | | | | 1721 | Untouch | -- | -- | -- | -- | -- | 1722 | ed | | | | | | 1723 | headers | | | | | | 1724 +---------+-----+--------------+---------------+-------------+------+ 1726 Non Storing: Summary of the use of headers from not-RPL-aware-leaf to 1727 not-RPL-aware-leaf 1729 8. Observations about the cases 1731 8.1. Storing mode 1733 [I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP 1734 header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header 1735 as described in Section 7 of the document. 1737 There are potential significant advantages to having a single code 1738 path that always processes IP-in-IP headers with no options. 1740 Thanks to the change of the RPI option type from 0x63 to 0x23, there 1741 is no longer any uncertainty about when to use an IP-in-IP header in 1742 the storing mode. A Hop-by-Hop Options Header containing the RPI 1743 option SHOULD always be added when 6LRs originate packets (without 1744 IP-in-IP headers), and IP-in-IP headers should always be added 1745 (addressed to the root when on the way up, to the end-host when on 1746 the way down) when a 6LR find that it needs to insert a Hop-by-Hop 1747 Options Header containing the RPI option. 1749 In order to support the above two cases with full generality, the 1750 different situations (always do IP-in-IP vs never use IP-in-IP) 1751 should be signaled in the RPL protocol itself. 1753 8.2. Non-Storing mode 1755 In the non-storing case, dealing with non-RPL aware leaf nodes is 1756 much easier as the 6LBR (DODAG root) has complete knowledge about the 1757 connectivity of all DODAG nodes, and all traffic flows through the 1758 root node. 1760 The 6LBR can recognize non-RPL aware leaf nodes because it will 1761 receive a DAO about that node from the 6LN immediately above that 1762 node. This means that the non-storing mode case can avoid ever using 1763 hop-by-hop IP-in-IP headers. 1765 Unlike in the storing mode case, there is no need for all nodes to 1766 know about the existence of non-RPL aware nodes. Only the 6LBR needs 1767 to change when there are non-RPL aware nodes. Further, in the non- 1768 storing case, the 6LBR is informed by the DAOs when there are non-RPL 1769 aware nodes. 1771 9. 6LoRH Compression cases 1773 The [I-D.ietf-roll-routing-dispatch] proposes a compression method 1774 for RPI, RH3 and IPv6-in-IPv6. 1776 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 1777 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 1778 an IP-in-IP and RPI compression headers. The type of this case is 1779 critical since IP-in-IP is encapsulating a RPI header. 1781 +--+-----+---+--------------+-----------+-------------+-------------+ 1782 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | 1783 +--+-----+---+--------------+-----------+-------------+-------------+ 1785 Figure 9: Critical IP-in-IP (RPI). 1787 10. IANA Considerations 1789 This document updates the registration made in [RFC6553] Destination 1790 Options and Hop-by-Hop Options registry from 0x63 to 0x23. 1792 Hex Value Binary Value 1793 act chg rest Description Reference 1794 --------- --- --- ------- ----------------- ---------- 1795 0x23 00 1 00011 RPL Option [RFCXXXX] 1796 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 1798 Figure 10: Option Type in RPL Option. 1800 We propose to use DODAG Configuration Option Flags in the DODAG 1801 Configuration option as follows: 1803 +------------+-----------------+---------------+ 1804 | Bit number | Description | Reference | 1805 +------------+-----------------+---------------+ 1806 | 3 | RPI 0x23 enable | This document | 1807 +------------+-----------------+---------------+ 1809 Figure 11: DODAG Configuration Option Flag to indicate the RPI-flag- 1810 day. 1812 11. Security Considerations 1814 The security considerations covering of [RFC6553] and [RFC6554] apply 1815 when the packets get into RPL Domain. 1817 The IPIP mechanism described in this document is much more limited 1818 than the general mechanism described in [RFC2473]. The willingness 1819 of each node in the LLN to decapsulate packets and forward them could 1820 be exploited by nodes to disguise the origin of an attack. 1822 Nodes outside of the LLN will need to pass IPIP traffic through the 1823 RPL root to perform this attack. To counter, the RPL root SHOULD 1824 either restrict ingress of IPIP packets (the simpler solution), or it 1825 SHOULD do a deep packet inspection wherein it walks the IP header 1826 extension chain until it can inspect the upper-layer-payload as 1827 described in [RFC7045]. In particular, the RPL root SHOULD do BCP38 1828 ([RFC2827]) processing on the source addresses of all IP headers that 1829 it examines in both directions. 1831 Note: there are some situations where a prefix will spread across 1832 multiple LLNs via mechanisms such as described in 1833 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 1834 needs to take this into account. 1836 Nodes with the LLN can use the IPIP mechanism to mount an attack on 1837 another part of the LLN, while disguising the origin of the attack. 1838 The mechanism can even be abused to make it appear that the attack is 1839 coming from outside the LLN, and unless countered, this could be used 1840 to mount a Distributed Denial Of Service attack upon nodes elsewhere 1841 in the Internet. See [DDOS-KREBS] for an example of such attacks 1842 already seen in the real world. 1844 While a typical LLN may be a very poor origin for attack traffic (as 1845 the networks tend to be very slow, and the nodes often have very low 1846 duty cycles) given enough nodes, they could still have a significant 1847 impact, particularly if the attack was on another LLN! Additionally, 1848 some uses of RPL involve large backbone ISP scale equipment 1849 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1850 multiple 100Gb/s interfaces. 1852 Blocking or careful filtering of IPIP traffic entering the LLN as 1853 described above will make sure that any attack that is mounted must 1854 originate compromised nodes within the LLN. The use of BCP38 1855 filtering at the RPL root on egress traffic will both alert the 1856 operator to the existence of the attack, as well as drop the attack 1857 traffic. As the RPL network is typically numbered from a single 1858 prefix, which is itself assigned by RPL, BCP38 filtering involves a 1859 single prefix comparison and should be trivial to automatically 1860 configure. 1862 There are some scenarios where IPIP traffic SHOULD be allowed to pass 1863 through the RPL root, such as the IPIP mediated communications 1864 between a new Pledge and the Join Registrar/Coordinator (JRC) when 1865 using [I-D.ietf-anima-bootstrapping-keyinfra] and 1866 [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the 1867 RPL root to do careful filtering: it occurs only when the Join 1868 Coordinator is not co-located inside the RPL root. 1870 With the above precautions, an attack using IPIP tunnels will be by a 1871 node within the LLN on another node within the LLN. Such an attack 1872 could, of course, be done directly. An attack of this kind is 1873 meaningful only if the source addresses are either fake or if the 1874 point is to amplify return traffic. Such an attack, could also be 1875 done without the use of IPIP headers using forged source addresses. 1876 If the attack requires bi-directional communication, then IPIP 1877 provides no advantages. 1879 [RFC2473] suggests that tunnel entry and exit points can be secured, 1880 via the "Use IPsec". This solution has all the problems that 1881 [RFC5406] goes into. In an LLN such a solution would degenerate into 1882 every node having a tunnel with every other node. It would provide a 1883 small amount of origin address authentication at a very high cost; 1884 doing BCP38 at every node (linking layer-3 addresses to layer-2 1885 addresses, and to already present layer-2 cryptographic mechanisms) 1886 would be cheaper should RPL be run in an environment where hostile 1887 nodes are likely to be a part of the LLN. 1889 The RH3 header usage described here can be abused in equivalent ways 1890 with an IPIP header to add the needed RH3 header. As such, the 1891 attacker's RH3 header will not be seen by the network until it 1892 reaches the end host, which will decapsulate it. An end-host SHOULD 1893 be suspicious about a RH3 header which has additional hops which have 1894 not yet been processed, and SHOULD ignore such a second RH3 header. 1896 In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch] 1897 to compress the IPIP and RH3 headers. As such, the compressor at the 1898 RPL-root will see the second RH3 header and MAY choose to discard the 1899 packet if the RH3 header has not been completely consumed. A 1900 consumed (inert) RH3 header could be present in a packet that flows 1901 from one LLN, crosses the Internet, and enters another LLN. As per 1902 the discussion in this document, such headers do not need to be 1903 removed. However, there is no case described in this document where 1904 an RH3 is inserted in a non-storing network on traffic that is 1905 leaving the LLN, but this document SHOULD NOT preclude such a future 1906 innovation. It should just be noted that an incoming RH3 must be 1907 fully consumed, or very carefully inspected. 1909 The RPI header, if permitted to enter the LLN, could be used by an 1910 attacker to change the priority of a packet by selecting a different 1911 RPL instanceID, perhaps one with a higher energy cost, for instance. 1912 It could also be that not all nodes are reachable in an LLN using the 1913 default instanceID, but a change of instanceID would permit an 1914 attacker to bypass such filtering. Like the RH3, an RPI header is to 1915 be inserted by the RPL root on traffic entering the LLN by first 1916 inserting an IPIP header. The attacker's RPI header therefore will 1917 not be seen by the network. Upon reaching the destination node the 1918 RPI header has no further meaning and is just skipped; the presence 1919 of a second RPI header will have no meaning to the end node as the 1920 packet has already been identified as being at it's final 1921 destination. 1923 The RH3 and RPI headers could be abused by an attacker inside of the 1924 network to route packets on non-obvious ways, perhaps eluding 1925 observation. This usage is in fact part of [RFC6997] and can not be 1926 restricted at all. This is a feature, not a bug. 1928 [RFC7416] deals with many other threats to LLNs not directly related 1929 to the use of IPIP headers, and this document does not change that 1930 analysis. 1932 12. Acknowledgments 1934 This work is partially funded by the FP7 Marie Curie Initial Training 1935 Network (ITN) METRICS project (grant agreement No. 607728). 1937 The authors would like to acknowledge the review, feedback, and 1938 comments of (alphabetical order): Robert Cragie, Simon Duquennoy, 1939 Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias 1940 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 1942 13. References 1944 13.1. Normative References 1946 [I-D.ietf-6man-rfc2460bis] 1947 Deering, S. and R. Hinden, "Internet Protocol, Version 6 1948 (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work 1949 in progress), May 2017. 1951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1952 Requirement Levels", BCP 14, RFC 2119, 1953 DOI 10.17487/RFC2119, March 1997, 1954 . 1956 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1957 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 1958 December 1998, . 1960 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1961 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1962 December 1998, . 1964 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1965 Defeating Denial of Service Attacks which employ IP Source 1966 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1967 May 2000, . 1969 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1970 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 1971 February 2009, . 1973 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 1974 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 1975 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 1976 Low-Power and Lossy Networks", RFC 6550, 1977 DOI 10.17487/RFC6550, March 2012, 1978 . 1980 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1981 Power and Lossy Networks (RPL) Option for Carrying RPL 1982 Information in Data-Plane Datagrams", RFC 6553, 1983 DOI 10.17487/RFC6553, March 2012, 1984 . 1986 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 1987 Routing Header for Source Routes with the Routing Protocol 1988 for Low-Power and Lossy Networks (RPL)", RFC 6554, 1989 DOI 10.17487/RFC6554, March 2012, 1990 . 1992 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 1993 of IPv6 Extension Headers", RFC 7045, 1994 DOI 10.17487/RFC7045, December 2013, 1995 . 1997 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 1998 and M. Richardson, Ed., "A Security Threat Analysis for 1999 the Routing Protocol for Low-Power and Lossy Networks 2000 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2001 . 2003 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2004 "IPv6 over Low-Power Wireless Personal Area Network 2005 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2006 April 2017, . 2008 13.2. Informative References 2010 [DDOS-KREBS] 2011 Goodin, D., "Record-breaking DDoS reportedly delivered by 2012 >145k hacked cameras", September 2016, 2013 . 2016 [I-D.ietf-6lo-backbone-router] 2017 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 2018 backbone-router-04 (work in progress), July 2017. 2020 [I-D.ietf-6tisch-architecture] 2021 Thubert, P., "An Architecture for IPv6 over the TSCH mode 2022 of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work 2023 in progress), August 2017. 2025 [I-D.ietf-6tisch-dtsecurity-secure-join] 2026 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2027 6tisch-dtsecurity-secure-join-01 (work in progress), 2028 February 2017. 2030 [I-D.ietf-anima-autonomic-control-plane] 2031 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2032 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2033 plane-12 (work in progress), October 2017. 2035 [I-D.ietf-anima-bootstrapping-keyinfra] 2036 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2037 S., and K. Watsen, "Bootstrapping Remote Secure Key 2038 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2039 keyinfra-08 (work in progress), October 2017. 2041 [I-D.ietf-roll-dao-projection] 2042 Thubert, P. and J. Pylakutty, "Root initiated routing 2043 state in RPL", draft-ietf-roll-dao-projection-02 (work in 2044 progress), September 2017. 2046 [I-D.ietf-roll-routing-dispatch] 2047 Thubert, P., Bormann, C., Toutain, L., and R. Cragie, 2048 "6LoWPAN Routing Header", draft-ietf-roll-routing- 2049 dispatch-05 (work in progress), October 2016. 2051 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2052 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2053 DOI 10.17487/RFC4192, September 2005, 2054 . 2056 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2057 Control Message Protocol (ICMPv6) for the Internet 2058 Protocol Version 6 (IPv6) Specification", STD 89, 2059 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2060 . 2062 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2063 Bormann, "Neighbor Discovery Optimization for IPv6 over 2064 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2065 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2066 . 2068 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2069 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2070 in Low-Power and Lossy Networks", RFC 6997, 2071 DOI 10.17487/RFC6997, August 2013, 2072 . 2074 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2075 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2076 2014, . 2078 [Second6TischPlugtest] 2079 "2nd 6Tisch Plugtest", . 2082 Authors' Addresses 2084 Maria Ines Robles 2085 Ericsson 2086 Hirsalantie 11 2087 Jorvas 02420 2088 Finland 2090 Email: maria.ines.robles@ericsson.com 2092 Michael C. Richardson 2093 Sandelman Software Works 2094 470 Dawson Avenue 2095 Ottawa, ON K1Z 5V7 2096 CA 2098 Email: mcr+ietf@sandelman.ca 2099 URI: http://www.sandelman.ca/mcr/ 2101 Pascal Thubert 2102 Cisco Systems, Inc 2103 Village d'Entreprises Green Side 400, Avenue de Roumanille 2104 Batiment T3, Biot - Sophia Antipolis 06410 2105 France 2107 Email: pthubert@cisco.com