--- 1/draft-ietf-roll-capabilities-00.txt 2020-03-09 03:13:32.617344651 -0700 +++ 2/draft-ietf-roll-capabilities-01.txt 2020-03-09 03:13:32.657345666 -0700 @@ -1,22 +1,22 @@ ROLL R. Jadhav, Ed. Internet-Draft Huawei Tech Intended status: Standards Track P. Thubert -Expires: August 13, 2020 Cisco +Expires: September 10, 2020 Cisco M. Richardson Sandelman Software Works R. Sahoo, Ed. - February 10, 2020 + March 9, 2020 RPL Capabilities - draft-ietf-roll-capabilities-00 + draft-ietf-roll-capabilities-01 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. @@ -24,21 +24,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 August 13, 2020. + This Internet-Draft will expire on September 10, 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 @@ -49,43 +49,46 @@ 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 - 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Capability Catagories . . . . . . . . . . . . . . . . . . 5 3.2. Capability Control Message Option . . . . . . . . . . . . 5 3.3. Capabilities Handshake . . . . . . . . . . . . . . . . . 6 - 3.4. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . 6 - 3.4.1. Projected Route Capability . . . . . . . . . . . . . 6 - 3.4.1.1. Format of Projected Route Capability . . . . . . 7 - 3.4.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . 8 - 3.4.2.1. Format of 6LoRH Capability . . . . . . . . . . . 9 - 3.4.3. Routing Resource Capability . . . . . . . . . . . . . 9 - 3.4.3.1. Format of Routing Resource Capability . . . . . . 10 - 3.4.4. Neighbor Cache Capability . . . . . . . . . . . . . . 11 - 3.4.4.1. Format of Neighbor Cache Capability . . . . . . . 12 - 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 5.1. New option: Capabilities . . . . . . . . . . . . . . . . 12 - 5.2. New Registry for Capabilities Flags . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 7.2. Informative References . . . . . . . . . . . . . . . . . 13 - Appendix A. Capability Handshake Example . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Guidelines for defining new capabilities . . . . . . . . . . 7 + 4.1. Handling Capability flags . . . . . . . . . . . . . . . . 7 + 4.1.1. Rules to handle capabilities flag . . . . . . . . . . 7 + 5. ROLL Capabilities . . . . . . . . . . . . . . . . . . . . . . 7 + 5.1. Projected Route Capability (PRC) . . . . . . . . . . . . 8 + 5.1.1. Format of Projected Route Capability . . . . . . . . 8 + 5.2. 6LoRH Capability . . . . . . . . . . . . . . . . . . . . 9 + 5.2.1. Format of 6LoRH Capability . . . . . . . . . . . . . 10 + 5.3. Routing Resource Capability . . . . . . . . . . . . . . . 11 + 5.3.1. Format of Routing Resource Capability . . . . . . . . 11 + 5.4. Neighbor Cache Capability . . . . . . . . . . . . . . . . 12 + 5.4.1. Format of Neighbor Cache Capability . . . . . . . . . 13 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 7.1. New option: Capabilities . . . . . . . . . . . . . . . . 13 + 7.2. New Registry for Capabilities Flags . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 9.2. Informative References . . . . . . . . . . . . . . . . . 15 + Appendix A. Capability Handshake Example . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 @@ -219,39 +222,40 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 |G|I|. . . . . .| CAPInfo(Opt) + | CAPType |J|I|G|.|.|.|.|.| CAPInfo(Opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 G bit. The first Bit of the - CAPType indicates if the capability is mandatory or optional Value of - 1 indicates its a mandatory capability and 0 indicates its an - optional capability + of the capability indicated by the I bit. + + J = Join only as leaf if capability not understood + + I = Capability Info present + G = If set indicates a Global Capability else its a local. For a capability if it's mandatory and global bit is set then node those either doesn't understand the capability or doesn't have this capability should not join the DODAG as a router. All the global - capablities MUST be diseminated across the network. - - I = Cap Info present + capablities MUST be diseminated across the network. 6LRs in the + network MUST copy the global capabilities in their DIOs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CAPLen | Cap Info(format decided by individual cap spec) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Capabilities Info Capability Information provides additional information for the given @@ -270,23 +274,58 @@ 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 Capabilties Option. This handling is similar to the Transit Information Option as supported in Section 6.7.8. of [RFC6550]. -3.4. ROLL Capabilities +4. Guidelines for defining new capabilities -3.4.1. Projected Route Capability + 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 + + The 'G' (global) flag indicating global capability should be set only + by the root. However, it is not mandatory for the root to set this + flag for all capabilities it indicates. It should set this flag only + for those capabilities which the 6LRs downstream must propagate + further downstream. + + The 'I' (information) flag is set only when there is additional + information to be set in context to the capability. + + 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. + +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]. + +5. ROLL Capabilities +5.1. Projected Route Capability (PRC) [I-D.ietf-roll-dao-projection] proposes mechanisms to compute and install traffic engineered paths in the RPL network. It enables an RPL Root to install and maintain Projected Routes based on requested path metric, within its DODAG, along with a selected set of nodes that may or may not include self, for a chosen duration. Projected Route Capability will be used to enable this TE path calculation. PRC will be an optional global capability. Any node that does not understand or support the projected route functions can still act as an LR. @@ -309,31 +348,30 @@ can be part of a storing or non-storing or both mode of projected routes. Here the PRC will be part of the DAO message. The capability will convey the below information. The PRC MUST have either of the information or both depending upon the node type.If originator is BR, then both the information MUST be there. I: Supports projected route for both storing and non-storing mode. - II: List of supported path metrics that supported that can be used - to compute projected routes + II: List of supported path metrics that can be used to compute + projected routes. III: [To Decide] Can we add the PCE address information to this? -3.4.1.1. Format of Projected Route Capability - +5.1.1. Format of Projected Route 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type=0x01 |G|I|. . . . . .| CAPLen | MOP | Resvd | + | Type=0x01 |J|I|G|. . . . .| CAPLen | MOP | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Metric 1 | Routing Metric 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Metric n-1 | Routing Metric n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Projected Route Capability TLV Type: 0x01. @@ -342,41 +380,40 @@ CAPLen: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. MOP: 3-bit field indicating the mode of operation of projected route capability. Resvd: 5-bit unused fields.They MUST be initialized to zero by the sender and MUST be ignored by the receiver. - Routing Merric: 16 bit unsigned integer represetning the the routing + Routing Metric: 16 bit unsigned integer represetning the routing metric to be used for TE path calculation. There can be n number of such routing metric fields. These fileds are alowed with the PRC sent by the DODAG ROOT. LRs MUST not send routing metric information with PRC. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x01 | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Routing Metric Information -3.4.2. 6LoRH Capability +5.2. 6LoRH Capability [RFC8138] introduces a new 6LoWPAN Routing Header (6LoRH) to carry IPv6 routing information. The 6LoRH may contain source routing information such as a compressed form of SRH, and other sorts of routing information such as the RPI and IP-in-IP encapsulation - The transition to [RFC8138] in a network can only be done when all nodes support the specification. In a mixed case with both RFC8138-capable and non-capable nodes it would not be posssible to take advantage of 6LoRH.[I-D.thubert-roll-turnon-rfc8138] defines a mechanism to control the use of 6LoRH in a DODAG by using "T" flag bit in RPL configuration option. To assist DODAG root to decide if it has to set "T" flag bit in RPL Configuration Option to enable 6LoRH within its DODAG, all LRs in DODAG MUST inform their support of [RFC8138] by adding 6LoRH capability TLV to their advertised capability control message option. @@ -392,38 +429,38 @@ support RFC 8138.So if DODAG is still not using 6LoRH, it MUST refrain from using the compression and if it is already using it, it MUST deny the LR from joining the DODAG with proper error code. [TODO- Need to add new Error code]. 6LoRH capability is an optional capability any node that doesn't understand or support the 6LoRH can join the DODAG if the "T" flag in the RPL Configuration option is not set otherwise it MUST join the network as a leaf node. -3.4.2.1. Format of 6LoRH Capability +5.2.1. Format of 6LoRH 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type=0x02 |G|I|. . . . . .| Reserved | + | Type=0x02 |J|I|G|. . . . .| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: 6LoRH Capability TLV Type: 0x02. Flags: LRs MUST set it to 0. I bit will always be set to 0. Reserved: 16-bit unsigned integer, they MUST be initialized to zero by the sender and MUST be ignored by the receiver.. -3.4.3. Routing Resource Capability +5.3. 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 increase in DAO message transmission that impacts the energy and @@ -445,26 +482,26 @@ I: Master Routing Table Storing II: Storing mode P-DAO Table III: Non-Storing mode P-DAO Routing resource capabablity sent in DIO message has link local scope and it MUST not be forwarded. -3.4.3.1. Format of Routing Resource Capability +5.3.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type=0x03 |G|I|. . . . . .| CAPLen | RT | Resvd | + | Type=0x03 |J|I|G|. . . . .| CAPLen | RT | Resvd | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Capacity | Used Per | Threshold | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Routing Resource Capability TLV Type: 0x03. Flags: G bit MUST be set to 0. I bit will always be set to 1. @@ -489,21 +527,21 @@ percentage of routing table space currently in use. Threshold: 8 bit unsigned integer representing the maximum routing table space that can be used. If the routing resource type is RT1 and used Percentage is greater than or equal to a threshold, its siblings MUST stop using it as the preferred parent or remove it from the parent list. If the routing resource type is RT2 or RT3 and used Percentage is greater than or equal to a threshold, PCE MUST recompute some projected routes by excluding this node. -3.4.4. Neighbor Cache Capability +5.4. Neighbor Cache Capability A neighbor cache maintains neighboring one-hop connected nodes information such as MAC address, link-local IP address and other reachability state information needed for layer two communication.Node density has direct implications on the neighbor cache. In the constrained network scenario the size of the neighbor cache will be limited. Thus there are chances that a node may not be able to store all the neighboring nodes in its cache and use replacement algorithms to evict some of the entries to accommodate the new one. If the replaced neighbor has installed a DAO route on @@ -516,70 +554,73 @@ the availability of neighbor cache is not taken into consideration while selecting the DAO parent set. Neighbor Cache capability can be used by LR and BR to advertise their neighbor cache size information. This capablity information has only link scope and should not be advertised in the entire network. [TODO-- As neighbor cache entries category is not yet standardized i think we can't use it in capability. With categories format of the TLV is going to chnage.] -3.4.4.1. Format of Neighbor Cache Capability +5.4.1. Format of Neighbor Cache Capability -4. Acknowledgements +6. Acknowledgements Thanks to Georgios Papadopoulos, Li Zhao for the review and feedback. -5. IANA Considerations +7. IANA Considerations -5.1. New option: Capabilities +7.1. New option: Capabilities New entry is required for supporting new Capabilities option in the "RPL Control Message Options" space [RFC6550]. +-------+--------------+---------------+ | Value | Meaning | Reference | +-------+--------------+---------------+ | TBD1 | Capabilities | This document | +-------+--------------+---------------+ New options -5.2. New Registry for Capabilities Flags +7.2. 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 -6. Security Considerations +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 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. -7. References + [TODO] implications of malicious attack involving setting the + capability flags. -7.1. Normative References +9. References + +9.1. Normative 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-dao-projection] Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated routing state in RPL", draft-ietf-roll-dao-projection-09 (work in progress), November 2019. @@ -599,21 +640,21 @@ JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [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, . -7.2. Informative References +9.2. Informative References [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