[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-ietf-roll-mopex-cap) 00 01 02 06

ROLL                                                      R. Jadhav, Ed.
Internet-Draft                                                    Huawei
Intended status: Standards Track                              P. Thubert
Expires: December 5, 2020                                          Cisco
                                                           M. Richardson
                                                Sandelman Software Works
                                                                R. Sahoo
                                                                 Juniper
                                                            June 3, 2020


                            RPL Capabilities
                    draft-ietf-roll-capabilities-06

Abstract

   This draft enables the discovery, advertisement and query of
   capabilities for RPL nodes.

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 December 5, 2020.

Copyright Notice

   Copyright (c) 2020 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 December 5, 2020                [Page 1]


Internet-Draft              RPL Capabilities                   June 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language and Terminology . . . . . . . . . .   3
     1.2.  What are Capabilities?  . . . . . . . . . . . . . . . . .   4
   2.  Requirements for this document  . . . . . . . . . . . . . . .   4
     2.1.  How are Capabilities different from existing RPL
           primitives? . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Capability Control Message Option . . . . . . . . . . . .   5
     3.2.  Capabilities Handshake  . . . . . . . . . . . . . . . . .   6
   4.  Querying Capabilities . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Capability Query (CAPQ) . . . . . . . . . . . . . . . . .   6
       4.1.1.  Capability Type List Control Option . . . . . . . . .   7
       4.1.2.  Secure CAPQ . . . . . . . . . . . . . . . . . . . . .   7
       4.1.3.  Base rules for CAPQ handling  . . . . . . . . . . . .   7
     4.2.  Capability Set Response (CAPS)  . . . . . . . . . . . . .   7
       4.2.1.  Secure CAPS . . . . . . . . . . . . . . . . . . . . .   8
   5.  Guidelines for defining new capabilities  . . . . . . . . . .   8
     5.1.  Handling Capability flags . . . . . . . . . . . . . . . .   8
       5.1.1.  Rules to handle capabilities flag . . . . . . . . . .   9
   6.  Node Capabilities . . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Capability Indicators . . . . . . . . . . . . . . . . . .   9
       6.1.1.  Format of Capability Indicators . . . . . . . . . . .   9
     6.2.  Routing Resource Capability . . . . . . . . . . . . . . .   9
       6.2.1.  Format of Routing Resource Capability . . . . . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  New option: Capabilities  . . . . . . . . . . . . . . . .  11
     8.2.  Capability Sub-Type . . . . . . . . . . . . . . . . . . .  11
     8.3.  New Registry for CAPQ Flags . . . . . . . . . . . . . . .  12
     8.4.  New Registry for Capabilities Flags . . . . . . . . . . .  12
     8.5.  New Registry for Capabilities Indicators  . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Capability Handshake Example . . . . . . . . . . . .  14
     A.1.  Query supported Cap Types . . . . . . . . . . . . . . . .  14
     A.2.  Query specific Cap Set  . . . . . . . . . . . . . . . . .  14
     A.3.  CAPS with partial Cap Set . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16






Jadhav, et al.          Expires December 5, 2020                [Page 2]


Internet-Draft              RPL Capabilities                   June 2020


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.

   This document adds a notion of capabilities using which nodes in the
   network could inform its peers about its additional capabilities.
   This document highlights the differences of capabilities from that of
   Mode of operation and explains the necessity of it.

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 MOP of the RPL Instance as
   administratively provisioned at and distributed by the DODAG root.

   MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].

   Capabilities: Additional features or capabilities that are supported
   by the node.

   Cap: Abbreviated term used for Capability.

   Caps: Abbreviated term used for Capabilities.

   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.

   NPDAO: No-Path DAO.  A DAO message which has target with lifetime 0.

   Upstream path/direction: Path or direction from the node to the Root
   in a DAG.

   Downstream path/direction: Path or direction to the node from the
   Root in a DAG.





Jadhav, et al.          Expires December 5, 2020                [Page 3]


Internet-Draft              RPL Capabilities                   June 2020


   This document uses terminology described in [RFC6550].  For the sake
   of readability all the known relevant terms are repeated in this
   section.

1.2.  What are Capabilities?

   Currently RPL specification does not have a mechanism whereby a node
   can signal the set of features that are available on its end.  Such a
   mechanism could help the root to advertise its capabilities and in
   response also determine some advanced information about the
   capabilities of the joining nodes.  This document defines
   Capabilities which could be supported by the nodes and handshaked as
   part of RPL signaling.  Capabilities are embedded as an RPL Control
   Message Option as defined in Section 6.7 of [RFC6550].

