idnits 2.17.1 draft-ietf-roll-capabilities-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. The 'C' bit of this capability MUST be set to 0. -- The document date (May 21, 2020) is 1436 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: 'TODO' is mentioned on line 414, but not defined == Unused Reference: 'I-D.ietf-lwig-nbr-mgmt-policy' is defined on line 444, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-dao-projection' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-turnon-rfc8138' is defined on line 454, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-roll-mopex-00 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-10 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track P. Thubert 5 Expires: November 22, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo 9 Juniper 10 May 21, 2020 12 RPL Capabilities 13 draft-ietf-roll-capabilities-05 15 Abstract 17 This draft enables the discovery, advertisement and query of 18 capabilities for RPL nodes. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 22, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 57 2. Requirements for this document . . . . . . . . . . . . . . . 4 58 2.1. How are Capabilities different from existing RPL 59 primitives? . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Capability Control Message Option . . . . . . . . . . . . 5 62 3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 63 4. Guidelines for defining new capabilities . . . . . . . . . . 6 64 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6 65 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6 66 5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7 68 5.1.1. Format of Capability Indicators . . . . . . . . . . . 7 69 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7 70 5.2.1. Format of Routing Resource Capability . . . . . . . . 8 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 8 74 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 9 75 7.3. New Registry for Capabilities Indicators . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Capability Handshake Example . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 RPL [RFC6550] specifies a proactive distance-vector based routing 86 scheme. The protocol creates a DAG-like structure which operates 87 with a given "Mode of Operation" (MOP) determining the minimal and 88 mandatory set of primitives to be supported by all the participating 89 nodes. 91 This document adds a notion of capabilities using which nodes in the 92 network could inform its peers about its additional capabilities. 93 This document highlights the differences of capabilities from that of 94 Mode of operation and explains the necessity of it. 96 1.1. Requirements Language and Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 MOP: Mode of Operation. Identifies the MOP of the RPL Instance as 103 administratively provisioned at and distributed by the DODAG root. 105 MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. 107 Capabilities: Additional features or capabilities that are supported 108 by the node. 110 DAO: DODAG Advertisement Object. An RPL message used to advertise 111 the target information in order to establish routing adjacencies. 113 DIO: DODAG Information Object. An RPL message initiated by the root 114 and is used to advertise the network configuration information. 116 Current parent: Parent 6LR node before switching to the new path. 118 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 120 Upstream path/direction: Path or direction from the node to the Root 121 in a DAG. 123 Downstream path/direction: Path or direction to the node from the 124 Root in a DAG. 126 This document uses terminology described in [RFC6550]. For the sake 127 of readability all the known relevant terms are repeated in this 128 section. 130 1.2. What are Capabilities? 132 Currently RPL specification does not have a mechanism whereby a node 133 can signal the set of features that are available on its end. Such a 134 mechanism could help the root to advertise its capabilities and in 135 response also determine some advanced information about the 136 capabilities of the joining nodes. This document defines 137 Capabilities which could be supported by the nodes and handshaked as 138 part of RPL signaling. Capabilities are embedded as RPL control 139 message option as defined Section 6.7 of [RFC6550] in the base 140 messages of DIO, DAO and DAO-ACK signaling. 142 2. Requirements for this document 144 Following are the requirements considered for this documents: 146 REQ1: Backwards compatibility. The new options and new fields in 147 the DIO message should be backward compatible i.e. if there 148 are nodes which support old MOPs they could still operate in 149 their own instances. 151 REQ2: Optional capabilities handshake. Capabilities are features, 152 possibly optional, which could be handshaked between the nodes 153 and the root within an RPL Instance. 155 REQ3: Capabilities handshake could be optionally added with existing 156 MOPs. Capabilities been optional in nature could be put to 157 use with existing MOPs. Capabilities and MOP-extension is 158 mutually independent i.e. a DIO can have a capabilities 159 option, MOP-extension option or both in the same message. 161 REQ4: Capabilities could be explicitly queried. 163 2.1. How are Capabilities different from existing RPL primitives? 165 The Mode of Operation (MOP) field in RPL mandates the operational 166 requirement for the nodes joining as routers. MOP and DIO 167 Configuration Option is strictly controlled by the Root node in RPL. 168 Intermediate 6LRs cannot modify these fields. Also, the MOP never 169 changes for the lifetime of the RPL Instance. Changes in DIO 170 Configuration Option are possible but are rare. Capabilities, on the 171 other hand, might change more dynamically. 173 RPL DIO message also carries routing metrics and constraints as 174 specified in [RFC6551]. Metrics and constraints are used as part of 175 objective function which aids in node's rank calculation. A router 176 may use capabilities carried in DIO message as additional metrics/ 177 constraints. However, capabilities have a larger scope and may be 178 carried in other messages other than DIO and can flow in both the 179 directions (upstream and downstream). 181 3. Capabilities 183 Handling of Capabilities MUST be supported if the network uses MOPex 184 [I-D.ietf-roll-mopex]. 186 Note that capabilities and MOPex are mutually exclusive and it is 187 possible for an implementation to support either or both of the 188 options. 190 3.1. Capability Control Message Option 192 0 1 2 3 193 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type = TODO | Option Length | Capabilities TLVs 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: Capabilities Option 200 Multiple capabilities could be sent in the same message. The length 201 field allows the message parser to skip the capability TLV parsing. 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | CapType | Len |J|I|C| Flags | ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Capabilities TLV 211 Every capability is identified by its type and it may have an 212 optional Capability Info. Note that a given capability may or may 213 not be diseminated with additional information depending on the scope 214 of the capability indicated by the I bit. 216 Len: 8-bit unsigned integer, representing the length in octets of the 217 TLV, not including the CapType, Length and Flags fields. 219 J = Join only as leaf if capability not understood. 221 I = Ignore the message if this capability is not understood. 223 C = Flag indicating that the capability MUST be copied in the 224 downstream message. 226 3.2. Capabilities Handshake 228 The root node could advertise the set of capabilities it supports in 229 the DIO message. A node could take advantage of the knowledge that 230 the root supports a particular capability. Similarly a node could 231 advertise its capabilities in the DAO message using the capability 232 control message option defined in this document. Capabilities 233 advertised by non-root nodes are strictly a subset of the 234 capabilities advertised by the root. 236 In storing MOP, the DAO message from the 6LR could contain multiple 237 target options because of the DAO-Aggregation. The targets of the 238 capabilities option are indicated by one or more Target options that 239 precede the Capabilities Option. This handling is similar to the 240 Transit Information Option as supported in Section 6.7.8. of 241 [RFC6550]. 243 4. Guidelines for defining new capabilities 245 This section provides guidelines/recommendations towards defining new 246 capabilities. Note that the capabilities might be carried as part of 247 the multicast messaging such as DIO and hence the set should be used 248 in restrictive manner as far as possible. 250 4.1. Handling Capability flags 252 A node MUST drop or discard the message with an unknown capability 253 with 'D' flag set. The message MUST be discarded silently. 255 The 'J' (join) flag can be set in context to a capability either by a 256 6LR or the root. The 'J' flag indicates that if the capability is 257 not supported by a node then it can join the instance only as a 6LN 258 (or do not join as 6LR). 260 The 'C' (copy) flag is set by the node indicating that the 261 capabilities MUST be copied downstream by the node even if the node 262 does not understand the capability. 264 4.1.1. Rules to handle capabilities flag 265 On receiving a capability it does not support, the node MUST check 266 the 'J' flag of the capability before joining the Instance. If the 267 'J' flag is set then it can only join as a 6LN. 268 If the node is operating as 6LR and subsequently it receives a 269 capability from its preferred parent which it does not understand 270 with 'J' flag set, then the node has to switch itself to 6LN mode. 271 During switching the node needs to inform its downstream peers of its 272 changed status by sending a DIO with infinite rank as mentioned in 273 RFC6550. Alternatively, a node may decide to switch to another 274 parent with compatible and known capabilities. 275 Capabilities are used to indicate a feature that is supported by the 276 node. Capabilities are not meant for configuration management for 277 e.g., setting a threshold. 279 5. Node Capabilities 280 5.1. Capability Indicators 282 Capability Indicators indicates the capabilities supported by the 283 node in the form of simple flags. Capabilities who do not have 284 additional information to be specified could make use of these flags 285 to indicate their support. 287 5.1.1. Format of Capability Indicators 289 0 1 2 3 290 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 3: Capability Indicators TLV 297 Flags: LRs MUST set it to 0. I bit will always be set to 0. 299 T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. 301 5.2. Routing Resource Capability 303 Storing mode of operation requires each intermediate router in the 304 LLN to maintain routing states' information in the routing table. 305 LLN routers typically operate with constraints on processing power, 306 memory, and energy (battery power). Memory limits the number of 307 routing states an LR and BR can maintain. When the routing table of 308 an LR or BR is full, it will either reject the new DAO messages 309 received or will use some replacement policy to remove a routing 310 entry and add the new one. Rejection of DAO messages will lead to an 311 increase in DAO message transmission that impacts the energy and 312 network convergence time. Routing state replacement leads to 313 downward path downtime. 315 One possible way to solve problems due to routing table size 316 constraint is to use this information to add neighbors to the DAO 317 parent set. Routing resource capability can be used by LR and BR to 318 advertise their current routing table usage details in the network. 319 LR or LNs in LLN can use this information in the selection of the DAO 320 parent set. PCE can use this information to select intermediate 321 routers for the projected routes. Routing Resource is an optional 322 capability. 324 Routing resource capabablity sent in DIO message has link local scope 325 and it MUST not be forwarded. The 'C' bit of this capability MUST be 326 set to 0. 328 5.2.1. Format of Routing Resource Capability 330 0 1 2 3 331 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Total Capacity | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 4: Routing Resource Capability TLV 340 Type: 0x02. 342 Flags: I bit MUST be set to 0. C bit MUST be set to 0. 344 Len: 8-bit unsigned integer, representing the length in octets of the 345 option, not including the Option Type and Length/flags fields. 347 Resvd: 8-bit unused field. It MUST be initialized to zero by the 348 sender and MUST be ignored by the receiver. 350 Total Capacity: 16 bit unsigned integer representing the routing 351 table size. 353 6. Acknowledgements 355 Thanks to Georgios Papadopoulos, Li Zhao for early review and 356 feedback. 358 7. IANA Considerations 360 7.1. New option: Capabilities 362 New entry is required for supporting new Capabilities option in the 363 "RPL Control Message Options" space [RFC6550]. 365 +-------+-----------------------------+---------------+ 366 | Value | Meaning | Reference | 367 +-------+-----------------------------+---------------+ 368 | 0x01 | Capability Indicators | This document | 369 | 0x02 | Routing Resource Capability | This document | 370 +-------+-----------------------------+---------------+ 372 New options 374 7.2. New Registry for Capabilities Flags 376 IANA is requested to create a registry for the Capabilities flags as 377 described in Section 2.1 of this document. This registry should be 378 located in TODO. New Capabilities flags may be allocated only by an 379 IETF review. Currently no flags are defined by this document. Each 380 value is tracked with the following qualities: 382 o Flag 384 o Description 386 o Defining RFC 388 7.3. New Registry for Capabilities Indicators 390 IANA is requested to create a registry for the Capabilities 391 Indicators as described in Section 5.1 of this document. This 392 registry should be located in TODO. New Capabilities indicators may 393 be allocated only by an IETF review. Each value is tracked with the 394 following qualities: 396 o Flag 398 o Description 400 o Defining RFC 402 8. Security Considerations 404 The options defined in this document are carried in the base message 405 objects as defined in [RFC6550]. The RPL control message options are 406 protected by the same security mechanisms that protect the base 407 messages. 409 Capabilities flag can reveal that the node has been upgraded or is 410 running a old feature set. This document assumes that the base 411 messages that carry these options are protected by RPL security 412 mechanisms and thus are not visible to a malicious node. 414 [TODO] implications of malicious attack involving setting the 415 capability flags. 417 9. References 418 9.1. Normative References 420 [I-D.ietf-roll-mopex] 421 Jadhav, R., Thubert, P., and M. Richardson, "Mode of 422 Operation extension", draft-ietf-roll-mopex-00 (work in 423 progress), April 2020. 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 431 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 432 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 433 Low-Power and Lossy Networks", RFC 6550, 434 DOI 10.17487/RFC6550, March 2012, 435 . 437 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 438 "IPv6 over Low-Power Wireless Personal Area Network 439 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 440 April 2017, . 442 9.2. Informative References 444 [I-D.ietf-lwig-nbr-mgmt-policy] 445 Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, 446 "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- 447 nbr-mgmt-policy-03 (work in progress), February 2019. 449 [I-D.ietf-roll-dao-projection] 450 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 451 routing state in RPL", draft-ietf-roll-dao-projection-10 452 (work in progress), May 2020. 454 [I-D.thubert-roll-turnon-rfc8138] 455 Thubert, P. and L. Zhao, "Configuration option for RFC 456 8138", draft-thubert-roll-turnon-rfc8138-03 (work in 457 progress), July 2019. 459 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 460 and D. Barthel, "Routing Metrics Used for Path Calculation 461 in Low-Power and Lossy Networks", RFC 6551, 462 DOI 10.17487/RFC6551, March 2012, 463 . 465 Appendix A. Capability Handshake Example 467 Root 6LR 6LN 468 | | | 469 | DIO(CS1) | | 470 |------------>| DIO(CS1) | 471 | |----------->| 472 | | | 473 | | DAO(CS2) | 474 | |<-----------| 475 | DAO(CS2) | | 476 |<------------| | 477 | | | 478 CS: Capabilities Set 479 CS1: Capabilities set advertised by root 480 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 482 Figure 5: Capabilities Option 484 Authors' Addresses 486 Rahul Arvind Jadhav (editor) 487 Huawei 488 Kundalahalli Village, Whitefield, 489 Bangalore, Karnataka 560037 490 India 492 Phone: +91-080-49160700 493 Email: rahul.ietf@gmail.com 495 Pascal Thubert 496 Cisco Systems, Inc 497 Building D 498 45 Allee des Ormes - BP1200 499 MOUGINS - Sophia Antipolis 06254 500 France 502 Phone: +33 497 23 26 34 503 Email: pthubert@cisco.com 505 Michael Richardson 506 Sandelman Software Works 508 Email: mcr+ietf@sandelman.ca 509 Rabi Narayan Sahoo 510 Juniper 512 Email: rabinarayans0828@gmail.com