ROLL                                                      R. Jadhav, Ed.
Internet-Draft                                               Huawei Tech
Intended status: Standards Track                              P. Thubert
Expires: October 2, 2021                                           Cisco
                                                           M. Richardson
                                                Sandelman Software Works
                                                          March 31, 2021


                      Mode of Operation extension
                        draft-ietf-roll-mopex-03

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 October 2, 2021.

Copyright Notice

   Copyright (c) 2021 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 October 2, 2021                [Page 1]


Internet-Draft                MOP extension                   March 2021


   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 . . . . . . . . . .   3
   2.  Requirements for this document  . . . . . . . . . . . . . . .   3
   3.  Extended MOP Control Message Option . . . . . . . . . . . . .   4
     3.1.  Handling MOPex  . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Use of values 0-6 in the MOPex option . . . . . . . . . .   4
   4.  Extending RPL Control Options . . . . . . . . . . . . . . . .   4
   5.  Implementation Considerations . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Mode of operation: MOPex  . . . . . . . . . . . . . . . .   6
     7.2.  New options: MOPex and Capabilities . . . . . . . . . . .   6
     7.3.  New Registry for Extended-MOP-value . . . . . . . . . . .   7
     7.4.  Change in RPL Control Option field  . . . . . . . . . . .   7
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   RPL [RFC6550] specifies a proactive distance-vector based routing
   scheme.  The protocol creates a DAG-like structure that operates with
   a given "Mode of Operation" (MOP) determining the minimum 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 recipient 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 the 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 the mode of operation values.

   This document further extends the RPL Control Option syntax to handle
   generic flags.  The primary aim of these flags is to define the
   behavior of a node not supporting the given control type.  If a node
   does not support a given RPL Control Option, there are following
   possibilities:



Jadhav, et al.           Expires October 2, 2021                [Page 2]


Internet-Draft                MOP extension                   March 2021


      Strip off the option

      Copy the option as-is

      Ignore the message containing this option

      Let the node join in only as a 6LN to this parent

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].

   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 to establish routing adjacencies.

   DIO: DODAG Information Object.  An RPL message initiated by the root
   and used to advertise the network configuration information.

   Current parent: Parent 6LR node before switching to the new path.

   This document uses the 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.  The 3-bits MOP as defined in [RFC6550] 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 that support old MOPs they could still operate in
          their RPL Instances.






Jadhav, et al.           Expires October 2, 2021                [Page 3]


Internet-Draft                MOP extension                   March 2021


3.  Extended MOP Control Message Option

   This document reserves the existing MOP value 7 to be used as an
   extender.  DIO messages with an MOP value of 7 MUST 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

   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 a node that does not support the received
   MOP to still join the network as a leaf node.  This semantics
   continues to be true even in the case of MOPex.

3.2.  Use of values 0-6 in the MOPex option

   The MOPex option could also be allowed to re-use the values 0-6,
   which have been used for MOP so far.  The use of current MOPs in
   MOPex indicates that the MOP is supported with an extended set of
   semantics e.g., the capability options [I-D.ietf-roll-capabilities].

4.  Extending RPL Control Options

   Section 6.7.1 of RFC6550 explains the RPL Control Message Option
   Generic Format.  This document extends this format to following:









Jadhav, et al.           Expires October 2, 2021                [Page 4]