2.  Requirements for this document

   Following are the requirements considered for this documents:

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

   REQ2:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.

   REQ3:  Capabilities handshake could be optionally added with existing
          MOPs.  Capabilities been optional in nature could be put to
          use with existing MOPs.  Capabilities and MOP-extension is
          mutually independent i.e. a DIO can have a capabilities
          option, MOP-extension option or both in the same message.

   REQ4:  Capabilities could be explicitly queried.

2.1.  How are Capabilities different from existing RPL primitives?

   The Mode of Operation (MOP) field in RPL mandates the operational
   requirement for the nodes joining as routers.  MOP and DIO
   Configuration Option is strictly controlled by the Root node in RPL.
   Intermediate 6LRs cannot modify these fields.  Also, the MOP never
   changes for the lifetime of the RPL Instance.  Changes in DIO
   Configuration Option are possible but are rare.  Capabilities, on the
   other hand, might change more dynamically.

   RPL DIO message also carries routing metrics and constraints as
   specified in [RFC6551].  Metrics and constraints are used as part of



Jadhav, et al.          Expires December 5, 2020                [Page 4]


Internet-Draft              RPL Capabilities                   June 2020


   objective function which aids in node's rank calculation.  A router
   may use capabilities carried in DIO message as additional metrics/
   constraints.  However, capabilities have a larger scope and may be
   carried in other messages other than DIO and can flow in both the
   directions (upstream and downstream).

3.  Capabilities

   Handling of Capabilities MUST be supported if the network uses MOPex
   [I-D.ietf-roll-mopex].

   Note that capabilities and MOPex are mutually exclusive and it is
   possible for an implementation to support either or both of the
   options.

3.1.  Capability Control Message Option

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = TODO | Option Length | Capabilities TLVs
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 1: Capabilities Option

   Multiple capabilities could be sent in the same message.  The length
   field allows the message parser to skip the capability TLV parsing.

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   CapType     |     Len       |J|I|C|  Flags  |     ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 2: Capabilities TLV

   Every capability is identified by its type and it may have an
   optional Capability Info.  Note that a given capability may or may
   not be diseminated with additional information depending on the scope
   of the capability indicated by the I bit.

   Len: 8-bit unsigned integer, representing the length in octets of the
   TLV, not including the CapType, Length and Flags fields.

   J = Join only as leaf if capability not understood.

   I = Ignore the message if this capability is not understood.



Jadhav, et al.          Expires December 5, 2020                [Page 5]


Internet-Draft              RPL Capabilities                   June 2020


   C = Flag indicating that the capability MUST be copied in the
   downstream message.

3.2.  Capabilities Handshake

   The root node could advertise the set of capabilities it supports in
   the DIO message.  A node could take advantage of the knowledge that
   the root supports a particular capability.  Similarly a node could
   advertise its capabilities in the DAO message using the capability
   control message option defined in this document.  Capabilities
   advertised by non-root nodes are strictly a subset of the
   capabilities advertised by the root.

   In storing MOP, the DAO message from the 6LR could contain multiple
   target options because of the DAO-Aggregation.  The targets of the
   capabilities option are indicated by one or more Target options that
   precede the Capabilities Option.  This handling is similar to the
   Transit Information Option as supported in Section 6.7.8. of
   [RFC6550].

4.  Querying Capabilities

   Nodes may be interested in knowing the capabilities of another node
   before taking an action.  For e.g., Consider
   [I-D.ietf-roll-dao-projection], the Root may want to know the
   capabilities of the nodes along a network segment before it initiates
   a projected DAO to install the routes along that segment.

   Caps can be carried in existing RPL Control messages as Control
   Options, however Caps can also be queried explicitly.  This section
   provides a way for a node to query capability set of another node.
   The capability query and subsequent response messages are directly
   addressed between the two peers.

4.1.  Capability Query (CAPQ)

     0                   1                   2                   3
     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |       Flags   |   reserved    | CAPQSequence  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Option(s)...
     +-+-+-+-+-+-+-+-+

                        Figure 3: CAPQ base object

   CAPQSequence:  One byte, Sequence number sent by the CAPQ sender
       which is reflected back by the responder in the CAPS message.



Jadhav, et al.          Expires December 5, 2020                [Page 6]


