Mode of Operation extension
draft-ietf-roll-mopex-07
| Document | Type | Active Internet-Draft (roll WG) | |
|---|---|---|---|
| Authors | Rahul Jadhav , Pascal Thubert , Michael Richardson | ||
| Last updated | 2023-09-20 (Latest revision 2023-06-04) | ||
| Replaces | draft-jadhav-roll-mopex, draft-ietf-roll-mopex-cap | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | Ines Robles | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | mariainesrobles@googlemail.com |
draft-ietf-roll-mopex-07
ROLL R.A. Jadhav, Ed.
Internet-Draft Huawei Tech
Intended status: Standards Track P. Thubert
Expires: 6 December 2023 Cisco
M. Richardson
Sandelman Software Works
4 June 2023
Mode of Operation extension
draft-ietf-roll-mopex-07
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.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jadhav, et al. Expires 6 December 2023 [Page 1]
Internet-Draft MOP extension June 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language and Terminology . . . . . . . . . . 3
2. Requirements for this document . . . . . . . . . . . . . . . 3
3. Extended MOP Control Message Option . . . . . . . . . . . . . 4
3.1. Handling MOPex . . . . . . . . . . . . . . . . . . . . . 4
3.2. Use of values 0-6 in the MOPex option . . . . . . . . . . 4
4. Extending RPL Control Options . . . . . . . . . . . . . . . . 5
5. Implementation Considerations . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7.1. Mode of operation: MOPex . . . . . . . . . . . . . . . . 7
7.2. New option: Extended MOP (MOPex) . . . . . . . . . . . . 7
7.3. New Registry for MOPex value . . . . . . . . . . . . . . 7
7.4. Change in RPL Control Option field . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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.
Jadhav, et al. Expires 6 December 2023 [Page 2]
Internet-Draft MOP extension June 2023
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 leaf to this parent
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.
Jadhav, et al. Expires 6 December 2023 [Page 3]
Internet-Draft MOP extension June 2023
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].
Jadhav, et al. Expires 6 December 2023 [Page 4]
Internet-Draft MOP extension June 2023
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:
Option Type: 8-bit identifier of the type of option. The Option
Type values are assigned by IANA (see Section 20.4 of [RFC6550]).
'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 field
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.
Option Flags: 8-bit unsigned integer, representing flags in the
context of the Extended RPL Control Option. This document defines
three flags 'J', 'C', and 'I'. These flags only apply if the
Option Type is unknown or unsupported.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Unused |J|I|C|
+-+-+-+-+-+-+-+-+
Figure 3: Option Flags in Extended RPL Control Option
'J' (Join) flag: If set, the node MAY only join the network as a
leaf.
'C' (Copy) flag: If set, the node MUST copy this Option Type in
the DIO message it generates. If unset, the node MUST strip off
the Option and process the message.
Jadhav, et al. Expires 6 December 2023 [Page 5]
Internet-Draft MOP extension June 2023
'I' (Ignore) flag: If set, the node MUST ignore the whole message
regardless of the setting of the J and C flags.
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.
+=========+=========+===============================+
| '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 |
+---------+---------+-------------------------------+
Table 1: Option Flags handling
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.
Jadhav, et al. Expires 6 December 2023 [Page 6]
Internet-Draft MOP extension June 2023
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].
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| 7 | MOPex | This document |
+-------+-------------+---------------+
Table 2: Mode of Operation
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.
+=======+======================+===============+
| Value | Meaning | Reference |
+=======+======================+===============+
| TBD1 | Extended MOP (MOPex) | This document |
+-------+----------------------+---------------+
Table 3: New options
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
Jadhav, et al. Expires 6 December 2023 [Page 7]
Internet-Draft MOP extension June 2023
* Reference
+=============+=============+===========+
| MOPex Value | Description | Reference |
+=============+=============+===========+
| 0 to 6 | MOP | [RFC6550] |
+-------------+-------------+-----------+
Table 4: Registry for MOPex values
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.
+==============+==================+=================+
| Range | Option Type | Reference |
+==============+==================+=================+
| 0x00 to 0x7f | Base Options | [RFC6550] |
+--------------+------------------+-----------------+
| 0x80 to 0xFf | Extended Options | [this document] |
+--------------+------------------+-----------------+
Table 5: Registry for RPL Control Option
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, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Jadhav, et al. Expires 6 December 2023 [Page 8]
Internet-Draft MOP extension June 2023
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <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, April 2021,
<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, 9 November 2021,
<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
Phone: +91-080-49160700
Email: rahul.ietf@gmail.com
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Jadhav, et al. Expires 6 December 2023 [Page 9]
Internet-Draft MOP extension June 2023
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
Jadhav, et al. Expires 6 December 2023 [Page 10]