idnits 2.17.1 draft-ietf-roll-capabilities-09.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 == 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 (9 November 2021) is 871 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 586, but not defined == Unused Reference: 'I-D.ietf-lwig-nbr-mgmt-policy' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-turnon-rfc8138' is defined on line 634, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-roll-mopex-03 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-21 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R.A. Jadhav, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track P. Thubert 5 Expires: 13 May 2022 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R.N. Sahoo 9 Juniper 10 9 November 2021 12 RPL Capabilities 13 draft-ietf-roll-capabilities-09 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 13 May 2022. 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language and Terminology . . . . . . . . . . 3 55 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 4 56 2. Requirements for this document . . . . . . . . . . . . . . . 4 57 2.1. How are Capabilities different from existing RPL 58 primitives? . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Capability Control Message Option . . . . . . . . . . . . 5 61 3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 62 4. Querying Capabilities . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Capability Query (CAPQ) . . . . . . . . . . . . . . . . . 6 64 4.1.1. Capability Type List Control Option . . . . . . . . . 7 65 4.1.2. Secure CAPQ . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.3. Base rules for CAPQ handling . . . . . . . . . . . . 7 67 4.2. Capability Set Response (CAPS) . . . . . . . . . . . . . 7 68 4.2.1. Secure CAPS . . . . . . . . . . . . . . . . . . . . . 8 69 5. Guidelines for defining new capabilities . . . . . . . . . . 8 70 5.1. Handling Capability flags . . . . . . . . . . . . . . . . 8 71 5.1.1. Rules to handle capabilities flag . . . . . . . . . . 9 72 6. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Capability Indicators . . . . . . . . . . . . . . . . . . 9 74 6.1.1. Format of Capability Indicators . . . . . . . . . . . 9 75 6.2. Routing Resource Capability . . . . . . . . . . . . . . . 10 76 6.2.1. Format of Routing Resource Capability . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. New option: Capabilities . . . . . . . . . . . . . . . . 11 80 8.2. Capability Sub-Type . . . . . . . . . . . . . . . . . . . 12 81 8.3. New Registry for CAPQ Flags . . . . . . . . . . . . . . . 12 82 8.4. New Registry for Capabilities Flags . . . . . . . . . . . 12 83 8.5. New Registry for Capabilities Indicators . . . . . . . . 13 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 87 10.2. Informative References . . . . . . . . . . . . . . . . . 14 88 Appendix A. Capability Handshake Example . . . . . . . . . . . . 14 89 A.1. Query supported Cap Types . . . . . . . . . . . . . . . . 14 90 A.2. Query specific Cap Set . . . . . . . . . . . . . . . . . 15 91 A.3. CAPS with partial Cap Set . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 94 1. Introduction 96 RPL [RFC6550] specifies a proactive distance-vector based routing 97 scheme. The protocol creates a DAG-like structure which operates 98 with a given "Mode of Operation" (MOP) determining the minimal and 99 mandatory set of primitives to be supported by all the participating 100 nodes. 102 This document adds a notion of capabilities using which nodes in the 103 network could inform its peers about its additional capabilities. 104 This document highlights the differences of capabilities from that of 105 Mode of operation and explains the necessity of it. 107 1.1. Requirements Language and Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 MOP: Mode of Operation. Identifies the MOP of the RPL Instance as 114 administratively provisioned at and distributed by the DODAG root. 116 MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. 118 Capabilities: Additional features or capabilities that are supported 119 by the node. 121 Cap: Abbreviated term used for Capability. 123 Caps: Abbreviated term used for Capabilities. 125 DAO: DODAG Advertisement Object. An RPL message used to advertise 126 the target information in order to establish routing adjacencies. 128 DIO: DODAG Information Object. An RPL message initiated by the root 129 and is used to advertise the network configuration information. 131 Current parent: Parent 6LR node before switching to the new path. 133 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 135 Upstream path/direction: Path or direction from the node to the Root 136 in a DAG. 138 Downstream path/direction: Path or direction to the node from the 139 Root in a DAG. 141 This document uses terminology described in [RFC6550]. For the sake 142 of readability all the known relevant terms are repeated in this 143 section. 145 1.2. What are Capabilities? 147 Currently RPL specification does not have a mechanism whereby a node 148 can signal the set of features that are available on its end. Such a 149 mechanism could help the root to advertise its capabilities and in 150 response also determine some advanced information about the 151 capabilities of the joining nodes. This document defines 152 Capabilities which could be supported by the nodes and handshaked as 153 part of RPL signaling. Capabilities are embedded as an RPL Control 154 Message Option as defined in Section 6.7 of [RFC6550]. 156 2. Requirements for this document 158 Following are the requirements considered for this documents: 160 REQ1: Backwards compatibility. The new options and new fields in 161 the DIO message should be backward compatible i.e. if there 162 are nodes which support old MOPs they could still operate in 163 their own instances. 165 REQ2: Optional capabilities handshake. Capabilities are features, 166 possibly optional, which could be handshaked between the nodes 167 and the root within an RPL Instance. 169 REQ3: Capabilities handshake could be optionally added with existing 170 MOPs. Capabilities been optional in nature could be put to 171 use with existing MOPs. Capabilities and MOP-extension is 172 mutually independent i.e. a DIO can have a capabilities 173 option, MOP-extension option or both in the same message. 175 REQ4: 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 as part of 189 objective function which aids in node's rank calculation. A router 190 may use capabilities carried in DIO message as additional metrics/ 191 constraints. However, capabilities have a larger scope and may be 192 carried in other messages other than DIO and can flow in both the 193 directions (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 could 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 diseminated with additional information depending on the scope 228 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 could advertise the set of capabilities it supports in 243 the DIO message. A node could take advantage of the knowledge that 244 the root supports a particular capability. Similarly a node could 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 are strictly a subset of the 248 capabilities advertised by the root. 250 In storing MOP, the DAO message from the 6LR could 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 e.g., Consider 261 [I-D.ietf-roll-dao-projection], the Root may want to know the 262 capabilities of the nodes along a network segment before it initiates 263 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 capability set of another node. 268 The capability query and subsequent response messages are directly 269 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 284 which is 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 CAPQ base object may be followed by one or more options. The 291 Capability Type List Control Option Figure 4 is used to carry a set 292 of capability types to query about. 294 If the sender does not send Figure 4 option, this would indicate that 295 the node intends to query the capability type list Figure 4 supported 296 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 +-+-+-+-+-+-+-+-+ 330 Figure 5: CAPS base object 332 Flags: One byte, set to zero by sender, ignored by receiver. 334 reserved: One byte, set to zero by sender, ignored by receiver. 336 CAPQSequence: One byte, Sequence number copied from CAPQSequence 337 received in the CAPQ message. 339 CAPS message SHOULD contain the capability set Figure 1 queried by 340 the CAPQ sender. If the target node does not support subset of the 341 queried capabilities then the Figure 4 option with the unsupported 342 cap-types SHOULD be sent back indicating the queried capabilities 343 not-supported by the target node. For an example, check Appendix A.3 345 If the CAPQ message does not contain any Figure 4 option then the 346 receiver MUST respond with the cap types it supports using Figure 4. 348 If the capability set cannot be transmitted in a single message (for 349 e.g., because of MTU limitations) then multiple CAPS messages could 350 be used. All the CAPS message MUST use the same CAPQSequence number 351 copied from the corresponding CAPQ message. 353 4.2.1. Secure CAPS 355 A Secure CAPS message follows the format in [RFC6550] Figure 7, where 356 the base message format is the CAPS message shown in Figure 5. 358 5. Guidelines for defining new capabilities 360 This section provides guidelines/recommendations towards defining new 361 capabilities. Note that the capabilities might be carried as part of 362 the multicast messaging such as DIO and hence the set should be used 363 in restrictive manner as far as possible. 365 5.1. Handling Capability flags 367 A node MUST drop or discard the message with an unknown capability 368 with 'D' flag set. The message MUST be discarded silently. 370 The 'J' (join) flag can be set in context to a capability either by a 371 6LR or the root. The 'J' flag indicates that if the capability is 372 not supported by a node then it can join the instance only as a 6LN 373 (or do not join as 6LR). 375 The 'C' (copy) flag is set by the node indicating that the 376 capabilities MUST be copied downstream by the node even if the node 377 does not understand the capability. 379 5.1.1. Rules to handle capabilities flag 381 On receiving a capability it does not support, the node MUST check 382 the 'J' flag of the capability before joining the Instance. If the 383 'J' flag is set then it can only join as a 6LN. 385 If the node is operating as 6LR and subsequently it receives a 386 capability from its preferred parent which it does not understand 387 with 'J' flag set, then the node has to switch itself to 6LN mode. 388 During switching the node needs to inform its downstream peers of its 389 changed status by sending a DIO with infinite rank as mentioned in 390 RFC6550. Alternatively, a node may decide to switch to another 391 parent with compatible and known capabilities. 393 Capabilities are used to indicate a feature that is supported by the 394 node. Capabilities are not meant for configuration management for 395 e.g., setting a threshold. 397 6. Node Capabilities 399 6.1. Capability Indicators 401 Capability Indicators indicates the capabilities supported by the 402 node in the form of simple flags. Capabilities who do not have 403 additional information to be specified could make use of these flags 404 to indicate their support. 406 6.1.1. Format of Capability Indicators 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 6: Capability Indicators TLV 416 Flags: LRs MUST set it to 0. I bit will always be set to 0. 418 T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. 420 6.2. Routing Resource Capability 422 Storing mode of operation requires each intermediate router in the 423 LLN to maintain routing states' information in the routing table. 424 LLN routers typically operate with constraints on processing power, 425 memory, and energy (battery power). Memory limits the number of 426 routing states an LR and BR can maintain. When the routing table of 427 an LR or BR is full, it will either reject the new DAO messages 428 received or will use some replacement policy to remove a routing 429 entry and add the new one. Rejection of DAO messages will lead to an 430 increase in DAO message transmission that impacts the energy and 431 network convergence time. Routing state replacement leads to 432 downward path downtime. 434 One possible way to solve problems due to routing table size 435 constraint is to use this information to add neighbors to the DAO 436 parent set. Routing resource capability can be used by LR and BR to 437 advertise their current routing table usage details in the network. 438 LR or LNs in LLN can use this information in the selection of the DAO 439 parent set. PCE can use this information to select intermediate 440 routers for the projected routes. Routing Resource is an optional 441 capability. 443 Routing resource capabablity sent in DIO message has link local scope 444 and it MUST not be forwarded. The 'C' bit of this capability MUST be 445 set to 0. 447 6.2.1. Format of Routing Resource Capability 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Total Capacity | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 7: Routing Resource Capability TLV 459 Type: 0x02. 461 Flags: I bit MUST be set to 0. C bit MUST be set to 0. 463 Len: 8-bit unsigned integer, representing the length in octets of the 464 option, not including the Option Type and Length/flags fields. 466 Resvd: 8-bit unused field. It MUST be initialized to zero by the 467 sender and MUST be ignored by the receiver. 469 Total Capacity: 16 bit unsigned integer representing the routing 470 table size. 472 7. Acknowledgements 474 Thanks to Georgios Papadopoulos, Li Zhao for early review and 475 feedback. 477 8. IANA Considerations 479 IANA is requested to allocate new codes for the CAPQ and CAPS 480 messages from the RPL Control Codes registry. 482 +======+============================+===============+ 483 | Code | Description | Reference | 484 +======+============================+===============+ 485 | TBD1 | Capability Query | This document | 486 +------+----------------------------+---------------+ 487 | TBD2 | Capability Response | This document | 488 +------+----------------------------+---------------+ 489 | TBD3 | Secure Capability Query | This document | 490 +------+----------------------------+---------------+ 491 | TBD4 | Secure Capability Response | This document | 492 +------+----------------------------+---------------+ 494 Table 1: New RPL Control Messages 496 The MSB of the codes allocated to "Secure" messages above should be 497 set. 499 8.1. New option: Capabilities 501 New entry is required for supporting new Capabilities option and new 502 Capability Type List Option in the "RPL Control Message Options" 503 space [RFC6550]. 505 +=======+=============================+===============+ 506 | Value | Meaning | Reference | 507 +=======+=============================+===============+ 508 | TODO | Capability Option | This document | 509 +-------+-----------------------------+---------------+ 510 | TODO | Capability Type List Option | This document | 511 +-------+-----------------------------+---------------+ 513 Table 2: New options 515 8.2. Capability Sub-Type 517 IANA is requested to create a registry for the Capabilities Type as 518 described in Figure 2 of this document. This registry should be 519 located in TODO. New Capabilities types may be allocated only by an 520 IETF review. 522 +=======+=============================+===============+ 523 | Value | Meaning | Reference | 524 +=======+=============================+===============+ 525 | 0x01 | Capability Indicators | This document | 526 +-------+-----------------------------+---------------+ 527 | 0x02 | Routing Resource Capability | This document | 528 +-------+-----------------------------+---------------+ 530 Table 3: Type 532 8.3. New Registry for CAPQ Flags 534 IANA is requested to create a registry for the Capabilities flags as 535 described in Section 4.1 of this document. This registry should be 536 located in TODO. New Capabilities flags may be allocated only by an 537 IETF review. Currently no flags are defined by this document. Each 538 value is tracked with the following qualities: 540 * Flag 542 * Description 544 * Defining RFC 546 8.4. New Registry for Capabilities Flags 548 IANA is requested to create a registry for the Capabilities flags as 549 described in Section 2.1 of this document. This registry should be 550 located in TODO. New Capabilities flags may be allocated only by an 551 IETF review. Currently no flags are defined by this document. Each 552 value is tracked with the following qualities: 554 * Flag 556 * Description 558 * Defining RFC 560 8.5. New Registry for Capabilities Indicators 562 IANA is requested to create a registry for the Capabilities 563 Indicators as described in Section 6.1 of this document. This 564 registry should be located in TODO. New Capabilities indicators may 565 be allocated only by an IETF review. Each value is tracked with the 566 following qualities: 568 * Flag 570 * Description 572 * Defining RFC 574 9. Security Considerations 576 The options defined in this document are carried in the base message 577 objects as defined in [RFC6550]. The RPL control message options are 578 protected by the same security mechanisms that protect the base 579 messages. 581 Capabilities flag can reveal that the node has been upgraded or is 582 running a old feature set. This document assumes that the base 583 messages that carry these options are protected by RPL security 584 mechanisms and thus are not visible to a malicious node. 586 [TODO] implications of malicious attack involving setting the 587 capability flags. 589 10. References 591 10.1. Normative References 593 [I-D.ietf-roll-mopex] 594 Jadhav, R. A., Thubert, P., and M. Richardson, "Mode of 595 Operation extension", Work in Progress, Internet-Draft, 596 draft-ietf-roll-mopex-03, 31 March 2021, 597 . 600 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 601 Requirement Levels", BCP 14, RFC 2119, 602 DOI 10.17487/RFC2119, March 1997, 603 . 605 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 606 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 607 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 608 Low-Power and Lossy Networks", RFC 6550, 609 DOI 10.17487/RFC6550, March 2012, 610 . 612 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 613 "IPv6 over Low-Power Wireless Personal Area Network 614 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 615 April 2017, . 617 10.2. Informative References 619 [I-D.ietf-lwig-nbr-mgmt-policy] 620 Jadhav, R. A., Sahoo, R. N., Duquennoy, S., and J. 621 Eriksson, "Neighbor Management Policy for 6LoWPAN", Work 622 in Progress, Internet-Draft, draft-ietf-lwig-nbr-mgmt- 623 policy-03, 21 February 2019, 624 . 627 [I-D.ietf-roll-dao-projection] 628 Thubert, P., Jadhav, R. A., and M. Gillmore, "Root 629 initiated routing state in RPL", Work in Progress, 630 Internet-Draft, draft-ietf-roll-dao-projection-21, 27 631 September 2021, . 634 [I-D.thubert-roll-turnon-rfc8138] 635 Thubert, P. and L. Zhao, "Configuration option for RFC 636 8138", Work in Progress, Internet-Draft, draft-thubert- 637 roll-turnon-rfc8138-03, 8 July 2019, . 640 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 641 and D. Barthel, "Routing Metrics Used for Path Calculation 642 in Low-Power and Lossy Networks", RFC 6551, 643 DOI 10.17487/RFC6551, March 2012, 644 . 646 Appendix A. Capability Handshake Example 648 A.1. Query supported Cap Types 649 Root 6LR/6LN 650 | | 651 | CAPQ(seq=1, opts=nil) | 652 |---------------------------------->| 653 | | 654 | | 655 | CAPS(seq=1, opts={CapTypeList}) | 656 |<----------------------------------| 657 | | 659 Figure 8: Query supported Cap Types 661 CAPQ message with no CapTypeList Option results in the peer 662 responding with a CAPS message with CapTypeList Option indicating all 663 the capability set it supports. 665 A.2. Query specific Cap Set 667 Root 6LR/6LN 668 | | 669 | CAPQ(seq=2, | 670 | opts={CapTypeList=[Cap1, Cap2]})| 671 |---------------------------------->| 672 | | 673 | | 674 | CAPS(seq=2, | 675 | opts={Cap1=Cap1Value, | 676 | Cap2=Cap2Value}) | 677 |<----------------------------------| 678 | | 680 Figure 9: Query specific Cap Set 682 This flow indicates the case where the Root probes for specific 683 Capabilities of the peer node and the peer node responds with the 684 value of indicated Capability set. 686 A.3. CAPS with partial Cap Set 687 Root 6LR/6LN 688 | | 689 | CAPQ(seq=3, | 690 | opts={CapTypeList=[Cap1, Cap2, | 691 | Cap3, Cap4]})| 692 |---------------------------------->| 693 | | 694 | | 695 | CAPS(seq=3, | 696 | opts={Cap2=Cap2Value, | 697 | Cap3=Cap3Value, | 698 | CapTypeList=[Cap1,Cap4]})| 699 |<----------------------------------| 700 | | 702 Figure 10: Partial Capability Set handshake 704 Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4} 705 from the peer node. However the peer node does not support or does 706 not understand capability {cap1, cap4}. In this case the peer node 707 will respond back with value of Cap2 and Cap3 (which it understands) 708 and set the CapTypeList option with {Cap1, Cap4} type. 710 Authors' Addresses 712 Rahul Arvind Jadhav (editor) 713 Huawei 714 Kundalahalli Village, Whitefield, 715 Bangalore 560037 716 Karnataka 717 India 719 Phone: +91-080-49160700 720 Email: rahul.ietf@gmail.com 722 Pascal Thubert 723 Cisco Systems, Inc 724 Building D 725 45 Allee des Ormes - BP1200 726 06254 MOUGINS - Sophia Antipolis 727 France 729 Phone: +33 497 23 26 34 730 Email: pthubert@cisco.com 731 Michael Richardson 732 Sandelman Software Works 734 Email: mcr+ietf@sandelman.ca 736 Rabi Narayan Sahoo 737 Juniper 739 Email: rabinarayans0828@gmail.com