idnits 2.17.00 (12 Aug 2021) /tmp/idnits35606/draft-ietf-roll-mopex-02.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 (September 29, 2020) is 599 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) == Outdated reference: A later version (-09) exists of draft-ietf-roll-capabilities-07 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL R. Jadhav, Ed. 3 Internet-Draft Huawei Tech 4 Intended status: Standards Track P. Thubert 5 Expires: April 2, 2021 Cisco 6 M. Richardson 7 Sandelman Software Works 8 September 29, 2020 10 Mode of Operation extension 11 draft-ietf-roll-mopex-02 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 April 2, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language and Terminology . . . . . . . . . . 3 56 2. Requirements for this document . . . . . . . . . . . . . . . 3 57 3. Extended MOP Control Message Option . . . . . . . . . . . . . 4 58 3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4 60 4. Extending RPL Control Options . . . . . . . . . . . . . . . . 4 61 5. Implementation Considerations . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 6 65 7.2. New options: MOPex and Capabilities . . . . . . . . . . . 6 66 7.3. New Registry for Extended-MOP-value . . . . . . . . . . . 7 67 7.4. Change in RPL Control Option field . . . . . . . . . . . 7 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 RPL [RFC6550] specifies a proactive distance-vector based routing 77 scheme. The protocol creates a DAG-like structure which operates 78 with a given "Mode of Operation" (MOP) determining the minimal and 79 mandatory set of primitives to be supported by all the participating 80 nodes. 82 MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is 83 specific to the RPL Instance. The recipient of the DIO message can 84 join the specified network as a router only when it can support the 85 primitives as required by the mode of operation value. For example, 86 in case of MOP=3 (Storing MOP with multicast support) the nodes can 87 join the network as routers only when they can handle the DAO 88 advertisements from the peers and manage routing tables. The 3-bit 89 value is already exhausted and requires replenishment. This document 90 introduces a mechanism to extend mode of operation values. 92 This document further extends the RPL Control Option syntax to handle 93 generic flags. The primary aim of these flags is to define the 94 behaviour of a node not supporting the given control type. If a node 95 does not support a given RPL Control Option, there are following 96 possibilities: 98 Strip off the option 100 Copy the option as-is 102 Ignore the message containing this option 104 Let the node join in only as a 6LN to this parent 106 1.1. Requirements Language and Terminology 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 MOP: Mode of Operation. Identifies the mode of operation of the RPL 113 Instance as administratively provisioned at and distributed by the 114 DODAG root. 116 MOPex: Extended MOP: This document extends the MOP values over a 117 bigger range. This extension of MOP is called MOPex. 119 DAO: DODAG Advertisement Object. An RPL message used to advertise 120 the target information in order to establish routing adjacencies. 122 DIO: DODAG Information Object. An RPL message initiated by the root 123 and used to advertise the network configuration information. 125 Current parent: Parent 6LR node before switching to the new path. 127 This document uses terminology described in [RFC6550]. For the sake 128 of readability all the known relevant terms are repeated in this 129 section. 131 2. Requirements for this document 133 Following are the requirements considered for this documents: 135 REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An 136 MOP extension needs to extend the possibility of adding new 137 MOPs in the future. 139 REQ2: Backwards compatibility. The new options and new fields in 140 the DIO message should be backward compatible i.e. if there 141 are nodes which support old MOPs they could still operate in 142 their own RPL Instances. 144 3. Extended MOP Control Message Option 146 This document reserves existing MOP value 7 to be used as an 147 extender. DIO messages with MOP value of 7 may refer to the Extended 148 MOP (MOPex) option in the DIO message. 150 0 1 2 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 153 | Type = TODO | Opt Length | OP-value 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 156 Figure 1: Extended MOP Option 158 The option length value MUST be less than or equal to 2. An option 159 length value of zero is invalid and the implementation MUST silently 160 ignore the DIO on receiving a value of zero. 162 3.1. Handling MOPex 164 The MOPex option MUST be used only if the base DIO MOP is 7. If the 165 base DIO MOP is 7 and if the MOPex option is not present then the DIO 166 MUST be silently ignored. If the base DIO MOP is less than 7 then 167 MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex 168 option is present, then the implementation MUST use the final MOP 169 value from the MOPex. 171 Note that [RFC6550] allows a node that does not support the received 172 MOP to still join the network as a leaf node. This semantics 173 continues to be true even in case of MOPex. 175 3.2. Use of values 0-6 in the MOPex option 177 The MOPex option could also be allowed to re-use the values 0-6, 178 which have been used for MOP so far. The use of current MOPs in 179 MOPex indicates that the MOP is supported with extended set of 180 semantics for e.g., the capability options 181 [I-D.ietf-roll-capabilities]. 183 4. Extending RPL Control Options 185 Section 6.7.1 of RFC6550 explains the RPL Control Message Option 186 Generic Format. This document extends this format to following: 188 0 1 2 189 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- 191 |X| OptionType| Option Length |Opt Flags|J|I|C| Option Data 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------- 194 Figure 2: Extended RPL Option Format 196 New fields in extended RPL Control Message Option Format: 198 'X' bit in Option Type: Value 1 indicates that this is an extended 199 option. If the 'X' flag is set, a 1 byte Option Flags follows the 200 Option Length field. 202 Option Length: 8-bit unsigned integer, representing the length in 203 octets of the option, not including the Option Type and Length 204 fields. Option Flags and variable length Option Data fields are 205 included in the length. 207 'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if 208 the Option Type is not understood. 210 'C' (Copy) bit in Option Flags: A node that does not understand 211 the Option Type MUST copy the Option while generating the 212 corresponding message. For e.g., if a 6LR receives a DIO message 213 with an unknown Option with 'C' bit set and if the 6LR choses to 214 accept this node as the preferred parent then the node MUST copy 215 this option in the subsequent DIO message it generates. 216 Alternatively, if the 'C' flag is unset the node MUST strip off 217 the option and process the message. 219 'I' (Ignore) bit in Option Flags: A node that does not understand 220 the Option Type MUST ignore this whole message if the 'I' bit is 221 set. If 'I' bit is set than the value of 'J' and 'C' bits are 222 irrelevant and the message MUST be ignored. 224 Note that this format does not deprecate the previous format, it 225 simply extends it and the new format is applicable only when 2nd bit 226 ('X' flag) of the Option Type is set. Option Type 0x80 to 0xFF are 227 thus applicable only as extended options. 229 +---------+---------+-----------------------------------------------+ 230 | 'J' bit | 'C' bit | Handling | 231 +---------+---------+-----------------------------------------------+ 232 | 0 | 0 | Strip off the option, and the node can join | 233 | | | as 6LR | 234 | 0 | 1 | Copy the option, and the node can join as 6LR | 235 | 1 | NA | Join as 6LN | 236 +---------+---------+-----------------------------------------------+ 238 Table 1: Option Flags handling 240 If a node receives an unknown Option without 'X' flag set then the 241 node MUST ignore the option and process the message. The option MUST 242 be treated as if J=0, C=0, I=0. 244 5. Implementation Considerations 246 In [RFC6550], it was possible to discard an unsupported DIO-MOP just 247 by inspecting the base message. With this document, the MOPex is a 248 different control message option and thus the discarding of the DIO 249 message can only happen after inspecting the message options. 251 6. Acknowledgements 253 Thank you Dominique Barthel for important review/feedback on 254 extending Control Options. 256 7. IANA Considerations 258 7.1. Mode of operation: MOPex 260 IANA is requested to assign a new Mode of Operation, named "MOPex" 261 for MOP extension under the RPL registry. The value of 7 is to be 262 assigned from the "Mode of Operation" space [RFC6550] 264 +-------+-------------+---------------+ 265 | Value | Description | Reference | 266 +-------+-------------+---------------+ 267 | 7 | MOPex | This document | 268 +-------+-------------+---------------+ 270 Mode of Operation 272 7.2. New options: MOPex and Capabilities 274 A new entry is required for supporting new option "MOPex" in the "RPL 275 Control Message Options" space [RFC6550]. 277 +-------+---------+---------------+ 278 | Value | Meaning | Reference | 279 +-------+---------+---------------+ 280 | TBD1 | MOPex | This document | 281 +-------+---------+---------------+ 283 New options 285 7.3. New Registry for Extended-MOP-value 287 IANA is requested to create a registry for the extended-MOP-value 288 (MOPex). This registry should be located in TODO. New MOPex values 289 may be allocated only by an IETF review. Currently no values are 290 defined by this document. Each value is tracked with the following 291 qualities: 293 o MOPex value 295 o Description 297 o Defining RFC 299 7.4. Change in RPL Control Option field 301 Section 4 of this document specifies MSB of the RPL Control Option to 302 be used as a bit to indicate RPL Extended Control Options. 304 IANA is requested to reduce the unassigned values range from 0x10 to 305 0x7f for RPL Control Options. 307 IANA is requested to create a new registry for RPL Extended Control 308 Options indicating values 0x80 to 0xff. New values may be allocated 309 only by an IETF Review. Each value is tracked with the following 310 qualities: 312 o Value 314 o Meaning 316 o Defining RFC 318 The value could be in the range of 0x80 to 0xff. 320 8. Security Considerations 322 The options defined in this document are carried in the base message 323 objects as defined in [RFC6550]. The RPL control message options are 324 protected by the same security mechanisms that protect the base 325 messages. 327 Capabilities flag can reveal that the node has been upgraded or is 328 running a old feature set. This document assumes that the base 329 messages that carry these options are protected by RPL security 330 mechanisms and thus are not visible to a malicious node. 332 9. References 334 9.1. Normative References 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, 338 DOI 10.17487/RFC2119, March 1997, 339 . 341 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 342 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 343 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 344 Low-Power and Lossy Networks", RFC 6550, 345 DOI 10.17487/RFC6550, March 2012, 346 . 348 9.2. Informative References 350 [I-D.ietf-roll-capabilities] 351 Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo, 352 "RPL Capabilities", draft-ietf-roll-capabilities-07 (work 353 in progress), September 2020. 355 Authors' Addresses 357 Rahul Arvind Jadhav (editor) 358 Huawei Tech 359 Kundalahalli Village, Whitefield, 360 Bangalore, Karnataka 560037 361 India 363 Phone: +91-080-49160700 364 Email: rahul.ietf@gmail.com 365 Pascal Thubert 366 Cisco Systems, Inc 367 Building D 368 45 Allee des Ormes - BP1200 369 MOUGINS - Sophia Antipolis 06254 370 France 372 Phone: +33 497 23 26 34 373 Email: pthubert@cisco.com 375 Michael Richardson 376 Sandelman Software Works 378 Email: mcr+ietf@sandelman.ca