idnits 2.17.00 (12 Aug 2021) /tmp/idnits4572/draft-ietf-roll-useofrplinfo-24.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 10 has weird spacing: '... Routes and I...' == Line 244 has weird spacing: '... act chg ...' == Line 281 has weird spacing: '... act chg ...' == Line 1956 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 (January 23, 2019) is 1214 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 1959, but not defined == Unused Reference: 'RFC4192' is defined on line 2204, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-thubert-roll-unaware-leaves-06 -- Possible downref: Normative reference to a draft: ref. 'I-D.thubert-roll-unaware-leaves' == 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 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). 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: July 27, 2019 P. Thubert 7 Cisco 8 January 23, 2019 10 Using RPL Option Type, Routing Header for Source Routes and IPv6-in- 11 IPv6 encapsulation in the RPL Data Plane 12 draft-ietf-roll-useofrplinfo-24 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 July 27, 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Requirements Language . . . . . . . . . . . . 5 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. . . . . . . . . . . . . 9 70 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . 27 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 . . . 31 96 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 32 97 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 32 98 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 99 leaf . . . . . . . . . . . . . . . . . . . . . . . . 33 100 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 101 root . . . . . . . . . . . . . . . . . . . . . . . . 34 102 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 35 103 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 104 Internet . . . . . . . . . . . . . . . . . . . . . . 35 105 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 106 leaf . . . . . . . . . . . . . . . . . . . . . . . . 36 107 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 108 Internet . . . . . . . . . . . . . . . . . . . . . . 37 109 7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 110 aware-leaf . . . . . . . . . . . . . . . . . . . . . 38 111 7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 39 112 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL- 113 aware-leaf . . . . . . . . . . . . . . . . . . . . . 39 114 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 115 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 41 116 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 117 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 42 118 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 119 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 43 120 8. Operational Considerations of supporting 121 not-RPL-aware-leaves . . . . . . . . . . . . . . . . . . . . 43 122 9. Operational considerations of introducing 0x23 . . . . . . . 44 123 9.1. Has deployment been discussed? . . . . . . . . . . . . . 45 124 9.2. Has installation and initial setup been discussed?? . . . 45 125 9.3. Has the migration path been discussed? . . . . . . . . . 45 126 9.4. Have the Requirements on other protocols and 127 functional components been discussed? . . . . . . . . . . 45 128 9.5. Has the impact on network operation been discussed? . . . 45 129 9.6. Have suggestions for verifying correct operation been 130 discussed? . . . . . . . . . . . . . . . . . . . . . . . 45 131 9.7. Has management interoperability been discussed? . . . . . 45 132 9.8. Are there fault or threshold conditions that should be 133 reported? . . . . . . . . . . . . . . . . . . . . . . . . 46 134 9.9. Is configuration discussed? . . . . . . . . . . . . . . . 46 135 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 136 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 137 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 138 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 139 13.1. Normative References . . . . . . . . . . . . . . . . . . 49 140 13.2. Informative References . . . . . . . . . . . . . . . . . 50 142 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 144 1. Introduction 146 RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) 147 [RFC6550] is a routing protocol for constrained networks. RFC 6553 148 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 149 Hop-by-Hop header to quickly identify inconsistencies (loops) in the 150 routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route 151 Header" (RH3), an IPv6 Extension Header to deliver datagrams within a 152 RPL routing domain, particularly in non-storing mode. 154 These various items are referred to as RPL artifacts, and they are 155 seen on all of the data-plane traffic that occurs in RPL routed 156 networks; they do not in general appear on the RPL control plane 157 traffic at all which is mostly hop-by-hop traffic (one exception 158 being DAO messages in non-storing mode). 160 It has become clear from attempts to do multi-vendor 161 interoperability, and from a desire to compress as many of the above 162 artifacts as possible that not all implementors agree when artifacts 163 are necessary, or when they can be safely omitted, or removed. 165 An interim meeting went through the 24 cases defined here to discover 166 if there were any shortcuts, and this document is the result of that 167 discussion. This document clarifies examples that intend to 168 illustrate the result of the normative language in RFC8200 and 169 RFC6553. In other words, the examples are intended to be normative 170 explanation of the results of executing that language. 172 A Routing Header Dispatch for 6LoWPAN (6LoRH)([RFC8138]) defines a 173 mechanism for compressing RPL Option information and Routing Header 174 type 3 [RFC6554], as well as an efficient IPv6-in-IPv6 technique. 176 1.1. Overview 178 The rest of the document is organized as follows: Section 2 describes 179 the used terminology. Section 3 describes the updates to RFC6553, 180 RFC6550 and RFC 8138. Section 4 provides the reference topology used 181 for the uses cases. Section 5 describes the uses cases included. 182 Section 6 describes the storing mode cases and section 7 the non- 183 storing mode cases. Section 8 describes the operational 184 considerations for the proposed change on RPL Option type. Section 9 185 depicts the 6LoRH Compression cases, section 10 the IANA 186 considerations and then section 11 describes the security aspects. 188 2. Terminology and Requirements Language 190 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 192 "OPTIONAL" in this document are to be interpreted as described in BCP 193 14 [RFC2119], [RFC8174] when, and only when, they appear in all 194 capitals, as shown here. 196 Terminology defined in [RFC7102] applies to this document: LBR, LLN, 197 RPL, RPL Domain and ROLL. 199 RPL-node: A device which implements RPL, thus the device is RPL- 200 aware. Please note that the device can be found inside the LLN or 201 outside LLN. In this document a RPL-node which is a leaf of a 202 (Destination Oriented Directed Acyclic Graph) DODAG is called RPL- 203 aware-leaf (Raf). 205 RPL-not-capable: A device which does not implement RPL, thus the 206 device is not-RPL-aware. Please note that the device can be found 207 inside the LLN. In this document a not-RPL-aware node which is a 208 leaf of a DODAG is called not-RPL-aware-leaf (~Raf). 210 6LN: [RFC6775] defines it as: "A 6LoWPAN node is any host or router 211 participating in a LoWPAN. This term is used when referring to 212 situations in which either a host or router can play the role 213 described.". In this document, a 6LN acts as a leaf. 215 6LR, 6LBR are defined in [RFC6775]. 217 Flag Day: A transition that involves have a network with different 218 values of RPL Option Type. Thus the network do not work correctly. 220 Hop-by-hop IPv6-in-IPv6 headers: The term "hop-by-hop IPv6-in-IPv6" 221 header refers to: adding a header that originates from a node to an 222 adjacent node, using the addresses (usually the GUA or ULA, but could 223 use the link-local addresses) of each node. If the packet must 224 traverse multiple hops, then it must be decapsulated at each hop, and 225 then re-encapsulated again in a similar fashion. 227 3. Updates to RFC6553, RFC6550 and RFC 8138 229 3.1. Updates to RFC 6553 231 This modification is required to be able to send, for example, IPv6 232 packets from a RPL-aware-leaf to a not-RPL-aware node through 233 Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 234 encapsulation. 236 [RFC6553] states as shown below, that in the Option Type field of the 237 RPL Option header, the two high order bits must be set to '01' and 238 the third bit is equal to '1'. The first two bits indicate that the 239 IPv6 node must discard the packet if it doesn't recognize the option 240 type, and the third bit indicates that the Option Data may change in 241 route. The remaining bits serve as the option type. 243 Hex Value Binary Value 244 act chg rest Description Reference 245 --------- --- --- ------- ----------------- ---------- 246 0x63 01 1 00011 RPL Option [RFC6553] 248 Figure 1: Option Type in RPL Option. 250 Recent changes in [RFC8200] (section 4, page 8), states: "it is now 251 expected that nodes along a packet's delivery path only examine and 252 process the Hop-by-Hop Options header if explicitly configured to do 253 so". Processing of the Hop-by-Hop Options header (by IPv6 254 intermediate nodes) is now optional, but if they are configured to 255 process the header, and if such nodes encounter an option with the 256 first two bits set to 01, they will drop the packet (if they conform 257 to [RFC8200]). Host systems should do the same, irrespective of the 258 configuration. 260 Based on that, if an IPv6 (intermediate) node (RPL-not-capable) 261 receives a packet with an RPL Option, it should ignore the HBH RPL 262 option (skip over this option and continue processing the header). 263 This is relevant, as it was mentioned previously, in the case that 264 there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). 266 Thus, this document updates the Option Type field to: the two high 267 order bits MUST be set to '00' and the third bit is equal to '1'. 268 The first two bits indicate that the IPv6 node MUST skip over this 269 option and continue processing the header ([RFC8200] Section 4.2) if 270 it doesn't recognize the option type, and the third bit continues to 271 be set to indicate that the Option Data may change en route. The 272 remaining bits serve as the option type and remain as 0x3. This 273 ensures that a packet that leaves the RPL domain of an LLN (or that 274 leaves the LLN entirely) will not be discarded when it contains the 275 [RFC6553] RPL Hop-by-Hop option known as RPI. 277 This is a significant update to [RFC6553]. [RFCXXXX] represents this 278 document. 280 Hex Value Binary Value 281 act chg rest Description Reference 282 --------- --- --- ------- ----------------- ---------- 283 0x23 00 1 00011 RPL Option [RFCXXXX] 285 Figure 2: Revised Option Type in RPL Option. 287 This change creates a flag day for existing networks which are 288 currently using 0x63 as the RPI value. A move to 0x23 will not be 289 understood by those networks. It is suggested that implementations 290 accept both 0x63 and 0x23 when processing. 292 In the cases where a forwarding node is forwarding traffic that is 293 not addressed directly to it (such as when the outer IPv6-in-IPv6 294 header is not a Link-Local address), then RFC8200 forbids changing 295 the RPI type code when forwarding. 297 When forwarding traffic that is wrapped in Link-Local IPv6-in-IPv6 298 headers, the forwarding node is in effect originating new packets, 299 and it MAY make a choice as to whether to use the old (0x63) RPI Type 300 code, or the new (0x23) RPI Type code. In that situation, 301 implementations SHOULD use the same value as was received. This 302 allows to the network to be incrementally upgraded, and in some cases 303 may allow the DODAG root to know which parts of the network are 304 upgraded. 306 A network which is switching from straight 6lowpan compression 307 mechanism to those described in [RFC8138] will experience a flag day 308 in the data compression anyway, and if possible this change can be 309 deployed at the same time. 311 The change of RPI option type from 0x63 to 0x23, makes all [RFC8200] 312 Section 4.2 compliant nodes tolerant of the RPL artifacts. There is 313 therefore no longer a necessity to remove the artifacts when sending 314 traffic to the Internet. This change clarifies when to use an IPv6- 315 in-IPv6 header, and how to address them: The Hop-by-Hop Options 316 Header containing the RPI option SHOULD always be added when 6LRs 317 originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 318 headers SHOULD always be added when a 6LR find that it needs to 319 insert a Hop-by-Hop Options Header containing the RPI option. The 320 IPv6-in-IPv6 header is to be addressed to the RPL root when on the 321 way up, and to the end-host when on the way down. 323 Non-constrained uses of RPL are not in scope of this document, and 324 applicability statements for those uses MAY provide different advice, 325 E.g. [I-D.ietf-anima-autonomic-control-plane]. 327 In the non-storing case, dealing with non-RPL aware leaf nodes is 328 much easier as the 6LBR (DODAG root) has complete knowledge about the 329 connectivity of all DODAG nodes, and all traffic flows through the 330 root node. 332 The 6LBR can recognize non-RPL aware leaf nodes because it will 333 receive a DAO about that node from the 6LR immediately above that 334 non-RPL aware node. This means that the non-storing mode case can 335 avoid ever using hop-by-hop IPv6-in-IPv6 headers for traffic 336 originating from the root to leafs. 338 The non-storing mode case does not require the type change from 0x63 339 to 0x23, as the root can always create the right packet. The type 340 change does not adversely affect the non-storing case. 342 3.2. Updates to RFC 8138 344 RPI-6LoRH header provides a compressed form for the RPL RPI [RFC8138] 345 in section 6. A node that is decompressing this header MUST 346 decompress using the RPL RPI option type that is currently active: 347 that is, a choice between 0x23 (new) and 0x63 (old). The node will 348 know which to use based upon the presence of the DODAG Configuration 349 Option described in the next section. E.g. If the network is in 350 0x23 mode (by DIO option), then it should be decompressed to 0x23. 352 [RFC8138] section 7 documents how to compress the IPv6-in-IPv6 353 header. 355 There are potential significant advantages to having a single code 356 path that always processes IPv6-in-IPv6 headers with no options. 358 In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- 359 RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise 360 an IPv6-in-IPv6 and RPI compression headers. The use of the IPv6-in- 361 IPv6 header is MANDATORY in this case, and it SHOULD be compressed 362 with [RFC8138] section 7. 364 +--+-----+---+--------------+-----------+-----------+-----------+ 365 |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI-6LoRH |LOWPAN IPHC| 366 +--+-----+---+--------------+-----------+-----------+-----------+ 368 Figure 3: Critical IPv6-in-IPv6 (RPI). 370 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 371 Configuration Option Flag. 373 In order to avoid a Flag Day caused by lack of interoperation between 374 new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag 375 in the DIO Configuration Option, to indicate when then new RPI value 376 can be safely used. Without this, there could be a mix of new nodes 377 (which understand 0x23 and 0x63), and old nodes (which understand 378 0x63 only). A new node would not know if it was safe to use 0x23. 380 This is done via a DODAG Configuration Option flag which will 381 propagate through the network. If the flag is received with a value 382 zero (which is the default), then new nodes will remain in RFC6553 383 Compatible Mode; originating traffic with the old-RPI (0x63) value. 385 As stated in [RFC6550] the DODAG Configuration option is present in 386 DIO messages. The DODAG Configuration option distributes 387 configuration information. It is generally static, and does not 388 change within the DODAG. This information is configured at the DODAG 389 root and distributed throughout the DODAG with the DODAG 390 Configuration option. Nodes other than the DODAG root do not modify 391 this information when propagating the DODAG Configuration option. 393 The DODAG Configuration Option has a Flag field which is modified by 394 this document. Currently, the DODAG Configuration Option in 395 [RFC6550] states: "the unused bits MUST be initialize to zero by the 396 sender and MUST be ignored by the receiver". 398 Bit number three of the flag field in the DODAG Configuration option 399 is to be used as follows: 401 +------------+-----------------+---------------+ 402 | Bit number | Description | Reference | 403 +------------+-----------------+---------------+ 404 | 3 | RPI 0x23 enable | This document | 405 +------------+-----------------+---------------+ 407 Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- 408 day. 410 In case of rebooting, the node (6LN or 6LR) does not remember if the 411 flag is set, so DIO messages would be set with the flag unset until a 412 DIO is received with the flag set. 414 4. Sample/reference topology 416 A RPL network in general is composed of a 6LBR (6LoWPAN Border 417 Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN 418 (6LoWPAN Node) as leaf logically organized in a DODAG structure. 420 Figure 4 shows the reference RPL Topology for this document. The 421 letters above the nodes are there so that they may be referenced in 422 subsequent sections. In the figure, 6LR represents a full router 423 node. The 6LN is a RPL aware router, or host (as a leaf). 424 Additionally, for simplification purposes, it is supposed that the 425 6LBR has direct access to Internet, thus the 6BBR is not present in 426 the figure. 428 The 6LN leaves (Raf - "RPL aware leaf"-) marked as (F, H and I) are 429 RPL nodes with no children hosts. 431 The leafs marked as ~Raf "not-RPL aware leaf" (G and J) are devices 432 which do not speak RPL at all (not-RPL-aware), but uses Router- 433 Advertisements, 6LowPAN DAR/DAC and efficient-ND only to participate 434 in the network [RFC6775]. In the document these leafs (G and J) are 435 also referred to as an IPv6 node. 437 The 6LBR ("A") in the figure is the root of the Global DODAG. 439 +------------+ 440 | INTERNET ----------+ 441 | | | 442 +------------+ | 443 | 444 | 445 | 446 A | 447 +-------+ 448 |6LBR | 449 +-----------|(root) |-------+ 450 | +-------+ | 451 | | 452 | | 453 | | 454 | | 455 | B |C 456 +---|---+ +---|---+ 457 | 6LR | | 6LR | 458 +-------->| |--+ +--- ---+ 459 | +-------+ | | +-------+ | 460 | | | | 461 | | | | 462 | | | | 463 | | | | 464 | D | E | | 465 +-|-----+ +---|---+ | | 466 | 6LR | | 6LR | | | 467 | | +------ | | | 468 +---|---+ | +---|---+ | | 469 | | | | | 470 | | +--+ | | 471 | | | | | 472 | | | | | 473 | | | I | J | 474 F | | G | H | | 475 +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ 476 | Raf | | ~Raf | | Raf | | Raf | | ~Raf | 477 | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | 478 +-------+ +-------+ +------+ +-------+ +-------+ 480 Figure 5: A reference RPL Topology. 482 RPL defines the RPL Control messages (control plane), a new ICMPv6 483 [RFC4443] message with Type 155. DIS (DODAG Information 484 Solicitation), DIO (DODAG Information Object) and DAO (Destination 485 Advertisement Object) messages are all RPL Control messages but with 486 different Code values. A RPL Stack is shown in Figure 5. 488 +--------------+ 489 | Upper Layers | 490 | | 491 +--------------+ 492 | RPL | 493 | | 494 +--------------+ 495 | ICMPv6 | 496 | | 497 +--------------+ 498 | IPv6 | 499 | | 500 +--------------+ 501 | 6LoWPAN | 502 | | 503 +--------------+ 504 | PHY-MAC | 505 | | 506 +--------------+ 508 Figure 6: RPL Stack. 510 RPL supports two modes of Downward traffic: in storing mode (RPL-SM), 511 it is fully stateful; in non-storing (RPL-NSM), it is fully source 512 routed. A RPL Instance is either fully storing or fully non-storing, 513 i.e. a RPL Instance with a combination of storing and non-storing 514 nodes is not supported with the current specifications at the time of 515 writing this document. 517 5. Use cases 519 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 520 encapsulation are going to be analyzed for a number of representative 521 traffic flows. 523 This document assumes that the LLN is using the no-drop RPI option 524 (0x23). 526 The uses cases describe the communication between RPL-aware-nodes, 527 with the root (6LBR), and with Internet. This document also describe 528 the communication between nodes acting as leaves that do not 529 understand RPL, but are part of the LLN. these nodes are named as 530 not-RPL-aware-leaf, mentioned previously. (e.g. Section 6.1.4 Flow 531 from not-RPL-aware-leaf to root) This document describes also how is 532 the communication inside of the LLN when it has the final destination 533 addressed outside of the LLN e.g. with destination to Internet. 534 (e.g. Section 6.2.3 Flow from not-RPL-aware-leaf to Internet) 536 The uses cases comprise as follow: 538 Interaction between Leaf and Root: 540 RPL-aware-leaf to root 542 root to RPL-aware-leaf 544 not-RPL-aware-leaf to root 546 root to not-RPL-aware-leaf 548 Interaction between Leaf and Internet: 550 RPL-aware-leaf to Internet 552 Internet to RPL-aware-leaf 554 not-RPL-aware-leaf to Internet 556 Internet to not-RPL-aware-leaf 558 Interaction between Leafs: 560 RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 562 RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 564 not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) 566 not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) 568 This document is consistent with the rule that a Header cannot be 569 inserted or removed on the fly inside an IPv6 packet that is being 570 routed. This is a fundamental precept of the IPv6 architecture as 571 outlined in [RFC8200]. Extensions may not be added or removed except 572 by the sender or the receiver. 574 However, unlike [RFC6553], the Hop-by-Hop Option Header used for the 575 RPI artifact has the first two bits set to '00'. This means that the 576 RPI artifact will be ignored when received by a host or router that 577 does not understand that option ( Section 4.2 [RFC8200]). 579 This means that when the no-drop RPI option code 0x23 is used, a 580 packet that leaves the RPL domain of an LLN (or that leaves the LLN 581 entirely) will not be discarded when it contains the [RFC6553] RPL 582 Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is 583 left in place even if the end host does not understand it. 585 NOTE: There is some possible security risk when the RPI information 586 is released to the Internet. At this point this is a theoretical 587 situation; no clear attack has been described. At worst, it is clear 588 that the RPI option would waste some network bandwidth when it 589 escapes. This is traded off against the savings in the LLN by not 590 having to encapsulate the packet in order to remove the artifact. 592 As the rank information in the RPI artifact is changed at each hop, 593 it will typically be zero when it arrives at the DODAG root. The 594 DODAG root SHOULD force it to zero when passing the packet out to the 595 Internet. The Internet will therefore not see any SenderRank 596 information. 598 Despite being legal to leave the RPI artifact in place, an 599 intermediate router that needs to add an extension header (RH3 or RPI 600 Option) MUST still encapsulate the packet in an (additional) outer IP 601 header. The new header is placed after this new outer IP header. 603 A corollary is that an RH3 or RPI Option can only be removed by an 604 intermediate router if it is placed in an encapsulating IPv6 Header, 605 which is addressed TO the intermediate router. When it does so, the 606 whole encapsulating header must be removed. (A replacement may be 607 added). This sometimes can result in outer IP headers being 608 addressed to the next hop router using link-local address. 610 Both RPI and RH3 headers may be modified in very specific ways by 611 routers on the path of the packet without the need to add to remove 612 an encapsulating header. Both headers were designed with this 613 modification in mind, and both the RPL RH3 and the RPL option are 614 marked mutable but recoverable: so an IPsec AH security header can be 615 applied across these headers, but it can not secure the values which 616 mutate. 618 RPI MUST be present in every single RPL data packet. There is one 619 exception in non-storing mode: when a packet is going down from the 620 root the RPI MAY be omitted. The rational is that in a downward non- 621 storing mode, the entire route is written, so there can be no loops 622 by construction, nor any confusion about which forwarding table to 623 use (as the root has already made all routing decisions). However, 624 there are still cases, such as in 6tisch, where the instanceID 625 portion of the RPI header may still be needed [RFC8180] to pick an 626 appropriate priority or channel at each hop. 628 Prior to [RFC8138], there was significant interest in removing the 629 RPI for downward flows in non-storing mode. The exception covered a 630 very small number of cases, and causes significant interoperability 631 challenges, yet costed significant code and testing complexity. The 632 ability to compress the RPI down to three bytes or less removes much 633 of the pressure to optimize this any further 634 [I-D.ietf-anima-autonomic-control-plane]. 636 The earlier examples are more extensive to make sure that the process 637 is clear, while later examples are more concise. 639 6. Storing mode 641 In storing mode (fully stateful), the sender can determine if the 642 destination is inside the LLN by looking if the destination address 643 is matched by the DIO's Prefix Information Option (PIO) option. 645 The following table itemizes which headers are needed in each of the 646 following scenarios. It indicate if an IPv6-in-IPv6 header MUST be 647 inserted, and whether the destination address of the IPv6-in-IPv6 648 header is the next hop, or the final target address. There are these 649 possible situations: hop-by-hop necessary (indicated by "hop"), or 650 final target address possible (indicated by "tgt"). In all cases hop 651 by hop MAY be used rather than the final target address. 653 In cases where no IPv6-in-IPv6 header is needed, the column states as 654 "No". 656 In all cases the RPI headers are needed, since it identifies 657 inconsistencies (loops) in the routing topology. In all cases the 658 RH3 is not needed because it is not used in storing mode. 660 In each case, 6LR_i are the intermediate routers from source to 661 destination. "1 <= i <= n", n is the number of routers (6LR) that 662 the packet go through from source (6LN) to destination. 664 The leaf can be a router 6LR or a host, both indicated as 6LN (see 665 Figure 5). 667 +---------------------+--------------+------------+--------------+ 668 | Interaction between | Use Case |IPv6-in-IPv6| v6-in-v6 dst | 669 +---------------------+--------------+------------+--------------+ 670 | | Raf to root | No | No | 671 + +--------------+------------+--------------+ 672 | Leaf - Root | root to Raf | No | No | 673 + +--------------+------------+--------------+ 674 | | root to ~Raf | No | No | 675 + +--------------+------------+--------------+ 676 | | ~Raf to root | MUST | root | 677 +---------------------+--------------+------------+--------------+ 678 | | Raf to Int | No | No | 679 + +--------------+------------+--------------+ 680 | Leaf - Internet | Int to Raf | MUST | tgt (Raf) | 681 + +--------------+------------+--------------+ 682 | | ~Raf to Int | MUST | root | 683 + +--------------+------------+--------------+ 684 | | Int to ~Raf | MUST | hop | 685 +---------------------+--------------+------------+--------------+ 686 | | Raf to Raf | No | No | 687 + +--------------+------------+--------------+ 688 | | Raf to ~Raf | No | No | 689 + Leaf - Leaf +--------------+------------+--------------+ 690 | | ~Raf to Raf | MUST | tgt (Raf) | 691 + +--------------+------------+--------------+ 692 | | ~Raf to ~Raf | Yes | hop | 693 +---------------------+--------------+------------+--------------+ 695 Figure 7: IPv6-in-IPv6 encapsulation in Storing mode. 697 6.1. Storing Mode: Interaction between Leaf and Root 699 In this section is described the communication flow in storing mode 700 (SM) between, 702 RPL-aware-leaf to root 704 root to RPL-aware-leaf 706 not-RPL-aware-leaf to root 708 root to not-RPL-aware-leaf 710 6.1.1. SM: Example of Flow from RPL-aware-leaf to root 712 In storing mode, RFC 6553 (RPI) is used to send RPL Information 713 instanceID and rank information. 715 As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does not 716 generally issue DIO messages; a leaf node accepts DIO messages from 717 upstream. (When the inconsistency in routing occurs, a leaf node 718 will generate a DIO with an infinite rank, to fix it). It may issue 719 DAO and DIS messages though it generally ignores DAO and DIS 720 messages. 722 In this case the flow comprises: 724 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 726 For example, a communication flow could be: Node F --> Node E --> 727 Node B --> Node A root(6LBR) 729 As it was mentioned in this document 6LRs, 6LBR are always full- 730 fledged RPL routers. 732 The 6LN (Node F) inserts the RPI header, and sends the packet to 6LR 733 (Node E) which decrements the rank in RPI and sends the packet up. 734 When the packet arrives at 6LBR (Node A), the RPI is removed and the 735 packet is processed. 737 No IPv6-in-IPv6 header is required. 739 The RPI header can be removed by the 6LBR because the packet is 740 addressed to the 6LBR. The 6LN must know that it is communicating 741 with the 6LBR to make use of this scenario. The 6LN can know the 742 address of the 6LBR because it knows the address of the root via the 743 DODAGID in the DIO messages. 745 +-------------------+-----+-------+------+ 746 | Header | 6LN | 6LR_i | 6LBR | 747 +-------------------+-----+-------+------+ 748 | Inserted headers | RPI | -- | -- | 749 | Removed headers | -- | -- | RPI | 750 | Re-added headers | -- | -- | -- | 751 | Modified headers | -- | RPI | -- | 752 | Untouched headers | -- | -- | -- | 753 +-------------------+-----+-------+------+ 755 Table 1: Storing: Summary of the use of headers from RPL-aware-leaf 756 to root 758 6.1.2. SM: Example of Flow from root to RPL-aware-leaf 760 In this case the flow comprises: 762 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 764 For example, a communication flow could be: Node A root(6LBR) --> 765 Node B --> Node D --> Node F 767 In this case the 6LBR inserts RPI header and sends the packet down, 768 the 6LR is going to increment the rank in RPI (it examines the 769 instanceID to identify the right forwarding table), the packet is 770 processed in the 6LN and the RPI removed. 772 No IPv6-in-IPv6 header is required. 774 +-------------------+------+-------+------+ 775 | Header | 6LBR | 6LR_i | 6LN | 776 +-------------------+------+-------+------+ 777 | Inserted headers | RPI | -- | -- | 778 | Removed headers | -- | -- | RPI | 779 | Re-added headers | -- | -- | -- | 780 | Modified headers | -- | RPI | -- | 781 | Untouched headers | -- | -- | -- | 782 +-------------------+------+-------+------+ 784 Table 2: Storing: Summary of the use of headers from root to RPL- 785 aware-leaf 787 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf 789 In this case the flow comprises: 791 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 793 For example, a communication flow could be: Node A root(6LBR) --> 794 Node B --> Node E --> Node G 796 As the RPI extension can be ignored by the not-RPL-aware leaf, this 797 situation is identical to the previous scenario. 799 +-------------------+------+-------+----------------+ 800 | Header | 6LBR | 6LR_i | IPv6 | 801 +-------------------+------+-------+----------------+ 802 | Inserted headers | RPI | -- | -- | 803 | Removed headers | -- | -- | -- | 804 | Re-added headers | -- | -- | -- | 805 | Modified headers | -- | RPI | -- | 806 | Untouched headers | -- | -- | RPI (Ignored) | 807 +-------------------+------+-------+----------------+ 809 Table 3: Storing: Summary of the use of headers from root to not-RPL- 810 aware-leaf 812 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root 814 In this case the flow comprises: 816 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 818 For example, a communication flow could be: Node G --> Node E --> 819 Node B --> Node A root(6LBR) 821 When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), 822 the 6LR_1 will insert a RPI header, encapsuladed in a IPv6-in-IPv6 823 header. The IPv6-in-IPv6 header can be addressed to the next hop 824 (Node B), or to the root (Node A). The root removes the header and 825 processes the packet. 827 +---------+-----+---------------+------------------+----------------+ 828 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | 829 | | 6 | | | | 830 +---------+-----+---------------+------------------+----------------+ 831 | Inserte | -- | IPv6-in- | IPv6-in- | -- | 832 | d | | IPv6(RPI) | IPv6(RPI)(1) | | 833 | headers | | | | | 834 | Removed | -- | -- | -- | IPv6-in- | 835 | headers | | | | IPv6(RPI) | 836 | Re- | -- | -- | IPv6-in- | -- | 837 | added | | | IPv6(RPI)(1) | | 838 | headers | | | | | 839 | Modifie | -- | -- | IPv6-in- | -- | 840 | d | | | IPv6(RPI)(2) | | 841 | headers | | | | | 842 | Untouch | -- | -- | -- | -- | 843 | ed | | | | | 844 | headers | | | | | 845 +---------+-----+---------------+------------------+----------------+ 847 Table 4: Storing: Summary of the use of headers from not-RPL-aware- 848 leaf to root. (1) Case where the IPv6-in-IPv6 header is addressed to 849 the next hop (Node B). (2) Case where the IPv6-in-IPv6 header is 850 addressed to the root (Node A) 852 6.2. Storing Mode: Interaction between Leaf and Internet. 854 In this section is described the communication flow in storing mode 855 (SM) between, 857 RPL-aware-leaf to Internet 859 Internet to RPL-aware-leaf 861 not-RPL-aware-leaf to Internet 863 Internet to not-RPL-aware-leaf 865 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet 867 RPL information from RFC 6553 may go out to Internet as it will be 868 ignored by nodes which have not been configured to be RPI aware. 870 In this case the flow comprises: 872 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 873 For example, the communication flow could be: Node F --> Node D --> 874 Node B --> Node A root(6LBR) --> Internet 876 No IPv6-in-IPv6 header is required. 878 Note: In this use case it is used a node as leaf, but this use case 879 can be also applicable to any RPL-node type (e.g. 6LR) 881 +-------------------+------+-------+------+----------------+ 882 | Header | 6LN | 6LR_i | 6LBR | Internet | 883 +-------------------+------+-------+------+----------------+ 884 | Inserted headers | RPI | -- | -- | -- | 885 | Removed headers | -- | -- | -- | -- | 886 | Re-added headers | -- | -- | -- | -- | 887 | Modified headers | -- | RPI | -- | -- | 888 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 889 +-------------------+------+-------+------+----------------+ 891 Table 5: Storing: Summary of the use of headers from RPL-aware-leaf 892 to Internet 894 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf 896 In this case the flow comprises: 898 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 900 For example, a communication flow could be: Internet --> Node A 901 root(6LBR) --> Node B --> Node D --> Node F 903 When the packet arrives from Internet to 6LBR the RPI header is added 904 in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the 905 rank in the RPI. When the packet arrives at 6LN the RPI header is 906 removed and the packet processed. 908 +---------+--------+---------------+---------------+----------------+ 909 | Header | Intern | 6LBR | 6LR_i | 6LN | 910 | | et | | | | 911 +---------+--------+---------------+---------------+----------------+ 912 | Inserte | -- | IPv6-in- | -- | -- | 913 | d | | IPv6(RPI) | | | 914 | headers | | | | | 915 | Removed | -- | -- | -- | IPv6-in- | 916 | headers | | | | IPv6(RPI) | 917 | Re- | -- | -- | -- | -- | 918 | added | | | | | 919 | headers | | | | | 920 | Modifie | -- | -- | IPv6-in- | -- | 921 | d | | | IPv6(RPI) | | 922 | headers | | | | | 923 | Untouch | -- | -- | -- | -- | 924 | ed | | | | | 925 | headers | | | | | 926 +---------+--------+---------------+---------------+----------------+ 928 Table 6: Storing: Summary of the use of headers from Internet to RPL- 929 aware-leaf 931 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 933 In this case the flow comprises: 935 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 936 Internet 938 For example, a communication flow could be: Node G --> Node E --> 939 Node B --> Node A root(6LBR) --> Internet 941 The 6LR_1 (i=1) node will add an IPv6-in-IPv6(RPI) header addressed 942 either to the root, or hop-by-hop such that the root can remove the 943 RPI header before passing upwards. The IPv6-in-IPv6 addressed to the 944 root cause less processing overhead. On the other hand, with hop-by- 945 hop the intermediate routers can check the routing tables for a 946 better routing path, thus it could be more efficient and faster. 947 Implementation should decide which approach to take. 949 The originating node will ideally leave the IPv6 flow label as zero 950 so that the packet can be better compressed through the LLN. The 951 6LBR will set the flow label of the packet to a non-zero value when 952 sending to the Internet. 954 +-------+----+-------------+---------------+---------------+--------+ 955 | Heade | IP | 6LR_1 | 6LR_i | 6LBR | Intern | 956 | r | v6 | | [i=2,..,n]_ | | et | 957 +-------+----+-------------+---------------+---------------+--------+ 958 | Inser | -- | IPv6-in- | IPv6-in- | -- | -- | 959 | ted h | | IPv6(RPI) | IPv6(RPI)(2) | | | 960 | eader | | | | | | 961 | s | | | | | | 962 | Remov | -- | -- | IPv6-in- | IPv6-in- | -- | 963 | ed he | | | IPv6(RPI)(2) | IPv6(RPI)(1) | | 964 | aders | | | | | | 965 | Re- | -- | -- | -- | -- | -- | 966 | added | | | | | | 967 | heade | | | | | | 968 | rs | | | | | | 969 | Modif | -- | -- | IPv6-in- | -- | -- | 970 | ied h | | | IPv6(RPI)(1) | | | 971 | eader | | | | | | 972 | s | | | | | | 973 | Untou | -- | -- | -- | -- | -- | 974 | ched | | | | | | 975 | heade | | | | | | 976 | rs | | | | | | 977 +-------+----+-------------+---------------+---------------+--------+ 979 Table 7: Storing: Summary of the use of headers from not-RPL-aware- 980 leaf to Internet. (1) Case when packet is addressed to the root. 981 (2) Case when the packet is addressed hop-by-hop. 983 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-leaf. 985 In this case the flow comprises: 987 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 989 For example, a communication flow could be: Internet --> Node A 990 root(6LBR) --> Node B --> Node E --> Node G 992 The 6LBR will have to add an RPI header within an IPv6-in-IPv6 993 header. The IPv6-in-IPv6 is addressed to the not-RPL-aware-leaf, 994 leaving the RPI inside. 996 Note that there is a requirement that the final node be able to 997 remove one or more IPv6-in-IPv6 headers which are all addressed to 998 it, mentioned in [I-D.thubert-roll-unaware-leaves] : 1000 "RPL data packets are often encapsulated using IP in IP. The 6LN 1001 MUST be able to decapsulate a packet when it is the destination of 1002 the outer header and process correctly the inner header." 1004 The 6LBR MAY set the flow label on the inner IPv6-in-IPv6 header to 1005 zero in order to aid in compression. 1007 +--------+---------+---------------+---------------+----------------+ 1008 | Header | Interne | 6LBR | 6LR_i | IPv6 | 1009 | | t | | | | 1010 +--------+---------+---------------+---------------+----------------+ 1011 | Insert | -- | IPv6-in- | -- | -- | 1012 | ed hea | | IPv6(RPI) | | | 1013 | ders | | | | | 1014 | Remove | -- | -- | -- | IPv6-in- | 1015 | d head | | | | IPv6(RPI)- RPI | 1016 | ers | | | | (Ignored) | 1017 | Re- | -- | -- | -- | -- | 1018 | added | | | | | 1019 | header | | | | | 1020 | s | | | | | 1021 | Modifi | -- | -- | IPv6-in- | -- | 1022 | ed hea | | | IPv6(RPI) | | 1023 | ders | | | | | 1024 | Untouc | -- | -- | -- | -- | 1025 | hed he | | | | | 1026 | aders | | | | | 1027 +--------+---------+---------------+---------------+----------------+ 1029 Table 8: Storing: Summary of the use of headers from Internet to non- 1030 RPL-aware-leaf 1032 6.3. Storing Mode: Interaction between Leaf and Leaf 1034 In this section is described the communication flow in storing mode 1035 (SM) between, 1037 RPL-aware-leaf to RPL-aware-leaf 1039 RPL-aware-leaf to not-RPL-aware-leaf 1041 not-RPL-aware-leaf to RPL-aware-leaf 1043 not-RPL-aware-leaf to not-RPL-aware-leaf 1045 6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1047 In [RFC6550] RPL allows a simple one-hop optimization for both 1048 storing and non-storing networks. A node may send a packet destined 1049 to a one-hop neighbor directly to that node. See section 9 in 1050 [RFC6550]. 1052 When the nodes are not directly connected, then in storing mode, the 1053 flow comprises: 1055 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> 6LN 1057 For example, a communication flow could be: Node F --> Node D --> 1058 Node B --> Node E --> Node H 1060 6LR_ia (Node D) are the intermediate routers from source to the 1061 common parent (6LR_x) (Node B) In this case, "1 <= ia <= n", n is the 1062 number of routers (6LR) that the packet go through from 6LN (Node F) 1063 to the common parent (6LR_x). 1065 6LR_id (Node E) are the intermediate routers from the common parent 1066 (6LR_x) (Node B) to destination 6LN (Node H). In this case, "1 <= id 1067 <= m", m is the number of routers (6LR) that the packet go through 1068 from the common parent (6LR_x) to destination 6LN. 1070 It is assumed that the two nodes are in the same RPL Domain (that 1071 they share the same DODAG root). At the common parent (Node B), the 1072 direction of RPI is changed (from increasing to decreasing the rank). 1074 While the 6LR nodes will update the RPI, no node needs to add or 1075 remove the RPI, so no IPv6-in-IPv6 headers are necessary. This may 1076 be done regardless of where the destination is, as the included RPI 1077 will be ignored by the receiver. 1079 +---------------+--------+--------+---------------+--------+--------+ 1080 | Header | 6LN | 6LR_ia | 6LR_x (common | 6LR_id | 6LN | 1081 | | src | | parent) | | dst | 1082 +---------------+--------+--------+---------------+--------+--------+ 1083 | Inserted | RPI | -- | -- | -- | -- | 1084 | headers | | | | | | 1085 | Removed | -- | -- | -- | -- | RPI | 1086 | headers | | | | | | 1087 | Re-added | -- | -- | -- | -- | -- | 1088 | headers | | | | | | 1089 | Modified | -- | RPI | RPI | RPI | -- | 1090 | headers | | | | | | 1091 | Untouched | -- | -- | -- | -- | -- | 1092 | headers | | | | | | 1093 +---------------+--------+--------+---------------+--------+--------+ 1095 Table 9: Storing: Summary of the use of headers for RPL-aware-leaf to 1096 RPL-aware-leaf 1098 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 1100 In this case the flow comprises: 1102 6LN --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> not-RPL-aware 1103 6LN (IPv6) 1105 For example, a communication flow could be: Node F --> Node D --> 1106 Node B --> Node E --> Node G 1108 6LR_ia are the intermediate routers from source (6LN) to the common 1109 parent (6LR_x) In this case, "1 <= ia <= n", n is the number of 1110 routers (6LR) that the packet go through from 6LN to the common 1111 parent (6LR_x). 1113 6LR_id (Node E) are the intermediate routers from the common parent 1114 (6LR_x) (Node B) to destination not-RPL-aware 6LN (IPv6) (Node G). 1115 In this case, "1 <= id <= m", m is the number of routers (6LR) that 1116 the packet go through from the common parent (6LR_x) to destination 1117 6LN. 1119 This situation is identical to the previous situation Section 6.3.1 1120 +-----------+------+--------+---------------+--------+--------------+ 1121 | Header | 6LN | 6LR_ia | 6LR_x(common | 6LR_id | IPv6 | 1122 | | src | | parent) | | | 1123 +-----------+------+--------+---------------+--------+--------------+ 1124 | Inserted | RPI | -- | -- | -- | -- | 1125 | headers | | | | | | 1126 | Removed | -- | -- | -- | -- | -- | 1127 | headers | | | | | | 1128 | Re-added | -- | -- | -- | -- | -- | 1129 | headers | | | | | | 1130 | Modified | -- | RPI | RPI | RPI | -- | 1131 | headers | | | | | | 1132 | Untouched | -- | -- | -- | -- | RPI(Ignored) | 1133 | headers | | | | | | 1134 +-----------+------+--------+---------------+--------+--------------+ 1136 Table 10: Storing: Summary of the use of headers for RPL-aware-leaf 1137 to non-RPL-aware-leaf 1139 6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 1141 In this case the flow comprises: 1143 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> common parent (6LR_x) --> 1144 6LR_id --> 6LN 1146 For example, a communication flow could be: Node G --> Node E --> 1147 Node B --> Node D --> Node F 1149 6LR_ia (Node E) are the intermediate routers from source (not-RPL- 1150 aware 6LN (IPv6)) (Node G) to the common parent (6LR_x) (Node B). In 1151 this case, "1 <= ia <= n", n is the number of routers (6LR) that the 1152 packet go through from source to the common parent. 1154 6LR_id (Node D) are the intermediate routers from the common parent 1155 (6LR_x) (Node B) to destination 6LN (Node F). In this case, "1 <= id 1156 <= m", m is the number of routers (6LR) that the packet go through 1157 from the common parent (6LR_x) to destination 6LN. 1159 The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node 1160 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 1161 header. The IPv6-in-IPv6 header is addressed to the destination 6LN 1162 (Node F). 1164 +-------+----+------------+-------------+-------------+-------------+ 1165 | Heade | IP | 6LR_ia | common | 6LR_id | 6LN | 1166 | r | v6 | | parent | | | 1167 | | | | (6LRx) | | | 1168 +-------+----+------------+-------------+-------------+-------------+ 1169 | Inser | -- | IPv6-in- | -- | -- | -- | 1170 | ted h | | IPv6(RPI) | | | | 1171 | eader | | | | | | 1172 | s | | | | | | 1173 | Remov | -- | -- | -- | -- | IPv6-in- | 1174 | ed he | | | | | IPv6(RPI) | 1175 | aders | | | | | | 1176 | Re- | -- | -- | -- | -- | -- | 1177 | added | | | | | | 1178 | heade | | | | | | 1179 | rs | | | | | | 1180 | Modif | -- | -- | IPv6-in- | IPv6-in- | -- | 1181 | ied h | | | IPv6(RPI) | IPv6(RPI) | | 1182 | eader | | | | | | 1183 | s | | | | | | 1184 | Untou | -- | -- | -- | -- | -- | 1185 | ched | | | | | | 1186 | heade | | | | | | 1187 | rs | | | | | | 1188 +-------+----+------------+-------------+-------------+-------------+ 1190 Table 11: Storing: Summary of the use of headers from not-RPL-aware- 1191 leaf to RPL-aware-leaf 1193 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 1194 leaf 1196 In this case the flow comprises: 1198 not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LR_id --> not- 1199 RPL-aware 6LN (IPv6 dst) 1201 For example, a communication flow could be: Node G --> Node E --> 1202 Node B --> Node A (root) --> Node C --> Node J 1204 Internal nodes 6LR_ia (e.g: Node E or Node B) are the intermediate 1205 routers from the not-RPL-aware source (Node G) to the root (6LBR) 1206 (Node A). In this case, "1 < ia <= n", n is the number of routers 1207 (6LR) that the packet go through from IPv6 src to the root. 1209 6LR_id (C) are the intermediate routers from the root (Node A) to the 1210 destination Node J. In this case, "1 <= id <= m", m is the number of 1211 routers (6LR) that the packet go through from the root to destination 1212 (IPv6 dst). 1214 Note that this flow is identical to Section 6.3.3, except for where 1215 the IPv6-in-IPv6 header is inserted. 1217 The 6LR_1 (Node E) receives the packet from the the IPv6 node (Node 1218 G) and inserts the RPI header (RPI), encapsulated in an IPv6-in-IPv6 1219 header. The IPv6-in-IPv6 header is addressed to the final 1220 destination (Node J). 1222 +-------+----+------------+-------------+-------------+-------------+ 1223 | Heade | IP | 6LR_1 | 6LR_ia | 6LR_m | IPv6 dst | 1224 | r | v6 | | | | | 1225 | | sr | | | | | 1226 | | c | | | | | 1227 +-------+----+------------+-------------+-------------+-------------+ 1228 | Inser | -- | IPv6-in- | -- | -- | -- | 1229 | ted h | | IPv6(RPI) | | | | 1230 | eader | | | | | | 1231 | s | | | | | | 1232 | Remov | -- | -- | -- | -- | IPv6-in- | 1233 | ed he | | | | | IPv6(RPI), | 1234 | aders | | | | | RPI Ignored | 1235 | Re- | -- | -- | -- | -- | -- | 1236 | added | | | | | | 1237 | heade | | | | | | 1238 | rs | | | | | | 1239 | Modif | -- | -- | IPv6-in- | IPv6-in- | -- | 1240 | ied h | | | IPv6(RPI) | IPv6(RPI) | | 1241 | eader | | | | | | 1242 | s | | | | | | 1243 | Untou | -- | -- | -- | -- | -- | 1244 | ched | | | | | | 1245 | heade | | | | | | 1246 | rs | | | | | | 1247 +-------+----+------------+-------------+-------------+-------------+ 1249 Table 12: Storing: Summary of the use of headers from not-RPL-aware- 1250 leaf to non-RPL-aware-leaf 1252 7. Non Storing mode 1254 In Non Storing Mode (Non SM) (fully source routed), the 6LBR (DODAG 1255 root) has complete knowledge about the connectivity of all DODAG 1256 nodes, and all traffic flows through the root node. Thus, there is 1257 no need for all nodes to know about the existence of non-RPL aware 1258 nodes. Only the 6LBR needs to act if compensation is necessary for 1259 non-RPL aware receivers. 1261 The following table summarizes what headers are needed in the 1262 following scenarios, and indicates when the RPI, RH3 and IPv6-in-IPv6 1263 header are to be inserted. There are these possible situations: 1264 target destination address possible (indicated by "tgt"), to a 6LR, 1265 to a 6LN or to the root. In cases where no IPv6-in-IPv6 header is 1266 needed, the column states as "No". 1268 The leaf can be a router 6LR or a host, both indicated as 6LN 1269 (Figure 3). In the Figure the (1) indicates a 6tisch case [RFC8180], 1270 where the instanceID portion of the RPI header may still be needed to 1271 pick an appropriate priority or channel at each hop. 1273 +-----------------+--------------+-----+-----+----------+----------+ 1274 | Interaction | Use Case | RPI | RH3 | v6-in-v6 | v6-in-v6 | 1275 | between | | | | | dst | 1276 +-----------------+--------------+-----+-----+----------+----------+ 1277 | | Raf to root | Yes | No | No | No | 1278 + +--------------+-----+-----+----------+----------+ 1279 | Leaf - Root | root to Raf | Opt | Yes | No | No | 1280 + +--------------+-----+-----+----------+----------+ 1281 | | root to ~Raf |No(1)| Yes | MUST | 6LR | 1282 + +--------------+-----+-----+----------+----------+ 1283 | | ~Raf to root | Yes | No | MUST | root | 1284 +-----------------+--------------+-----+-----+----------+----------+ 1285 | | Raf to Int | Yes | No | MUST | root | 1286 + +--------------+-----+-----+----------+----------+ 1287 | Leaf - Internet | Int to Raf |No(1)| Yes | MUST | tgt | 1288 + +--------------+-----+-----+----------+----------+ 1289 | | ~Raf to Int | Yes | No | MUST | root | 1290 + +--------------+-----+-----+----------+----------+ 1291 | | Int to ~Raf |No(1)| Yes | MUST | 6LR | 1292 +-----------------+--------------+-----+-----+----------+----------+ 1293 | | Raf to Raf | Yes | Yes | MUST | root/tgt | 1294 + +--------------+-----+-----+----------+----------+ 1295 | | Raf to ~Raf | Yes | Yes | MUST | root/6LR | 1296 + Leaf - Leaf +--------------+-----+-----+----------+----------+ 1297 | | ~Raf to Raf | Yes | Yes | MUST | root/6LN | 1298 + +--------------+-----+-----+----------+----------+ 1299 | | ~Raf to ~Raf | Yes | Yes | MUST | root/6LR | 1300 +-----------------+--------------+-----+-----+----------+----------+ 1302 (1)-6tisch networks may need the RPI information. 1304 Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IPv6-in-IPv6 1305 encapsulation. 1307 7.1. Non-Storing Mode: Interaction between Leaf and Root 1309 In this section is described the communication flow in Non Storing 1310 Mode (Non-SM) between, 1312 RPL-aware-leaf to root 1314 root to RPL-aware-leaf 1316 not-RPL-aware-leaf to root 1318 root to not-RPL-aware-leaf 1320 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root 1322 In non-storing mode the leaf node uses default routing to send 1323 traffic to the root. The RPI header MUST be included since contains 1324 the rank information, which is used to avoid/detect loops. 1326 RPL-aware-leaf (6LN) --> 6LR_i --> root(6LBR) 1328 For example, a communication flow could be: Node F --> Node D --> 1329 Node B --> Node A (root) 1331 6LR_i are the intermediate routers from source to destination. In 1332 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1333 packet go through from source (6LN) to destination (6LBR). 1335 This situation is the same case as storing mode. 1337 +-------------------+-----+-------+------+ 1338 | Header | 6LN | 6LR_i | 6LBR | 1339 +-------------------+-----+-------+------+ 1340 | Inserted headers | RPI | -- | -- | 1341 | Removed headers | -- | -- | RPI | 1342 | Re-added headers | -- | -- | -- | 1343 | Modified headers | -- | RPI | -- | 1344 | Untouched headers | -- | -- | -- | 1345 +-------------------+-----+-------+------+ 1347 Table 13: Non Storing: Summary of the use of headers from RPL-aware- 1348 leaf to root 1350 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf 1352 In this case the flow comprises: 1354 root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1356 For example, a communication flow could be: Node A (root) --> Node B 1357 --> Node D --> Node F 1359 6LR_i are the intermediate routers from source to destination. In 1360 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1361 packet go through from source (6LBR) to destination (6LN). 1363 The 6LBR inserts an RH3, and a RPI header. No IPv6-in-IPv6 header is 1364 necessary as the traffic originates with an RPL aware node, the 6LBR. 1365 The destination is known to RPL-aware because, the root knows the 1366 whole topology in non-storing mode. 1368 +-------------------+-----------------+-------+------------------+ 1369 | Header | 6LBR | 6LR_i | 6LN | 1370 +-------------------+-----------------+-------+------------------+ 1371 | Inserted headers | (opt: RPI), RH3 | -- | -- | 1372 | Removed headers | -- | -- | RH3, (opt: RPI) | 1373 | Re-added headers | -- | -- | -- | 1374 | Modified headers | -- | RH3 | -- | 1375 | Untouched headers | -- | -- | -- | 1376 +-------------------+-----------------+-------+------------------+ 1378 Table 14: Non Storing: Summary of the use of headers from root to 1379 RPL-aware-leaf 1381 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-leaf 1383 In this case the flow comprises: 1385 root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1387 For example, a communication flow could be: Node A (root) --> Node B 1388 --> Node E --> Node G 1390 6LR_i are the intermediate routers from source to destination. In 1391 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1392 packet go through from source (6LBR) to destination (IPv6). 1394 In 6LBR the RH3 is added, it is modified at each intermediate 6LR 1395 (6LR_1 and so on) and it is fully consumed in the last 6LR (6LR_n), 1396 but left there. If RPI is left by the previous 6LR, then the IPv6 1397 node which does not understand the RPI, will ignore it (following 1398 RFC8200), thus encapsulation is not necessary. Due the complete 1399 knowledge of the topology at the root, the 6LBR may optionally 1400 address the IPv6-in-IPv6 header to the last 6LR, such that it is 1401 removed prior to the IPv6 node. Please see Section 8 for 1402 clarification of use of IPv6-in-IPv6 encapsulation. 1404 +---------------+-------------+--------------+------------+---------+ 1405 | Header | 6LBR | 6LR_i(i=1) | 6LR_n(i=n) | IPv6 | 1406 +---------------+-------------+--------------+------------+---------+ 1407 | Inserted | (opt: RPI), | -- | -- | -- | 1408 | headers | RH3 | | | | 1409 | Removed | -- | -- | RH3 | -- | 1410 | headers | | | | | 1411 | Re-added | -- | -- | -- | -- | 1412 | headers | | | | | 1413 | Modified | -- | (opt: RPI), | (opt: RPI) | -- | 1414 | headers | | RH3 | | | 1415 | Untouched | -- | -- | -- | opt: | 1416 | headers | | | | RPI | 1417 +---------------+-------------+--------------+------------+---------+ 1419 Table 15: Non Storing: Summary of the use of headers from root to 1420 not-RPL-aware-leaf 1422 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to root 1424 In this case the flow comprises: 1426 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i --> root (6LBR) 1428 For example, a communication flow could be: Node G --> Node E --> 1429 Node B --> Node A (root) 1431 6LR_i are the intermediate routers from source to destination. In 1432 this case, "1 < i <= n", n is the number of routers (6LR) that the 1433 packet go through from source (IPv6) to destination (6LBR). For 1434 example, 6LR_1 (i=1) is the router that receives the packets from the 1435 IPv6 node. 1437 In this case the RPI is added by the first 6LR (6LR1) (Node E), 1438 encapsulated in an IPv6-in-IPv6 header, and is modified in the 1439 following 6LRs. The RPI and entire packet is consumed by the root. 1441 +---------+-----+----------------+----------------+-----------------+ 1442 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | 1443 | | 6 | | | | 1444 +---------+-----+----------------+----------------+-----------------+ 1445 | Inserte | -- | IPv6-in- | -- | -- | 1446 | d | | IPv6(RPI) | | | 1447 | headers | | | | | 1448 | Removed | -- | -- | -- | IPv6-in- | 1449 | headers | | | | IPv6(RPI) | 1450 | Re- | -- | -- | -- | -- | 1451 | added | | | | | 1452 | headers | | | | | 1453 | Modifie | -- | -- | IPv6-in- | -- | 1454 | d | | | IPv6(RPI) | | 1455 | headers | | | | | 1456 | Untouch | -- | -- | -- | -- | 1457 | ed | | | | | 1458 | headers | | | | | 1459 +---------+-----+----------------+----------------+-----------------+ 1461 Table 16: Non Storing: Summary of the use of headers from not-RPL- 1462 aware-leaf to root 1464 7.2. Non-Storing Mode: Interaction between Leaf and Internet 1466 This section will describe the communication flow in Non Storing Mode 1467 (Non-SM) between: 1469 RPL-aware-leaf to Internet 1471 Internet to RPL-aware-leaf 1473 not-RPL-aware-leaf to Internet 1475 Internet to not-RPL-aware-leaf 1477 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to Internet 1479 In this case the flow comprises: 1481 RPL-aware-leaf (6LN) --> 6LR_i --> root (6LBR) --> Internet 1483 For example, a communication flow could be: Node F --> Node D --> 1484 Node B --> Node A --> Internet 1486 6LR_i are the intermediate routers from source to destination. In 1487 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1488 packet go through from source (6LN) to 6LBR. 1490 This case is identical to storing-mode case. 1492 The IPv6 flow label should be set to zero to aid in compression, and 1493 the 6LBR will set it to a non-zero value when sending towards the 1494 Internet. 1496 +-------------------+------+-------+------+----------------+ 1497 | Header | 6LN | 6LR_i | 6LBR | Internet | 1498 +-------------------+------+-------+------+----------------+ 1499 | Inserted headers | RPI | -- | -- | -- | 1500 | Removed headers | -- | -- | -- | -- | 1501 | Re-added headers | -- | -- | -- | -- | 1502 | Modified headers | -- | RPI | -- | -- | 1503 | Untouched headers | -- | -- | RPI | RPI (Ignored) | 1504 +-------------------+------+-------+------+----------------+ 1506 Table 17: Non Storing: Summary of the use of headers from RPL-aware- 1507 leaf to Internet 1509 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-leaf 1511 In this case the flow comprises: 1513 Internet --> root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) 1515 For example, a communication flow could be: Internet --> Node A 1516 (root) --> Node B --> Node D --> Node F 1518 6LR_i are the intermediate routers from source to destination. In 1519 this case, "1 <= i <= n", n is the number of routers (6LR) that the 1520 packet go through from 6LBR to destination(6LN). 1522 The 6LBR must add an RH3 header. As the 6LBR will know the path and 1523 address of the target node, it can address the IPv6-in-IPv6 header to 1524 that node. The 6LBR will zero the flow label upon entry in order to 1525 aid compression. 1527 +-----------+----------+--------------+--------------+--------------+ 1528 | Header | Internet | 6LBR | 6LR_i | 6LN | 1529 +-----------+----------+--------------+--------------+--------------+ 1530 | Inserted | -- | IPv6-in-IPv6 | -- | -- | 1531 | headers | | (RH3,RPI) | | | 1532 | Removed | -- | -- | -- | IPv6-in-IPv6 | 1533 | headers | | | | (RH3,RPI) | 1534 | Re-added | -- | -- | -- | -- | 1535 | headers | | | | | 1536 | Modified | -- | -- | IPv6-in-IPv6 | -- | 1537 | headers | | | (RH3,RPI) | | 1538 | Untouched | -- | -- | -- | -- | 1539 | headers | | | | | 1540 +-----------+----------+--------------+--------------+--------------+ 1542 Table 18: Non Storing: Summary of the use of headers from Internet to 1543 RPL-aware-leaf 1545 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to Internet 1547 In this case the flow comprises: 1549 not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> 1550 Internet 1552 For example, a communication flow could be: Node G --> Node E --> 1553 Node B --> Node A --> Internet 1555 6LR_i are the intermediate routers from source to destination. In 1556 this case, "1 < i <= n", n is the number of routers (6LR) that the 1557 packet go through from source(IPv6) to 6LBR. e.g 6LR_1 (i=1). 1559 In this case the flow label is recommended to be zero in the IPv6 1560 node. As RPL headers are added in the IPv6 node packet, the first 1561 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 1562 The IPv6-in-IPv6 header will be addressed to the root. This case is 1563 identical to the storing-mode case (see Section 6.2.3). 1565 +---------+-----+------------+-------------+-------------+----------+ 1566 | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Internet | 1567 | | 6 | | [i=2,..,n]_ | | | 1568 +---------+-----+------------+-------------+-------------+----------+ 1569 | Inserte | -- | IPv6-in- | -- | -- | -- | 1570 | d | | IPv6 (RPI) | | | | 1571 | headers | | | | | | 1572 | Removed | -- | -- | -- | IPv6-in- | -- | 1573 | headers | | | | IPv6 (RPI) | | 1574 | Re- | -- | -- | -- | -- | -- | 1575 | added | | | | | | 1576 | headers | | | | | | 1577 | Modifie | -- | -- | IPv6-in- | -- | -- | 1578 | d | | | IPv6 (RPI) | | | 1579 | headers | | | | | | 1580 | Untouch | -- | -- | -- | -- | -- | 1581 | ed | | | | | | 1582 | headers | | | | | | 1583 +---------+-----+------------+-------------+-------------+----------+ 1585 Table 19: Non Storing: Summary of the use of headers from not-RPL- 1586 aware-leaf to Internet 1588 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 1590 In this case the flow comprises: 1592 Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) 1594 For example, a communication flow could be: Internet --> Node A 1595 (root) --> Node B --> Node E --> Node G 1597 6LR_i are the intermediate routers from source to destination. In 1598 this case, "1 < i <= n", n is the number of routers (6LR) that the 1599 packet go through from 6LBR to not-RPL-aware-leaf (IPv6). 1601 The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The 1602 6LBR will know the path, and will recognize that the final node is 1603 not an RPL capable node as it will have received the connectivity DAO 1604 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 1605 header destination be the last 6LR. The 6LBR will set to zero the 1606 flow label upon entry in order to aid compression. 1608 +---------+--------+------------+------------+---------------+------+ 1609 | Header | Intern | 6LBR | 6LR_1 | 6LR_i(i=2,.., | IPv6 | 1610 | | et | | | n) | | 1611 +---------+--------+------------+------------+---------------+------+ 1612 | Inserte | -- | IPv6-in- | -- | -- | -- | 1613 | d | | IPv6 (RH3, | | | | 1614 | headers | | RPI) | | | | 1615 | Removed | -- | -- | -- | IPv6-in-IPv6 | -- | 1616 | headers | | | | (RH3,RPI)(1) | | 1617 | Re- | -- | -- | -- | -- | -- | 1618 | added | | | | | | 1619 | headers | | | | | | 1620 | Modifie | -- | -- | IPv6-in- | IPv6-in-IPv6 | -- | 1621 | d | | | IPv6 | (RH3, RPI) | | 1622 | headers | | | (RH3,RPI) | | | 1623 | Untouch | -- | -- | -- | -- | -- | 1624 | ed | | | | | | 1625 | headers | | | | | | 1626 +---------+--------+------------+------------+---------------+------+ 1628 Table 20: NonStoring: Summary of the use of headers from Internet to 1629 non-RPL-aware-leaf (1) The last 6LR before the IPv6 node. 1631 7.3. Non-Storing Mode: Interaction between Leafs 1633 In this section is described the communication flow in Non Storing 1634 Mode (Non-SM) between, 1636 RPL-aware-leaf to RPL-aware-leaf 1638 RPL-aware-leaf to not-RPL-aware-leaf 1640 not-RPL-aware-leaf to RPL-aware-leaf 1642 not-RPL-aware-leaf to not-RPL-aware-leaf 1644 7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-aware-leaf 1646 In this case the flow comprises: 1648 6LN src --> 6LR_ia --> root (6LBR) --> 6LR_id --> 6LN dst 1650 For example, a communication flow could be: Node F --> Node D --> 1651 Node B --> Node A (root) --> Node B --> Node E --> Node H 1653 6LR_ia are the intermediate routers from source to the root In this 1654 case, "1 <= ia <= n", n is the number of routers (6LR) that the 1655 packet go through from 6LN to the root. 1657 6LR_id are the intermediate routers from the root to the destination. 1658 In this case, "1 <= ia <= m", m is the number of the intermediate 1659 routers (6LR). 1661 This case involves only nodes in same RPL Domain. The originating 1662 node will add a RPI header to the original packet, and send the 1663 packet upwards. 1665 The originating node SHOULD put the RPI into an IPv6-in-IPv6 header 1666 addressed to the root, so that the 6LBR can remove that header. If 1667 it does not, then additional resources are wasted on the way down to 1668 carry the useless RPI option. 1670 The 6LBR will need to insert an RH3 header, which requires that it 1671 add an IPv6-in-IPv6 header. It SHOULD be able to remove the RPI, as 1672 it was contained in an IPv6-in-IPv6 header addressed to it. 1673 Otherwise, there MAY be a RPI header buried inside the inner IP 1674 header, which should get ignored. 1676 Networks that use the RPL P2P extension [RFC6997] are essentially 1677 non-storing DODAGs and fall into this scenario or scenario 1678 Section 7.1.2, with the originating node acting as 6LBR. 1680 +---------+------------+-------+-------------+--------+-------------+ 1681 | Header | 6LN src | 6LR_i | 6LBR | 6LR_id | 6LN dst | 1682 | | | a | | | | 1683 +---------+------------+-------+-------------+--------+-------------+ 1684 | Inserte | IPv6-in- | -- | IPv6-in- | -- | -- | 1685 | d | IPv6 | | IPv6 | | | 1686 | headers | (RPI1) | | (RH3->6LN, | | | 1687 | | | | opt RPI2) | | | 1688 | Removed | -- | -- | IPv6-in- | -- | IPv6-in- | 1689 | headers | | | IPv6 (RPI1) | | IPv6 (RH3, | 1690 | | | | | | opt RPI2) | 1691 | Re- | -- | -- | -- | -- | -- | 1692 | added | | | | | | 1693 | headers | | | | | | 1694 | Modifie | -- | RPI1 | -- | RPI2 | -- | 1695 | d | | | | | | 1696 | headers | | | | | | 1697 | Untouch | -- | -- | -- | -- | -- | 1698 | ed | | | | | | 1699 | headers | | | | | | 1700 +---------+------------+-------+-------------+--------+-------------+ 1702 Table 21: Non Storing: Summary of the use of headers for RPL-aware- 1703 leaf to RPL-aware-leaf 1705 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 1706 leaf 1708 In this case the flow comprises: 1710 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 1712 For example, a communication flow could be: Node F --> Node D --> 1713 Node B --> Node A (root) --> Node B --> Node E --> Node G 1715 6LR_ia are the intermediate routers from source to the root In this 1716 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1718 6LR_id are the intermediate routers from the root to the destination. 1719 In this case, "1 <= ia <= m", m is the number of the intermediate 1720 routers (6LR). 1722 As in the previous case, the 6LN will insert a RPI (RPI_1) header 1723 which MUST be in an IPv6-in-IPv6 header addressed to the root so that 1724 the 6LBR can remove this RPI. The 6LBR will then insert an RH3 1725 inside a new IPv6-in-IPv6 header addressed to the 6LR_id. The RPI is 1726 optional from 6LBR to 6LR_id (RPI_2). 1728 +---------+-----------+-----------+------------+------------+-------+ 1729 | Header | 6LN | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1730 +---------+-----------+-----------+------------+------------+-------+ 1731 | Inserte | IPv6-in- | -- | IPv6-in- | -- | -- | 1732 | d | IPv6 | | IPv6 (RH3, | | | 1733 | headers | (RPI1) | | opt RPI_2) | | | 1734 | Removed | -- | -- | IPv6-in- | IPv6-in- | -- | 1735 | headers | | | IPv6 | IPv6 (RH3, | | 1736 | | | | (RPI_1) | opt RPI_2) | | 1737 | Re- | -- | -- | -- | -- | -- | 1738 | added | | | | | | 1739 | headers | | | | | | 1740 | Modifie | -- | IPv6-in- | -- | IPv6-in- | -- | 1741 | d | | IPv6 | | IPv6 (RH3, | | 1742 | headers | | (RPI_1) | | opt RPI_2) | | 1743 | Untouch | -- | -- | -- | -- | opt | 1744 | ed | | | | | RPI_2 | 1745 | headers | | | | | | 1746 +---------+-----------+-----------+------------+------------+-------+ 1748 Table 22: Non Storing: Summary of the use of headers from RPL-aware- 1749 leaf to not-RPL-aware-leaf 1751 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to RPL-aware- 1752 leaf 1754 In this case the flow comprises: 1756 not-RPL-aware 6LN (IPv6) --> 6LR_ia --> root (6LBR) --> 6LR_id --> 1757 6LN 1759 For example, a communication flow could be: Node G --> Node E --> 1760 Node B --> Node A (root) --> Node B --> Node E --> Node H 1762 6LR_ia are the intermediate routers from source to the root. In this 1763 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1765 6LR_id are the intermediate routers from the root to the destination. 1766 In this case, "1 <= ia <= m", m is the number of the intermediate 1767 routers (6LR). 1769 This scenario is mostly identical to the previous one. The RPI is 1770 added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header 1771 addressed to the root. The 6LBR will remove this RPI, and add it's 1772 own IPv6-in-IPv6 header containing an RH3 header and optional RPI 1773 (RPI_2). 1775 +---------+-----+------------+------------+------------+------------+ 1776 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | 6LN | 1777 | | 6 | | | | | 1778 +---------+-----+------------+------------+------------+------------+ 1779 | Inserte | -- | IPv6-in- | IPv6-in- | -- | -- | 1780 | d | | IPv6 | IPv6 (RH3, | | | 1781 | headers | | (RPI_1) | opt RPI_2) | | | 1782 | Removed | -- | -- | IPv6-in- | -- | IPv6-in- | 1783 | headers | | | IPv6 | | IPv6 (RH3, | 1784 | | | | (RPI_1) | | opt RPI_2) | 1785 | Re- | -- | -- | -- | -- | -- | 1786 | added | | | | | | 1787 | headers | | | | | | 1788 | Modifie | -- | -- | -- | IPv6-in- | -- | 1789 | d | | | | IPv6 (RH3, | | 1790 | headers | | | | opt RPI_2) | | 1791 | Untouch | -- | -- | -- | -- | -- | 1792 | ed | | | | | | 1793 | headers | | | | | | 1794 +---------+-----+------------+------------+------------+------------+ 1796 Table 23: Non Storing: Summary of the use of headers from not-RPL- 1797 aware-leaf to RPL-aware-leaf 1799 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to not-RPL- 1800 aware-leaf 1802 In this case the flow comprises: 1804 not-RPL-aware 6LN (IPv6 src)--> 6LR_ia --> root (6LBR) --> 6LR_id --> 1805 not-RPL-aware (IPv6 dst) 1807 For example, a communication flow could be: Node G --> Node E --> 1808 Node B --> Node A (root) --> Node C --> Node J 1810 6LR_ia are the intermediate routers from source to the root. In this 1811 case, "1 <= ia <= n", n is the number of intermediate routers (6LR) 1813 6LR_id are the intermediate routers from the root to the destination. 1814 In this case, "1 <= ia <= m", m is the number of the intermediate 1815 routers (6LR). 1817 This scenario is the combination of the previous two cases. 1819 +----------+-----+-------------+--------------+--------------+------+ 1820 | Header | IPv | 6LR_1 | 6LBR | 6LR_id | IPv6 | 1821 | | 6 | | | | dst | 1822 | | src | | | | | 1823 +----------+-----+-------------+--------------+--------------+------+ 1824 | Inserted | -- | IPv6-in- | IPv6-in-IPv6 | -- | -- | 1825 | headers | | IPv6 | (RH3, opt | | | 1826 | | | (RPI_1) | RPI_2) | | | 1827 | Removed | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | 1828 | headers | | | (RPI_1) | (RH3, opt | | 1829 | | | | | RPI_2) | | 1830 | Re-added | -- | -- | -- | -- | -- | 1831 | headers | | | | | | 1832 | Modified | -- | -- | -- | -- | -- | 1833 | headers | | | | | | 1834 | Untouche | -- | -- | -- | -- | -- | 1835 | d | | | | | | 1836 | headers | | | | | | 1837 +----------+-----+-------------+--------------+--------------+------+ 1839 Table 24: Non Storing: Summary of the use of headers from not-RPL- 1840 aware-leaf to not-RPL-aware-leaf 1842 8. Operational Considerations of supporting not-RPL-aware-leaves 1844 Roughly half of the situations described in this document involve 1845 leaf ("host") nodes that do not speak RPL. These nodes fall into two 1846 further categories: ones that drop a packet that have RPI or RH3 1847 headers, and ones that continue to process a packet that has RPI and/ 1848 or RH3 headers. 1850 [RFC8200] provides for new rules that suggest that nodes that have 1851 not been configured (explicitly) to examine Hop-by-Hop headers, 1852 should ignore those headers, and continue processing the packet. 1853 Despite this, and despite the switch from 0x63 to 0x23, there may be 1854 hosts that are pre-RFC8200, or simply intolerant. Those hosts will 1855 drop packets that continue to have RPL artifacts in them. In 1856 general, such hosts can not be easily supported in RPL LLNs. 1858 There are some specific cases where it is possible to remove the RPL 1859 artifacts prior to forwarding the packet to the leaf host. The 1860 critical thing is that the artifacts have been inserted by the RPL 1861 root inside an IPv6-in-IPv6 header, and that the header has been 1862 addressed to the 6LR immediately prior to the leaf node. In that 1863 case, in the process of removing the IPv6-in-IPv6 header, the 1864 artifacts can also be removed. 1866 The above case occurs whenever traffic originates from the outside 1867 the LLN (the "Internet" cases above), and non-storing mode is used. 1868 In non-storing mode, the RPL root knows the exact topology (as it 1869 must be create the RH3 header), and therefore knows what the 6LR 1870 prior to the leaf --- the 6LR_n. 1872 Traffic originating from the RPL root (such as when the data 1873 collection system is co-located on the RPL root), does not require an 1874 IPv6-in-IPv6 header (in either mode), as the packet is originating at 1875 the root, and the root can insert the RPI and RH3 headers directly 1876 into the packet, as it is formed. Such a packet is slightly smaller, 1877 but only can be sent to nodes (whether RPL aware or not), that will 1878 tolerate the RPL artifacts. 1880 An operator that finds itself with a lot of traffic from the RPL root 1881 to RPL-not-aware-leaves, will have to do IPv6-in-IPv6 encapsulation 1882 if the leaf is not tolerant of the RPL artifacts. Such an operator 1883 could otherwise omit this unnecessary header if it was certain of the 1884 properties of the leaf. 1886 As storing mode can not know the final path of the traffic, 1887 intolerant (that drop packets with RPL artifacts) leaf nodes can not 1888 be supported. 1890 9. Operational considerations of introducing 0x23 1892 This section describes the operational considerations 1894 9.1. Has deployment been discussed? 1896 There are no known multivendor deployments outside of the research 1897 groups! All known deployments of RPL are in market verticals, with a 1898 single vendor providing all components. Research groups typically 1899 are using Contiki, RiotOS, or OpenWSN., and these are easily adapted 1900 to 0x23 functionality. Compatibility issue of RPL Option type not 1901 seems to be quite relevant for research groups. 1903 9.2. Has installation and initial setup been discussed?? 1905 During bootstrapping the node get the DIO with the information of RPL 1906 Option Type and Indicating the new RPI in the DODAG Configuration 1907 Option Flag. The DODAG root is in charge to configure the current 1908 network to the new value gradually, through DIO messages and when all 1909 the nodes are set with the new value. The DODAG should change to a 1910 new DODAG version. Not able to send data plane messages. Should 1911 drop the packet. In case of rebooting, the node does not remember 1912 the RPL Option Type. Thus, the DIO is sent with flag indicating the 1913 new RPI value. 1915 9.3. Has the migration path been discussed? 1917 TBD 1919 9.4. Have the Requirements on other protocols and functional components 1920 been discussed? 1922 It allows to send packets to non-RPL nodes, the 0x23?.. 1924 TBD 1926 9.5. Has the impact on network operation been discussed? 1928 Missconfiguration in case that a node join. 1930 TBD 1932 9.6. Have suggestions for verifying correct operation been discussed? 1934 TBD 1936 9.7. Has management interoperability been discussed? 1938 TBD 1940 9.8. Are there fault or threshold conditions that should be reported? 1942 TBD 1944 9.9. Is configuration discussed? 1946 TBD 1948 10. IANA Considerations 1950 This document updates the registration made in [RFC6553] Destination 1951 Options and Hop-by-Hop Options registry from 0x63 to 0x23. 1953 [RFCXXXX] represents this document. 1955 Hex Value Binary Value 1956 act chg rest Description Reference 1957 --------- --- --- ------- ----------------- ---------- 1958 0x23 00 1 00011 RPL Option [RFCXXXX] 1959 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 1961 Figure 9: Option Type in RPL Option. 1963 The DODAG Configuration Option Flags in the DODAG Configuration 1964 option is updated as follows: 1966 +------------+-----------------+---------------+ 1967 | Bit number | Description | Reference | 1968 +------------+-----------------+---------------+ 1969 | 3 | RPI 0x23 enable | This document | 1970 +------------+-----------------+---------------+ 1972 Figure 10: DODAG Configuration Option Flag to indicate the RPI-flag- 1973 day. 1975 11. Security Considerations 1977 The security considerations covered in [RFC6553] and [RFC6554] apply 1978 when the packets are in the RPL Domain. 1980 The IPv6-in-IPv6 mechanism described in this document is much more 1981 limited than the general mechanism described in [RFC2473]. The 1982 willingness of each node in the LLN to decapsulate packets and 1983 forward them could be exploited by nodes to disguise the origin of an 1984 attack. 1986 While a typical LLN may be a very poor origin for attack traffic (as 1987 the networks tend to be very slow, and the nodes often have very low 1988 duty cycles) given enough nodes, they could still have a significant 1989 impact, particularly if the attack was on another LLN! Additionally, 1990 some uses of RPL involve large backbone ISP scale equipment 1991 [I-D.ietf-anima-autonomic-control-plane], which may be equipped with 1992 multiple 100Gb/s interfaces. 1994 Blocking or careful filtering of IPv6-in-IPv6 traffic entering the 1995 LLN as described above will make sure that any attack that is mounted 1996 must originate from compromised nodes within the LLN. The use of 1997 BCP38 filtering at the RPL root on egress traffic will both alert the 1998 operator to the existence of the attack, as well as drop the attack 1999 traffic. As the RPL network is typically numbered from a single 2000 prefix, which is itself assigned by RPL, BCP38 filtering involves a 2001 single prefix comparison and should be trivial to automatically 2002 configure. 2004 There are some scenarios where IPv6-in-IPv6 traffic should be allowed 2005 to pass through the RPL root, such as the IPv6-in-IPv6 mediated 2006 communications between a new Pledge and the Join Registrar/ 2007 Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] 2008 and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for 2009 the RPL root to do careful filtering: it occurs only when the Join 2010 Coordinator is not co-located inside the RPL root. 2012 With the above precautions, an attack using IPv6-in-IPv6 tunnels will 2013 be by a node within the LLN on another node within the LLN. Such an 2014 attack could, of course, be done directly. An attack of this kind is 2015 meaningful only if the source addresses are either fake or if the 2016 point is to amplify return traffic. Such an attack, could also be 2017 done without the use of IPv6-in-IPv6 headers using forged source 2018 addresses. If the attack requires bi-directional communication, then 2019 IPv6-in-IPv6 provides no advantages. 2021 [RFC2473] suggests that tunnel entry and exit points can be secured, 2022 via the "Use IPsec". The suggested solution has all the problems 2023 that [RFC5406] goes into. In an LLN such a solution would degenerate 2024 into every node having a tunnel with every other node. It would 2025 provide a small amount of origin address authentication at a very 2026 high cost; doing BCP38 at every node (linking layer-3 addresses to 2027 layer-2 addresses, and to already present layer-2 cryptographic 2028 mechanisms) would be cheaper should RPL be run in an environment 2029 where hostile nodes are likely to be a part of the LLN. 2031 The RH3 header usage described here can be abused in equivalent ways 2032 with an IPv6-in-IPv6 header to add the needed RH3 header. As such, 2033 the attacker's RH3 header will not be seen by the network until it 2034 reaches the end host, which will decapsulate it. An end-host SHOULD 2035 be suspicious about a RH3 header which has additional hops which have 2036 not yet been processed, and SHOULD ignore such a second RH3 header. 2038 In addition, the LLN will likely use [RFC8138] to compress the IPv6- 2039 in-IPv6 and RH3 headers. As such, the compressor at the RPL-root 2040 will see the second RH3 header and MAY choose to discard the packet 2041 if the RH3 header has not been completely consumed. A consumed 2042 (inert) RH3 header could be present in a packet that flows from one 2043 LLN, crosses the Internet, and enters another LLN. As per the 2044 discussion in this document, such headers do not need to be removed. 2045 However, there is no case described in this document where an RH3 is 2046 inserted in a non-storing network on traffic that is leaving the LLN, 2047 but this document should not preclude such a future innovation. It 2048 should just be noted that an incoming RH3 must be fully consumed, or 2049 very carefully inspected. 2051 The RPI header, if permitted to enter the LLN, could be used by an 2052 attacker to change the priority of a packet by selecting a different 2053 RPLInstanceID, perhaps one with a higher energy cost, for instance. 2054 It could also be that not all nodes are reachable in an LLN using the 2055 default instanceID, but a change of instanceID would permit an 2056 attacker to bypass such filtering. Like the RH3, a RPI header is to 2057 be inserted by the RPL root on traffic entering the LLN by first 2058 inserting an IPv6-in-IPv6 header. The attacker's RPI header 2059 therefore will not be seen by the network. Upon reaching the 2060 destination node the RPI header has no further meaning and is just 2061 skipped; the presence of a second RPI header will have no meaning to 2062 the end node as the packet has already been identified as being at 2063 it's final destination. 2065 The RH3 and RPI headers could be abused by an attacker inside of the 2066 network to route packets on non-obvious ways, perhaps eluding 2067 observation. This usage is in fact part of [RFC6997] and can not be 2068 restricted at all. This is a feature, not a bug. 2070 [RFC7416] deals with many other threats to LLNs not directly related 2071 to the use of IPv6-in-IPv6 headers, and this document does not change 2072 that analysis. 2074 Nodes within the LLN can use the IPv6-in-IPv6 mechanism to mount an 2075 attack on another part of the LLN, while disguising the origin of the 2076 attack. The mechanism can even be abused to make it appear that the 2077 attack is coming from outside the LLN, and unless countered, this 2078 could be used to mount a Distributed Denial Of Service attack upon 2079 nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of 2080 such attacks already seen in the real world. 2082 Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic 2083 through the RPL root to perform this attack. To counter, the RPL 2084 root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the 2085 simpler solution), or it SHOULD do a deep packet inspection wherein 2086 it walks the IP header extension chain until it can inspect the 2087 upper-layer-payload as described in [RFC7045]. In particular, the 2088 RPL root SHOULD do BCP38 ([RFC2827]) processing on the source 2089 addresses of all IP headers that it examines in both directions. 2091 Note: there are some situations where a prefix will spread across 2092 multiple LLNs via mechanisms such as the one described in 2093 [I-D.ietf-6lo-backbone-router]. In this case the BCP38 filtering 2094 needs to take this into account, either by exchanging detailed 2095 routing information on each LLN, or by moving the BCP38 filtering 2096 further towards the Internet, so that the details of the multiple 2097 LLNs do not matter. 2099 12. Acknowledgments 2101 We are very thankful to the grant by the Finnish Foundation for 2102 Technology Promotion (Tekniikan Edistaemissaeaetioen - TES), and the 2103 grant by the FP7 Marie Curie Initial Training Network (ITN) METRICS 2104 project (grant agreement No. 607728) 2106 A special BIG thanks to C. M. Heard for the help with the 2107 Section 3. Much of the redaction in that section is based on his 2108 comments. 2110 Additionally, the authors would like to acknowledge the review, 2111 feedback, and comments of (alphabetical order): Robert Cragie, Simon 2112 Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias 2113 Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. 2115 13. References 2117 13.1. Normative References 2119 [I-D.thubert-roll-unaware-leaves] 2120 Thubert, P., "Routing for RPL Leaves", draft-thubert-roll- 2121 unaware-leaves-06 (work in progress), November 2018. 2123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2124 Requirement Levels", BCP 14, RFC 2119, 2125 DOI 10.17487/RFC2119, March 1997, 2126 . 2128 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2129 Defeating Denial of Service Attacks which employ IP Source 2130 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 2131 May 2000, . 2133 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2134 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2135 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2136 Low-Power and Lossy Networks", RFC 6550, 2137 DOI 10.17487/RFC6550, March 2012, 2138 . 2140 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2141 Power and Lossy Networks (RPL) Option for Carrying RPL 2142 Information in Data-Plane Datagrams", RFC 6553, 2143 DOI 10.17487/RFC6553, March 2012, 2144 . 2146 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2147 Routing Header for Source Routes with the Routing Protocol 2148 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2149 DOI 10.17487/RFC6554, March 2012, 2150 . 2152 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 2153 of IPv6 Extension Headers", RFC 7045, 2154 DOI 10.17487/RFC7045, December 2013, 2155 . 2157 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2158 "IPv6 over Low-Power Wireless Personal Area Network 2159 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2160 April 2017, . 2162 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2163 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2164 May 2017, . 2166 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2167 (IPv6) Specification", STD 86, RFC 8200, 2168 DOI 10.17487/RFC8200, July 2017, 2169 . 2171 13.2. Informative References 2173 [DDOS-KREBS] 2174 Goodin, D., "Record-breaking DDoS reportedly delivered by 2175 >145k hacked cameras", September 2016, 2176 . 2179 [I-D.ietf-6lo-backbone-router] 2180 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2181 Backbone Router", draft-ietf-6lo-backbone-router-10 (work 2182 in progress), January 2019. 2184 [I-D.ietf-6tisch-dtsecurity-secure-join] 2185 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2186 6tisch-dtsecurity-secure-join-01 (work in progress), 2187 February 2017. 2189 [I-D.ietf-anima-autonomic-control-plane] 2190 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 2191 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2192 plane-18 (work in progress), August 2018. 2194 [I-D.ietf-anima-bootstrapping-keyinfra] 2195 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2196 S., and K. Watsen, "Bootstrapping Remote Secure Key 2197 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2198 keyinfra-18 (work in progress), January 2019. 2200 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2201 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2202 December 1998, . 2204 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2205 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2206 DOI 10.17487/RFC4192, September 2005, 2207 . 2209 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2210 Control Message Protocol (ICMPv6) for the Internet 2211 Protocol Version 6 (IPv6) Specification", STD 89, 2212 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2213 . 2215 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 2216 Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, 2217 February 2009, . 2219 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2220 Bormann, "Neighbor Discovery Optimization for IPv6 over 2221 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2222 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2223 . 2225 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2226 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2227 in Low-Power and Lossy Networks", RFC 6997, 2228 DOI 10.17487/RFC6997, August 2013, 2229 . 2231 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2232 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2233 2014, . 2235 [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 2236 and M. Richardson, Ed., "A Security Threat Analysis for 2237 the Routing Protocol for Low-Power and Lossy Networks 2238 (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, 2239 . 2241 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2242 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2243 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2244 May 2017, . 2246 Authors' Addresses 2248 Maria Ines Robles 2249 Aalto University 2250 Innopoli 2251 Espoo 02150 2252 Finland 2254 Email: mariainesrobles@gmail.com 2256 Michael C. Richardson 2257 Sandelman Software Works 2258 470 Dawson Avenue 2259 Ottawa, ON K1Z 5V7 2260 CA 2262 Email: mcr+ietf@sandelman.ca 2263 URI: http://www.sandelman.ca/mcr/ 2264 Pascal Thubert 2265 Cisco Systems, Inc 2266 Village d'Entreprises Green Side 400, Avenue de Roumanille 2267 Batiment T3, Biot - Sophia Antipolis 06410 2268 France 2270 Email: pthubert@cisco.com