idnits 2.17.1 draft-ietf-roll-turnon-rfc8138-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to directly say this. It does mention RFC6550 though, so this could be OK. -- The draft header indicates that this document updates RFC8138, but the abstract doesn't seem to directly say this. It does mention RFC8138 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (15 April 2020) is 1471 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) ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-38 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-14 == Outdated reference: A later version (-09) exists of draft-ietf-roll-capabilities-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft L. Zhao 4 Updates: 6550, 8138 (if approved) Cisco Systems 5 Intended status: Standards Track 15 April 2020 6 Expires: 17 October 2020 8 A RPL Configuration Option for the 6LoWPAN Routing Header 9 draft-ietf-roll-turnon-rfc8138-06 11 Abstract 13 This document complements RFC 8138 and dedicates a bit in the RPL 14 configuration option defined in RFC 6550 to indicate whether RFC 8138 15 compression is used within the RPL Instance. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 17 October 2020. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.3. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Inconsistent State While Migrating . . . . . . . . . . . 6 59 5.2. Single RPL Instance Scenario . . . . . . . . . . . . . . 6 60 5.3. Double RPL Instances Scenario . . . . . . . . . . . . . . 7 61 5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 66 10. Informative References . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 The transition of a RPL [RFC6550] network to activate the compression 72 defined in [RFC8138] can only be done when all routers in the network 73 support it. Otherwise, a non-capable node acting as a router would 74 drop the compressed packets and black-hole its subDAG. In a mixed 75 case with both RFC8138-capable and non-capable nodes, the compression 76 may be turned on only if all the non-capable nodes act as Hosts and 77 their RPL parents handle the compression/decompression for them. 79 This document complements [RFC8138] and dedicates a flag in the RPL 80 configuration option to indicate whether [RFC8138] compression should 81 be used within the RPL Instance. The setting of this new flag is 82 controlled by the Root and propagates as is in the whole network. 83 When the bit is not set, source nodes that support [RFC8138] should 84 refrain from using the compression unless the information is 85 superseded by configuration. 87 With RPL, a leaf is an IPv6 Host, which implies that leaves do not 88 forward packets. This specification provides scenarios that force a 89 non-capable RPL-Aware Node (RAN) to become a leaf. The parent router 90 must know, e.g., by configuration, or leveraging "RPL Capabilities" 91 [CAPABILITIES], when a leaf does not support the compression defined 92 in [RFC8138]. This is implicitly the case for a RPL-Unaware Leaf 93 (RUL) but is not known for a RPL-Aware Leaf (RAL). The parent router 94 must uncompress the packets before delivering them to a non-capable 95 leaf and it must compress the traffic from the leaf. 97 2. Terminology 99 2.1. References 101 The Terminology used in this document is consistent with and 102 incorporates that described in "Terms Used in Routing for Low-Power 103 and Lossy Networks (LLNs)" [RFC7102]. Other terms in use in LLNs are 104 found in "Terminology for Constrained-Node Networks" [RFC7228]. 106 "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by 107 a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for 108 Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract 109 information that RPL defines to be placed in data packets, e.g., as 110 the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By 111 extension the term "RPI" is often used to refer to the RPL Option 112 itself. The DODAG Information Solicitation (DIS), Destination 113 Advertisement Object (DAO) and DODAG Information Object (DIO) 114 messages are also specified in [RFC6550]. 116 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 117 Leaf (RAL) consistently with "Using RPI Option Type, Routing Header 118 for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data 119 Plane" [USEofRPLinfo]. The term RPL-Aware Node (RAN) refers to a 120 node that is either a RAL or a RPL Router. A RAN manages the 121 reachability of its addresses and prefixes by injecting them in RPL 122 by itself. In contrast, a RUL leverages "Registration Extensions for 123 IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor 124 Discovery" [RFC8505] to obtain reachability services from its parent 125 router(s) as specified in "Routing for RPL Leaves" [UNAWARE-LEAVES]. 127 2.2. Glossary 129 This document often uses the following acronyms: 131 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 132 6LoRH: 6LoWPAN Routing Header 133 DIO: DODAG Information Object (a RPL message) 134 DODAG: Destination-Oriented Directed Acyclic Graph 135 LLN: Low-Power and Lossy Network 136 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 137 OF: RPL Objective Function 138 OCP: RPL Objective Code Point 139 MOP: RPL Mode of Operation 140 RPI: RPL Packet Information 141 RAL: RPL-Aware Leaf 142 RAN: RPL-Aware Node 143 RUL: RPL-Unaware Leaf 144 SRH: Source Routing Header 146 2.3. BCP 14 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119][RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 3. Updating RFC 6550 156 This specification defines a new flag "Enable RFC8138 Compression" 157 (T). The "T" flag is set to turn on the use of the compression of 158 RPL artifacts with [RFC8138] within a RPL Instance. If a RPL 159 Instance has multiple Roots then they must be coordinated to use the 160 same setting. 162 RPL defines a Configuration Option that is registered to IANA in 163 section 20.14. of [RFC6550]. The "T" flag is encoded in one of the 164 reserved control bits in the RPL Configuration Option. The bit 165 position of the "T" flag is indicated in Section 6. 167 Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) 168 in the DIO Base Object. The new "T" flag is defined only for MOP 169 value between 0 to 6. For a MOP value of 7 or above, the flag MAY 170 indicate something different and MUST NOT be interpreted as "Enable 171 RFC8138 Compression" unless the specification of the MOP indicates to 172 do so. 174 4. Updating RFC 8138 176 A node that supports this specification MUST source packets in the 177 compressed form using [RFC8138] if and only if the "T" flag is set. 178 This behaviour can be overridden by the configuration of the node in 179 order to cope with intermediate implementations of the Root that 180 support [RFC8138] but not this specification and cannot set the "T" 181 flag. 183 The decision of using [RFC8138] is made by the originator of the 184 packet depending on its capabilities and its knowledge of the state 185 of the "T" flag. A router that encapsulates a packet is the 186 originator of the resulting packet and decides whether to compress 187 the outer headers as indicated above. An external target 188 [USEofRPLinfo] is not expected to support [RFC8138]. An intermediate 189 router MUST forward the packet in the form that the source used, 190 either compressed or uncompressed, unless it is forwarding to an 191 external target or delivering to a leaf that is not known to support 192 [RFC8138], in which cases it MUST uncompress the packet. 194 5. Transition Scenarios 196 A node that supports [RFC8138] but not this specification can only be 197 used in an homogeneous network. Enabling the [RFC8138] compression 198 requires a "flag day"; all nodes must be upgraded, and then the 199 network can be rebooted with the [RFC8138] compression turned on. 201 A node that supports this specification can work in a network with 202 [RFC8138] compression turned on or off with the "T" flag set 203 accordingly and in a network in transition from off to on or on to 204 off (see Section 5.1). 206 A node that does not support [RFC8138] can interoperate with nodes 207 that do in a network with [RFC8138] compression turned off. If the 208 compression is turned on, the node cannot forward compressed packets 209 and therefore it cannot act as a router. It may remain connected to 210 that network as a leaf, generates uncompressed packets, and can 211 receive packets if they are delivered by the parent router in the 212 uncompressed form. Unless this is known by other means, the node 213 SHOULD join as a RUL as an indication that its parent router needs to 214 uncompress the packets before delivering. 216 [RFC6550] states that "Nodes other than the DODAG Root MUST NOT 217 modify this information when propagating the DODAG Configuration 218 option". Therefore, even a legacy parent propagates the "T" flag as 219 set by the Root whether it supports this specification or not. So 220 when the "T" flag is set, it is transparently flooded to all the 221 nodes in the RPL Instance. 223 Sections 8.5 and 9.2 of [RFC6550] also suggests that a RAN may only 224 attach to a DODAG as a leaf when it does not support the Mode of 225 Operation of a RPL Instance, the Objective Function (OF) as indicated 226 by the Objective Code Point (OCP) or some other parameters in the 227 configuration option. 229 This specification reiterates that a RAN that is configured to 230 operate in a RPL Instance but does not support a value for a known 231 parameter that is mandatory for routing, such as the OCP, MUST NOT 232 operate as a router but MAY still join as a leaf. Note that a legacy 233 RAN will not recognize when a reserved field is used and will not 234 turn to a leaf when the "T" flag is set. 236 The intent for this specification is to perform a migration once and 237 for all without the need for a flag day. In particular it is not the 238 intention to undo the setting of the "T" flag, and though it is 239 possible to roll back (see Section 5.4), adding nodes that do not 240 support [RFC8138] after a roll back may be problematic if the roll 241 back is not fully complete (see caveats in Section 5.2). 243 5.1. Inconsistent State While Migrating 245 When the "T" flag is turned on in the configuration option by the 246 Root, the information slowly percolates through the DODAG as the DIO 247 gets propagated. 249 Some nodes will see the flag and start sourcing packets in the 250 compressed form while other nodes in the same RPL Instance are still 251 not aware of it. Conversely, in non-storing mode, the Root will 252 start using [RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH) 253 that routes all the way to the parent router or to the leaf. 255 To ensure that a packet is forwarded across the RPL Instance in the 256 form in which it was generated, it is required that all the routers 257 support [RFC8138] at the time of the switch, and that all nodes that 258 do not support [RFC8138] only operate as leaves. 260 Setting the "T" flag is ultimately the responsibility of the network 261 administrator. In a case of upgrading a network to turn the 262 compression on, the network SHOULD be operated with the "T" flag 263 reset until all targeted nodes are upgraded to support this 264 specification. Section 5.2 and Section 5.3 provide possible 265 transition scenarios where this can be enforced. 267 5.2. Single RPL Instance Scenario 269 In a Single RPL Instance Scenario, nodes that support [RFC8138] are 270 configured with a new OCP, that may use the same OF operation or a 271 variation of it, while nodes that do not support [RFC8138] are not, 272 but are configured to join an unknown OCP. 274 The Root migrates to the new OCP before it sets the "T" flag, so that 275 nodes that do not support [RFC8138] are all attached as leaves when 276 the "T" flag is eventually set. 278 The parent router - which supports [RFC8138] - compresses the packets 279 originated from the leaf and uncompresses the packets going to the 280 leaf. This may be done on the fly by the parent of a non-capable 281 RAL, or as part of the tunneling operation between the parent and the 282 Root, if the leaf behaves as a RUL. This is described in section 7, 283 8, and 9 of [USEofRPLinfo]. 285 Note that though tunneling from the Root to the parent is the generic 286 case for RULs, on paper it is possible for the Root to avoid it for 287 the traffic that it originates. The Root SHOULD always use tunneling 288 to the parent of a RUL, even for its own packets, unless it knows 289 that the leaf supports [RFC8138]. 291 This scenario presents a number of caveats: 293 * The method consumes an extra OCP. It also forces nodes that do 294 not support [RFC8138] to operate as RULs, unless there is a method 295 to let the parent router know that it must uncompress the packet 296 for this RAL. 298 * If the RPL implementation of a node does not turn it to a leaf 299 when the OCP is changed to an unknown one, then the node may be 300 stalled. 302 * If the only possible parents of a node are nodes that do not 303 support [RFC8138], then that node will loose all its parent at the 304 time of the migration and it will be stalled until a parent is 305 deployed with the new capability. 307 5.3. Double RPL Instances Scenario 309 An alternative to the Single RPL Instance Scenario is to deploy an 310 additional RPL Instance for the nodes that support [RFC8138]. 312 The two RPL Instances operate independently as specified in 313 [RFC6550]. The preexisting RPL Instance does not use [RFC8138], 314 whereas the new RPL Instance does. This is signaled by the "T" flag 315 which is only set in the configuration option in DIO messages in the 316 new RPL Instance. 318 Nodes that support [RFC8138] participate in both Instances but favor 319 the new RPL Instance for the traffic that they source. By contrast, 320 nodes that only support the uncompressed format would either not be 321 configured for the new RPL Instance, or would be configured to join 322 it as leaves only. 324 This method eliminates the risks of nodes being stalled that are 325 described in Section 5.2 but requires implementations to support at 326 least two RPL Instances and demands management capabilities to 327 introduce new RPL Instances and deprecate old ones. 329 5.4. Rolling Back 331 After downgrading a network to turn the [RFC8138] compression off, 332 the administrator SHOULD make sure that all nodes have converged to 333 the "T" flag reset before allowing nodes that do not support the 334 compression in the network (see caveats in Section 5.2). 336 It is RECOMMENDED to only deploy nodes that support [RFC8138] in a 337 network where the compression is turned on. A node that does not 338 support [RFC8138] MUST only be used as a leaf. 340 6. IANA Considerations 342 This specification updates the Registry for the "DODAG Configuration 343 Option Flags" that was created for [RFC6550] as follows: 345 +------------+---------------------------------+-----------+ 346 | Bit Number | Capability Description | Reference | 347 +============+=================================+===========+ 348 | 2 | Turn on RFC8138 Compression (T) | THIS RFC | 349 +------------+---------------------------------+-----------+ 351 Table 1: New DODAG Configuration Option Flag 353 7. Security Considerations 355 First of all, it is worth noting that with [RFC6550], every node in 356 the LLN that is RPL-aware can inject any RPL-based attack in the 357 network. A trust model MUST be put in place so that rogue nodes are 358 excluded from participating to the RPL and the 6LowpAN signaling, and 359 from the data packet exchange. This trust model could be at a 360 minimum based on a Layer-2 Secure joining and the Link-Layer 361 security. This is a generic RPL and 6LoWPAN requirement, see Req5.1 362 in Appendix of [RFC8505]. 364 Setting the "T" flag before some routers are upgraded may cause a 365 loss of packets. The new bit is protected as the rest of the 366 configuration so this is just one of the many attacks that can happen 367 if an attacker manages to inject a corrupted configuration. 369 Setting and resetting the "T" flag may create inconsistencies in the 370 network but as long as all nodes are upgraded to [RFC8138] support 371 they will be able to forward both forms. The source is responsible 372 for selecting whether the packet is compressed or not, and all 373 routers must use the format that the source selected. So the result 374 of an inconsistency is merely that both forms will be present in the 375 network, at an additional cost of bandwidth for packets in the 376 uncompressed form. 378 8. Acknowledgments 380 The authors wish to thank Dominique Barthel and Rahul Jadhav for 381 their in-depth reviews and constructive suggestions. 383 9. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 391 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 392 May 2017, . 394 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 395 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 396 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 397 Low-Power and Lossy Networks", RFC 6550, 398 DOI 10.17487/RFC6550, March 2012, 399 . 401 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 402 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 403 2014, . 405 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 406 Constrained-Node Networks", RFC 7228, 407 DOI 10.17487/RFC7228, May 2014, 408 . 410 [USEofRPLinfo] 411 Robles, I., Richardson, M., and P. Thubert, "Using RPI 412 Option Type, Routing Header for Source Routes and IPv6-in- 413 IPv6 encapsulation in the RPL Data Plane", Work in 414 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-38, 415 23 March 2020, . 418 [UNAWARE-LEAVES] 419 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 420 Work in Progress, Internet-Draft, draft-ietf-roll-unaware- 421 leaves-14, 11 April 2020, . 424 10. Informative References 426 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 427 Power and Lossy Networks (RPL) Option for Carrying RPL 428 Information in Data-Plane Datagrams", RFC 6553, 429 DOI 10.17487/RFC6553, March 2012, 430 . 432 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 433 "IPv6 over Low-Power Wireless Personal Area Network 434 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 435 April 2017, . 437 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 438 Perkins, "Registration Extensions for IPv6 over Low-Power 439 Wireless Personal Area Network (6LoWPAN) Neighbor 440 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 441 . 443 [CAPABILITIES] 444 Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo, 445 "RPL Capabilities", Work in Progress, Internet-Draft, 446 draft-ietf-roll-capabilities-02, 11 March 2020, 447 . 450 Authors' Addresses 452 Pascal Thubert (editor) 453 Cisco Systems, Inc 454 Building D 455 45 Allee des Ormes - BP1200 456 06254 MOUGINS - Sophia Antipolis 457 France 459 Phone: +33 497 23 26 34 460 Email: pthubert@cisco.com 462 Li Zhao 463 Cisco Systems, Inc 464 Xinsi Building 465 No. 926 Yi Shan Rd 466 SHANGHAI 467 200233 468 China 470 Email: liz3@cisco.com