Mode of Operation extension

Internet-Draft	MOP extension	October 2022
Jadhav, et al.	Expires 14 April 2023	[Page]

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 14 April 2023.¶

Copyright Notice

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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:¶

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

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:¶


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

Table 1: Option Flags handling
'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

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

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

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

Table 3: New options
Value	Meaning	Reference
TBD1	MOPex	This document

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:¶

MOPex value¶
Description¶
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:¶

Value¶
Meaning¶
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 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. A., Thubert, P., Richardson, M., and R. N. Sahoo, "RPL Capabilities", Work in Progress, Internet-Draft, draft-ietf-roll-capabilities-09, 9 November 2021, <https://www.ietf.org/archive/id/draft-ietf-roll-capabilities-09.txt>.