idnits 2.17.1 draft-rahul-mop-ext-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 7, 2019) is 1904 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. Jadhav, Ed. 3 Internet-Draft Huawei Tech 4 Intended status: Standards Track P. Thubert 5 Expires: August 11, 2019 Cisco 6 February 7, 2019 8 RPL Mode of Operation extension 9 draft-rahul-mop-ext-00 11 Abstract 13 RPL allows different mode of operations which allows nodes to have a 14 consensus on the basic primitives that must be supported to join the 15 network. The MOP field in RFC6550 is of 3 bits and is fast 16 depleting. This document extends the MOP field specification and 17 adds a notion of capabilities using which the nodes can further 18 advertise their support for, possibly optional, capabilities. 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 August 11, 2019. 37 Copyright Notice 39 Copyright (c) 2019 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. Final MOP . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1. Capability Control Message Option . . . . . . . . . . . . 5 61 4.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 62 5. Implementations Consideration . . . . . . . . . . . . . . . . 5 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 68 9.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Appendix A. Capability Handshake Example . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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. 88 1.1. Requirements Language and Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 94 MOP: Mode of Operation. Identifies the mode of operation of the RPL 95 Instance as administratively provisioned at and distributed by the 96 DODAG root. 98 DAO: DODAG Advertisement Object. An RPL message used to advertise 99 the target information in order to establish routing adjacencies. 101 DIO: DODAG Information Object. An RPL message initiated by the root 102 and is used to advertise the network configuration information. 104 Current parent: Parent 6LR node before switching to the new path. 106 NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. 108 MOPex: MOP extension as defined in this document. 110 This document uses terminology described in [RFC6550]. For the sake 111 of readability all the known relevant terms are repeated in this 112 section. 114 2. Requirements for this document 116 Following are the requirements considered for this documents: 118 REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An 119 MOP extension needs to extend the possibility of adding new 120 MOPs in the future. 122 REQ2: Optional capabilities handshake. Capabilities are features, 123 possibly optional, which could be handshaked between the nodes 124 and the root within an RPL Instance. 126 REQ3: Backwards compatibility. The new options and new fields in 127 the DIO message should be backward compatible i.e. if there 128 are nodes which support old MOPs they could still operate in 129 their own instances. 131 REQ4: Capabilities handshake could be optionally added with existing 132 MOPs. Capabilities been optional in nature could be put to 133 use with existing MOPs. Capabilities and MOP-extension is 134 mutually independent i.e. a DIO can have a capabilities 135 option, MOP-extension option or both in the same message. 137 3. Extended MOP Control Message Option 139 This document reserves existing MOP value 7 to be used as an 140 extender. DIO messages with MOP value of 7 MUST refer to the 141 Extended MOP (MOPex) option in the DIO message. If the MOPex option 142 is absent in the DIO whose MOP is 7, then the DIO message MUST be 143 silently discarded. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type = TODO | Extended-MOP-value | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: Extended MOP Option 153 3.1. Final MOP 155 An implementation supporting this document MUST calculate the final 156 MOP value as the sum of base MOP (as supported in Section 6.3.1. of 157 [RFC6550]) plus the MOPex value. Thus if the MOPex value is 0, it 158 means the final MOP is 7 since the base MOP in this case will be set 159 to 7. 161 +----------+-------+-----------+ 162 | Base MOP | MOPex | Final MOP | 163 +----------+-------+-----------+ 164 | 0 | NA | 0 | 165 | 1 | NA | 1 | 166 | : | : | : | 167 | 6 | NA | 6 | 168 | 7 | 0 | 7 | 169 | 7 | 1 | 8 | 170 | 7 | 2 | 9 | 171 | : | : | : | 172 +----------+-------+-----------+ 174 Table 1: Final MOP calculation 176 4. Capabilities 178 Currently RPL specification does not have a mechanism whereby a node 179 can signal the set of features that are available on its end. Such a 180 mechanism could help the root to advertise its capabilities and in 181 response also determine some advanced information about the 182 capabilities of the joining nodes. The Mode of Operation field in 183 RPL mandates the operational requirement and does not allow loose 184 coupling of additional capabilities. This document defines 185 Capabilities as additional features which could be supported by the 186 nodes and handshaked as part of RPL signaling. Capabilities are 187 embedded as RPL control message option as defined Section 6.7 of 188 [RFC6550] in the base messages of DIO, DAO and DAO-ACK signaling. 190 4.1. Capability Control Message Option 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type = TODO | Capabilities Flags | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 2: Capabilities Option 200 There are no capability flags defined by this document. 202 4.2. Capabilities Handshake 204 The root node could advertise the set of capabilities it supports in 205 the DIO message. A node could take advantage of the knowledge that 206 the root supports a particular capability. Similarly a node could 207 advertise its capabilities in the DAO message using the capability 208 control message option defined in this document. Capabilities 209 advertised by non-root nodes are strictly a subset of the 210 capabilities advertised by the root. 212 In storing MOP, the DAO message from the 6LR could contain multiple 213 target options. The targets of the capabilities option are indicated 214 by one or more Target options that precede the Capabilties Option. 215 This handling is similar to the Transit Information Option as 216 supported in Section 6.7.8. of [RFC6550]. 218 5. Implementations Consideration 220 The MOP-extension could cause 3-byte increase in memory in the RPL- 221 Instance. The MOP field in the RPL-Instance needs to be upgraded to 222 a 32 bit integer. 224 [RFC6550], it was possible to discard an unsupported DIO-MOP just by 225 inspecting the base message. With this document, the MOPex is a 226 different control message option and thus the discarding of the DIO 227 message could happen after inspecting the message options. 229 A node in storing MOP could independently construct a DAO message 230 with target options containing its child/sub-childs. Thus with 231 capabilities it needs to reconstruct the capabilities field as well. 232 This may result in increase in the memory requirement on per routing- 233 entry basis. 235 6. Acknowledgements 237 Thanks 239 7. IANA Considerations 241 IANA is requested to allocate MOP field value 0x7 in the DIO base 242 object defined in RPL [RFC6550] section 6.3.1 for MOP extension. 244 TODO 246 8. Security Considerations 248 The options defined in this document are carried in the base message 249 objects as defined in [RFC6550]. The RPL control message options are 250 protected by the same security mechanisms that protect the base 251 messages. 253 Capabilities flag can reveal that the node has been upgraded or is 254 running a old feature set. This document assumes that the base 255 messages that carry these options are protected by RPL security 256 mechanisms and thus are not visible to a malicious node. 258 9. References 260 9.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 9.2. Informative References 269 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 270 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 271 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 272 Low-Power and Lossy Networks", RFC 6550, 273 DOI 10.17487/RFC6550, March 2012, 274 . 276 Appendix A. Capability Handshake Example 277 Root 6LR 6LN 278 | | | 279 | DIO(CS1) | | 280 |------------>| DIO(CS1) | 281 | |----------->| 282 | | | 283 | | DAO(CS2) | 284 | |<-----------| 285 | DAO(CS2) | | 286 |<------------| | 287 | | | 288 CS: Capabilities Set 289 CS1: Capabilities set advertised by root 290 CS2: Capabilities set advertised by node. CS2 is a subset of CS1. 292 Figure 3: Capabilities Option 294 Authors' Addresses 296 Rahul Arvind Jadhav (editor) 297 Huawei Tech 298 Kundalahalli Village, Whitefield, 299 Bangalore, Karnataka 560037 300 India 302 Phone: +91-080-49160700 303 Email: rahul.ietf@gmail.com 305 Pascal Thubert 306 Cisco Systems, Inc 307 Building D 308 45 Allee des Ormes - BP1200 309 MOUGINS - Sophia Antipolis 06254 310 France 312 Phone: +33 497 23 26 34 313 Email: pthubert@cisco.com