--- 1/draft-ietf-roll-capabilities-04.txt 2020-05-21 03:13:04.605912518 -0700 +++ 2/draft-ietf-roll-capabilities-05.txt 2020-05-21 03:13:04.633913222 -0700 @@ -1,23 +1,23 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Intended status: Standards Track P. Thubert -Expires: November 17, 2020 Cisco +Expires: November 22, 2020 Cisco M. Richardson Sandelman Software Works R. Sahoo Juniper - May 16, 2020 + May 21, 2020 RPL Capabilities - draft-ietf-roll-capabilities-04 + draft-ietf-roll-capabilities-05 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. @@ -25,21 +25,21 @@ 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 November 17, 2020. + This Internet-Draft will expire on November 22, 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 @@ -48,22 +48,22 @@ include Simplified BSD License text as described in Section 4.e of 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 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 3 2. Requirements for this document . . . . . . . . . . . . . . . 4 - 2.1. How are Capabilities different from MOP or DIO - Configuration Option? . . . . . . . . . . . . . . . . . . 4 + 2.1. How are Capabilities different from existing RPL + primitives? . . . . . . . . . . . . . . . . . . . . . . . 4 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Capability Control Message Option . . . . . . . . . . . . 5 3.2. Capabilities Handshake . . . . . . . . . . . . . . . . . 5 4. Guidelines for defining new capabilities . . . . . . . . . . 6 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 6 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 6 5. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Capability Indicators . . . . . . . . . . . . . . . . . . 7 5.1.1. Format of Capability Indicators . . . . . . . . . . . 7 5.2. Routing Resource Capability . . . . . . . . . . . . . . . 7 @@ -81,52 +81,49 @@ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 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 the nodes in - the network could inform its peers about its additional capabilities/ - features. This document highlights the differences of capabilities - from that of Mode of operation and explains the necessity of it. + 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 mode of operation of the RPL - Instance as administratively provisioned at and distributed by the - DODAG root. + 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 which might - possibly be optional that are supported by the node. + Capabilities: Additional features or capabilities that are supported + by the node. 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. - MOPex: MOP extension as defined in this document. - 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. This document uses terminology described in [RFC6550]. For the sake of readability all the known relevant terms are repeated in this section. @@ -156,30 +153,29 @@ 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 MOP or DIO Configuration - Option? +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 could not modify the values. Also, the MOP never + 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 very rare. Capabilities, - on the other hand, might change more dynamically. + 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 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 @@ -246,46 +242,46 @@ 4. 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. 4.1. Handling Capability flags - A node MUST drop or discard the message silently having an unknown - capability with 'D' (discard) flag set. - - The 'I' (information) flag is set only when there is additional - information to be set in context to the capability. + 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. + capabilities MUST be copied downstream by the node even if the node + does not understand the capability. 4.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 which it doesn't 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]. + 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./>. + e.g., setting a threshold. 5. Node Capabilities 5.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. 5.1.1. Format of Capability Indicators @@ -414,29 +410,24 @@ 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. 9. References 9.1. Normative References - [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. + [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, . [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, @@ -448,24 +439,29 @@ (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, . 9.2. Informative References [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-mopex] - Jadhav, R., Thubert, P., and M. Richardson, "Mode of - Operation extension", draft-ietf-roll-mopex-00 (work in - progress), April 2020. + [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, . Appendix A. Capability Handshake Example Root 6LR 6LN