idnits 2.17.1 draft-ietf-roll-capabilities-08.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 -- The document date (March 17, 2021) is 1133 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 589, but not defined == Outdated reference: A later version (-07) exists of draft-ietf-roll-mopex-02 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-16 Summary: 0 errors (**), 0 flaws (~~), 4 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 4 Intended status: Standards Track P. Thubert 5 Expires: September 18, 2021 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo 9 Juniper 10 March 17, 2021 12 RPL Capabilities 13 draft-ietf-roll-capabilities-08 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 September 18, 2021. 37 Copyright Notice 39 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 4 57 2. Requirements for this document . . . . . . . . . . . . . . . 4 58 2.1. How are Capabilities different from existing RPL 59 primitives? . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Capability Control Message Option . . . . . . . . . . . . 5 62 3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 63 4. Querying Capabilities . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Capability Query (CAPQ) . . . . . . . . . . . . . . . . . 6 65 4.1.1. Capability Type List Control Option . . . . . . . . . 7 66 4.1.2. Secure CAPQ . . . . . . . . . . . . . . . . . . . . . 7 67 4.1.3. Base rules for CAPQ handling . . . . . . . . . . . . 7 68 4.2. Capability Set Response (CAPS) . . . . . . . . . . . . . 7 69 4.2.1. Secure CAPS . . . . . . . . . . . . . . . . . . . . . 8 70 5. Guidelines for defining new capabilities . . . . . . . . . . 8 71 5.1. Handling Capability flags . . . . . . . . . . . . . . . . 8 72 5.1.1. Rules to handle capabilities flag . . . . . . . . . . 9 73 6. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. Capability Indicators . . . . . . . . . . . . . . . . . . 9 75 6.1.1. Format of Capability Indicators . . . . . . . . . . . 9 76 6.2. Routing Resource Capability . . . . . . . . . . . . . . . 10 77 6.2.1. Format of Routing Resource Capability . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. New option: Capabilities . . . . . . . . . . . . . . . . 11 81 8.2. Capability Sub-Type . . . . . . . . . . . . . . . . . . . 11 82 8.3. New Registry for CAPQ Flags . . . . . . . . . . . . . . . 12 83 8.4. New Registry for Capabilities Flags . . . . . . . . . . . 12 84 8.5. New Registry for Capabilities Indicators . . . . . . . . 12 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 88 10.2. Informative References . . . . . . . . . . . . . . . . . 13 89 Appendix A. Capability Handshake Example . . . . . . . . . . . . 14 90 A.1. Query supported Cap Types . . . . . . . . . . . . . . . . 14 91 A.2. Query specific Cap Set . . . . . . . . . . . . . . . . . 14 92 A.3. CAPS with partial Cap Set . . . . . . . . . . . . . . . . 15 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 RPL [RFC6550] specifies a proactive distance-vector based routing 98 scheme. The protocol creates a DAG-like structure which operates 99 with a given "Mode of Operation" (MOP) determining the minimal and 100 mandatory set of primitives to be supported by all the participating 101 nodes. 103 This document adds a notion of capabilities, through which a node in 104 the network could inform its peers about its additional capabilities. 105 Using capabilities, a node could determine whether the target node 106 supports the required feature before utilizing the feature. This 107 document highlights the differences between capabilities and Mode of 108 Operation and explains the necessity for the former. 110 1.1. Requirements Language and Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 MOP: Mode of Operation. Identifies the MOP of the RPL Instance as 117 administratively provisioned at and distributed by the DODAG root. 119 MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. 121 Capabilities: Additional features or capabilities that are supported 122 by the node. 124 Cap: Abbreviated term used for Capability. 126 Caps: Abbreviated term used for Capabilities. 128 DAO: DODAG Advertisement Object. A RPL (pronounced ripple) message 129 used to advertise the target information in order to establish 130 routing adjacencies. 132 DIO: DODAG Information Object. A RPL message initiated by the root 133 and is used to advertise the network configuration information. 135 Current parent: Parent 6LR node before switching to the new path. 137 NPDAO: No-Path DAO. A DAO message that contains a Transit 138 Information Option with lifetime equal to 0. 140 Upstream path/direction: Path or direction from the node to the Root 141 in a DAG. 143 Downstream path/direction: Path or direction to the node from the 144 Root in a DAG. 146 This document uses terminology described in [RFC6550]. For the sake 147 of readability all the known relevant terms are repeated in this 148 section. 150 1.2. What are Capabilities? 152 Currently, RPL specification does not have a mechanism whereby a node 153 can signal the set of features that are available on its end. Such a 154 mechanism could help the root to advertise its capabilities and in 155 response also determine some advanced information about the 156 capabilities of the joining nodes. This document defines 157 Capabilities and corresponding messaging handshakes that could be 158 supported by the nodes. Capabilities are embedded as an RPL Control 159 Message Option as defined in Section 6.7 of [RFC6550]. 161 2. Requirements for this document 163 Following are the requirements considered for this documents: 165 REQ1: Optional capabilities handshake. Capabilities are features, 166 possibly optional, which could be indicated between the nodes 167 and the root within an RPL Instance. 169 REQ2: Capabilities handshake could be optionally added with existing 170 MOPs. Capabilities, being optional, could be put to use with 171 existing MOPs. Capabilities and MOP-extension are mutually 172 independent i.e. a DIO can have a capabilities option, MOP- 173 extension option, or both in the same message. 175 REQ3: Capabilities could be explicitly queried. 177 2.1. How are Capabilities different from existing RPL primitives? 179 The Mode of Operation (MOP) field in RPL mandates the operational 180 requirement for the nodes joining as routers. MOP and DIO 181 Configuration Option is strictly controlled by the Root node in RPL. 182 Intermediate 6LRs cannot modify these fields. Also, the MOP never 183 changes for the lifetime of the RPL Instance. Changes in DIO 184 Configuration Option are possible but are rare. Capabilities, on the 185 other hand, might change more dynamically. 187 RPL DIO message also carries routing metrics and constraints as 188 specified in [RFC6551]. Metrics and constraints are used in addition 189 to an objective function to determine a node's rank calculation. A 190 router may use capabilities carried in DIO messages as additional 191 metrics/constraints. However, capabilities have a larger scope and 192 might be carried in messages other than DIO and can flow in either 193 direction (upstream and downstream). 195 3. Capabilities 197 Handling of Capabilities MUST be supported if the network uses MOPex 198 [I-D.ietf-roll-mopex]. 200 Note that capabilities and MOPex are mutually exclusive and it is 201 possible for an implementation to support either or both of the 202 options. 204 3.1. Capability Control Message Option 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Type = TODO | Option Length | Capabilities TLVs 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: Capabilities Option 214 Multiple capabilities can be sent in the same message. The length 215 field allows the message parser to skip the capability TLV parsing. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | CapType | Len |J|I|C| Flags | ... 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: Capabilities TLV 225 Every capability is identified by its type and it may have an 226 optional Capability Info. Note that a given capability may or may 227 not be disseminated with additional information depending on the 228 scope of the capability indicated by the I bit. 230 Len: 8-bit unsigned integer, representing the length in octets of the 231 TLV, not including the CapType, Length and Flags fields. 233 J = Join only as leaf if capability not understood. 235 I = Ignore the message if this capability is not understood. 237 C = Flag indicating that the capability MUST be copied in the 238 downstream message. 240 3.2. Capabilities Handshake 242 The root node can advertise the set of capabilities it supports in 243 the DIO message. A node can take advantage of the knowledge that the 244 root supports a particular capability. Similarly, a node can 245 advertise its capabilities in the DAO message using the capability 246 control message option defined in this document. Capabilities 247 advertised by non-root nodes is strictly a subset of the capabilities 248 advertised by the root. 250 In storing MOP, the DAO message from the 6LR can contain multiple 251 target options because of the DAO-Aggregation. The targets of the 252 capabilities option are indicated by one or more Target options that 253 precede the Capabilities Option. This handling is similar to the 254 Transit Information Option as supported in Section 6.7.8. of 255 [RFC6550]. 257 4. Querying Capabilities 259 Nodes may be interested in knowing the capabilities of another node 260 before taking an action. For example, consider 261 [I-D.ietf-roll-dao-projection], in which the Root may want to know 262 the capabilities of the nodes along a network segment before it 263 initiates a projected DAO to install the routes along that segment. 265 Caps can be carried in existing RPL Control messages as Control 266 Options, however, Caps can also be queried explicitly. This section 267 provides a way for a node to query the capability set of another 268 node. The capability query and subsequent response messages are 269 directly addressed between the two peers. 271 4.1. Capability Query (CAPQ) 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | RPLInstanceID | Flags | reserved | CAPQSequence | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Option(s)... 279 +-+-+-+-+-+-+-+-+ 281 Figure 3: CAPQ base object 283 CAPQSequence: One byte, Sequence number sent by the CAPQ sender and 284 reflected back by the responder in the CAPS message. 286 Flags: One byte, set to zero by sender, ignored by receiver. 288 reserved: One byte, set to zero by sender, ignored by receiver. 290 The CAPQ base object may be followed by one or more options. The 291 Capability Type List Control Option (see Figure 4) is used to carry a 292 set of capability types to query about. 294 If the sender does not send a Capability Type List Control Option, 295 this indicates that the node intends to query the Capability Type 296 List supported by the target node. 298 4.1.1. Capability Type List Control Option 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = TODO | Option Length | CapType1 | CapType2 | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | CapType3 | ..... 306 +-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 4: Capability Type List Control Option 310 4.1.2. Secure CAPQ 312 A Secure CAPQ message follows the format in [RFC6550] Figure 7, where 313 the base message format is the CAPQ message shown in Figure 3. 315 4.1.3. Base rules for CAPQ handling 317 A CAPQ message may get dropped or lost in the transit. The sender of 318 CAPQ MAY retry the CAPQ message after some delay. The delay SHOULD 319 NOT be less than 1 second. 321 4.2. Capability Set Response (CAPS) 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | RPLInstanceID | Flags | Reserved | CAPQSequence | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Option(s)... 329 +-+-+-+-+-+-+-+-+ 331 Figure 5: CAPS base object 333 Flags: One byte, set to zero by sender, ignored by receiver. 335 reserved: One byte, set to zero by sender, ignored by receiver. 337 CAPQSequence: One byte, Sequence number copied from CAPQSequence 338 received in the CAPQ message. 340 CAPS message SHOULD contain the capability set Figure 1 queried by 341 the CAPQ sender. If the target node does not support a subset of the 342 queried capabilities then the Capability Type List with the 343 unsupported cap-types SHOULD be sent back indicating the queried 344 capabilities not-supported by the target node. For example, check 345 Appendix A.3 347 If the CAPQ message does not contain any Capability Type List option 348 then the receiver MUST respond with the cap types it supports using a 349 Capability Type List Option (see Figure 4). 351 If the capability set cannot be transmitted in a single message (for 352 e.g., because of MTU limitations) then multiple CAPS messages could 353 be used. All the CAPS messages MUST use the same CAPQSequence number 354 copied from the corresponding CAPQ message. 356 4.2.1. Secure CAPS 358 A Secure CAPS message follows the format in [RFC6550] Figure 7, where 359 the base message format is the CAPS message shown in Figure 5. 361 5. Guidelines for defining new capabilities 363 This section provides guidelines/recommendations towards defining new 364 capabilities. Note that the capabilities might be carried as part of 365 the multicast messaging such as DIO and hence the set should be used 366 sparingly. 368 5.1. Handling Capability flags 370 A node MUST drop or discard the message with an unknown capability 371 with the 'D' flag set. The message MUST be discarded silently. 373 The 'J' (join) flag can be set in context to a capability either by a 374 6LR or the root. The 'J' flag indicates that if the capability is 375 not supported by a node then it can join the instance only as a 6LN 376 (or do not join as 6LR). 378 The 'C' (copy) flag is set by the node indicating that the 379 capabilities MUST be copied downstream by the node even if the node 380 does not understand the capability. 382 5.1.1. Rules to handle capabilities flag 384 How should a node react to capability it does 385 not support before joining the Instance? 386 On receiving a capability it does not support, the node MUST check 387 the 'J' flag of the capability before joining the Instance. If 388 the 'J' flag is set then it can only join as a 6LN. 390 How should a node react to capability it does not support after 391 joining the Instance? 392 If the node is operating as 6LR and subsequently it receives a 393 capability from its preferred parent which it does not understand 394 with 'J' flag set, then the node has to switch itself to 6LN mode. 395 During switching, the node needs to inform its downstream peers of 396 its changed status by sending a DIO with infinite rank as 397 mentioned in RFC6550. Alternatively, a node may decide to switch 398 to another parent with compatible and known capabilities. 400 When to use and when not to use Capabilities? 402 Capabilities are used to indicate a feature that is supported by 403 the node. Capabilities are not meant for configuration management 404 for e.g., setting a threshold. 406 6. Node Capabilities 408 6.1. Capability Indicators 410 Capability Indicators indicate the capabilities supported by the node 411 in the form of simple flags. Capabilities that do not need 412 additional information to be specified can make use of these flags to 413 indicate their support. 415 6.1.1. Format of Capability Indicators 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Figure 6: Capability Indicators TLV 425 Flags: LRs MUST set it to 0. I bit will always be set to 0. 427 T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. 429 6.2. Routing Resource Capability 431 Storing Mode of Operation requires each intermediate router in the 432 LLN to maintain routing state information in the routing table. LLN 433 routers typically operate with constraints on processing power, 434 memory, and energy (battery power). Memory limits the size of the 435 routing state an LR and BR can maintain. When the routing table of 436 an LR or BR is full, it will either reject the new DAO messages 437 received or will use some replacement policy to remove a routing 438 entry and add the new one. Rejection of DAO messages will lead to an 439 increase in DAO message transmission that impacts the energy and 440 network convergence time. Routing state replacement leads to 441 downward path downtime. 443 One possible way to solve problems due to routing table size 444 constraint is to use this information to add neighbors to the DAO 445 parent set. Routing resource capability can be used by LR and BR to 446 advertise their current routing table usage details in the network. 447 LR or LNs in LLN can use this information in the selection of the DAO 448 parent set. PCE can use this information to select intermediate 449 routers for the projected routes. Routing Resource is an optional 450 capability. 452 Routing resource capabablity sent in DIO message has link local scope 453 and it MUST NOT be forwarded. The 'C' bit of this capability MUST be 454 set to 0. 456 6.2.1. Format of Routing Resource Capability 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Total Capacity | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Figure 7: Routing Resource Capability TLV 468 Type: 0x02. 470 Flags: I bit MUST be set to 0. C bit MUST be set to 0. 472 Len: 8-bit unsigned integer, representing the length in octets of the 473 option, not including the Option Type and Length/flags fields. 475 Resvd: 8-bit unused field. It MUST be initialized to zero by the 476 sender and MUST be ignored by the receiver. 478 Total Capacity: 16 bit unsigned integer representing the routing 479 table size. 481 7. Acknowledgements 483 Thanks to Georgios Papadopoulos, Li Zhao for early review and 484 feedback. 486 8. IANA Considerations 488 IANA is requested to allocate new codes for the CAPQ and CAPS 489 messages from the RPL Control Codes registry. 491 +------+----------------------------+---------------+ 492 | Code | Description | Reference | 493 +------+----------------------------+---------------+ 494 | TBD1 | Capability Query | This document | 495 | TBD2 | Capability Response | This document | 496 | TBD3 | Secure Capability Query | This document | 497 | TBD4 | Secure Capability Response | This document | 498 +------+----------------------------+---------------+ 500 New RPL Control Messages 502 The MSB of the codes allocated to "Secure" messages above should be 503 set. 505 8.1. New option: Capabilities 507 New entry is required for supporting new Capabilities option and new 508 Capability Type List Option in the "RPL Control Message Options" 509 space [RFC6550]. 511 +-------+-----------------------------+---------------+ 512 | Value | Meaning | Reference | 513 +-------+-----------------------------+---------------+ 514 | TODO | Capability Option | This document | 515 | TODO | Capability Type List Option | This document | 516 +-------+-----------------------------+---------------+ 518 New options 520 8.2. Capability Sub-Type 522 IANA is requested to create a registry for the Capabilities Type as 523 described in Figure 2 of this document. This registry should be 524 located in TODO. New Capabilities types may be allocated only by an 525 IETF review. 527 +-------+-----------------------------+---------------+ 528 | Value | Meaning | Reference | 529 +-------+-----------------------------+---------------+ 530 | 0x01 | Capability Indicators | This document | 531 | 0x02 | Routing Resource Capability | This document | 532 +-------+-----------------------------+---------------+ 534 Type 536 8.3. New Registry for CAPQ Flags 538 IANA is requested to create a registry for the Capabilities flags as 539 described in Section 4.1 of this document. This registry should be 540 located in TODO. New Capabilities flags may be allocated only by an 541 IETF review. Currently no flags are defined by this document. Each 542 value is tracked with the following qualities: 544 o Flag 546 o Description 548 o Defining RFC 550 8.4. New Registry for Capabilities Flags 552 IANA is requested to create a registry for the Capabilities flags as 553 described in Section 2.1 of this document. This registry should be 554 located in TODO. New Capabilities flags may be allocated only by an 555 IETF review. Currently no flags are defined by this document. Each 556 value is tracked with the following qualities: 558 o Flag 560 o Description 562 o Defining RFC 564 8.5. New Registry for Capabilities Indicators 566 IANA is requested to create a registry for the Capabilities 567 Indicators as described in Section 6.1 of this document. This 568 registry should be located in TODO. New Capabilities indicators may 569 be allocated only by an IETF review. Each value is tracked with the 570 following qualities: 572 o Flag 574 o Description 575 o Defining RFC 577 9. Security Considerations 579 The options defined in this document are carried in the base message 580 objects as defined in [RFC6550]. The RPL control message options are 581 protected by the same security mechanisms that protect the base 582 messages. 584 Capabilities flag can reveal that the node has been upgraded or is 585 running a old feature set. This document assumes that the base 586 messages that carry these options are protected by RPL security 587 mechanisms and thus are not visible to a malicious node. 589 [TODO] implications of malicious attack involving setting the 590 capability flags. 592 10. References 594 10.1. Normative References 596 [I-D.ietf-roll-mopex] 597 Jadhav, R., Thubert, P., and M. Richardson, "Mode of 598 Operation extension", draft-ietf-roll-mopex-02 (work in 599 progress), September 2020. 601 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, 603 DOI 10.17487/RFC2119, March 1997, 604 . 606 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 607 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 608 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 609 Low-Power and Lossy Networks", RFC 6550, 610 DOI 10.17487/RFC6550, March 2012, 611 . 613 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 614 "IPv6 over Low-Power Wireless Personal Area Network 615 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 616 April 2017, . 618 10.2. Informative References 620 [I-D.ietf-roll-dao-projection] 621 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 622 routing state in RPL", draft-ietf-roll-dao-projection-16 623 (work in progress), January 2021. 625 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 626 and D. Barthel, "Routing Metrics Used for Path Calculation 627 in Low-Power and Lossy Networks", RFC 6551, 628 DOI 10.17487/RFC6551, March 2012, 629 . 631 Appendix A. Capability Handshake Example 633 A.1. Query supported Cap Types 635 Root 6LR/6LN 636 | | 637 | CAPQ(seq=1, opts=nil) | 638 |---------------------------------->| 639 | | 640 | | 641 | CAPS(seq=1, opts={CapTypeList}) | 642 |<----------------------------------| 643 | | 645 Figure 8: Query supported Cap Types 647 CAPQ message with no CapTypeList Option results in the peer 648 responding with a CAPS message with CapTypeList Option indicating all 649 the capability set it supports. 651 A.2. Query specific Cap Set 653 Root 6LR/6LN 654 | | 655 | CAPQ(seq=2, | 656 | opts={CapTypeList=[Cap1, Cap2]})| 657 |---------------------------------->| 658 | | 659 | | 660 | CAPS(seq=2, | 661 | opts={Cap1=Cap1Value, | 662 | Cap2=Cap2Value}) | 663 |<----------------------------------| 664 | | 666 Figure 9: Query specific Cap Set 668 This flow indicates the case where the Root probes for specific 669 Capabilities of the peer node and the peer node responds with the 670 value of indicated Capability set. 672 A.3. CAPS with partial Cap Set 674 Root 6LR/6LN 675 | | 676 | CAPQ(seq=3, | 677 | opts={CapTypeList=[Cap1, Cap2, | 678 | Cap3, Cap4]})| 679 |---------------------------------->| 680 | | 681 | | 682 | CAPS(seq=3, | 683 | opts={Cap2=Cap2Value, | 684 | Cap3=Cap3Value, | 685 | CapTypeList=[Cap1,Cap4]})| 686 |<----------------------------------| 687 | | 689 Partial Capability Set handshake 691 Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4} 692 from the peer node. However the peer node does not support or does 693 not understand capability {cap1, cap4}. In this case the peer node 694 will respond back with value of Cap2 and Cap3 (which it understands) 695 and set the CapTypeList option with {Cap1, Cap4} type. 697 Authors' Addresses 699 Rahul Arvind Jadhav (editor) 700 Marathahalli 701 Bangalore, Karnataka 560037 702 India 704 Email: rahul.ietf@gmail.com 706 Pascal Thubert 707 Cisco Systems, Inc 708 Building D 709 45 Allee des Ormes - BP1200 710 MOUGINS - Sophia Antipolis 06254 711 France 713 Phone: +33 497 23 26 34 714 Email: pthubert@cisco.com 715 Michael Richardson 716 Sandelman Software Works 718 Email: mcr+ietf@sandelman.ca 720 Rabi Narayan Sahoo 721 Juniper 723 Email: rabinarayans0828@gmail.com