Internet-Draft              RPL Capabilities                   June 2020


   Flags:  One byte, set to zero by sender, ignored by receiver.

   reserved:  One byte, set to zero by sender, ignored by receiver.

   CAPQ base object may be followed by one or more options.  The
   Capability Type List Control Option Figure 4 is used to carry a set
   of capability types to query about.

   If the sender does not send Figure 4 option, this would indicate that
   the node intends to query the capability type list Figure 4 supported
   by the target node.

4.1.1.  Capability Type List Control Option

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Type = TODO | Option Length |  CapType1     |  CapType2     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  CapType3     |  .....
     +-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 4: Capability Type List Control Option

4.1.2.  Secure CAPQ

   A Secure CAPQ message follows the format in [RFC6550] Figure 7, where
   the base message format is the CAPQ message shown in Figure 3.

4.1.3.  Base rules for CAPQ handling

   A CAPQ message may get dropped or lost in the transit.  The sender of
   CAPQ MAY retry the CAPQ message after some delay.  The delay SHOULD
   NOT be less than 1 second.

4.2.  Capability Set Response (CAPS)

     0                   1                   2                   3
     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | RPLInstanceID |    Flags      |  Reserved     |  CAPQSequence |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option(s)...
     +-+-+-+-+-+-+-+-+

                        Figure 5: CAPS base object

   Flags:  One byte, set to zero by sender, ignored by receiver.



Jadhav, et al.          Expires December 5, 2020                [Page 7]


Internet-Draft              RPL Capabilities                   June 2020


   reserved:  One byte, set to zero by sender, ignored by receiver.

   CAPQSequence:  One byte, Sequence number copied from CAPQSequence
       received in the CAPQ message.

   CAPS message SHOULD contain the capability set Figure 1 queried by
   the CAPQ sender.  If the target node does not support subset of the
   queried capabilities then the Figure 4 option with the unsupported
   cap-types SHOULD be sent back indicating the queried capabilities
   not-supported by the target node.  For an example, check Appendix A.3

   If the CAPQ message does not contain any Figure 4 option then the
   receiver MUST respond with the cap types it supports using Figure 4.

   If the capability set cannot be transmitted in a single message (for
   e.g., because of MTU limitations) then multiple CAPS messages could
   be used.  All the CAPS message MUST use the same CAPQSequence number
   copied from the corresponding CAPQ message.

4.2.1.  Secure CAPS

   A Secure CAPS message follows the format in [RFC6550] Figure 7, where
   the base message format is the CAPS message shown in Figure 5.

5.  Guidelines for defining new capabilities

   This section provides guidelines/recommendations towards defining new
   capabilities.  Note that the capabilities might be carried as part of
   the multicast messaging such as DIO and hence the set should be used
   in restrictive manner as far as possible.

5.1.  Handling Capability flags

   A node MUST drop or discard the message with an unknown capability
   with 'D' flag set.  The message MUST be discarded silently.

   The 'J' (join) flag can be set in context to a capability either by a
   6LR or the root.  The 'J' flag indicates that if the capability is
   not supported by a node then it can join the instance only as a 6LN
   (or do not join as 6LR).

   The 'C' (copy) flag is set by the node indicating that the
   capabilities MUST be copied downstream by the node even if the node
   does not understand the capability.







Jadhav, et al.          Expires December 5, 2020                [Page 8]


Internet-Draft              RPL Capabilities                   June 2020


5.1.1.  Rules to handle capabilities flag
   On receiving a capability it does not support, the node MUST check
   the 'J' flag of the capability before joining the Instance.  If the
   'J' flag is set then it can only join as a 6LN.
   If the node is operating as 6LR and subsequently it receives a
   capability from its preferred parent which it does not understand
   with 'J' flag set, then the node has to switch itself to 6LN mode.
   During switching the node needs to inform its downstream peers of its
   changed status by sending a DIO with infinite rank as mentioned in
   RFC6550.  Alternatively, a node may decide to switch to another
   parent with compatible and known capabilities.
   Capabilities are used to indicate a feature that is supported by the
   node.  Capabilities are not meant for configuration management for
   e.g., setting a threshold.

6.  Node Capabilities

6.1.  Capability Indicators

   Capability Indicators indicates the capabilities supported by the
   node in the form of simple flags.  Capabilities who do not have
   additional information to be specified could make use of these flags
   to indicate their support.

6.1.1.  Format of Capability Indicators

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CapType=0x01  |     Len       |J|I|C|   Flags |T|..Indicators..
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: Capability Indicators TLV

   Flags: LRs MUST set it to 0.  I bit will always be set to 0.

   T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].

