ROLL R. Jadhav, Ed. Internet-Draft Huawei Tech Intended status: Standards Track P. Thubert Expires: May 21, 2020 Cisco M. Richardson Sandelman Software Works November 18, 2019 Mode of Operation extension draft-jadhav-roll-mopex-00 Abstract RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network. The MOP field in RFC6550 is of 3 bits and is fast depleting. This document extends the MOP for future use. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 21, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Jadhav, et al. Expires May 21, 2020 [Page 1] Internet-Draft MOP extension November 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language and Terminology . . . . . . . . . . 2 2. Requirements for this document . . . . . . . . . . . . . . . 3 3. Extended MOP Control Message Option . . . . . . . . . . . . . 3 3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4 3.2. Use of MOPex for MOP less than equal to 6 . . . . . . . . 4 4. Implementation Considerations . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 4 6.2. New options: MOPex and Capabilities . . . . . . . . . . . 5 6.3. New Registry for Extended-MOP-value . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction RPL [RFC6550] specifies a proactive distance-vector based routing scheme. The protocol creates a DAG-like structure which operates with a given "Mode of Operation" (MOP) determining the minimal and mandatory set of primitives to be supported by all the participating nodes. MOP as per [RFC6550] is a 3-bit value carried in DIO messages and is specific to the RPL Instance. The receipient of the DIO message can join the specified network as a router only when it can support the primitives as required by the mode of operation value. For example, in case of MOP=3 (Storing MOP with multicast support) the nodes can join the network as routers only when they can handle the DAO advertisements from the peers and manage routing tables. The 3-bit value is already exhausted and requires replenishment. This document introduces a mechanism to extend mode of operation values. 1.1. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Jadhav, et al. Expires May 21, 2020 [Page 2] Internet-Draft MOP extension November 2019 MOP: Mode of Operation. Identifies the mode of operation of the RPL Instance as administratively provisioned at and distributed by the DODAG root. MOPex: Extended MOP: This document extends the MOP values over a bigger range. This extension of MOP is called MOPex. DAO: DODAG Advertisement Object. An RPL message used to advertise the target information in order to establish routing adjacencies. DIO: DODAG Information Object. An RPL message initiated by the root and is used to advertise the network configuration information. Current parent: Parent 6LR node before switching to the new path. This document uses terminology described in [RFC6550]. For the sake of readability all the known relevant terms are repeated in this section. 2. Requirements for this document Following are the requirements considered for this documents: REQ1: MOP extension. Current MOP of 3-bit is fast depleting. An MOP extension needs to extend the possibility of adding new MOPs in the future. REQ2: Backwards compatibility. The new options and new fields in the DIO message should be backward compatible i.e. if there are nodes which support old MOPs they could still operate in their own instances. 3. Extended MOP Control Message Option This document reserves existing MOP value 7 to be used as an extender. DIO messages with MOP value of 7 may refer to the Extended MOP (MOPex) option in the DIO message. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- | Type = TODO | Opt Length | OP-value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--------------- Figure 1: Extended MOP Option Jadhav, et al. Expires May 21, 2020 [Page 3] Internet-Draft MOP extension November 2019 The option length value MUST be less than or equal to 2. An option length value of zero is invalid and the implementation MUST silently ignore the DIO on receiving a value of zero. 3.1. Handling MOPex The MOPex option MUST be used only if the base DIO MOP is 7. If the base DIO MOP is 7 and if the MOPex option is not present then the DIO MUST be silently ignored. If the base DIO MOP is less than 7 then MOPex MUST NOT be used. In case the base MOP is 7 and if the MOPex option is present, then the implementation MUST use the final MOP value from the MOPex. Note that [RFC6550] allows the node who does not support the received MOP to still join the network as a leaf node. This semantic continues to be true even in case of MOPex. 3.2. Use of MOPex for MOP less than equal to 6 The current set of MOPs (values 0-6) could also be used in MOPex. The use of current MOPs in MOPex indicates that the MOP is supported with extended set of semantics for e.g., the capability options [I-D.ietf-roll-mopex-cap]. 4. Implementation Considerations [RFC6550], it was possible to discard an unsupported DIO-MOP just by inspecting the base message. With this document, the MOPex is a different control message option and thus the discarding of the DIO message could happen after inspecting the message options. 5. Acknowledgements 6. IANA Considerations 6.1. Mode of operation: MOPex IANA is requested to assign a new Mode of Operation, named "MOPex" for MOP extension under the RPL registry. The value of 7 is to be assigned from the "Mode of Operation" space [RFC6550] +-------+-------------+---------------+ | Value | Description | Reference | +-------+-------------+---------------+ | 7 | MOPex | This document | +-------+-------------+---------------+ Mode of Operation Jadhav, et al. Expires May 21, 2020 [Page 4] Internet-Draft MOP extension November 2019 6.2. New options: MOPex and Capabilities A new entry is required for supporting new option "MOPex" in the "RPL Control Message Options" space [RFC6550]. +-------+---------+---------------+ | Value | Meaning | Reference | +-------+---------+---------------+ | TBD1 | MOPex | This document | +-------+---------+---------------+ New options 6.3. New Registry for Extended-MOP-value IANA is requested to create a registry for the extended-MOP-value (MOPex). This registry should be located in TODO. New MOPex values may be allocated only by an IETF review. Currently no values are defined by this document. Each value is tracked with the following qualities: o MOPex value o Description o Defining RFC 7. Security Considerations The options defined in this document are carried in the base message objects as defined in [RFC6550]. The RPL control message options are protected by the same security mechanisms that protect the base messages. Capabilities flag can reveal that the node has been upgraded or is running a old feature set. This document assumes that the base messages that carry these options are protected by RPL security mechanisms and thus are not visible to a malicious node. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Jadhav, et al. Expires May 21, 2020 [Page 5] Internet-Draft MOP extension November 2019 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . 8.2. Informative References [I-D.ietf-roll-mopex-cap] Jadhav, R., Thubert, P., and M. Richardson, "Mode of Operation extension and Capabilities", draft-ietf-roll- mopex-cap-01 (work in progress), November 2019. Authors' Addresses Rahul Arvind Jadhav (editor) Huawei Tech Kundalahalli Village, Whitefield, Bangalore, Karnataka 560037 India Phone: +91-080-49160700 Email: rahul.ietf@gmail.com Pascal Thubert Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 France Phone: +33 497 23 26 34 Email: pthubert@cisco.com Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca Jadhav, et al. Expires May 21, 2020 [Page 6]