idnits 2.17.1 draft-ietf-roll-mopex-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6550]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 November 2021) is 892 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 Tech 4 Intended status: Standards Track P. Thubert 5 Expires: 13 May 2022 Cisco 6 M. Richardson 7 Sandelman Software Works 8 9 November 2021 10 Mode of Operation extension 11 draft-ietf-roll-mopex-04 13 Abstract 15 RPL allows different mode of operations which allows nodes to have a 16 consensus on the basic primitives that must be supported to join the 17 network. The MOP field in [RFC6550] is of 3 bits and is fast 18 depleting. This document extends the MOP for future use. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language and Terminology . . . . . . . . . . 3 55 2. Requirements for this document . . . . . . . . . . . . . . . 3 56 3. Extended MOP Control Message Option . . . . . . . . . . . . . 4 57 3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4 58 3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4 59 4. Extending RPL Control Options . . . . . . . . . . . . . . . . 4 60 5. Implementation Considerations . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6 64 7.2. New options: MOPex and Capabilities . . . . . . . . . . . 7 65 7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7 66 7.4. Change in RPL Control Option field . . . . . . . . . . . 7 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 RPL [RFC6550] specifies a proactive distance-vector based routing 76 scheme. The protocol creates a DAG-like structure that operates with 77 a given "Mode of Operation" (MOP) determining the minimum and 78 mandatory set of primitives to be supported by all the participating 79 nodes. 81 MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is 82 specific to the RPL Instance. The recipient of the DIO message can 83 join the specified network as a router only when it can support the 84 primitives as required by the mode of operation value. For example, 85 in the case of MOP=3 (Storing MOP with multicast support), the nodes 86 can join the network as routers only when they can handle the DAO 87 advertisements from the peers and manage routing tables. The 3-bit 88 value is already exhausted and requires replenishment. This document 89 introduces a mechanism to extend the mode of operation values. 91 This document further extends the RPL Control Option syntax to handle 92 generic flags. The primary aim of these flags is to define the 93 behavior of a node not supporting the given control type. If a node 94 does not support a given RPL Control Option, there are following 95 possibilities: 97 Strip off the option 99 Copy the option as-is 101 Ignore the message containing this option 103 Let the node join in only as a 6LN to this parent 105 1.1. Requirements Language and Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 MOP: Mode of Operation. Identifies the mode of operation of the RPL 112 Instance as administratively provisioned at and distributed by the 113 DODAG root. 115 MOPex: Extended MOP: This document extends the MOP values over a 116 bigger range. This extension of MOP is called MOPex. 118 DAO: DODAG Advertisement Object. An RPL message used to advertise 119 the target information to establish routing adjacencies. 121 DIO: DODAG Information Object. An RPL message initiated by the root 122 and used to advertise the network configuration information. 124 Current parent: Parent 6LR node before switching to the new path. 126 This document uses the terminology described in [RFC6550]. For the 127 sake of readability, all the known relevant terms are repeated in 128 this section. 130 2. Requirements for this document 132 Following are the requirements considered for this documents: 134 REQ1: MOP extension. The 3-bits MOP as defined in [RFC6550] is fast 135 depleting. An MOP extension needs to extend the possibility 136 of adding new MOPs in the future. 138 REQ2: Backwards compatibility. The new options and new fields in 139 the DIO message should be backward compatible i.e. if there 140 are nodes that support old MOPs they could still operate in 141 their RPL Instances. 143 3. Extended MOP Control Message Option 145 This document reserves the existing MOP value 7 to be used as an 146 extender. DIO messages with an MOP value of 7 MUST refer to the 147 Extended MOP (MOPex) option in the DIO message. 149 0 1 2 150 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 152 | Type = TODO | Opt Length | OP-value 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 155 Figure 1: Extended MOP Option 157 The option length value MUST be less than or equal to 2. An option 158 length value of zero is invalid and the implementation MUST silently 159 ignore the DIO on receiving a value of zero. 161 3.1. Handling MOPex 163 The MOPex option MUST be used only if the base DIO MOP is 7. If the 164 base DIO MOP is 7 and if the MOPex option is not present then the DIO 165 MUST be silently ignored. If the base DIO MOP is less than 7 then 166 MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex 167 option is present, then the implementation MUST use the final MOP 168 value from the MOPex. 170 Note that [RFC6550] allows a node that does not support the received 171 MOP to still join the network as a leaf node. This semantics 172 continues to be true even in the case of MOPex. 174 3.2. Use of values 0-6 in the MOPex option 176 The MOPex option could also be allowed to re-use the values 0-6, 177 which have been used for MOP so far. The use of current MOPs in 178 MOPex indicates that the MOP is supported with an extended set of 179 semantics e.g., the capability options [I-D.ietf-roll-capabilities]. 181 4. Extending RPL Control Options 183 Section 6.7.1 of RFC6550 explains the RPL Control Message Option 184 Generic Format. This document extends this format to following: 186 0 1 2 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- 189 |X| OptionType| Option Length |Opt Flags|J|I|C| Option Data 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- 192 Figure 2: Extended RPL Option Format 194 New fields in extended RPL Control Message Option Format: 196 'X' bit in Option Type: Value 1 indicates that this is an extended 197 option. If the 'X' flag is set, a 1-byte Option Flags follows the 198 Option Length field. 200 Option Length: 8-bit unsigned integer, representing the length in 201 octets of the option, not including the Option Type and Length 202 fields. Option Flags and variable length Option Data fields are 203 included in the length. 205 'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if 206 the Option Type is not understood. 208 'C' (Copy) bit in Option Flags: A node that does not understand 209 the Option Type MUST copy the Option while generating the 210 corresponding message. E.g., if a 6LR receives a DIO message with 211 an unknown Option with 'C' bit set and if the 6LR chooses to 212 accept this node as the preferred parent then the node MUST copy 213 this option in the subsequent DIO message it generates. 214 Alternatively, if the 'C' flag is unset the node MUST strip off 215 the option and process the message. 217 'I' (Ignore) bit in Option Flags: A node that does not understand 218 the Option Type MUST ignore this whole message if the 'I' bit is 219 set. If the 'I' bit is set then the value of 'J' and 'C' bits are 220 irrelevant and the message MUST be ignored. 222 Note that this format does not deprecate the previous format, it 223 simply extends it and the new format is applicable only when 2nd bit 224 ('X' flag) of the Option Type is set. Option Type 0x80 to 0xFF are 225 thus applicable only as extended options. 227 +=========+=========+===========================+ 228 | 'J' bit | 'C' bit | Handling | 229 +=========+=========+===========================+ 230 | 0 | 0 | Strip off the option, and | 231 | | | the node can join as 6LR | 232 +---------+---------+---------------------------+ 233 | 0 | 1 | Copy the option, and the | 234 | | | node can join as 6LR | 235 +---------+---------+---------------------------+ 236 | 1 | NA | Join as 6LN | 237 +---------+---------+---------------------------+ 239 Table 1: Option Flags handling 241 If a node receives an unknown Option without 'X' flag set then the 242 node MUST ignore the option and process the message. The option MUST 243 be treated as if J=0, C=0, I=0. 245 5. Implementation Considerations 247 In [RFC6550], it was possible to discard an unsupported DIO-MOP just 248 by inspecting the base message. With this document, the MOPex is a 249 different control message option and thus the discarding of the DIO 250 message can only happen after inspecting the message options. 252 6. Acknowledgements 254 Thank you Dominique Barthel for important review/feedback on 255 extending Control Options. 257 7. IANA Considerations 259 7.1. Mode of operation: MOPex 261 IANA is requested to assign a new Mode of Operation, named "MOPex" 262 for MOP extension under the RPL registry. The value of 7 is to be 263 assigned from the "Mode of Operation" space [RFC6550] 265 +=======+=============+===============+ 266 | Value | Description | Reference | 267 +=======+=============+===============+ 268 | 7 | MOPex | This document | 269 +-------+-------------+---------------+ 271 Table 2: Mode of Operation 273 7.2. New options: MOPex and Capabilities 275 A new entry is required for supporting new option "MOPex" in the "RPL 276 Control Message Options" space [RFC6550]. 278 +=======+=========+===============+ 279 | Value | Meaning | Reference | 280 +=======+=========+===============+ 281 | TBD1 | MOPex | This document | 282 +-------+---------+---------------+ 284 Table 3: New options 286 7.3. New Registry for Extended-MOP-value 288 IANA is requested to create a registry for the extended-MOP-value 289 (MOPex). This registry should be located in TODO. New MOPex values 290 may be allocated only by an IETF review. Currently no values are 291 defined by this document. Each value is tracked with the following 292 qualities: 294 * MOPex value 296 * Description 298 * Defining RFC 300 7.4. Change in RPL Control Option field 302 Section 4 of this document specifies MSB of the RPL Control Option to 303 be used as a bit to indicate RPL Extended Control Options. 305 IANA is requested to reduce the unassigned values range from 0x10 to 306 0x7f for RPL Control Options. 308 IANA is requested to create a new registry for RPL Extended Control 309 Options indicating values 0x80 to 0xff. New values may be allocated 310 only by an IETF Review. Each value is tracked with the following 311 qualities: 313 * Value 315 * Meaning 317 * Defining RFC 319 The value could be in the range of 0x80 to 0xff. 321 8. Security Considerations 323 The options defined in this document are carried in the base message 324 objects as defined in [RFC6550]. The RPL control message options are 325 protected by the same security mechanisms that protect the base 326 messages. 328 Capabilities flag can reveal that the node has been upgraded or is 329 running a old feature set. This document assumes that the base 330 messages that carry these options are protected by RPL security 331 mechanisms and thus are not visible to a malicious node. 333 9. References 335 9.1. Normative References 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, 339 DOI 10.17487/RFC2119, March 1997, 340 . 342 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 343 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 344 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 345 Low-Power and Lossy Networks", RFC 6550, 346 DOI 10.17487/RFC6550, March 2012, 347 . 349 9.2. Informative References 351 [I-D.ietf-roll-capabilities] 352 Jadhav, R. A., Thubert, P., Richardson, M., and R. N. 353 Sahoo, "RPL Capabilities", Work in Progress, Internet- 354 Draft, draft-ietf-roll-capabilities-09, 9 November 2021, 355 . 358 Authors' Addresses 360 Rahul Arvind Jadhav (editor) 361 Huawei Tech 362 Kundalahalli Village, Whitefield, 363 Bangalore 560037 364 Karnataka 365 India 367 Phone: +91-080-49160700 368 Email: rahul.ietf@gmail.com 369 Pascal Thubert 370 Cisco Systems, Inc 371 Building D 372 45 Allee des Ormes - BP1200 373 06254 MOUGINS - Sophia Antipolis 374 France 376 Phone: +33 497 23 26 34 377 Email: pthubert@cisco.com 379 Michael Richardson 380 Sandelman Software Works 382 Email: mcr+ietf@sandelman.ca