Skip to main content

20. IANA Considerations

20.1. RPL Control Message​

The RPL control message is an ICMP information message type that is to be used carry DODAG Information Objects, DODAG Information Solicitations, and Destination Advertisement Objects in support of RPL operation.

IANA has defined an ICMPv6 Type Number Registry. The type value for the RPL control message is 155.

20.2. New Registry for RPL Control Codes​

IANA has created a registry, RPL Control Codes, for the Code field of the ICMPv6 RPL control message.

New codes may be allocated only by an IETF Review. Each code is tracked with the following qualities:

  • Code

  • Description

  • Defining RFC

The following codes are currently defined:

CodeDescriptionReference
0x00DODAG Information SolicitationThis document
0x01DODAG Information ObjectThis document
0x02Destination Advertisement ObjectThis document
0x03Destination Advertisement Object AcknowledgmentThis document
0x80Secure DODAG Information SolicitationThis document
0x81Secure DODAG Information ObjectThis document
0x82Secure Destination Advertisement ObjectThis document
0x83Secure Destination Advertisement Object AcknowledgmentThis document
0x8AConsistency CheckThis document

20.3. New Registry for the Mode of Operation (MOP)​

IANA has created a registry for the 3-bit Mode of Operation (MOP), which is contained in the DIO Base.

New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:

  • Mode of Operation Value

  • Capability description

  • Defining RFC

Four values are currently defined:

MOP valueDescriptionReference
0No Downward routes maintained by RPLThis document
1Non-Storing Mode of OperationThis document
2Storing Mode of Operation with no multicast supportThis document
3Storing Mode of Operation with multicast supportThis document

The rest of the range, decimal 4 to 7, is currently unassigned.

20.4. RPL Control Message Options​

IANA has created a registry for the RPL Control Message Options.

New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:

  • Value

  • Meaning

  • Defining RFC

ValueMeaningReference
0x00Pad1This document
0x01PadNThis document
0x02DAG Metric ContainerThis Document
0x03Routing InformationThis Document
0x04DODAG ConfigurationThis Document
0x05RPL TargetThis Document
0x06Transit InformationThis Document
0x07Solicited InformationThis Document
0x08Prefix InformationThis Document
0x09Target DescriptorThis Document

20.5. Objective Code Point (OCP) Registry​

IANA has created a registry to manage the codespace of the Objective Code Point (OCP) field.

No OCPs are defined in this specification.

New codes may be allocated only by an IETF Review. Each code is tracked with the following qualities:

  • Code

  • Description

  • Defining RFC

20.6. New Registry for the Security Section Algorithm​

IANA has created a registry for the values of the 8-bit Algorithm field in the Security section.

New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:

  • Value

  • Encryption/MAC

  • Signature

  • Defining RFC

The following value is currently defined:

ValueEncryption/MACSignatureReference
0CCM with AES-128RSA with SHA-256This document

20.7. New Registry for the Security Section Flags​

IANA has created a registry for the 8-bit Security Section Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

No bit is currently defined for the Security Section Flags field.

20.8. New Registry for Per-KIM Security Levels​

IANA has created one registry for the 3-bit Security Level (LVL) field per allocated KIM value.

For a given KIM value, new levels may be allocated only by an IETF Review. Each level is tracked with the following qualities:

  • Level

  • KIM value

  • Description

  • Defining RFC

The following levels per KIM value are currently defined:

LevelKIM valueDescriptionReference
00See Figure 11This document
10See Figure 11This document
20See Figure 11This document
30See Figure 11This document
01See Figure 11This document
11See Figure 11This document
21See Figure 11This document
31See Figure 11This document
02See Figure 11This document
12See Figure 11This document
22See Figure 11This document
32See Figure 11This document
03See Figure 11This document
13See Figure 11This document
23See Figure 11This document
33See Figure 11This document

20.9. New Registry for DODAG Informational Solicitation (DIS) Flags​

IANA has created a registry for the DIS (DODAG Informational Solicitation) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags field.

20.10. New Registry for the DODAG Information Object (DIO) Flags​

IANA has created a registry for the 8-bit DODAG Information Object (DIO) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags.

20.11. New Registry for the Destination Advertisement Object (DAO) Flags​

IANA has created a registry for the 8-bit Destination Advertisement Object (DAO) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bits are currently defined:

Bit numberDescriptionReference
0DAO-ACK request (K)This document
1DODAGID field is present (D)This document

20.12. New Registry for the Destination Advertisement Object (DAO) Acknowledgement Flags​

IANA has created a registry for the 8-bit Destination Advertisement Object (DAO) Acknowledgement Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bit is currently defined:

Bit numberDescriptionReference
0DODAGID field is present (D)This document

20.13. New Registry for the Consistency Check (CC) Flags​

IANA has created a registry for the 8-bit Consistency Check (CC) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bit is currently defined:

Bit numberDescriptionReference
0CC Response (R)This document

20.14. New Registry for the DODAG Configuration Option Flags​

IANA has created a registry for the 8-bit DODAG Configuration Option Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bits are currently defined:

Bit numberDescriptionReference
4Authentication Enabled (A)This document
5-7Path Control Size (PCS)This document

20.15. New Registry for the RPL Target Option Flags​

IANA has created a registry for the 8-bit RPL Target Option Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

No bit is currently defined for the RPL Target Option Flags.

20.16. New Registry for the Transit Information Option Flags​

IANA has created a registry for the 8-bit Transit Information Option (TIO) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bits are currently defined:

Bit numberDescriptionReference
0External (E)This document

20.17. New Registry for the Solicited Information Option Flags​

IANA has created a registry for the 8-bit Solicited Information Option (SIO) Flags field.

New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:

  • Bit number (counting from bit 0 as the most significant bit)

  • Capability description

  • Defining RFC

The following bits are currently defined:

Bit numberDescriptionReference
0Version Predicate match (V)This document
1InstanceID Predicate match (I)This document
2DODAGID Predicate match (D)This document

20.18. ICMPv6: Error in Source Routing Header​

In some cases RPL will return an ICMPv6 error message when a message cannot be delivered as specified by its source routing header. This ICMPv6 error message is "Error in Source Routing Header".

IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message Types. ICMPv6 Message Type 1 describes "Destination Unreachable" codes. The "Error in Source Routing Header" code is has been allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, with a code value of 7.

The rules for assigning new IPv6 multicast addresses are defined in [RFC3307]. This specification requires the allocation of a new permanent multicast address with a link-local scope for RPL nodes called all-RPL-nodes, with a value of ff02::1a.

Last updated on