6.2.  Routing Resource Capability

   Storing mode of operation requires each intermediate router in the
   LLN to maintain routing states' information in the routing table.
   LLN routers typically operate with constraints on processing power,
   memory, and energy (battery power).  Memory limits the number of
   routing states an LR and BR can maintain.  When the routing table of
   an LR or BR is full, it will either reject the new DAO messages
   received or will use some replacement policy to remove a routing
   entry and add the new one.  Rejection of DAO messages will lead to an



Jadhav, et al.          Expires December 5, 2020                [Page 9]


Internet-Draft              RPL Capabilities                   June 2020


   increase in DAO message transmission that impacts the energy and
   network convergence time.  Routing state replacement leads to
   downward path downtime.

   One possible way to solve problems due to routing table size
   constraint is to use this information to add neighbors to the DAO
   parent set.  Routing resource capability can be used by LR and BR to
   advertise their current routing table usage details in the network.
   LR or LNs in LLN can use this information in the selection of the DAO
   parent set.  PCE can use this information to select intermediate
   routers for the projected routes.  Routing Resource is an optional
   capability.

   Routing resource capabablity sent in DIO message has link local scope
   and it MUST not be forwarded.  The 'C' bit of this capability MUST be
   set to 0.

6.2.1.  Format of Routing Resource Capability

      0                   1                   2                   3
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | CapType=0x02  |    Len=3      |J|I|C|  Flags  |  Reserved     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Total Capacity         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7: Routing Resource Capability TLV

   Type: 0x02.

   Flags: I bit MUST be set to 0.  C bit MUST be set to 0.

   Len: 8-bit unsigned integer, representing the length in octets of the
   option, not including the Option Type and Length/flags fields.

   Resvd: 8-bit unused field.  It MUST be initialized to zero by the
   sender and MUST be ignored by the receiver.

   Total Capacity: 16 bit unsigned integer representing the routing
   table size.

7.  Acknowledgements

   Thanks to Georgios Papadopoulos, Li Zhao for early review and
   feedback.





Jadhav, et al.          Expires December 5, 2020               [Page 10]


Internet-Draft              RPL Capabilities                   June 2020


8.  IANA Considerations

   IANA is requested to allocate new codes for the CAPQ and CAPS
   messages from the RPL Control Codes registry.

           +------+----------------------------+---------------+
           | Code |        Description         |   Reference   |
           +------+----------------------------+---------------+
           | TBD1 |      Capability Query      | This document |
           | TBD2 |    Capability Response     | This document |
           | TBD3 |  Secure Capability Query   | This document |
           | TBD4 | Secure Capability Response | This document |
           +------+----------------------------+---------------+

                         New RPL Control Messages

   The MSB of the codes allocated to "Secure" messages above should be
   set.

8.1.  New option: Capabilities

   New entry is required for supporting new Capabilities option and new
   Capability Type List Option in the "RPL Control Message Options"
   space [RFC6550].

          +-------+-----------------------------+---------------+
          | Value |           Meaning           |   Reference   |
          +-------+-----------------------------+---------------+
          |  TODO |      Capability Option      | This document |
          |  TODO | Capability Type List Option | This document |
          +-------+-----------------------------+---------------+

                                New options

8.2.  Capability Sub-Type

   IANA is requested to create a registry for the Capabilities Type as
   described in Figure 2 of this document.  This registry should be
   located in TODO.  New Capabilities types may be allocated only by an
   IETF review.











Jadhav, et al.          Expires December 5, 2020               [Page 11]


Internet-Draft              RPL Capabilities                   June 2020


          +-------+-----------------------------+---------------+
          | Value |           Meaning           |   Reference   |
          +-------+-----------------------------+---------------+
          |  0x01 |    Capability Indicators    | This document |
          |  0x02 | Routing Resource Capability | This document |
          +-------+-----------------------------+---------------+

                                   Type

8.3.  New Registry for CAPQ Flags

   IANA is requested to create a registry for the Capabilities flags as
   described in Section 4.1 of this document.  This registry should be
   located in TODO.  New Capabilities flags may be allocated only by an
   IETF review.  Currently no flags are defined by this document.  Each
   value is tracked with the following qualities:

   o  Flag

   o  Description

   o  Defining RFC

8.4.  New Registry for Capabilities Flags

   IANA is requested to create a registry for the Capabilities flags as
   described in Section 2.1 of this document.  This registry should be
   located in TODO.  New Capabilities flags may be allocated only by an
   IETF review.  Currently no flags are defined by this document.  Each
   value is tracked with the following qualities:

   o  Flag

   o  Description

   o  Defining RFC

