Internet-Draft MOP extension June 2023
Jadhav, et al. Expires 6 December 2023 [Page]
Workgroup:
ROLL
Internet-Draft:
draft-ietf-roll-mopex-07
Published:
Intended Status:
Standards Track
Expires:
Authors:
R.A. Jadhav, Ed.
Huawei Tech
P. Thubert
Cisco
M. Richardson
Sandelman Software Works

Mode of Operation extension

Abstract

The Routing Protocol for Low-Power and Lossy Networks (RPL) can have different modes of operation (MOP) to allow nodes to agree on the basic primitives that must be supported to join a network. The MOP field defined in RFC6550 is fast depleting. This document specifies an extended MOP option 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 6 December 2023.

Table of Contents

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 fast depleting 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:

1.1. Requirements Language and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

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: Destination Advertisement Object (see Section 6.4 of [RFC6550])

DIO: DODAG Information Object (see Section 6.3 of [RFC6550])

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

2. Requirements for this document

The following are the requirements considered for this document:

REQ1:
MOP extension. The 3-bits MOP as defined in [RFC6550] is fast depleting. A 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.

3. Extended MOP Control Message Option

This document assigns MOP value 7 to be used as an extender Section 7. A DIO message with a MOP value of 7 indicates that the MOP for RPL instance is contained in the Extended MOP (MOPex) option.

 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 = TBD1 | Option Length |  MOPex-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. Section 6.7.1 of [RFC6550] explains how to interpret Option Length and subsequent Option Data (which is MOPex-value in this context).

3.1. Handling MOPex

The MOPex option MUST be used only if the DIO MOP is 7. If the DIO MOP is 7 and if the MOPex option is not present or invalid then the DIO MUST be silently ignored. If the 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 MOPex value.

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. All the general assumptions that are applicable in the context of MOP are applicable in the context of MOPex as well.

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

The MOPex option should also be used for existing MOP values 0-6. The use of current MOPs (values 0 to 6) in MOPex indicates that the MOP might be 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] describes the RPL Control Message Option Generic Format. This document extends the format as follows:


 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| Option Type | Option Length | Option Flags  | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------
Figure 2: Extended RPL Option Format

The new fields in the Extended RPL Option are specified as follows:

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

Table 1: Option Flags handling
'J' bit 'C' bit Handling
0 0 Strip off the option, and the node can join as RPL router
0 1 Copy the option, and the node can join as RPL router
1 NA Join as leaf

5. Implementation Considerations

In [RFC6550], it was possible to discard an unsupported MOP just by inspecting the DIO base object. With the extensions in this document, the MOPex is in a control message option and thus discarding of the DIO message can only happen after inspecting the message options.

An implementation should carefully set the Option Flags considering implications of nodes not supporting the corresponding Option Type.

Unsetting the 'J' flag means that a node receiving an unsupported Option Type would be allowed to join as a RPL router. Thus the implementation should carefully consider the implications of such a node joining the network as a RPL router.

Setting the 'C' (Copy) bit should be carefully considered since the node would copy the Option of its preferred parent whose DIO it has accepted from the set of parent nodes.

6. Acknowledgements

Thank you Dominique Barthel for important review/feedback on extending Control Options. Thanks to Alvaro Retana for shaping the final version with detailed review comments.

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

Table 2: Mode of Operation
Value Description Reference
7 MOPex This document

This document updated [RFC9008] to remove the reservation on Mode of Operation value 7. IANA is requested to assign the Mode of Operation value 7 to MOPex, as shown in Table 2. As shown there, all other references related to value 7 are to be removed. IANA is also requested to replace the reference to [RFC9008] in the overall registry with a reference to this document.

7.2. New option: Extended MOP (MOPex)

IANA is requested to assign a value from the RPL Control Message Options registry for the Extended MOP (MOPex) option Section 3 as shown in Table 3.

Table 3: New options
Value Meaning Reference
TBD1 Extended MOP (MOPex) This document

7.3. New Registry for MOPex value

IANA is requested to create a registry for the MOPex-value Section 3. This registry should be located in the Routing Protocol for Low Power and Lossy Networks (RPL) group. New MOPex values may be allocated only by an IETF review. Each value is tracked with the following qualities:

  • MOPex value
  • Description
  • Reference
Table 4: Registry for MOPex values
MOPex Value Description Reference
0 to 6 MOP [RFC6550]

7.4. Change in RPL Control Option field

IANA is requested to modify the RPL Control Message Options registry to include an Extended Control Options range as shown in Table 5. IANA is also requested to add [this document] as a reference for this updated registry.

Table 5: Registry for RPL Control Option
Range Option Type Reference
0x00 to 0x7f Base Options [RFC6550]
0x80 to 0xFf Extended Options [this document]

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. As such, the Security Consideration in [RFC6550] apply.

The use of MOP 7 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, , <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, , <https://www.rfc-editor.org/info/rfc6550>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9008]
Robles, M.I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, , <https://www.rfc-editor.org/info/rfc9008>.

9.2. Informative References

[I-D.ietf-roll-capabilities]
Jadhav, R., Thubert, P., Richardson, M., and R. N. Sahoo, "RPL Capabilities", Work in Progress, Internet-Draft, draft-ietf-roll-capabilities-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-roll-capabilities-09>.

Authors' Addresses

Rahul Arvind Jadhav (editor)
Huawei Tech
Kundalahalli Village, Whitefield,
Bangalore 560037
Karnataka
India
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Michael Richardson
Sandelman Software Works