idnits 2.17.00 (12 Aug 2021) /tmp/idnits24367/draft-ietf-roll-useofrplinfo-25.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 232 has weird spacing: '... act chg ...' == Line 269 has weird spacing: '... act chg ...' == Line 1916 has weird spacing: '... act chg ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1167 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 1919, but not defined == Outdated reference: draft-ietf-6lo-ap-nd has been published as RFC 8928 == Outdated reference: draft-ietf-6lo-backbone-router has been published as RFC 8929 == 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 (-07) exists of draft-thubert-roll-unaware-leaves-06 Summary: 0 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group M. Robles 3 Internet-Draft Aalto 4 Updates: 6553, 6550, 8138 (if approved) M. Richardson 5 Intended status: Standards Track SSW 6 Expires: September 12, 2019 P. Thubert 7 Cisco 8 March 11, 2019 10 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 11 encapsulation in the RPL Data Plane 12 draft-ietf-roll-useofrplinfo-25 14 Abstract 16 This document looks at different data flows through LLN (Low-Power 17 and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power 18 and Lossy Networks) is used to establish routing. The document 19 enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 20 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is 21 required in data plane. This analysis provides the basis on which to 22 design efficient compression of these headers. This document updates 23 RFC 6553 adding a change to the RPL Option Type. Additionally, this 24 document updates RFC 6550 to indicate about this change and updates 25 RFC8138 as well to consider the new Option Type when RPL Option is 26 decompressed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2019. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 4 65 3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5 66 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 67 3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 8 68 3.3. Updates to RFC 6550: Indicating the new RPI in the 69 DODAG Configuration Option Flag. . . . . . . . . . . . . 8 70 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 9 71 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 16 74 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 17 75 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 18 76 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 18 77 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 19 78 6.2. Storing Mode: Interaction between Leaf and Internet. . . 20 79 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 20 80 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 21 81 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 82 Internet . . . . . . . . . . . . . . . . . . . . . . 22 83 6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 84 leaf. . . . . . . . . . . . . . . . . . . . . . . . . 23 85 6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 24 86 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware- 87 leaf . . . . . . . . . . . . . . . . . . . . . . . . 24 88 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 89 aware-leaf . . . . . . . . . . . . . . . . . . . . . 26 90 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL- 91 aware-leaf . . . . . . . . . . . . . . . . . . . . . 26 92 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 93 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 28 94 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 29 95 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 30 96 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 31 97 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 31 98 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 99 leaf . . . . . . . . . . . . . . . . . . . . . . . . 32 100 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 101 root . . . . . . . . . . . . . . . . . . . . . . . . 33 102 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 34 103 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 104 Internet . . . . . . . . . . . . . . . . . . . . . . 34 105 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 106 leaf . . . . . . . . . . . . . . . . . . . . . . . . 35 107 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 108 Internet . . . . . . . . . . . . . . . . . . . . . . 36 109 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 110 aware-leaf . . . . . . . . . . . . . . . . . . . . . 37 111 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 38 112 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 113 aware-leaf . . . . . . . . . . . . . . . . . . . . . 38 114 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 115 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 40 116 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 117 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 41 118 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 119 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 42 120 8. Operational Considerations of supporting 121 not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 42 122 9. Operational considerations of introducing 0x23 . . . . . . . 43 123 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 125 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 126 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 127 13.1. Normative References . . . . . . . . . . . . . . . . . . 48 128 13.2. Informative References . . . . . . . . . . . . . . . . . 49 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 131 1. Introduction 133 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 134 [RFC6550] is a routing protocol for constrained networks. RFC 6553 135 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 136 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 137 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 138 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 139 RPL routing domain, particularly in non-storing mode. 141 These various items are referred to as RPL artifacts, and they are 142 seen on all of the data-plane traffic that occurs in RPL routed 143 networks; they do not in general appear on the RPL control plane 144 traffic at all which is mostly hop-by-hop traffic (one exception 145 being DAO messages in non-storing mode). 147 It has become clear from attempts to do multi-vendor 148 interoperability, and from a desire to compress as many of the above 149 artifacts as possible that not all implementors agree when artifacts 150 are necessary, or when they can be safely omitted, or removed. 152 An interim meeting went through the 24 cases defined here to discover 153 if there were any shortcuts, and this document is the result of that 154 discussion. This document clarifies examples that intend to 155 illustrate the result of the normative language in RFC8200 and 156 RFC6553. In other words, the examples are intended to be normative 157 explanation of the results of executing that language. 159 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 160 mechanism for compressing RPL Option information and Routing Header 161 type 3 [RFC6554], as well as an efficient IPv6-in-IPv6 technique. 163 1.1. Overview 165 The rest of the document is organized as follows: Section 2 describes 166 the used terminology. Section 3 describes the updates to RFC6553, 167 RFC6550 and RFC 8138. Section 4 provides the reference topology used 168 for the uses cases. Section 5 describes the uses cases included. 169 Section 6 describes the storing mode cases and section 7 the non- 170 storing mode cases. Section 8 describes the operational 171 considerations of supporting not-RPL-aware-leaves. Section 9 depicts 172 operational considerations for the proposed change on RPL Option 173 type, section 10 the IANA considerations and then section 11 174 describes the security aspects. 176 2. Terminology and Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119], [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 185 RPL, RPL Domain and ROLL. 187 RPL-node: A device which implements RPL, thus the device is RPL- 188 aware. Please note that the device can be found inside the LLN or 189 outside LLN. In this document a RPL-node which is a leaf of a 190 (Destination Oriented Directed Acyclic Graph) DODAG is called RPL- 191 aware-leaf (Raf). 193 RPL-not-capable: A device which does not implement RPL, thus the 194 device is not-RPL-aware. Please note that the device can be found 195 inside the LLN. In this document a not-RPL-aware node which is a 196 leaf of a DODAG is called not-RPL-aware-leaf (~Raf). 198 6LN: [RFC6775] defines it as: "A 6LoWPAN node is any host or router 199 participating in a LoWPAN. This term is used when referring to 200 situations in which either a host or router can play the role 201 described.". In this document, a 6LN acts as a leaf. 203 6LR, 6LBR are defined in [RFC6775]. 205 Flag Day: A transition that involves having a network with different 206 values of RPL Option Type. Thus the network does not work correctly. 208 Hop-by-hop IPv6-in-IPv6 headers: The term "hop-by-hop IPv6-in-IPv6" 209 header refers to: adding a header that originates from a node to an 210 adjacent node, using the addresses (usually the GUA or ULA, but could 211 use the link-local addresses) of each node. If the packet must 212 traverse multiple hops, then it must be decapsulated at each hop, and 213 then re-encapsulated again in a similar fashion. 215 3. Updates to RFC6553, RFC6550 and RFC 8138 217 3.1. Updates to RFC 6553 219 This modification is required to be able to send, for example, IPv6 220 packets from a RPL-aware-leaf to a not-RPL-aware node through 221 Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 222 encapsulation. 224 [RFC6553] states as shown below, that in the Option Type field of the 225 RPL Option header, the two high order bits must be set to '01' and 226 the third bit is equal to '1'. The first two bits indicate that the 227 IPv6 node must discard the packet if it doesn't recognize the option 228 type, and the third bit indicates that the Option Data may change in 229 route. The remaining bits serve as the option type. 231 Hex Value Binary Value 232 act chg rest Description Reference 233 --------- --- --- ------- ----------------- ---------- 234 0x63 01 1 00011 RPL Option [RFC6553] 236 Figure 1: Option Type in RPL Option. 238 Recent changes in [RFC8200] (section 4, page 8), states: "it is now 239 expected that nodes along a packet's delivery path only examine and 240 process the Hop-by-Hop Options header if explicitly configured to do 241 so". Processing of the Hop-by-Hop Options header (by IPv6 242 intermediate nodes) is now optional, but if they are configured to 243 process the header, and if such nodes encounter an option with the 244 first two bits set to 01, they will drop the packet (if they conform 245 to [RFC8200]). Host systems should do the same, irrespective of the 246 configuration. 248 Based on that, if an IPv6 (intermediate) node (RPL-not-capable) 249 receives a packet with an RPL Option, it should ignore the HBH RPL 250 option (skip over this option and continue processing the header). 251 This is relevant, as it was mentioned previously, in the case that 252 there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). 254 Thus, this document updates the Option Type field to: the two high 255 order bits MUST be set to '00' and the third bit is equal to '1'. 256 The first two bits indicate that the IPv6 node MUST skip over this 257 option and continue processing the header ([RFC8200] Section 4.2) if 258 it doesn't recognize the option type, and the third bit continues to 259 be set to indicate that the Option Data may change en route. The 260 remaining bits serve as the option type and remain as 0x3. This 261 ensures that a packet that leaves the RPL domain of an LLN (or that 262 leaves the LLN entirely) will not be discarded when it contains the 263 [RFC6553] RPL Hop-by-Hop option known as RPI. 265 This is a significant update to [RFC6553]. [RFCXXXX] represents this 266 document. 268 Hex Value Binary Value 269 act chg rest Description Reference 270 --------- --- --- ------- ----------------- ---------- 271 0x23 00 1 00011 RPL Option [RFCXXXX] 273 Figure 2: Revised Option Type in RPL Option. 275 This change creates a flag day for existing networks which are 276 currently using 0x63 as the RPI value. A move to 0x23 will not be 277 understood by those networks. It is suggested that implementations 278 accept both 0x63 and 0x23 when processing. 280 In the cases where a forwarding node is forwarding traffic that is 281 not addressed directly to it (such as when the outer IPv6-in-IPv6 282 header is not a Link-Local address), then RFC8200 forbids changing 283 the RPI type code when forwarding. 285 When forwarding traffic that is wrapped in Link-Local IPv6-in-IPv6 286 headers, the forwarding node is in effect originating new packets, 287 and it MAY make a choice as to whether to use the old (0x63) RPI Type 288 code, or the new (0x23) RPI Type code. In that situation, 289 implementations SHOULD use the same value as was received. This 290 allows to the network to be incrementally upgraded, and in some cases 291 may allow the DODAG root to know which parts of the network are 292 upgraded. 294 A network which is switching from straight 6lowpan compression 295 mechanism to those described in [RFC8138] will experience a flag day 296 in the data compression anyway, and if possible this change can be 297 deployed at the same time. 299 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 300 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 301 therefore no longer a necessity to remove the artifacts when sending 302 traffic to the Internet. This change clarifies when to use an IPv6- 303 in-IPv6 header, and how to address them: The Hop-by-Hop Options 304 Header containing the RPI option SHOULD always be added when 6LRs 305 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 306 headers SHOULD always be added when a 6LR find that it needs to 307 insert a Hop-by-Hop Options Header containing the RPI option. The 308 IPv6-in-IPv6 header is to be addressed to the RPL root when on the 309 way up, and to the end-host when on the way down. 311 Non-constrained uses of RPL are not in scope of this document, and 312 applicability statements for those uses may provide different advice, 313 E.g. [I-D.ietf-anima-autonomic-control-plane]. 315 In the non-storing case, dealing with non-RPL aware leaf nodes is 316 much easier as the 6LBR (DODAG root) has complete knowledge about the 317 connectivity of all DODAG nodes, and all traffic flows through the 318 root node. 320 The 6LBR can recognize non-RPL aware leaf nodes because it will 321 receive a DAO about that node from the 6LR immediately above that 322 non-RPL aware node. This means that the non-storing mode case can 323 avoid ever using hop-by-hop IPv6-in-IPv6 headers for traffic 324 originating from the root to leafs. 326 The non-storing mode case does not require the type change from 0x63 327 to 0x23, as the root can always create the right packet. The type 328 change does not adversely affect the non-storing case. 330 3.2. Updates to RFC 8138 332 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 333 in section 6. A node that is decompressing this header MUST 334 decompress using the RPL RPI option type that is currently active: 335 that is, a choice between 0x23 (new) and 0x63 (old). The node will 336 know which to use based upon the presence of the DODAG Configuration 337 Option described in the next section. E.g. If the network is in 338 0x23 mode (by DIO option), then it should be decompressed to 0x23. 340 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 341 header. 343 There are potential significant advantages to having a single code 344 path that always processes IPv6-in-IPv6 headers with no options. 346 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 347 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 348 an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in- 349 IPv6 header is MANDATORY in this case, and it SHOULD be compressed 350 with [RFC8138] section 7. 352 +--+-----+---+--------------+-----------+-----------+-----------+ 353 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI-6LoRH |LOWPAN IPHC| 354 +--+-----+---+--------------+-----------+-----------+-----------+ 356 Figure 3: IPv6-in-IPv6 (RPI). 358 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 359 Configuration Option Flag. 361 In order to avoid a Flag Day caused by lack of interoperation between 362 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 363 in the DIO Configuration Option, to indicate when then new RPI value 364 can be safely used. Without this, there could be a mix of new nodes 365 (which understand 0x23 and 0x63), and old nodes (which understand 366 0x63 only). A new node would not know if it was safe to use 0x23. 368 This is done via a DODAG Configuration Option flag which will 369 propagate through the network. If the flag is received with a value 370 zero (which is the default), then new nodes will remain in RFC6553 371 Compatible Mode; originating traffic with the old-RPI (0x63) value. 373 As stated in [RFC6550] the DODAG Configuration option is present in 374 DIO messages. The DODAG Configuration option distributes 375 configuration information. It is generally static, and does not 376 change within the DODAG. This information is configured at the DODAG 377 root and distributed throughout the DODAG with the DODAG 378 Configuration option. Nodes other than the DODAG root do not modify 379 this information when propagating the DODAG Configuration option. 381 The DODAG Configuration Option has a Flag field which is modified by 382 this document. Currently, the DODAG Configuration Option in 383 [RFC6550] states: "the unused bits MUST be initialize to zero by the 384 sender and MUST be ignored by the receiver". 386 Bit number three of the flag field in the DODAG Configuration option 387 is to be used as follows: 389 +------------+-----------------+---------------+ 390 | Bit number | Description | Reference | 391 +------------+-----------------+---------------+ 392 | 3 | RPI 0x23 enable | This document | 393 +------------+-----------------+---------------+ 395 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 396 day. 398 In case of rebooting, the node (6LN or 6LR) does not remember if the 399 flag is set, so DIO messages would be set with the flag unset until a 400 DIO is received with the flag set. 402 4. Sample/reference topology 404 A RPL network in general is composed of a 6LBR (6LoWPAN Border 405 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 406 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 408 Figure 4 shows the reference RPL Topology for this document. The 409 letters above the nodes are there so that they may be referenced in 410 subsequent sections. In the figure, 6LR represents a full router 411 node. The 6LN is a RPL aware router, or host (as a leaf). 412 Additionally, for simplification purposes, it is supposed that the 413 6LBR has direct access to Internet, thus the 6BBR is not present in 414 the figure. 416 The 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I) are 417 RPL nodes with no children hosts. 419 The leafs marked as ~Raf "not-RPL aware leaf" (G and J) are devices 420 which do not speak RPL at all (not-RPL-aware), but uses Router- 421 Advertisements, 6LowPAN DAR/DAC and efficient-ND only to participate 422 in the network [RFC6775]. In the document these leafs (G and J) are 423 also referred to as an IPv6 node. 425 The 6LBR ("A") in the figure is the root of the Global DODAG. 427 +------------+ 428 | INTERNET ----------+ 429 | | | 430 +------------+ | 431 | 432 | 433 | 434 A | 435 +-------+ 436 |6LBR | 437 +-----------|(root) |-------+ 438 | +-------+ | 439 | | 440 | | 441 | | 442 | | 443 | B |C 444 +---|---+ +---|---+ 445 | 6LR | | 6LR | 446 +-------->| |--+ +--- ---+ 447 | +-------+ | | +-------+ | 448 | | | | 449 | | | | 450 | | | | 451 | | | | 452 | D | E | | 453 +-|-----+ +---|---+ | | 454 | 6LR | | 6LR | | | 455 | | +------ | | | 456 +---|---+ | +---|---+ | | 457 | | | | | 458 | | +--+ | | 459 | | | | | 460 | | | | | 461 | | | I | J | 462 F | | G | H | | 463 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 464 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 465 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 466 +-------+ +-------+ +------+ +-------+ +-------+ 468 Figure 5: A reference RPL Topology. 470 RPL defines the RPL Control messages (control plane), a new ICMPv6 471 [RFC4443] message with Type 155. DIS (DODAG Information 472 Solicitation), DIO (DODAG Information Object) and DAO (Destination 473 Advertisement Object) messages are all RPL Control messages but with 474 different Code values. A RPL Stack is shown in Figure 5. 476 +--------------+ 477 | Upper Layers | 478 | | 479 +--------------+ 480 | RPL | 481 | | 482 +--------------+ 483 | ICMPv6 | 484 | | 485 +--------------+ 486 | IPv6 | 487 | | 488 +--------------+ 489 | 6LoWPAN | 490 | | 491 +--------------+ 492 | PHY-MAC | 493 | | 494 +--------------+ 496 Figure 6: RPL Stack. 498 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 499 it is fully stateful; in non-storing (RPL-NSM), it is fully source 500 routed. A RPL Instance is either fully storing or fully non-storing, 501 i.e. a RPL Instance with a combination of storing and non-storing 502 nodes is not supported with the current specifications at the time of 503 writing this document. 505 5. Use cases 507 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 508 encapsulation are going to be analyzed for a number of representative 509 traffic flows. 511 This document assumes that the LLN is using the no-drop RPI option 512 (0x23). 514 The uses cases describe the communication between RPL-aware-nodes, 515 with the root (6LBR), and with Internet. This document also describe 516 the communication between nodes acting as leaves that do not 517 understand RPL, but are part of the LLN. these nodes are named as 518 not-RPL-aware-leaf, mentioned previously. (e.g. Section 6.1.4 Flow 519 from not-RPL-aware-leaf to root) This document describes also how is 520 the communication inside of the LLN when it has the final destination 521 addressed outside of the LLN e.g. with destination to Internet. 522 (e.g. Section 6.2.3 Flow from not-RPL-aware-leaf to Internet) 524 The uses cases comprise as follow: 526 Interaction between Leaf and Root: 528 RPL-aware-leaf to root 530 root to RPL-aware-leaf 532 not-RPL-aware-leaf to root 534 root to not-RPL-aware-leaf 536 Interaction between Leaf and Internet: 538 RPL-aware-leaf to Internet 540 Internet to RPL-aware-leaf 542 not-RPL-aware-leaf to Internet 544 Internet to not-RPL-aware-leaf 546 Interaction between Leafs: 548 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 550 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 552 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 554 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 556 This document is consistent with the rule that a Header cannot be 557 inserted or removed on the fly inside an IPv6 packet that is being 558 routed. This is a fundamental precept of the IPv6 architecture as 559 outlined in [RFC8200]. Extensions may not be added or removed except 560 by the sender or the receiver. 562 However, unlike [RFC6553], the Hop-by-Hop Option Header used for the 563 RPI artifact has the first two bits set to '00'. This means that the 564 RPI artifact will be ignored when received by a host or router that 565 does not understand that option ( Section 4.2 [RFC8200]). 567 This means that when the no-drop RPI option code 0x23 is used, a 568 packet that leaves the RPL domain of an LLN (or that leaves the LLN 569 entirely) will not be discarded when it contains the [RFC6553] RPL 570 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is 571 left in place even if the end host does not understand it. 573 NOTE: There is some possible security risk when the RPI information 574 is released to the Internet. At this point this is a theoretical 575 situation; no clear attack has been described. At worst, it is clear 576 that the RPI option would waste some network bandwidth when it 577 escapes. This is traded off against the savings in the LLN by not 578 having to encapsulate the packet in order to remove the artifact. 580 As the rank information in the RPI artifact is changed at each hop, 581 it will typically be zero when it arrives at the DODAG root. The 582 DODAG root SHOULD force it to zero when passing the packet out to the 583 Internet. The Internet will therefore not see any SenderRank 584 information. 586 Despite being legal to leave the RPI artifact in place, an 587 intermediate router that needs to add an extension header (RH3 or RPI 588 Option) MUST still encapsulate the packet in an (additional) outer IP 589 header. The new header is placed after this new outer IP header. 591 A corollary is that an RH3 or RPI Option can only be removed by an 592 intermediate router if it is placed in an encapsulating IPv6 Header, 593 which is addressed TO the intermediate router. When it does so, the 594 whole encapsulating header must be removed. (A replacement may be 595 added). This sometimes can result in outer IP headers being 596 addressed to the next hop router using link-local address. 598 Both RPI and RH3 headers may be modified in very specific ways by 599 routers on the path of the packet without the need to add to remove 600 an encapsulating header. Both headers were designed with this 601 modification in mind, and both the RPL RH3 and the RPL option are 602 marked mutable but recoverable: so an IPsec AH security header can be 603 applied across these headers, but it can not secure the values which 604 mutate. 606 RPI MUST be present in every single RPL data packet. There is one 607 exception in non-storing mode: when a packet is going down from the 608 root the RPI MAY be omitted. The rational is that in a downward non- 609 storing mode, the entire route is written, so there can be no loops 610 by construction, nor any confusion about which forwarding table to 611 use (as the root has already made all routing decisions). However, 612 there are still cases, such as in 6tisch, where the instanceID 613 portion of the RPI header may still be needed [RFC8180] to pick an 614 appropriate priority or channel at each hop. 616 Prior to [RFC8138], there was significant interest in removing the 617 RPI for downward flows in non-storing mode. The exception covered a 618 very small number of cases, and causes significant interoperability 619 challenges, yet costed significant code and testing complexity. The 620 ability to compress the RPI down to three bytes or less removes much 621 of the pressure to optimize this any further 622 [I-D.ietf-anima-autonomic-control-plane]. 624 The earlier examples are more extensive to make sure that the process 625 is clear, while later examples are more concise. 627 6. Storing mode 629 In storing mode (fully stateful), the sender can determine if the 630 destination is inside the LLN by looking if the destination address 631 is matched by the DIO's Prefix Information Option (PIO) option. 633 The following table (Figure 7) itemizes which headers are needed in 634 each of the following scenarios. It indicate if an IPv6-in-IPv6 635 header must be inserted, and whether the destination address of the 636 IPv6-in-IPv6 header is the next hop, or the final target address. 637 There are these possible situations: hop-by-hop necessary (indicated 638 by "hop"), or final target address possible (indicated by "tgt"). In 639 all cases hop by hop may be used rather than the final target 640 address. 642 In cases where no IPv6-in-IPv6 header is needed, the column states as 643 "No". 645 In all cases the RPI headers are needed, since it identifies 646 inconsistencies (loops) in the routing topology. In all cases the 647 RH3 is not needed because it is not used in storing mode. 649 In each case, 6LR_i are the intermediate routers from source to 650 destination. "1 <= i <= n", n is the number of routers (6LR) that 651 the packet go through from source (6LN) to destination. 653 The leaf can be a router 6LR or a host, both indicated as 6LN (see 654 Figure 5). 656 +---------------------+--------------+------------+--------------+ 657 | Interaction between | Use Case |IPv6-in-IPv6| v6-in-v6 dst | 658 +---------------------+--------------+------------+--------------+ 659 | | Raf to root | No | No | 660 + +--------------+------------+--------------+ 661 | Leaf - Root | root to Raf | No | No | 662 + +--------------+------------+--------------+ 663 | | root to ~Raf | No | No | 664 + +--------------+------------+--------------+ 665 | | ~Raf to root | must | root | 666 +---------------------+--------------+------------+--------------+ 667 | | Raf to Int | No | No | 668 + +--------------+------------+--------------+ 669 | Leaf - Internet | Int to Raf | must | tgt (Raf) | 670 + +--------------+------------+--------------+ 671 | | ~Raf to Int | must | root | 672 + +--------------+------------+--------------+ 673 | | Int to ~Raf | must | hop | 674 +---------------------+--------------+------------+--------------+ 675 | | Raf to Raf | No | No | 676 + +--------------+------------+--------------+ 677 | | Raf to ~Raf | No | No | 678 + Leaf - Leaf +--------------+------------+--------------+ 679 | | ~Raf to Raf | must | tgt (Raf) | 680 + +--------------+------------+--------------+ 681 | | ~Raf to ~Raf | Yes | hop | 682 +---------------------+--------------+------------+--------------+ 684 Figure 7: Table of IPv6-in-IPv6 encapsulation in Storing mode. 686 6.1. Storing Mode: Interaction between Leaf and Root 688 In this section is described the communication flow in storing mode 689 (SM) between, 691 RPL-aware-leaf to root 693 root to RPL-aware-leaf 695 not-RPL-aware-leaf to root 697 root to not-RPL-aware-leaf 699 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 701 In storing mode, RFC 6553 (RPI) is used to send RPL Information 702 instanceID and rank information. 704 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 705 generally issue DIO messages; a leaf node accepts DIO messages from 706 upstream. (When the inconsistency in routing occurs, a leaf node 707 will generate a DIO with an infinite rank, to fix it). It may issue 708 DAO and DIS messages though it generally ignores DAO and DIS 709 messages. 711 In this case the flow comprises: 713 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 715 For example, a communication flow could be: Node F --> Node E --> 716 Node B --> Node A root(6LBR) 718 As it was mentioned in this document 6LRs, 6LBR are always full- 719 fledged RPL routers. 721 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 722 (Node E) which decrements the rank in RPI and sends the packet up. 723 When the packet arrives at 6LBR (Node A), the RPI is removed and the 724 packet is processed. 726 No IPv6-in-IPv6 header is required. 728 The RPI header can be removed by the 6LBR because the packet is 729 addressed to the 6LBR. The 6LN must know that it is communicating 730 with the 6LBR to make use of this scenario. The 6LN can know the 731 address of the 6LBR because it knows the address of the root via the 732 DODAGID in the DIO messages. 734 +-------------------+-----+-------+------+ 735 | Header | 6LN | 6LR_i | 6LBR | 736 +-------------------+-----+-------+------+ 737 | Inserted headers | RPI | -- | -- | 738 | Removed headers | -- | -- | RPI | 739 | Re-added headers | -- | -- | -- | 740 | Modified headers | -- | RPI | -- | 741 | Untouched headers | -- | -- | -- | 742 +-------------------+-----+-------+------+ 744 Table 1: Storing: Summary of the use of headers from RPL-aware-leaf 745 to root 747 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 749 In this case the flow comprises: 751 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 753 For example, a communication flow could be: Node A root(6LBR) --> 754 Node B --> Node D --> Node F 756 In this case the 6LBR inserts RPI header and sends the packet down, 757 the 6LR is going to increment the rank in RPI (it examines the 758 instanceID to identify the right forwarding table), the packet is 759 processed in the 6LN and the RPI removed. 761 No IPv6-in-IPv6 header is required. 763 +-------------------+------+-------+------+ 764 | Header | 6LBR | 6LR_i | 6LN | 765 +-------------------+------+-------+------+ 766 | Inserted headers | RPI | -- | -- | 767 | Removed headers | -- | -- | RPI | 768 | Re-added headers | -- | -- | -- | 769 | Modified headers | -- | RPI | -- | 770 | Untouched headers | -- | -- | -- | 771 +-------------------+------+-------+------+ 773 Table 2: Storing: Summary of the use of headers from root to RPL- 774 aware-leaf 776 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 778 In this case the flow comprises: 780 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 782 For example, a communication flow could be: Node A root(6LBR) --> 783 Node B --> Node E --> Node G 785 As the RPI extension can be ignored by the not-RPL-aware leaf, this 786 situation is identical to the previous scenario. 788 +-------------------+------+-------+----------------+ 789 | Header | 6LBR | 6LR_i | IPv6 | 790 +-------------------+------+-------+----------------+ 791 | Inserted headers | RPI | -- | -- | 792 | Removed headers | -- | -- | -- | 793 | Re-added headers | -- | -- | -- | 794 | Modified headers | -- | RPI | -- | 795 | Untouched headers | -- | -- | RPI (Ignored) | 796 +-------------------+------+-------+----------------+ 798 Table 3: Storing: Summary of the use of headers from root to not-RPL- 799 aware-leaf 801 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 803 In this case the flow comprises: 805 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 807 For example, a communication flow could be: Node G --> Node E --> 808 Node B --> Node A root(6LBR) 810 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 811 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 812 header. The IPv6-in-IPv6 header can be addressed to the next hop 813 (Node B), or to the root (Node A). The root removes the header and 814 processes the packet. 816 +---------+-----+---------------+------------------+----------------+ 817 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | 818 | | 6 | | | | 819 +---------+-----+---------------+------------------+----------------+ 820 | Inserte | -- | IPv6-in- | IPv6-in- | -- | 821 | d | | IPv6(RPI) | IPv6(RPI)(1) | | 822 | headers | | | | | 823 | Removed | -- | -- | -- | IPv6-in- | 824 | headers | | | | IPv6(RPI) | 825 | Re- | -- | -- | IPv6-in- | -- | 826 | added | | | IPv6(RPI)(1) | | 827 | headers | | | | | 828 | Modifie | -- | -- | IPv6-in- | -- | 829 | d | | | IPv6(RPI)(2) | | 830 | headers | | | | | 831 | Untouch | -- | -- | -- | -- | 832 | ed | | | | | 833 | headers | | | | | 834 +---------+-----+---------------+------------------+----------------+ 836 Table 4: Storing: Summary of the use of headers from not-RPL-aware- 837 leaf to root. (1) Case where the IPv6-in-IPv6 header is addressed to 838 the next hop (Node B). (2) Case where the IPv6-in-IPv6 header is 839 addressed to the root (Node A) 841 6.2. Storing Mode: Interaction between Leaf and Internet. 843 In this section is described the communication flow in storing mode 844 (SM) between, 846 RPL-aware-leaf to Internet 848 Internet to RPL-aware-leaf 850 not-RPL-aware-leaf to Internet 852 Internet to not-RPL-aware-leaf 854 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 856 RPL information from RFC 6553 may go out to Internet as it will be 857 ignored by nodes which have not been configured to be RPI aware. 859 In this case the flow comprises: 861 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 862 For example, the communication flow could be: Node F --> Node D --> 863 Node B --> Node A root(6LBR) --> Internet 865 No IPv6-in-IPv6 header is required. 867 Note: In this use case it is used a node as leaf, but this use case 868 can be also applicable to any RPL-node type (e.g. 6LR) 870 +-------------------+------+-------+------+----------------+ 871 | Header | 6LN | 6LR_i | 6LBR | Internet | 872 +-------------------+------+-------+------+----------------+ 873 | Inserted headers | RPI | -- | -- | -- | 874 | Removed headers | -- | -- | -- | -- | 875 | Re-added headers | -- | -- | -- | -- | 876 | Modified headers | -- | RPI | -- | -- | 877 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 878 +-------------------+------+-------+------+----------------+ 880 Table 5: Storing: Summary of the use of headers from RPL-aware-leaf 881 to Internet 883 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 885 In this case the flow comprises: 887 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 889 For example, a communication flow could be: Internet --> Node A 890 root(6LBR) --> Node B --> Node D --> Node F 892 When the packet arrives from Internet to 6LBR the RPI header is added 893 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 894 rank in the RPI. When the packet arrives at 6LN the RPI header is 895 removed and the packet processed. 897 +---------+--------+---------------+---------------+----------------+ 898 | Header | Intern | 6LBR | 6LR_i | 6LN | 899 | | et | | | | 900 +---------+--------+---------------+---------------+----------------+ 901 | Inserte | -- | IPv6-in- | -- | -- | 902 | d | | IPv6(RPI) | | | 903 | headers | | | | | 904 | Removed | -- | -- | -- | IPv6-in- | 905 | headers | | | | IPv6(RPI) | 906 | Re- | -- | -- | -- | -- | 907 | added | | | | | 908 | headers | | | | | 909 | Modifie | -- | -- | IPv6-in- | -- | 910 | d | | | IPv6(RPI) | | 911 | headers | | | | | 912 | Untouch | -- | -- | -- | -- | 913 | ed | | | | | 914 | headers | | | | | 915 +---------+--------+---------------+---------------+----------------+ 917 Table 6: Storing: Summary of the use of headers from Internet to RPL- 918 aware-leaf 920 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 922 In this case the flow comprises: 924 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 925 Internet 927 For example, a communication flow could be: Node G --> Node E --> 928 Node B --> Node A root(6LBR) --> Internet 930 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 931 either to the root, or hop-by-hop such that the root can remove the 932 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 933 root cause less processing overhead. On the other hand, with hop-by- 934 hop the intermediate routers can check the routing tables for a 935 better routing path, thus it could be more efficient and faster. 936 Implementation should decide which approach to take. 938 The originating node will ideally leave the IPv6 flow label as zero 939 so that the packet can be better compressed through the LLN. The 940 6LBR will set the flow label of the packet to a non-zero value when 941 sending to the Internet. 943 +-------+----+-------------+---------------+---------------+--------+ 944 | Heade | IP | 6LR_1 | 6LR_i | 6LBR | Intern | 945 | r | v6 | | [i=2,..,n]_ | | et | 946 +-------+----+-------------+---------------+---------------+--------+ 947 | Inser | -- | IPv6-in- | IPv6-in- | -- | -- | 948 | ted h | | IPv6(RPI) | IPv6(RPI)(2) | | | 949 | eader | | | | | | 950 | s | | | | | | 951 | Remov | -- | -- | IPv6-in- | IPv6-in- | -- | 952 | ed he | | | IPv6(RPI)(2) | IPv6(RPI)(1) | | 953 | aders | | | | | | 954 | Re- | -- | -- | -- | -- | -- | 955 | added | | | | | | 956 | heade | | | | | | 957 | rs | | | | | | 958 | Modif | -- | -- | IPv6-in- | -- | -- | 959 | ied h | | | IPv6(RPI)(1) | | | 960 | eader | | | | | | 961 | s | | | | | | 962 | Untou | -- | -- | -- | -- | -- | 963 | ched | | | | | | 964 | heade | | | | | | 965 | rs | | | | | | 966 +-------+----+-------------+---------------+---------------+--------+ 968 Table 7: Storing: Summary of the use of headers from not-RPL-aware- 969 leaf to Internet. (1) Case when packet is addressed to the root. 970 (2) Case when the packet is addressed hop-by-hop. 972 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf. 974 In this case the flow comprises: 976 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 978 For example, a communication flow could be: Internet --> Node A 979 root(6LBR) --> Node B --> Node E --> Node G 981 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 982 header. The IPv6-in-IPv6 is addressed to the not-RPL-aware-leaf, 983 leaving the RPI inside. 985 The final node should be able to remove one or more IPv6-in-IPv6 986 headers which are all addressed to it. Furhter details about this 987 are mentioned in [I-D.thubert-roll-unaware-leaves], which specifies 988 RPL routing for a 6LN acting as a plain host and not aware of RPL. 990 The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to 991 zero in order to aid in compression. 993 +--------+---------+---------------+---------------+----------------+ 994 | Header | Interne | 6LBR | 6LR_i | IPv6 | 995 | | t | | | | 996 +--------+---------+---------------+---------------+----------------+ 997 | Insert | -- | IPv6-in- | -- | -- | 998 | ed hea | | IPv6(RPI) | | | 999 | ders | | | | | 1000 | Remove | -- | -- | -- | IPv6-in- | 1001 | d head | | | | IPv6(RPI)- RPI | 1002 | ers | | | | (Ignored) | 1003 | Re- | -- | -- | -- | -- | 1004 | added | | | | | 1005 | header | | | | | 1006 | s | | | | | 1007 | Modifi | -- | -- | IPv6-in- | -- | 1008 | ed hea | | | IPv6(RPI) | | 1009 | ders | | | | | 1010 | Untouc | -- | -- | -- | -- | 1011 | hed he | | | | | 1012 | aders | | | | | 1013 +--------+---------+---------------+---------------+----------------+ 1015 Table 8: Storing: Summary of the use of headers from Internet to non- 1016 RPL-aware-leaf 1018 6.3. Storing Mode: Interaction between Leaf and Leaf 1020 In this section is described the communication flow in storing mode 1021 (SM) between, 1023 RPL-aware-leaf to RPL-aware-leaf 1025 RPL-aware-leaf to not-RPL-aware-leaf 1027 not-RPL-aware-leaf to RPL-aware-leaf 1029 not-RPL-aware-leaf to not-RPL-aware-leaf 1031 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1033 In [RFC6550] RPL allows a simple one-hop optimization for both 1034 storing and non-storing networks. A node may send a packet destined 1035 to a one-hop neighbor directly to that node. See section 9 in 1036 [RFC6550]. 1038 When the nodes are not directly connected, then in storing mode, the 1039 flow comprises: 1041 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1043 For example, a communication flow could be: Node F --> Node D --> 1044 Node B --> Node E --> Node H 1046 6LR_ia (Node D) are the intermediate routers from source to the 1047 common parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the 1048 number of routers (6LR) that the packet go through from 6LN (Node F) 1049 to the common parent (6LR_x). 1051 6LR_id (Node E) are the intermediate routers from the common parent 1052 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1053 <= m", m is the number of routers (6LR) that the packet go through 1054 from the common parent (6LR_x) to destination 6LN. 1056 It is assumed that the two nodes are in the same RPL Domain (that 1057 they share the same DODAG root). At the common parent (Node B), the 1058 direction of RPI is changed (from increasing to decreasing the rank). 1060 While the 6LR nodes will update the RPI, no node needs to add or 1061 remove the RPI, so no IPv6-in-IPv6 headers are necessary. This may 1062 be done regardless of where the destination is, as the included RPI 1063 will be ignored by the receiver. 1065 +---------------+--------+--------+---------------+--------+--------+ 1066 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1067 | | src | | parent) | | dst | 1068 +---------------+--------+--------+---------------+--------+--------+ 1069 | Inserted | RPI | -- | -- | -- | -- | 1070 | headers | | | | | | 1071 | Removed | -- | -- | -- | -- | RPI | 1072 | headers | | | | | | 1073 | Re-added | -- | -- | -- | -- | -- | 1074 | headers | | | | | | 1075 | Modified | -- | RPI | RPI | RPI | -- | 1076 | headers | | | | | | 1077 | Untouched | -- | -- | -- | -- | -- | 1078 | headers | | | | | | 1079 +---------------+--------+--------+---------------+--------+--------+ 1081 Table 9: Storing: Summary of the use of headers for RPL-aware-leaf to 1082 RPL-aware-leaf 1084 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 1086 In this case the flow comprises: 1088 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1089 6LN (IPv6) 1091 For example, a communication flow could be: Node F --> Node D --> 1092 Node B --> Node E --> Node G 1094 6LR_ia are the intermediate routers from source (6LN) to the common 1095 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1096 routers (6LR) that the packet go through from 6LN to the common 1097 parent (6LR_x). 1099 6LR_id (Node E) are the intermediate routers from the common parent 1100 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1101 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1102 the packet go through from the common parent (6LR_x) to destination 1103 6LN. 1105 This situation is identical to the previous situation Section 6.3.1 1107 +-----------+------+--------+---------------+--------+--------------+ 1108 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 1109 | | src | | parent) | | | 1110 +-----------+------+--------+---------------+--------+--------------+ 1111 | Inserted | RPI | -- | -- | -- | -- | 1112 | headers | | | | | | 1113 | Removed | -- | -- | -- | -- | -- | 1114 | headers | | | | | | 1115 | Re-added | -- | -- | -- | -- | -- | 1116 | headers | | | | | | 1117 | Modified | -- | RPI | RPI | RPI | -- | 1118 | headers | | | | | | 1119 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1120 | headers | | | | | | 1121 +-----------+------+--------+---------------+--------+--------------+ 1123 Table 10: Storing: Summary of the use of headers for RPL-aware-leaf 1124 to non-RPL-aware-leaf 1126 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1128 In this case the flow comprises: 1130 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1131 6LR_id --> 6LN 1132 For example, a communication flow could be: Node G --> Node E --> 1133 Node B --> Node D --> Node F 1135 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 1136 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In 1137 this case, "1 <= ia <= n", n is the number of routers (6LR) that the 1138 packet go through from source to the common parent. 1140 6LR_id (Node D) are the intermediate routers from the common parent 1141 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1142 <= m", m is the number of routers (6LR) that the packet go through 1143 from the common parent (6LR_x) to destination 6LN. 1145 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1146 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1147 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1148 (Node F). 1150 +-------+----+------------+-------------+-------------+-------------+ 1151 | Heade | IP | 6LR_ia | common | 6LR_id | 6LN | 1152 | r | v6 | | parent | | | 1153 | | | | (6LRx) | | | 1154 +-------+----+------------+-------------+-------------+-------------+ 1155 | Inser | -- | IPv6-in- | -- | -- | -- | 1156 | ted h | | IPv6(RPI) | | | | 1157 | eader | | | | | | 1158 | s | | | | | | 1159 | Remov | -- | -- | -- | -- | IPv6-in- | 1160 | ed he | | | | | IPv6(RPI) | 1161 | aders | | | | | | 1162 | Re- | -- | -- | -- | -- | -- | 1163 | added | | | | | | 1164 | heade | | | | | | 1165 | rs | | | | | | 1166 | Modif | -- | -- | IPv6-in- | IPv6-in- | -- | 1167 | ied h | | | IPv6(RPI) | IPv6(RPI) | | 1168 | eader | | | | | | 1169 | s | | | | | | 1170 | Untou | -- | -- | -- | -- | -- | 1171 | ched | | | | | | 1172 | heade | | | | | | 1173 | rs | | | | | | 1174 +-------+----+------------+-------------+-------------+-------------+ 1176 Table 11: Storing: Summary of the use of headers from not-RPL-aware- 1177 leaf to RPL-aware-leaf 1179 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1180 leaf 1182 In this case the flow comprises: 1184 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not- 1185 RPL-aware 6LN (IPv6 dst) 1187 For example, a communication flow could be: Node G --> Node E --> 1188 Node B --> Node A (root) --> Node C --> Node J 1190 Internal nodes 6LR_ia (e.g: Node E or Node B) are the intermediate 1191 routers from the not-RPL-aware source (Node G) to the root (6LBR) 1192 (Node A). In this case, "1 < ia <= n", n is the number of routers 1193 (6LR) that the packet go through from IPv6 src to the root. 1195 6LR_id (C) are the intermediate routers from the root (Node A) to the 1196 destination Node J. In this case, "1 <= id <= m", m is the number of 1197 routers (6LR) that the packet go through from the root to destination 1198 (IPv6 dst). 1200 Note that this flow is identical to Section 6.3.3, except for where 1201 the IPv6-in-IPv6 header is inserted. 1203 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1204 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1205 header. The IPv6-in-IPv6 header is addressed to the final 1206 destination (Node J). 1208 +-------+----+------------+-------------+-------------+-------------+ 1209 | Heade | IP | 6LR_1 | 6LR_ia | 6LR_m | IPv6 dst | 1210 | r | v6 | | | | | 1211 | | sr | | | | | 1212 | | c | | | | | 1213 +-------+----+------------+-------------+-------------+-------------+ 1214 | Inser | -- | IPv6-in- | -- | -- | -- | 1215 | ted h | | IPv6(RPI) | | | | 1216 | eader | | | | | | 1217 | s | | | | | | 1218 | Remov | -- | -- | -- | -- | IPv6-in- | 1219 | ed he | | | | | IPv6(RPI), | 1220 | aders | | | | | RPI Ignored | 1221 | Re- | -- | -- | -- | -- | -- | 1222 | added | | | | | | 1223 | heade | | | | | | 1224 | rs | | | | | | 1225 | Modif | -- | -- | IPv6-in- | IPv6-in- | -- | 1226 | ied h | | | IPv6(RPI) | IPv6(RPI) | | 1227 | eader | | | | | | 1228 | s | | | | | | 1229 | Untou | -- | -- | -- | -- | -- | 1230 | ched | | | | | | 1231 | heade | | | | | | 1232 | rs | | | | | | 1233 +-------+----+------------+-------------+-------------+-------------+ 1235 Table 12: Storing: Summary of the use of headers from not-RPL-aware- 1236 leaf to non-RPL-aware-leaf 1238 7. Non Storing mode 1240 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1241 root) has complete knowledge about the connectivity of all DODAG 1242 nodes, and all traffic flows through the root node. Thus, there is 1243 no need for all nodes to know about the existence of non-RPL aware 1244 nodes. Only the 6LBR needs to act if compensation is necessary for 1245 non-RPL aware receivers. 1247 The following table (Figure 8) summarizes what headers are needed in 1248 the following scenarios, and indicates when the RPI, RH3 and IPv6-in- 1249 IPv6 header are to be inserted. There are these possible situations: 1250 target destination address possible (indicated by "tgt"), to a 6LR, 1251 to a 6LN or to the root. In cases where no IPv6-in-IPv6 header is 1252 needed, the column states as "No". 1254 The leaf can be a router 6LR or a host, both indicated as 6LN 1255 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1256 where the instanceID portion of the RPI header may still be needed to 1257 pick an appropriate priority or channel at each hop. 1259 +-----------------+--------------+-----+-----+----------+----------+ 1260 | Interaction | Use Case | RPI | RH3 | v6-in-v6 | v6-in-v6 | 1261 | between | | | | | dst | 1262 +-----------------+--------------+-----+-----+----------+----------+ 1263 | | Raf to root | Yes | No | No | No | 1264 + +--------------+-----+-----+----------+----------+ 1265 | Leaf - Root | root to Raf | Opt | Yes | No | No | 1266 + +--------------+-----+-----+----------+----------+ 1267 | | root to ~Raf |No(1)| Yes | must | 6LR | 1268 + +--------------+-----+-----+----------+----------+ 1269 | | ~Raf to root | Yes | No | must | root | 1270 +-----------------+--------------+-----+-----+----------+----------+ 1271 | | Raf to Int | Yes | No | must | root | 1272 + +--------------+-----+-----+----------+----------+ 1273 | Leaf - Internet | Int to Raf |No(1)| Yes | must | tgt | 1274 + +--------------+-----+-----+----------+----------+ 1275 | | ~Raf to Int | Yes | No | must | root | 1276 + +--------------+-----+-----+----------+----------+ 1277 | | Int to ~Raf |No(1)| Yes | must | 6LR | 1278 +-----------------+--------------+-----+-----+----------+----------+ 1279 | | Raf to Raf | Yes | Yes | must | root/tgt | 1280 + +--------------+-----+-----+----------+----------+ 1281 | | Raf to ~Raf | Yes | Yes | must | root/6LR | 1282 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1283 | | ~Raf to Raf | Yes | Yes | must | root/6LN | 1284 + +--------------+-----+-----+----------+----------+ 1285 | | ~Raf to ~Raf | Yes | Yes | must | root/6LR | 1286 +-----------------+--------------+-----+-----+----------+----------+ 1288 (1)-6tisch networks may need the RPI information. 1290 Figure 8: Table that shows headers needed in Non-Storing mode: RPI, 1291 RH3, IPv6-in-IPv6 encapsulation. 1293 7.1. Non-Storing Mode: Interaction between Leaf and Root 1295 In this section is described the communication flow in Non Storing 1296 Mode (Non-SM) between, 1298 RPL-aware-leaf to root 1300 root to RPL-aware-leaf 1302 not-RPL-aware-leaf to root 1303 root to not-RPL-aware-leaf 1305 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1307 In non-storing mode the leaf node uses default routing to send 1308 traffic to the root. The RPI header must be included since it 1309 contains the rank information, which is used to avoid/detect loops. 1311 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1313 For example, a communication flow could be: Node F --> Node D --> 1314 Node B --> Node A (root) 1316 6LR_i are the intermediate routers from source to destination. In 1317 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1318 packet go through from source (6LN) to destination (6LBR). 1320 This situation is the same case as storing mode. 1322 +-------------------+-----+-------+------+ 1323 | Header | 6LN | 6LR_i | 6LBR | 1324 +-------------------+-----+-------+------+ 1325 | Inserted headers | RPI | -- | -- | 1326 | Removed headers | -- | -- | RPI | 1327 | Re-added headers | -- | -- | -- | 1328 | Modified headers | -- | RPI | -- | 1329 | Untouched headers | -- | -- | -- | 1330 +-------------------+-----+-------+------+ 1332 Table 13: Non Storing: Summary of the use of headers from RPL-aware- 1333 leaf to root 1335 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1337 In this case the flow comprises: 1339 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1341 For example, a communication flow could be: Node A (root) --> Node B 1342 --> Node D --> Node F 1344 6LR_i are the intermediate routers from source to destination. In 1345 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1346 packet go through from source (6LBR) to destination (6LN). 1348 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1349 necessary as the traffic originates with an RPL aware node, the 6LBR. 1351 The destination is known to RPL-aware because, the root knows the 1352 whole topology in non-storing mode. 1354 +-------------------+-----------------+-------+------------------+ 1355 | Header | 6LBR | 6LR_i | 6LN | 1356 +-------------------+-----------------+-------+------------------+ 1357 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1358 | Removed headers | -- | -- | RH3, (opt: RPI) | 1359 | Re-added headers | -- | -- | -- | 1360 | Modified headers | -- | RH3 | -- | 1361 | Untouched headers | -- | -- | -- | 1362 +-------------------+-----------------+-------+------------------+ 1364 Table 14: Non Storing: Summary of the use of headers from root to 1365 RPL-aware-leaf 1367 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1369 In this case the flow comprises: 1371 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1373 For example, a communication flow could be: Node A (root) --> Node B 1374 --> Node E --> Node G 1376 6LR_i are the intermediate routers from source to destination. In 1377 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1378 packet go through from source (6LBR) to destination (IPv6). 1380 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1381 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1382 but left there. If RPI is left by the previous 6LR, then the IPv6 1383 node which does not understand the RPI, will ignore it (following 1384 RFC8200), thus encapsulation is not necessary. Due to the complete 1385 knowledge of the topology at the root, the 6LBR may optionally 1386 address the IPv6-in-IPv6 header to the last 6LR, such that it is 1387 removed prior to the IPv6 node. Please see Section 8 for 1388 clarification of use of IPv6-in-IPv6 encapsulation. 1390 +---------------+-------------+--------------+------------+---------+ 1391 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1392 +---------------+-------------+--------------+------------+---------+ 1393 | Inserted | (opt: RPI), | -- | -- | -- | 1394 | headers | RH3 | | | | 1395 | Removed | -- | -- | RH3 | -- | 1396 | headers | | | | | 1397 | Re-added | -- | -- | -- | -- | 1398 | headers | | | | | 1399 | Modified | -- | (opt: RPI), | (opt: RPI) | -- | 1400 | headers | | RH3 | | | 1401 | Untouched | -- | -- | -- | opt: | 1402 | headers | | | | RPI | 1403 +---------------+-------------+--------------+------------+---------+ 1405 Table 15: Non Storing: Summary of the use of headers from root to 1406 not-RPL-aware-leaf 1408 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1410 In this case the flow comprises: 1412 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1414 For example, a communication flow could be: Node G --> Node E --> 1415 Node B --> Node A (root) 1417 6LR_i are the intermediate routers from source to destination. In 1418 this case, "1 < i <= n", n is the number of routers (6LR) that the 1419 packet go through from source (IPv6) to destination (6LBR). For 1420 example, 6LR_1 (i=1) is the router that receives the packets from the 1421 IPv6 node. 1423 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1424 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1425 following 6LRs. The RPI and entire packet is consumed by the root. 1427 +---------+-----+----------------+----------------+-----------------+ 1428 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | 1429 | | 6 | | | | 1430 +---------+-----+----------------+----------------+-----------------+ 1431 | Inserte | -- | IPv6-in- | -- | -- | 1432 | d | | IPv6(RPI) | | | 1433 | headers | | | | | 1434 | Removed | -- | -- | -- | IPv6-in- | 1435 | headers | | | | IPv6(RPI) | 1436 | Re- | -- | -- | -- | -- | 1437 | added | | | | | 1438 | headers | | | | | 1439 | Modifie | -- | -- | IPv6-in- | -- | 1440 | d | | | IPv6(RPI) | | 1441 | headers | | | | | 1442 | Untouch | -- | -- | -- | -- | 1443 | ed | | | | | 1444 | headers | | | | | 1445 +---------+-----+----------------+----------------+-----------------+ 1447 Table 16: Non Storing: Summary of the use of headers from not-RPL- 1448 aware-leaf to root 1450 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1452 This section will describe the communication flow in Non Storing Mode 1453 (Non-SM) between: 1455 RPL-aware-leaf to Internet 1457 Internet to RPL-aware-leaf 1459 not-RPL-aware-leaf to Internet 1461 Internet to not-RPL-aware-leaf 1463 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1465 In this case the flow comprises: 1467 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1469 For example, a communication flow could be: Node F --> Node D --> 1470 Node B --> Node A --> Internet 1472 6LR_i are the intermediate routers from source to destination. In 1473 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1474 packet go through from source (6LN) to 6LBR. 1476 This case is identical to storing-mode case. 1478 The IPv6 flow label should be set to zero to aid in compression, and 1479 the 6LBR will set it to a non-zero value when sending towards the 1480 Internet. 1482 +-------------------+------+-------+------+----------------+ 1483 | Header | 6LN | 6LR_i | 6LBR | Internet | 1484 +-------------------+------+-------+------+----------------+ 1485 | Inserted headers | RPI | -- | -- | -- | 1486 | Removed headers | -- | -- | -- | -- | 1487 | Re-added headers | -- | -- | -- | -- | 1488 | Modified headers | -- | RPI | -- | -- | 1489 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1490 +-------------------+------+-------+------+----------------+ 1492 Table 17: Non Storing: Summary of the use of headers from RPL-aware- 1493 leaf to Internet 1495 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1497 In this case the flow comprises: 1499 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1501 For example, a communication flow could be: Internet --> Node A 1502 (root) --> Node B --> Node D --> Node F 1504 6LR_i are the intermediate routers from source to destination. In 1505 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1506 packet go through from 6LBR to destination(6LN). 1508 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1509 address of the target node, it can address the IPv6-in-IPv6 header to 1510 that node. The 6LBR will zero the flow label upon entry in order to 1511 aid compression. 1513 +-----------+----------+--------------+--------------+--------------+ 1514 | Header | Internet | 6LBR | 6LR_i | 6LN | 1515 +-----------+----------+--------------+--------------+--------------+ 1516 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1517 | headers | | (RH3,RPI) | | | 1518 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1519 | headers | | | | (RH3,RPI) | 1520 | Re-added | -- | -- | -- | -- | 1521 | headers | | | | | 1522 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1523 | headers | | | (RH3,RPI) | | 1524 | Untouched | -- | -- | -- | -- | 1525 | headers | | | | | 1526 +-----------+----------+--------------+--------------+--------------+ 1528 Table 18: Non Storing: Summary of the use of headers from Internet to 1529 RPL-aware-leaf 1531 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1533 In this case the flow comprises: 1535 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1536 Internet 1538 For example, a communication flow could be: Node G --> Node E --> 1539 Node B --> Node A --> Internet 1541 6LR_i are the intermediate routers from source to destination. In 1542 this case, "1 < i <= n", n is the number of routers (6LR) that the 1543 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1545 In this case the flow label is recommended to be zero in the IPv6 1546 node. As RPL headers are added in the IPv6 node packet, the first 1547 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1548 The IPv6-in-IPv6 header will be addressed to the root. This case is 1549 identical to the storing-mode case (see Section 6.2.3). 1551 +---------+-----+------------+-------------+-------------+----------+ 1552 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Internet | 1553 | | 6 | | [i=2,..,n]_ | | | 1554 +---------+-----+------------+-------------+-------------+----------+ 1555 | Inserte | -- | IPv6-in- | -- | -- | -- | 1556 | d | | IPv6 (RPI) | | | | 1557 | headers | | | | | | 1558 | Removed | -- | -- | -- | IPv6-in- | -- | 1559 | headers | | | | IPv6 (RPI) | | 1560 | Re- | -- | -- | -- | -- | -- | 1561 | added | | | | | | 1562 | headers | | | | | | 1563 | Modifie | -- | -- | IPv6-in- | -- | -- | 1564 | d | | | IPv6 (RPI) | | | 1565 | headers | | | | | | 1566 | Untouch | -- | -- | -- | -- | -- | 1567 | ed | | | | | | 1568 | headers | | | | | | 1569 +---------+-----+------------+-------------+-------------+----------+ 1571 Table 19: Non Storing: Summary of the use of headers from not-RPL- 1572 aware-leaf to Internet 1574 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1576 In this case the flow comprises: 1578 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1580 For example, a communication flow could be: Internet --> Node A 1581 (root) --> Node B --> Node E --> Node G 1583 6LR_i are the intermediate routers from source to destination. In 1584 this case, "1 < i <= n", n is the number of routers (6LR) that the 1585 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1587 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1588 6LBR will know the path, and will recognize that the final node is 1589 not an RPL capable node as it will have received the connectivity DAO 1590 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1591 header destination be the last 6LR. The 6LBR will set to zero the 1592 flow label upon entry in order to aid compression. 1594 +---------+--------+------------+------------+---------------+------+ 1595 | Header | Intern | 6LBR | 6LR_1 | 6LR_i(i=2,.., | IPv6 | 1596 | | et | | | n) | | 1597 +---------+--------+------------+------------+---------------+------+ 1598 | Inserte | -- | IPv6-in- | -- | -- | -- | 1599 | d | | IPv6 (RH3, | | | | 1600 | headers | | RPI) | | | | 1601 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1602 | headers | | | | (RH3,RPI)(1) | | 1603 | Re- | -- | -- | -- | -- | -- | 1604 | added | | | | | | 1605 | headers | | | | | | 1606 | Modifie | -- | -- | IPv6-in- | IPv6-in-IPv6 | -- | 1607 | d | | | IPv6 | (RH3, RPI) | | 1608 | headers | | | (RH3,RPI) | | | 1609 | Untouch | -- | -- | -- | -- | -- | 1610 | ed | | | | | | 1611 | headers | | | | | | 1612 +---------+--------+------------+------------+---------------+------+ 1614 Table 20: NonStoring: Summary of the use of headers from Internet to 1615 non-RPL-aware-leaf (1) The last 6LR before the IPv6 node. 1617 7.3. Non-Storing Mode: Interaction between Leafs 1619 In this section is described the communication flow in Non Storing 1620 Mode (Non-SM) between, 1622 RPL-aware-leaf to RPL-aware-leaf 1624 RPL-aware-leaf to not-RPL-aware-leaf 1626 not-RPL-aware-leaf to RPL-aware-leaf 1628 not-RPL-aware-leaf to not-RPL-aware-leaf 1630 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1632 In this case the flow comprises: 1634 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1636 For example, a communication flow could be: Node F --> Node D --> 1637 Node B --> Node A (root) --> Node B --> Node E --> Node H 1639 6LR_ia are the intermediate routers from source to the root In this 1640 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1641 packet go through from 6LN to the root. 1643 6LR_id are the intermediate routers from the root to the destination. 1644 In this case, "1 <= ia <= m", m is the number of the intermediate 1645 routers (6LR). 1647 This case involves only nodes in same RPL Domain. The originating 1648 node will add a RPI header to the original packet, and send the 1649 packet upwards. 1651 The originating node should put the RPI into an IPv6-in-IPv6 header 1652 addressed to the root, so that the 6LBR can remove that header. If 1653 it does not, then additional resources are wasted on the way down to 1654 carry the useless RPI option. 1656 The 6LBR will need to insert an RH3 header, which requires that it 1657 add an IPv6-in-IPv6 header. It should be able to remove the RPI, as 1658 it was contained in an IPv6-in-IPv6 header addressed to it. 1659 Otherwise, there may be a RPI header buried inside the inner IP 1660 header, which should get ignored. 1662 Networks that use the RPL P2P extension [RFC6997] are essentially 1663 non-storing DODAGs and fall into this scenario or scenario 1664 Section 7.1.2, with the originating node acting as 6LBR. 1666 +---------+------------+-------+-------------+--------+-------------+ 1667 | Header | 6LN src | 6LR_i | 6LBR | 6LR_id | 6LN dst | 1668 | | | a | | | | 1669 +---------+------------+-------+-------------+--------+-------------+ 1670 | Inserte | IPv6-in- | -- | IPv6-in- | -- | -- | 1671 | d | IPv6 | | IPv6 | | | 1672 | headers | (RPI1) | | (RH3->6LN, | | | 1673 | | | | opt RPI2) | | | 1674 | Removed | -- | -- | IPv6-in- | -- | IPv6-in- | 1675 | headers | | | IPv6 (RPI1) | | IPv6 (RH3, | 1676 | | | | | | opt RPI2) | 1677 | Re- | -- | -- | -- | -- | -- | 1678 | added | | | | | | 1679 | headers | | | | | | 1680 | Modifie | -- | RPI1 | -- | RPI2 | -- | 1681 | d | | | | | | 1682 | headers | | | | | | 1683 | Untouch | -- | -- | -- | -- | -- | 1684 | ed | | | | | | 1685 | headers | | | | | | 1686 +---------+------------+-------+-------------+--------+-------------+ 1688 Table 21: Non Storing: Summary of the use of headers for RPL-aware- 1689 leaf to RPL-aware-leaf 1691 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1692 leaf 1694 In this case the flow comprises: 1696 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1698 For example, a communication flow could be: Node F --> Node D --> 1699 Node B --> Node A (root) --> Node B --> Node E --> Node G 1701 6LR_ia are the intermediate routers from source to the root In this 1702 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1704 6LR_id are the intermediate routers from the root to the destination. 1705 In this case, "1 <= ia <= m", m is the number of the intermediate 1706 routers (6LR). 1708 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1709 which must be in an IPv6-in-IPv6 header addressed to the root so that 1710 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1711 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. The RPI is 1712 optional from 6LBR to 6LR_id (RPI_2). 1714 +---------+-----------+-----------+------------+------------+-------+ 1715 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1716 +---------+-----------+-----------+------------+------------+-------+ 1717 | Inserte | IPv6-in- | -- | IPv6-in- | -- | -- | 1718 | d | IPv6 | | IPv6 (RH3, | | | 1719 | headers | (RPI1) | | opt RPI_2) | | | 1720 | Removed | -- | -- | IPv6-in- | IPv6-in- | -- | 1721 | headers | | | IPv6 | IPv6 (RH3, | | 1722 | | | | (RPI_1) | opt RPI_2) | | 1723 | Re- | -- | -- | -- | -- | -- | 1724 | added | | | | | | 1725 | headers | | | | | | 1726 | Modifie | -- | IPv6-in- | -- | IPv6-in- | -- | 1727 | d | | IPv6 | | IPv6 (RH3, | | 1728 | headers | | (RPI_1) | | opt RPI_2) | | 1729 | Untouch | -- | -- | -- | -- | opt | 1730 | ed | | | | | RPI_2 | 1731 | headers | | | | | | 1732 +---------+-----------+-----------+------------+------------+-------+ 1734 Table 22: Non Storing: Summary of the use of headers from RPL-aware- 1735 leaf to not-RPL-aware-leaf 1737 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1738 leaf 1740 In this case the flow comprises: 1742 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 1743 6LN 1745 For example, a communication flow could be: Node G --> Node E --> 1746 Node B --> Node A (root) --> Node B --> Node E --> Node H 1748 6LR_ia are the intermediate routers from source to the root. In this 1749 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1751 6LR_id are the intermediate routers from the root to the destination. 1752 In this case, "1 <= ia <= m", m is the number of the intermediate 1753 routers (6LR). 1755 This scenario is mostly identical to the previous one. The RPI is 1756 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1757 addressed to the root. The 6LBR will remove this RPI, and add it's 1758 own IPv6-in-IPv6 header containing an RH3 header and optional RPI 1759 (RPI_2). 1761 +---------+-----+------------+------------+------------+------------+ 1762 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN | 1763 | | 6 | | | | | 1764 +---------+-----+------------+------------+------------+------------+ 1765 | Inserte | -- | IPv6-in- | IPv6-in- | -- | -- | 1766 | d | | IPv6 | IPv6 (RH3, | | | 1767 | headers | | (RPI_1) | opt RPI_2) | | | 1768 | Removed | -- | -- | IPv6-in- | -- | IPv6-in- | 1769 | headers | | | IPv6 | | IPv6 (RH3, | 1770 | | | | (RPI_1) | | opt RPI_2) | 1771 | Re- | -- | -- | -- | -- | -- | 1772 | added | | | | | | 1773 | headers | | | | | | 1774 | Modifie | -- | -- | -- | IPv6-in- | -- | 1775 | d | | | | IPv6 (RH3, | | 1776 | headers | | | | opt RPI_2) | | 1777 | Untouch | -- | -- | -- | -- | -- | 1778 | ed | | | | | | 1779 | headers | | | | | | 1780 +---------+-----+------------+------------+------------+------------+ 1782 Table 23: Non Storing: Summary of the use of headers from not-RPL- 1783 aware-leaf to RPL-aware-leaf 1785 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1786 aware-leaf 1788 In this case the flow comprises: 1790 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1791 not-RPL-aware (IPv6 dst) 1793 For example, a communication flow could be: Node G --> Node E --> 1794 Node B --> Node A (root) --> Node C --> Node J 1796 6LR_ia are the intermediate routers from source to the root. In this 1797 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1799 6LR_id are the intermediate routers from the root to the destination. 1800 In this case, "1 <= ia <= m", m is the number of the intermediate 1801 routers (6LR). 1803 This scenario is the combination of the previous two cases. 1805 +----------+-----+-------------+--------------+--------------+------+ 1806 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1807 | | 6 | | | | dst | 1808 | | src | | | | | 1809 +----------+-----+-------------+--------------+--------------+------+ 1810 | Inserted | -- | IPv6-in- | IPv6-in-IPv6 | -- | -- | 1811 | headers | | IPv6 | (RH3, opt | | | 1812 | | | (RPI_1) | RPI_2) | | | 1813 | Removed | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1814 | headers | | | (RPI_1) | (RH3, opt | | 1815 | | | | | RPI_2) | | 1816 | Re-added | -- | -- | -- | -- | -- | 1817 | headers | | | | | | 1818 | Modified | -- | -- | -- | -- | -- | 1819 | headers | | | | | | 1820 | Untouche | -- | -- | -- | -- | -- | 1821 | d | | | | | | 1822 | headers | | | | | | 1823 +----------+-----+-------------+--------------+--------------+------+ 1825 Table 24: Non Storing: Summary of the use of headers from not-RPL- 1826 aware-leaf to not-RPL-aware-leaf 1828 8. Operational Considerations of supporting not-RPL-aware-leaves 1830 Roughly half of the situations described in this document involve 1831 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1832 further categories: ones that drop a packet that have RPI or RH3 1833 headers, and ones that continue to process a packet that has RPI and/ 1834 or RH3 headers. 1836 [RFC8200] provides for new rules that suggest that nodes that have 1837 not been configured (explicitly) to examine Hop-by-Hop headers, 1838 should ignore those headers, and continue processing the packet. 1839 Despite this, and despite the switch from 0x63 to 0x23, there may be 1840 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1841 drop packets that continue to have RPL artifacts in them. In 1842 general, such hosts can not be easily supported in RPL LLNs. 1844 There are some specific cases where it is possible to remove the RPL 1845 artifacts prior to forwarding the packet to the leaf host. The 1846 critical thing is that the artifacts have been inserted by the RPL 1847 root inside an IPv6-in-IPv6 header, and that the header has been 1848 addressed to the 6LR immediately prior to the leaf node. In that 1849 case, in the process of removing the IPv6-in-IPv6 header, the 1850 artifacts can also be removed. 1852 The above case occurs whenever traffic originates from the outside 1853 the LLN (the "Internet" cases above), and non-storing mode is used. 1854 In non-storing mode, the RPL root knows the exact topology (as it 1855 must be create the RH3 header), and therefore knows what the 6LR 1856 prior to the leaf --- the 6LR_n. 1858 Traffic originating from the RPL root (such as when the data 1859 collection system is co-located on the RPL root), does not require an 1860 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1861 the root, and the root can insert the RPI and RH3 headers directly 1862 into the packet, as it is formed. Such a packet is slightly smaller, 1863 but only can be sent to nodes (whether RPL aware or not), that will 1864 tolerate the RPL artifacts. 1866 An operator that finds itself with a lot of traffic from the RPL root 1867 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1868 if the leaf is not tolerant of the RPL artifacts. Such an operator 1869 could otherwise omit this unnecessary header if it was certain of the 1870 properties of the leaf. 1872 As storing mode can not know the final path of the traffic, 1873 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1874 be supported. 1876 9. Operational considerations of introducing 0x23 1878 This section describes the operational considerations of introducing 1879 the new RPI value of 0x23. 1881 Related to the deployment of RPL, there are no known multivendor 1882 deployments outside of the research groups! All known deployments of 1883 RPL are in market verticals, with a single vendor providing all 1884 components. Research groups typically are using Contiki, RiotOS, or 1885 OpenWSN, and these are easily adapted to 0x23 functionality. 1887 During bootstrapping the node get the DIO with the information of RPL 1888 Option Type, indicating the new RPI in the DODAG Configuration Option 1889 Flag. The DODAG root is in charge to configure the current network 1890 to the new value, through DIO messages and when all the nodes are set 1891 with the new value. The DODAG should change to a new DODAG version. 1892 In case of rebooting, the node does not remember the RPL Option Type. 1893 Thus, the DIO is sent with a flag indicating the new RPI value. 1895 The migration path to the change from 0x63 to 0x23 in networks that 1896 accepts both values is changed when the DIO is sent with the flag 1897 indicating the new RPI value. Namely, it remains at 0x63 until it is 1898 sure that the network is capable of 0x23, then it abruptly change to 1899 0x23. This options allows to send packets to non-RPL nodes, which 1900 should ignore the option and continue processing the packets. 1902 In case that a node join to a network that only process 0x63, it 1903 would produce a flag day as was mentioned previously. Indicating the 1904 new RPI in the DODAG Configuration Option Flag is a way to avoid the 1905 flag day in a network. It is recommended that a network process both 1906 options to enable interoperability. 1908 10. IANA Considerations 1910 This document updates the registration made in [RFC6553] Destination 1911 Options and Hop-by-Hop Options registry from 0x63 to 0x23. 1913 [RFCXXXX] represents this document. 1915 Hex Value Binary Value 1916 act chg rest Description Reference 1917 --------- --- --- ------- ----------------- ---------- 1918 0x23 00 1 00011 RPL Option [RFCXXXX] 1919 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 1921 Figure 9: Option Type in RPL Option. 1923 The DODAG Configuration Option Flags in the DODAG Configuration 1924 option is updated as follows: 1926 +------------+-----------------+---------------+ 1927 | Bit number | Description | Reference | 1928 +------------+-----------------+---------------+ 1929 | 3 | RPI 0x23 enable | This document | 1930 +------------+-----------------+---------------+ 1932 Figure 10: DODAG Configuration Option Flag to indicate the RPI-flag- 1933 day. 1935 11. Security Considerations 1937 The security considerations covered in [RFC6553] and [RFC6554] apply 1938 when the packets are in the RPL Domain. 1940 The IPv6-in-IPv6 mechanism described in this document is much more 1941 limited than the general mechanism described in [RFC2473]. The 1942 willingness of each node in the LLN to decapsulate packets and 1943 forward them could be exploited by nodes to disguise the origin of an 1944 attack. 1946 While a typical LLN may be a very poor origin for attack traffic (as 1947 the networks tend to be very slow, and the nodes often have very low 1948 duty cycles) given enough nodes, they could still have a significant 1949 impact, particularly if the attack was on another LLN! Additionally, 1950 some uses of RPL involve large backbone ISP scale equipment 1951 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1952 multiple 100Gb/s interfaces. 1954 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 1955 LLN as described above will make sure that any attack that is mounted 1956 must originate from compromised nodes within the LLN. The use of 1957 BCP38 filtering at the RPL root on egress traffic will both alert the 1958 operator to the existence of the attack, as well as drop the attack 1959 traffic. As the RPL network is typically numbered from a single 1960 prefix, which is itself assigned by RPL, BCP38 filtering involves a 1961 single prefix comparison and should be trivial to automatically 1962 configure. 1964 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 1965 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 1966 communications between a new Pledge and the Join Registrar/ 1967 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 1968 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 1969 the RPL root to do careful filtering: it occurs only when the Join 1970 Coordinator is not co-located inside the RPL root. 1972 With the above precautions, an attack using IPv6-in-IPv6 tunnels will 1973 be by a node within the LLN on another node within the LLN. Such an 1974 attack could, of course, be done directly. An attack of this kind is 1975 meaningful only if the source addresses are either fake or if the 1976 point is to amplify return traffic. Such an attack, could also be 1977 done without the use of IPv6-in-IPv6 headers using forged source 1978 addresses. If the attack requires bi-directional communication, then 1979 IPv6-in-IPv6 provides no advantages. 1981 [RFC2473] suggests that tunnel entry and exit points can be secured, 1982 via the "Use IPsec". The suggested solution has all the problems 1983 that [RFC5406] goes into. In an LLN such a solution would degenerate 1984 into every node having a tunnel with every other node. It would 1985 provide a small amount of origin address authentication at a very 1986 high cost; doing BCP38 at every node (linking layer-3 addresses to 1987 layer-2 addresses, and to already present layer-2 cryptographic 1988 mechanisms) would be cheaper should RPL be run in an environment 1989 where hostile nodes are likely to be a part of the LLN. 1991 The RH3 header usage described here can be abused in equivalent ways 1992 with an IPv6-in-IPv6 header to add the needed RH3 header. As such, 1993 the attacker's RH3 header will not be seen by the network until it 1994 reaches the end host, which will decapsulate it. An end-host should 1995 be suspicious about a RH3 header which has additional hops which have 1996 not yet been processed, and SHOULD ignore such a second RH3 header. 1998 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 1999 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2000 will see the second RH3 header and MAY choose to discard the packet 2001 if the RH3 header has not been completely consumed. A consumed 2002 (inert) RH3 header could be present in a packet that flows from one 2003 LLN, crosses the Internet, and enters another LLN. As per the 2004 discussion in this document, such headers do not need to be removed. 2005 However, there is no case described in this document where an RH3 is 2006 inserted in a non-storing network on traffic that is leaving the LLN, 2007 but this document should not preclude such a future innovation. It 2008 should just be noted that an incoming RH3 must be fully consumed, or 2009 very carefully inspected. 2011 The RPI header, if permitted to enter the LLN, could be used by an 2012 attacker to change the priority of a packet by selecting a different 2013 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2014 It could also be that not all nodes are reachable in an LLN using the 2015 default instanceID, but a change of instanceID would permit an 2016 attacker to bypass such filtering. Like the RH3, a RPI header is to 2017 be inserted by the RPL root on traffic entering the LLN by first 2018 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2019 therefore will not be seen by the network. Upon reaching the 2020 destination node the RPI header has no further meaning and is just 2021 skipped; the presence of a second RPI header will have no meaning to 2022 the end node as the packet has already been identified as being at 2023 it's final destination. 2025 The RH3 and RPI headers could be abused by an attacker inside of the 2026 network to route packets on non-obvious ways, perhaps eluding 2027 observation. This usage is in fact part of [RFC6997] and can not be 2028 restricted at all. This is a feature, not a bug. 2030 [RFC7416] deals with many other threats to LLNs not directly related 2031 to the use of IPv6-in-IPv6 headers, and this document does not change 2032 that analysis. 2034 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2035 attack on another part of the LLN, while disguising the origin of the 2036 attack. The mechanism can even be abused to make it appear that the 2037 attack is coming from outside the LLN, and unless countered, this 2038 could be used to mount a Distributed Denial Of Service attack upon 2039 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2040 such attacks already seen in the real world. 2042 If an attack comes from inside of LLN, it can be alleviated with SAVI 2043 (Source Address Validation Improvement) using [RFC8505] with 2044 [I-D.ietf-6lo-ap-nd]. The attacker will not be able to source with 2045 an address that is not registered, and the registration checks for 2046 topological correctness. Notice that there is an L2 authentication 2047 in most of the cases. If an attack comes from outside LLN IPv6-in- 2048 IPv6 can be used to hide inner routing headers, but RH3 is protected 2049 by its definition. 2051 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2052 through the RPL root to perform this attack. To counter, the RPL 2053 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2054 simpler solution), or it SHOULD do a deep packet inspection wherein 2055 it walks the IP header extension chain until it can inspect the 2056 upper-layer-payload as described in [RFC7045]. In particular, the 2057 RPL root SHOULD do BCP38 ([RFC2827]) processing on the source 2058 addresses of all IP headers that it examines in both directions. 2060 Note: there are some situations where a prefix will spread across 2061 multiple LLNs via mechanisms such as the one described in 2062 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2063 needs to take this into account, either by exchanging detailed 2064 routing information on each LLN, or by moving the BCP38 filtering 2065 further towards the Internet, so that the details of the multiple 2066 LLNs do not matter. 2068 12. Acknowledgments 2070 We are very thankful to the grant by the Finnish Foundation for 2071 Technology Promotion (Tekniikan Edistaemissaeaetioen - TES), and the 2072 grant by the FP7 Marie Curie Initial Training Network (ITN) METRICS 2073 project (grant agreement No. 607728) 2075 A special BIG thanks to C. M. Heard for the help with the 2076 Section 3. Much of the redaction in that section is based on his 2077 comments. 2079 Additionally, the authors would like to acknowledge the review, 2080 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2081 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2082 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2084 13. References 2086 13.1. Normative References 2088 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2089 Requirement Levels", BCP 14, RFC 2119, 2090 DOI 10.17487/RFC2119, March 1997, 2091 . 2093 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2094 Defeating Denial of Service Attacks which employ IP Source 2095 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2096 May 2000, . 2098 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2099 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2100 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2101 Low-Power and Lossy Networks", RFC 6550, 2102 DOI 10.17487/RFC6550, March 2012, 2103 . 2105 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2106 Power and Lossy Networks (RPL) Option for Carrying RPL 2107 Information in Data-Plane Datagrams", RFC 6553, 2108 DOI 10.17487/RFC6553, March 2012, 2109 . 2111 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2112 Routing Header for Source Routes with the Routing Protocol 2113 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2114 DOI 10.17487/RFC6554, March 2012, 2115 . 2117 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2118 of IPv6 Extension Headers", RFC 7045, 2119 DOI 10.17487/RFC7045, December 2013, 2120 . 2122 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2123 "IPv6 over Low-Power Wireless Personal Area Network 2124 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2125 April 2017, . 2127 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2128 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2129 May 2017, . 2131 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2132 (IPv6) Specification", STD 86, RFC 8200, 2133 DOI 10.17487/RFC8200, July 2017, 2134 . 2136 13.2. Informative References 2138 [DDOS-KREBS] 2139 Goodin, D., "Record-breaking DDoS reportedly delivered by 2140 >145k hacked cameras", September 2016, 2141 . 2144 [I-D.ietf-6lo-ap-nd] 2145 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2146 "Address Protected Neighbor Discovery for Low-power and 2147 Lossy Networks", draft-ietf-6lo-ap-nd-11 (work in 2148 progress), February 2019. 2150 [I-D.ietf-6lo-backbone-router] 2151 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2152 Backbone Router", draft-ietf-6lo-backbone-router-11 (work 2153 in progress), February 2019. 2155 [I-D.ietf-6tisch-dtsecurity-secure-join] 2156 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2157 6tisch-dtsecurity-secure-join-01 (work in progress), 2158 February 2017. 2160 [I-D.ietf-anima-autonomic-control-plane] 2161 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2162 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2163 plane-18 (work in progress), August 2018. 2165 [I-D.ietf-anima-bootstrapping-keyinfra] 2166 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2167 S., and K. Watsen, "Bootstrapping Remote Secure Key 2168 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2169 keyinfra-19 (work in progress), March 2019. 2171 [I-D.thubert-roll-unaware-leaves] 2172 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2173 unaware-leaves-06 (work in progress), November 2018. 2175 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2176 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2177 December 1998, . 2179 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2180 Control Message Protocol (ICMPv6) for the Internet 2181 Protocol Version 6 (IPv6) Specification", STD 89, 2182 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2183 . 2185 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2186 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2187 February 2009, . 2189 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2190 Bormann, "Neighbor Discovery Optimization for IPv6 over 2191 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2192 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2193 . 2195 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2196 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2197 in Low-Power and Lossy Networks", RFC 6997, 2198 DOI 10.17487/RFC6997, August 2013, 2199 . 2201 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2202 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2203 2014, . 2205 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2206 and M. Richardson, Ed., "A Security Threat Analysis for 2207 the Routing Protocol for Low-Power and Lossy Networks 2208 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2209 . 2211 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2212 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2213 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2214 May 2017, . 2216 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2217 Perkins, "Registration Extensions for IPv6 over Low-Power 2218 Wireless Personal Area Network (6LoWPAN) Neighbor 2219 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2220 . 2222 Authors' Addresses 2224 Maria Ines Robles 2225 Aalto University 2226 Innopoli 2227 Espoo 02150 2228 Finland 2230 Email: mariainesrobles@gmail.com 2232 Michael C. Richardson 2233 Sandelman Software Works 2234 470 Dawson Avenue 2235 Ottawa, ON K1Z 5V7 2236 CA 2238 Email: mcr+ietf@sandelman.ca 2239 URI: http://www.sandelman.ca/mcr/ 2241 Pascal Thubert 2242 Cisco Systems, Inc 2243 Village d'Entreprises Green Side 400, Avenue de Roumanille 2244 Batiment T3, Biot - Sophia Antipolis 06410 2245 France 2247 Email: pthubert@cisco.com