Internet-Draft                MOP extension                   March 2021


        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
       |X|   OptionType| Option Length |Opt Flags|J|I|C| Option Data
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------

                   Figure 2: Extended RPL Option Format

   New fields in extended RPL Control Message Option Format:

      'X' bit in Option Type: Value 1 indicates that this is an extended
      option.  If the 'X' flag is set, a 1-byte Option Flags follows the
      Option Length field.

      Option Length: 8-bit unsigned integer, representing the length in
      octets of the option, not including the Option Type and Length
      fields.  Option Flags and variable length Option Data fields are
      included in the length.

      'J' (Join) bit in Option Flags: A node MUST join only as a 6LN if
      the Option Type is not understood.

      'C' (Copy) bit in Option Flags: A node that does not understand
      the Option Type MUST copy the Option while generating the
      corresponding message.  E.g., if a 6LR receives a DIO message with
      an unknown Option with 'C' bit set and if the 6LR chooses to
      accept this node as the preferred parent then the node MUST copy
      this option in the subsequent DIO message it generates.
      Alternatively, if the 'C' flag is unset the node MUST strip off
      the option and process the message.

      'I' (Ignore) bit in Option Flags: A node that does not understand
      the Option Type MUST ignore this whole message if the 'I' bit is
      set.  If the 'I' bit is set then the value of 'J' and 'C' bits are
      irrelevant and the message MUST be ignored.

   Note that this format does not deprecate the previous format, it
   simply extends it and the new format is applicable only when 2nd bit
   ('X' flag) of the Option Type is set.  Option Type 0x80 to 0xFF are
   thus applicable only as extended options.











Jadhav, et al.           Expires October 2, 2021                [Page 5]


Internet-Draft                MOP extension                   March 2021


   +---------+---------+-----------------------------------------------+
   | 'J' bit | 'C' bit |                    Handling                   |
   +---------+---------+-----------------------------------------------+
   |    0    |    0    |  Strip off the option, and the node can join  |
   |         |         |                     as 6LR                    |
   |    0    |    1    | Copy the option, and the node can join as 6LR |
   |    1    |    NA   |                  Join as 6LN                  |
   +---------+---------+-----------------------------------------------+

                      Table 1: Option Flags handling

   If a node receives an unknown Option without 'X' flag set then the
   node MUST ignore the option and process the message.  The option MUST
   be treated as if J=0, C=0, I=0.

5.  Implementation Considerations

   In [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 can only happen after inspecting the message options.

6.  Acknowledgements

   Thank you Dominique Barthel for important review/feedback on
   extending Control Options.

7.  IANA Considerations

7.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

7.2.  New options: MOPex and Capabilities

   A new entry is required for supporting new option "MOPex" in the "RPL
   Control Message Options" space [RFC6550].




Jadhav, et al.           Expires October 2, 2021                [Page 6]


Internet-Draft                MOP extension                   March 2021


                    +-------+---------+---------------+
                    | Value | Meaning |   Reference   |
                    +-------+---------+---------------+
                    |  TBD1 |  MOPex  | This document |
                    +-------+---------+---------------+

                                New options

7.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.4.  Change in RPL Control Option field

   Section 4 of this document specifies MSB of the RPL Control Option to
   be used as a bit to indicate RPL Extended Control Options.

   IANA is requested to reduce the unassigned values range from 0x10 to
   0x7f for RPL Control Options.

   IANA is requested to create a new registry for RPL Extended Control
   Options indicating values 0x80 to 0xff.  New values may be allocated
   only by an IETF Review.  Each value is tracked with the following
   qualities:

   o  Value

   o  Meaning

   o  Defining RFC

   The value could be in the range of 0x80 to 0xff.

8.  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




Jadhav, et al.           Expires October 2, 2021                [Page 7]


Internet-Draft                MOP extension                   March 2021


   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.

9.  References

9.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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc6550>.

9.2.  Informative References

   [I-D.ietf-roll-capabilities]
              Jadhav, R., Thubert, P., Richardson, M., and R. Sahoo,
              "RPL Capabilities", draft-ietf-roll-capabilities-07 (work
              in progress), September 2020.

Authors' Addresses

   Rahul Arvind Jadhav (editor)
   Huawei Tech
   Kundalahalli Village, Whitefield,
   Bangalore, Karnataka  560037
   India

   Phone: +91-080-49160700
   Email: rahul.ietf@gmail.com










Jadhav, et al.           Expires October 2, 2021                [Page 8]


Internet-Draft                MOP extension                   March 2021


   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 October 2, 2021                [Page 9]