idnits 2.17.1 draft-jadhav-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 (March 6, 2020) is 1505 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-00 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: September 7, 2020 Cisco 6 M. Richardson 7 Sandelman Software Works 8 March 6, 2020 10 Mode of Operation extension 11 draft-jadhav-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 September 7, 2020. 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 . . . . . . . . . . 2 56 2. Requirements for this document . . . . . . . . . . . . . . . 3 57 3. Extended MOP Control Message Option . . . . . . . . . . . . . 3 58 3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4 60 4. Implementation Considerations . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 4 64 6.2. New options: MOPex and Capabilities . . . . . . . . . . . 5 65 6.3. New Registry for Extended-MOP-value . . . . . . . . . . . 5 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 8.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 RPL [RFC6550] specifies a proactive distance-vector based routing 75 scheme. The protocol creates a DAG-like structure which operates 76 with a given "Mode of Operation" (MOP) determining the minimal and 77 mandatory set of primitives to be supported by all the participating 78 nodes. 80 MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is 81 specific to the RPL Instance. The receipient of the DIO message can 82 join the specified network as a router only when it can support the 83 primitives as required by the mode of operation value. For example, 84 in case of MOP=3 (Storing MOP with multicast support) the nodes can 85 join the network as routers only when they can handle the DAO 86 advertisements from the peers and manage routing tables. The 3-bit 87 value is already exhausted and requires replenishment. This document 88 introduces a mechanism to extend mode of operation values. 90 1.1. Requirements Language and Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119 [RFC2119]. 96 MOP: Mode of Operation. Identifies the mode of operation of the RPL 97 Instance as administratively provisioned at and distributed by the 98 DODAG root. 100 MOPex: Extended MOP: This document extends the MOP values over a 101 bigger range. This extension of MOP is called MOPex. 103 DAO: DODAG Advertisement Object. An RPL message used to advertise 104 the target information in order to establish routing adjacencies. 106 DIO: DODAG Information Object. An RPL message initiated by the root 107 and is used to advertise the network configuration information. 109 Current parent: Parent 6LR node before switching to the new path. 111 This document uses terminology described in [RFC6550]. For the sake 112 of readability all the known relevant terms are repeated in this 113 section. 115 2. Requirements for this document 117 Following are the requirements considered for this documents: 119 REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An 120 MOP extension needs to extend the possibility of adding new 121 MOPs in the future. 123 REQ2: Backwards compatibility. The new options and new fields in 124 the DIO message should be backward compatible i.e. if there 125 are nodes which support old MOPs they could still operate in 126 their own instances. 128 3. Extended MOP Control Message Option 130 This document reserves existing MOP value 7 to be used as an 131 extender. DIO messages with MOP value of 7 may refer to the Extended 132 MOP (MOPex) option in the DIO message. 134 0 1 2 135 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 137 | Type = TODO | Opt Length | OP-value 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- 140 Figure 1: Extended MOP Option 142 The option length value MUST be less than or equal to 2. An option 143 length value of zero is invalid and the implementation MUST silently 144 ignore the DIO on receiving a value of zero. 146 3.1. Handling MOPex 148 The MOPex option MUST be used only if the base DIO MOP is 7. If the 149 base DIO MOP is 7 and if the MOPex option is not present then the DIO 150 MUST be silently ignored. If the base DIO MOP is less than 7 then 151 MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex 152 option is present, then the implementation MUST use the final MOP 153 value from the MOPex. 155 Note that [RFC6550] allows the node who does not support the received 156 MOP to still join the network as a leaf node. This semantic 157 continues to be true even in case of MOPex. 159 3.2. Use of values 0-6 in the MOPex option 161 The MOPex option could also be allowed to re-use the values 0-6, 162 which have been used for MOP so far. The use of current MOPs in 163 MOPex indicates that the MOP is supported with extended set of 164 semantics for e.g., the capability options 165 [I-D.ietf-roll-capabilities]. 167 4. Implementation Considerations 169 [RFC6550], it was possible to discard an unsupported DIO-MOP just by 170 inspecting the base message. With this document, the MOPex is a 171 different control message option and thus the discarding of the DIO 172 message could happen after inspecting the message options. 174 5. Acknowledgements 176 6. IANA Considerations 178 6.1. Mode of operation: MOPex 180 IANA is requested to assign a new Mode of Operation, named "MOPex" 181 for MOP extension under the RPL registry. The value of 7 is to be 182 assigned from the "Mode of Operation" space [RFC6550] 183 +-------+-------------+---------------+ 184 | Value | Description | Reference | 185 +-------+-------------+---------------+ 186 | 7 | MOPex | This document | 187 +-------+-------------+---------------+ 189 Mode of Operation 191 6.2. New options: MOPex and Capabilities 193 A new entry is required for supporting new option "MOPex" in the "RPL 194 Control Message Options" space [RFC6550]. 196 +-------+---------+---------------+ 197 | Value | Meaning | Reference | 198 +-------+---------+---------------+ 199 | TBD1 | MOPex | This document | 200 +-------+---------+---------------+ 202 New options 204 6.3. New Registry for Extended-MOP-value 206 IANA is requested to create a registry for the extended-MOP-value 207 (MOPex). This registry should be located in TODO. New MOPex values 208 may be allocated only by an IETF review. Currently no values are 209 defined by this document. Each value is tracked with the following 210 qualities: 212 o MOPex value 214 o Description 216 o Defining RFC 218 7. Security Considerations 220 The options defined in this document are carried in the base message 221 objects as defined in [RFC6550]. The RPL control message options are 222 protected by the same security mechanisms that protect the base 223 messages. 225 Capabilities flag can reveal that the node has been upgraded or is 226 running a old feature set. This document assumes that the base 227 messages that carry these options are protected by RPL security 228 mechanisms and thus are not visible to a malicious node. 230 8. References 232 8.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, 236 DOI 10.17487/RFC2119, March 1997, 237 . 239 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 240 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 241 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 242 Low-Power and Lossy Networks", RFC 6550, 243 DOI 10.17487/RFC6550, March 2012, 244 . 246 8.2. Informative References 248 [I-D.ietf-roll-capabilities] 249 Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo, 250 "RPL Capabilities", draft-ietf-roll-capabilities-00 (work 251 in progress), February 2020. 253 Authors' Addresses 255 Rahul Arvind Jadhav (editor) 256 Huawei Tech 257 Kundalahalli Village, Whitefield, 258 Bangalore, Karnataka 560037 259 India 261 Phone: +91-080-49160700 262 Email: rahul.ietf@gmail.com 264 Pascal Thubert 265 Cisco Systems, Inc 266 Building D 267 45 Allee des Ormes - BP1200 268 MOUGINS - Sophia Antipolis 06254 269 France 271 Phone: +33 497 23 26 34 272 Email: pthubert@cisco.com 273 Michael Richardson 274 Sandelman Software Works 276 Email: mcr+ietf@sandelman.ca