8.5.  New Registry for Capabilities Indicators

   IANA is requested to create a registry for the Capabilities
   Indicators as described in Section 6.1 of this document.  This
   registry should be located in TODO.  New Capabilities indicators may
   be allocated only by an IETF review.  Each value is tracked with the
   following qualities:

   o  Flag

   o  Description



Jadhav, et al.          Expires December 5, 2020               [Page 12]


Internet-Draft              RPL Capabilities                   June 2020


   o  Defining RFC

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

   [TODO] implications of malicious attack involving setting the
   capability flags.

10.  References

10.1.  Normative References

   [I-D.ietf-roll-mopex]
              Jadhav, R., Thubert, P., and M. Richardson, "Mode of
              Operation extension", draft-ietf-roll-mopex-00 (work in
              progress), April 2020.

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

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <https://www.rfc-editor.org/info/rfc8138>.

10.2.  Informative References







Jadhav, et al.          Expires December 5, 2020               [Page 13]


Internet-Draft              RPL Capabilities                   June 2020


   [I-D.ietf-lwig-nbr-mgmt-policy]
              Jadhav, R., Sahoo, R., Duquennoy, S., and J. Eriksson,
              "Neighbor Management Policy for 6LoWPAN", draft-ietf-lwig-
              nbr-mgmt-policy-03 (work in progress), February 2019.

   [I-D.ietf-roll-dao-projection]
              Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated
              routing state in RPL", draft-ietf-roll-dao-projection-10
              (work in progress), May 2020.

   [I-D.thubert-roll-turnon-rfc8138]
              Thubert, P. and L. Zhao, "Configuration option for RFC
              8138", draft-thubert-roll-turnon-rfc8138-03 (work in
              progress), July 2019.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              <https://www.rfc-editor.org/info/rfc6551>.

Appendix A.  Capability Handshake Example

A.1.  Query supported Cap Types

                 Root                             6LR/6LN
                 |                                   |
                 |  CAPQ(seq=1, opts=nil)            |
                 |---------------------------------->|
                 |                                   |
                 |                                   |
                 |  CAPS(seq=1, opts={CapTypeList})  |
                 |<----------------------------------|
                 |                                   |

                    Figure 8: Query supported Cap Types

   CAPQ message with no CapTypeList Option results in the peer
   responding with a CAPS message with CapTypeList Option indicating all
   the capability set it supports.

A.2.  Query specific Cap Set









Jadhav, et al.          Expires December 5, 2020               [Page 14]


Internet-Draft              RPL Capabilities                   June 2020


                 Root                             6LR/6LN
                 |                                   |
                 |  CAPQ(seq=2,                      |
                 |   opts={CapTypeList=[Cap1, Cap2]})|
                 |---------------------------------->|
                 |                                   |
                 |                                   |
                 |  CAPS(seq=2,                      |
                 |       opts={Cap1=Cap1Value,       |
                 |             Cap2=Cap2Value})      |
                 |<----------------------------------|
                 |                                   |

                     Figure 9: Query specific Cap Set

   This flow indicates the case where the Root probes for specific
   Capabilities of the peer node and the peer node responds with the
   value of indicated Capability set.

A.3.  CAPS with partial Cap Set

                 Root                             6LR/6LN
                 |                                   |
                 |  CAPQ(seq=3,                      |
                 |   opts={CapTypeList=[Cap1, Cap2,  |
                 |                      Cap3, Cap4]})|
                 |---------------------------------->|
                 |                                   |
                 |                                   |
                 |  CAPS(seq=3,                      |
                 |    opts={Cap2=Cap2Value,          |
                 |          Cap3=Cap3Value,          |
                 |          CapTypeList=[Cap1,Cap4]})|
                 |<----------------------------------|
                 |                                   |

                     Partial Capability Set handshake

   Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4}
   from the peer node.  However the peer node does not support or does
   not understand capability {cap1, cap4}. In this case the peer node
   will respond back with value of Cap2 and Cap3 (which it understands)
   and set the CapTypeList option with {Cap1, Cap4} type.








Jadhav, et al.          Expires December 5, 2020               [Page 15]


Internet-Draft              RPL Capabilities                   June 2020


Authors' Addresses

   Rahul Arvind Jadhav (editor)
   Huawei
   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


   Rabi Narayan Sahoo
   Juniper

   Email: rabinarayans0828@gmail.com


















Jadhav, et al.          Expires December 5, 2020               [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/