idnits 2.17.1 draft-ietf-roll-capabilities-07.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 (September 17, 2020) is 1309 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 578, but not defined == Unused Reference: 'I-D.ietf-lwig-nbr-mgmt-policy' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-roll-turnon-rfc8138' is defined on line 619, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-roll-mopex-01 == Outdated reference: A later version (-34) exists of draft-ietf-roll-dao-projection-11 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. Jadhav, Ed. 3 Internet-Draft 4 Intended status: Standards Track P. Thubert 5 Expires: March 21, 2021 Cisco 6 M. Richardson 7 Sandelman Software Works 8 R. Sahoo 9 Juniper 10 September 17, 2020 12 RPL Capabilities 13 draft-ietf-roll-capabilities-07 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 March 21, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 9 77 6.2.1. Format of Routing Resource Capability . . . . . . . . 10 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 16 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 This document highlights the differences between capabilities and 106 Mode of Operation and explains the necessity for the former. 108 1.1. Requirements Language and Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 MOP: Mode of Operation. Identifies the MOP of the RPL Instance as 115 administratively provisioned at and distributed by the DODAG root. 117 MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. 119 Capabilities: Additional features or capabilities that are supported 120 by the node. 122 Cap: Abbreviated term used for Capability. 124 Caps: Abbreviated term used for Capabilities. 126 DAO: DODAG Advertisement Object. A RPL (pronounced ripple) message 127 used to advertise the target information in order to establish 128 routing adjacencies. 130 DIO: DODAG Information Object. A RPL message initiated by the root 131 and is used to advertise the network configuration information. 133 Current parent: Parent 6LR node before switching to the new path. 135 NPDAO: No-Path DAO. A DAO message that contains a Transit 136 Information Option with lifetime equal to 0. 138 Upstream path/direction: Path or direction from the node to the Root 139 in a DAG. 141 Downstream path/direction: Path or direction to the node from the 142 Root in a DAG. 144 This document uses terminology described in [RFC6550]. For the sake 145 of readability all the known relevant terms are repeated in this 146 section. 148 1.2. What are Capabilities? 150 Currently RPL specification does not have a mechanism whereby a node 151 can signal the set of features that are available on its end. Such a 152 mechanism could help the root to advertise its capabilities and in 153 response also determine some advanced information about the 154 capabilities of the joining nodes. This document defines 155 Capabilities which could be supported by the nodes and handshaked as 156 part of RPL signaling. Capabilities are embedded as a RPL Control 157 Message Option as defined in Section 6.7 of [RFC6550]. 159 2. Requirements for this document 161 Following are the requirements considered for this documents: 163 REQ1: Optional capabilities handshake. Capabilities are features, 164 possibly optional, which could be handshaked between the nodes 165 and the root within an RPL Instance. 167 REQ2: Capabilities handshake could be optionally added with existing 168 MOPs. Capabilities, being optional in nature, could be put to 169 use with existing MOPs. Capabilities and MOP-extension are 170 mutually independent i.e. a DIO can have a capabilities 171 option, MOP-extension option or both in the same message. 173 REQ3: Capabilities could be explicitly queried. 175 2.1. How are Capabilities different from existing RPL primitives? 177 The Mode of Operation (MOP) field in RPL mandates the operational 178 requirement for the nodes joining as routers. MOP and DIO 179 Configuration Option is strictly controlled by the Root node in RPL. 180 Intermediate 6LRs cannot modify these fields. Also, the MOP never 181 changes for the lifetime of the RPL Instance. Changes in DIO 182 Configuration Option are possible but are rare. Capabilities, on the 183 other hand, might change more dynamically. 185 RPL DIO message also carries routing metrics and constraints as 186 specified in [RFC6551]. Metrics and constraints are used in addition 187 to an objective function to determine a node's rank calculation. A 188 router may use capabilities carried in DIO message as additional 189 metrics/constraints. However, capabilities have a larger scope and 190 may be carried in messages other than DIO and can flow in either 191 direction (upstream and downstream). 193 3. Capabilities 195 Handling of Capabilities MUST be supported if the network uses MOPex 196 [I-D.ietf-roll-mopex]. 198 Note that capabilities and MOPex are mutually exclusive and it is 199 possible for an implementation to support either or both of the 200 options. 202 3.1. Capability Control Message Option 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type = TODO | Option Length | Capabilities TLVs 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 1: Capabilities Option 212 Multiple capabilities can be sent in the same message. The length 213 field allows the message parser to skip the capability TLV parsing. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | CapType | Len |J|I|C| Flags | ... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 2: Capabilities TLV 223 Every capability is identified by its type and it may have an 224 optional Capability Info. Note that a given capability may or may 225 not be disseminated with additional information depending on the 226 scope of the capability indicated by the I bit. 228 Len: 8-bit unsigned integer, representing the length in octets of the 229 TLV, not including the CapType, Length and Flags fields. 231 J = Join only as leaf if capability not understood. 233 I = Ignore the message if this capability is not understood. 235 C = Flag indicating that the capability MUST be copied in the 236 downstream message. 238 3.2. Capabilities Handshake 240 The root node can advertise the set of capabilities it supports in 241 the DIO message. A node can take advantage of the knowledge that the 242 root supports a particular capability. Similarly a node can 243 advertise its capabilities in the DAO message using the capability 244 control message option defined in this document. Capabilities 245 advertised by non-root nodes are strictly a subset of the 246 capabilities advertised by the root. 248 In storing MOP, the DAO message from the 6LR can contain multiple 249 target options because of the DAO-Aggregation. The targets of the 250 capabilities option are indicated by one or more Target options that 251 precede the Capabilities Option. This handling is similar to the 252 Transit Information Option as supported in Section 6.7.8. of 253 [RFC6550]. 255 4. Querying Capabilities 257 Nodes may be interested in knowing the capabilities of another node 258 before taking an action. For example, consider 259 [I-D.ietf-roll-dao-projection], in which the Root may want to know 260 the capabilities of the nodes along a network segment before it 261 initiates a projected DAO to install the routes along that segment. 263 Caps can be carried in existing RPL Control messages as Control 264 Options, however Caps can also be queried explicitly. This section 265 provides a way for a node to query the capability set of another 266 node. The capability query and subsequent response messages are 267 directly addressed between the two peers. 269 4.1. Capability Query (CAPQ) 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | RPLInstanceID | Flags | reserved | CAPQSequence | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Option(s)... 277 +-+-+-+-+-+-+-+-+ 279 Figure 3: CAPQ base object 281 CAPQSequence: One byte, Sequence number sent by the CAPQ sender and 282 reflected back by the responder in the CAPS message. 284 Flags: One byte, set to zero by sender, ignored by receiver. 286 reserved: One byte, set to zero by sender, ignored by receiver. 288 The CAPQ base object may be followed by one or more options. The 289 Capability Type List Control Option (see Figure 4) is used to carry a 290 set of capability types to query about. 292 If the sender does not send a Capability Type List Control Option, 293 this indicates that the node intends to query the Capability Type 294 List supported by the target node. 296 4.1.1. Capability Type List Control Option 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type = TODO | Option Length | CapType1 | CapType2 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | CapType3 | ..... 304 +-+-+-+-+-+-+-+-+-+-+-+-+ 306 Figure 4: Capability Type List Control Option 308 4.1.2. Secure CAPQ 310 A Secure CAPQ message follows the format in [RFC6550] Figure 7, where 311 the base message format is the CAPQ message shown in Figure 3. 313 4.1.3. Base rules for CAPQ handling 315 A CAPQ message may get dropped or lost in the transit. The sender of 316 CAPQ MAY retry the CAPQ message after some delay. The delay SHOULD 317 NOT be less than 1 second. 319 4.2. Capability Set Response (CAPS) 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | RPLInstanceID | Flags | Reserved | CAPQSequence | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Option(s)... 327 +-+-+-+-+-+-+-+-+ 329 Figure 5: CAPS base object 331 Flags: One byte, set to zero by sender, ignored by receiver. 333 reserved: One byte, set to zero by sender, ignored by receiver. 335 CAPQSequence: One byte, Sequence number copied from CAPQSequence 336 received in the CAPQ message. 338 CAPS message SHOULD contain the capability set Figure 1 queried by 339 the CAPQ sender. If the target node does not support a subset of the 340 queried capabilities then the Capability Type List with the 341 unsupported cap-types SHOULD be sent back indicating the queried 342 capabilities not-supported by the target node. For an example, check 343 Appendix A.3 345 If the CAPQ message does not contain any Capability Type List option 346 then the receiver MUST respond with the cap types it supports using a 347 Capability Type List Option (see Figure 4). 349 If the capability set cannot be transmitted in a single message (for 350 e.g., because of MTU limitations) then multiple CAPS messages could 351 be used. All the CAPS messages MUST use the same CAPQSequence number 352 copied from the corresponding CAPQ message. 354 4.2.1. Secure CAPS 356 A Secure CAPS message follows the format in [RFC6550] Figure 7, where 357 the base message format is the CAPS message shown in Figure 5. 359 5. Guidelines for defining new capabilities 361 This section provides guidelines/recommendations towards defining new 362 capabilities. Note that the capabilities might be carried as part of 363 the multicast messaging such as DIO and hence the set should be used 364 sparingly, as much as possible. 366 5.1. Handling Capability flags 368 A node MUST drop or discard the message with an unknown capability 369 with the 'D' flag set. The message MUST be discarded silently. 371 The 'J' (join) flag can be set in context to a capability either by a 372 6LR or the root. The 'J' flag indicates that if the capability is 373 not supported by a node then it can join the instance only as a 6LN 374 (or do not join as 6LR). 376 The 'C' (copy) flag is set by the node indicating that the 377 capabilities MUST be copied downstream by the node even if the node 378 does not understand the capability. 380 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. 384 If the node is operating as 6LR and subsequently it receives a 385 capability from its preferred parent which it does not understand 386 with 'J' flag set, then the node has to switch itself to 6LN mode. 387 During switching, the node needs to inform its downstream peers of 388 its changed status by sending a DIO with infinite rank as mentioned 389 in RFC6550. Alternatively, a node may decide to switch to another 390 parent with compatible and known capabilities. 391 Capabilities are used to indicate a feature that is supported by the 392 node. Capabilities are not meant for configuration management for 393 e.g., setting a threshold. 395 6. Node Capabilities 397 6.1. Capability Indicators 399 Capability Indicators indicate the capabilities supported by the node 400 in the form of simple flags. Capabilities that do not need 401 additional information to be specified can make use of these flags to 402 indicate their support. 404 6.1.1. Format of Capability Indicators 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Figure 6: Capability Indicators TLV 414 Flags: LRs MUST set it to 0. I bit will always be set to 0. 416 T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. 418 6.2. Routing Resource Capability 420 Storing Mode of Operation requires each intermediate router in the 421 LLN to maintain routing state information in the routing table. LLN 422 routers typically operate with constraints on processing power, 423 memory, and energy (battery power). Memory limits the size of 424 routing state an LR and BR can maintain. When the routing table of 425 an LR or BR is full, it will either reject the new DAO messages 426 received or will use some replacement policy to remove a routing 427 entry and add the new one. Rejection of DAO messages will lead to an 428 increase in DAO message transmission that impacts the energy and 429 network convergence time. Routing state replacement leads to 430 downward path downtime. 432 One possible way to solve problems due to routing table size 433 constraint is to use this information to add neighbors to the DAO 434 parent set. Routing resource capability can be used by LR and BR to 435 advertise their current routing table usage details in the network. 436 LR or LNs in LLN can use this information in the selection of the DAO 437 parent set. PCE can use this information to select intermediate 438 routers for the projected routes. Routing Resource is an optional 439 capability. 441 Routing resource capabablity sent in DIO message has link local scope 442 and it MUST not be forwarded. The 'C' bit of this capability MUST be 443 set to 0. 445 6.2.1. Format of Routing Resource Capability 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Total Capacity | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 7: Routing Resource Capability TLV 457 Type: 0x02. 459 Flags: I bit MUST be set to 0. C bit MUST be set to 0. 461 Len: 8-bit unsigned integer, representing the length in octets of the 462 option, not including the Option Type and Length/flags fields. 464 Resvd: 8-bit unused field. It MUST be initialized to zero by the 465 sender and MUST be ignored by the receiver. 467 Total Capacity: 16 bit unsigned integer representing the routing 468 table size. 470 7. Acknowledgements 472 Thanks to Georgios Papadopoulos, Li Zhao for early review and 473 feedback. 475 8. IANA Considerations 477 IANA is requested to allocate new codes for the CAPQ and CAPS 478 messages from the RPL Control Codes registry. 480 +------+----------------------------+---------------+ 481 | Code | Description | Reference | 482 +------+----------------------------+---------------+ 483 | TBD1 | Capability Query | This document | 484 | TBD2 | Capability Response | This document | 485 | TBD3 | Secure Capability Query | This document | 486 | TBD4 | Secure Capability Response | This document | 487 +------+----------------------------+---------------+ 489 New RPL Control Messages 491 The MSB of the codes allocated to "Secure" messages above should be 492 set. 494 8.1. New option: Capabilities 496 New entry is required for supporting new Capabilities option and new 497 Capability Type List Option in the "RPL Control Message Options" 498 space [RFC6550]. 500 +-------+-----------------------------+---------------+ 501 | Value | Meaning | Reference | 502 +-------+-----------------------------+---------------+ 503 | TODO | Capability Option | This document | 504 | TODO | Capability Type List Option | This document | 505 +-------+-----------------------------+---------------+ 507 New options 509 8.2. Capability Sub-Type 511 IANA is requested to create a registry for the Capabilities Type as 512 described in Figure 2 of this document. This registry should be 513 located in TODO. New Capabilities types may be allocated only by an 514 IETF review. 516 +-------+-----------------------------+---------------+ 517 | Value | Meaning | Reference | 518 +-------+-----------------------------+---------------+ 519 | 0x01 | Capability Indicators | This document | 520 | 0x02 | Routing Resource Capability | This document | 521 +-------+-----------------------------+---------------+ 523 Type 525 8.3. New Registry for CAPQ Flags 527 IANA is requested to create a registry for the Capabilities flags as 528 described in Section 4.1 of this document. This registry should be 529 located in TODO. New Capabilities flags may be allocated only by an 530 IETF review. Currently no flags are defined by this document. Each 531 value is tracked with the following qualities: 533 o Flag 535 o Description 537 o Defining RFC 539 8.4. New Registry for Capabilities Flags 541 IANA is requested to create a registry for the Capabilities flags as 542 described in Section 2.1 of this document. This registry should be 543 located in TODO. New Capabilities flags may be allocated only by an 544 IETF review. Currently no flags are defined by this document. Each 545 value is tracked with the following qualities: 547 o Flag 549 o Description 551 o Defining RFC 553 8.5. New Registry for Capabilities Indicators 555 IANA is requested to create a registry for the Capabilities 556 Indicators as described in Section 6.1 of this document. This 557 registry should be located in TODO. New Capabilities indicators may 558 be allocated only by an IETF review. Each value is tracked with the 559 following qualities: 561 o Flag 563 o Description 564 o Defining RFC 566 9. Security Considerations 568 The options defined in this document are carried in the base message 569 objects as defined in [RFC6550]. The RPL control message options are 570 protected by the same security mechanisms that protect the base 571 messages. 573 Capabilities flag can reveal that the node has been upgraded or is 574 running a old feature set. This document assumes that the base 575 messages that carry these options are protected by RPL security 576 mechanisms and thus are not visible to a malicious node. 578 [TODO] implications of malicious attack involving setting the 579 capability flags. 581 10. References 583 10.1. Normative References 585 [I-D.ietf-roll-mopex] 586 Jadhav, R., Thubert, P., and M. Richardson, "Mode of 587 Operation extension", draft-ietf-roll-mopex-01 (work in 588 progress), June 2020. 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, 592 DOI 10.17487/RFC2119, March 1997, 593 . 595 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 596 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 597 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 598 Low-Power and Lossy Networks", RFC 6550, 599 DOI 10.17487/RFC6550, March 2012, 600 . 602 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 603 "IPv6 over Low-Power Wireless Personal Area Network 604 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 605 April 2017, . 607 10.2. Informative References 609 [I-D.ietf-lwig-nbr-mgmt-policy] 610 Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson, 611 "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig- 612 nbr-mgmt-policy-03 (work in progress), February 2019. 614 [I-D.ietf-roll-dao-projection] 615 Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated 616 routing state in RPL", draft-ietf-roll-dao-projection-11 617 (work in progress), September 2020. 619 [I-D.thubert-roll-turnon-rfc8138] 620 Thubert, P. and L. Zhao, "Configuration option for RFC 621 8138", draft-thubert-roll-turnon-rfc8138-03 (work in 622 progress), July 2019. 624 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 625 and D. Barthel, "Routing Metrics Used for Path Calculation 626 in Low-Power and Lossy Networks", RFC 6551, 627 DOI 10.17487/RFC6551, March 2012, 628 . 630 Appendix A. Capability Handshake Example 632 A.1. Query supported Cap Types 634 Root 6LR/6LN 635 | | 636 | CAPQ(seq=1, opts=nil) | 637 |---------------------------------->| 638 | | 639 | | 640 | CAPS(seq=1, opts={CapTypeList}) | 641 |<----------------------------------| 642 | | 644 Figure 8: Query supported Cap Types 646 CAPQ message with no CapTypeList Option results in the peer 647 responding with a CAPS message with CapTypeList Option indicating all 648 the capability set it supports. 650 A.2. Query specific Cap Set 651 Root 6LR/6LN 652 | | 653 | CAPQ(seq=2, | 654 | opts={CapTypeList=[Cap1, Cap2]})| 655 |---------------------------------->| 656 | | 657 | | 658 | CAPS(seq=2, | 659 | opts={Cap1=Cap1Value, | 660 | Cap2=Cap2Value}) | 661 |<----------------------------------| 662 | | 664 Figure 9: Query specific Cap Set 666 This flow indicates the case where the Root probes for specific 667 Capabilities of the peer node and the peer node responds with the 668 value of indicated Capability set. 670 A.3. CAPS with partial Cap Set 672 Root 6LR/6LN 673 | | 674 | CAPQ(seq=3, | 675 | opts={CapTypeList=[Cap1, Cap2, | 676 | Cap3, Cap4]})| 677 |---------------------------------->| 678 | | 679 | | 680 | CAPS(seq=3, | 681 | opts={Cap2=Cap2Value, | 682 | Cap3=Cap3Value, | 683 | CapTypeList=[Cap1,Cap4]})| 684 |<----------------------------------| 685 | | 687 Partial Capability Set handshake 689 Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4} 690 from the peer node. However the peer node does not support or does 691 not understand capability {cap1, cap4}. In this case the peer node 692 will respond back with value of Cap2 and Cap3 (which it understands) 693 and set the CapTypeList option with {Cap1, Cap4} type. 695 Authors' Addresses 697 Rahul Arvind Jadhav (editor) 698 Marathahalli 699 Bangalore, Karnataka 560037 700 India 702 Email: rahul.ietf@gmail.com 704 Pascal Thubert 705 Cisco Systems, Inc 706 Building D 707 45 Allee des Ormes - BP1200 708 MOUGINS - Sophia Antipolis 06254 709 France 711 Phone: +33 497 23 26 34 712 Email: pthubert@cisco.com 714 Michael Richardson 715 Sandelman Software Works 717 Email: mcr+ietf@sandelman.ca 719 Rabi Narayan Sahoo 720 Juniper 722 Email: rabinarayans0828@gmail.com