RFC 6550
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
6. ICMPv6 RPL Control Message
This document defines the RPL control message, a new ICMPv6 [RFC4443] message. A RPL control message is identified by a code and composed of a base that depends on the code (and a series of options). Most RPL control messages have the scope of a link. The only exception is for the DAO / DAO-ACK messages in Non-Storing mode, which are exchanged using a unicast address over multiple hops and thus uses global or unique-local addresses for both the source and destination addresses. For all other RPL control messages, the source address is a link-local address, and the destination address is either the all-RPL-nodes multicast address or a link-local unicast address of the destination. The all-RPL-nodes multicast address is a new address with a value of ff02::1a. In accordance with [RFC4443], the RPL Control Message consists of an ICMPv6 header followed by a message body. The message body is comprised of a message base and possibly a number of options as illustrated in Figure 6. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: RPL Control Message The RPL control message is an ICMPv6 information message with a Type of 155.
The Code field identifies the type of RPL control message. This document defines codes for the following RPL control message types (see Section 20.2)): o 0x00: DODAG Information Solicitation (Section 6.2) o 0x01: DODAG Information Object (Section 6.3) o 0x02: Destination Advertisement Object (Section 6.4) o 0x03: Destination Advertisement Object Acknowledgment (Section 6.5) o 0x80: Secure DODAG Information Solicitation (Section 6.2.2) o 0x81: Secure DODAG Information Object (Section 6.3.2) o 0x82: Secure Destination Advertisement Object (Section 6.4.2) o 0x83: Secure Destination Advertisement Object Acknowledgment (Section 6.5.2) o 0x8A: Consistency Check (Section 6.6) If a node receives a RPL control message with an unknown Code field, the node MUST discard the message without any further processing, MAY raise a management alert, and MUST NOT send any messages in response. The checksum is computed as specified in [RFC4443]. It is set to zero for the RPL security operations specified below and computed once the rest of the content of the RPL message including the security fields is all set. The high order bit (0x80) of the code denotes whether the RPL message has security enabled. Secure RPL messages have a format to support confidentiality and integrity, illustrated in Figure 7.
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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Security . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Base . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Option(s) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Secure RPL Control Message The remainder of this section describes the currently defined RPL control message Base formats followed by the currently defined RPL Control Message options.6.1. RPL Security Fields
Each RPL message has a secure variant. The secure variants provide integrity and replay protection as well as optional confidentiality and delay protection. Because security covers the base message as well as options, in secured messages the security information lies between the checksum and base, as shown in Figure 7. The level of security and the algorithms in use are indicated in the protocol messages as described below:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| Reserved | Algorithm |KIM|Resvd| LVL | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Key Identifier . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Security Section Message Authentication Codes (MACs) and signatures provide authentication over the entire unsecured ICMPv6 RPL control message, including the Security section with all fields defined, but with the ICMPv6 checksum temporarily set to zero. Encryption provides confidentiality of the secured RPL ICMPv6 message starting at the first byte after the Security section and continuing to the last byte of the packet. The security transformation yields a secured ICMPv6 RPL message with the inclusion of the cryptographic fields (MAC, signature, etc.). In other words, the security transformation itself (e.g., the Signature and/or Algorithm in use) will detail how to incorporate the cryptographic fields into the secured packet. The Security section itself does not explicitly carry those cryptographic fields. Use of the Security section is further detailed in Sections 19 and 10. Counter is Time (T): If the counter's Time flag is set, then the Counter field is a timestamp. If the flag is cleared, then the counter is an incrementing counter. Section 10.5 describes the details of the 'T' flag and Counter field. Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Security Algorithm (Algorithm): The Security Algorithm field specifies the encryption, MAC, and signature scheme the network uses. Supported values of this field are as follows:
+-----------+-------------------+------------------------+ | Algorithm | Encryption/MAC | Signature | +-----------+-------------------+------------------------+ | 0 | CCM with AES-128 | RSA with SHA-256 | | 1-255 | Unassigned | Unassigned | +-----------+-------------------+------------------------+ Figure 9: Security Algorithm (Algorithm) Encoding Section 10.9 describes the algorithms in greater detail. Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field that indicates whether the key used for packet protection is determined implicitly or explicitly and indicates the particular representation of the Key Identifier field. The Key Identifier Mode is set one of the values from the table below:
+------+-----+-----------------------------+------------+ | Mode | KIM | Meaning | Key | | | | | Identifier | | | | | Length | | | | | (octets) | +------+-----+-----------------------------+------------+ | 0 | 00 | Group key used. | 1 | | | | Key determined by Key Index | | | | | field. | | | | | | | | | | Key Source is not present. | | | | | Key Index is present. | | +------+-----+-----------------------------+------------+ | 1 | 01 | Per-pair key used. | 0 | | | | Key determined by source | | | | | and destination of packet. | | | | | | | | | | Key Source is not present. | | | | | Key Index is not present. | | +------+-----+-----------------------------+------------+ | 2 | 10 | Group key used. | 9 | | | | Key determined by Key Index | | | | | and Key Source Identifier. | | | | | | | | | | Key Source is present. | | | | | Key Index is present. | | +------+-----+-----------------------------+------------+ | 3 | 11 | Node's signature key used. | 0/9 | | | | If packet is encrypted, | | | | it uses a group key, Key | | | | | Index and Key Source | | | | | specify key. | | | | | | | | | | Key Source may be present. | | | | | Key Index may be present. | | +------+-----+-----------------------------+------------+ Figure 10: Key Identifier Mode (KIM) Encoding In Mode 3 (KIM=11), the presence or absence of the Key Source and Key Identifier depends on the Security Level (LVL) described below. If the Security Level indicates there is encryption, then the fields are present; if it indicates there is no encryption, then the fields are not present. Resvd: 3-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Security Level (LVL): The Security Level is a 3-bit field that
indicates the provided packet protection. This value can be
adapted on a per-packet basis and allows for varying levels of
data authenticity and, optionally, for data confidentiality.
The KIM field indicates whether signatures are used and the
meaning of the Level field. Note that the assigned values of
Security Level are not necessarily ordered -- a higher value of
LVL does not necessarily equate to increased security. The
Security Level is set to one of the values in the tables below:
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-7 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2 | Sign-2048 | 256 |
| 3 | ENC-Sign-2048 | 256 |
| 4-7 | Unassigned | N/A |
+-------+---------------+-----+
Figure 11: Security Level (LVL) Encoding
The MAC attribute indicates that the message has a MAC of the
specified length. The ENC attribute indicates that the message is
encrypted. The Sign attribute indicates that the message has a
signature of the specified length.
Flags: 8-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the
receiver.
Counter: The Counter field indicates the non-repeating 4-octet value
used to construct the cryptographic mechanism that implements
packet protection and allows for the provision of semantic
security. See Section 10.9.1.
Key Identifier: The Key Identifier field indicates which key was used
to protect the packet. This field provides various levels of
granularity of packet protection, including peer-to-peer keys,
group keys, and signature keys. This field is represented as
indicated by the Key Identifier Mode field and is formatted as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Source .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Index .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key Identifier
Key Source: The Key Source field, when present, indicates the logical
identifier of the originator of a group key. When present,
this field is 8 bytes in length.
Key Index: The Key Index field, when present, allows unique
identification of different keys with the same originator. It
is the responsibility of each key originator to make sure that
actively used keys that it issues have distinct key indices and
that all key indices have a value unequal to 0x00. Value 0x00
is reserved for a preinstalled, shared key. When present this
field is 1 byte in length.
Unassigned bits of the Security section are reserved. They MUST be
set to zero on transmission and MUST be ignored on reception.
6.2. DODAG Information Solicitation (DIS)
The DODAG Information Solicitation (DIS) message may be used to solicit a DODAG Information Object from a RPL node. Its use is analogous to that of a Router Solicitation as specified in IPv6 Neighbor Discovery; a node may use DIS to probe its neighborhood for nearby DODAGs. Section 8.3 describes how nodes respond to a DIS.6.2.1. Format of the DIS Base Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Option(s)... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: The DIS Base Object Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Unassigned bits of the DIS Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.6.2.2. Secure DIS
A Secure DIS message follows the format in Figure 7, where the base format is the DIS message shown in Figure 13.6.2.3. DIS Options
The DIS message MAY carry valid options. This specification allows for the DIS message to carry the following options: 0x00 Pad1 0x01 PadN 0x07 Solicited Information6.3. DODAG Information Object (DIO)
The DODAG Information Object carries information that allows a node to discover a RPL Instance, learn its configuration parameters,
select a DODAG parent set, and maintain the DODAG.6.3.1. Format of the DIO Base Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |Version Number | Rank | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |G|0| MOP | Prf | DTSN | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 14: The DIO Base Object Grounded (G): The Grounded 'G' flag indicates whether the DODAG advertised can satisfy the application-defined goal. If the flag is set, the DODAG is grounded. If the flag is cleared, the DODAG is floating. Mode of Operation (MOP): The Mode of Operation (MOP) field identifies the mode of operation of the RPL Instance as administratively provisioned at and distributed by the DODAG root. All nodes who join the DODAG must be able to honor the MOP in order to fully participate as a router, or else they must only join as a leaf. MOP is encoded as in the figure below:
+-----+-----------------------------------------------------+ | MOP | Description | +-----+-----------------------------------------------------+ | 0 | No Downward routes maintained by RPL | | 1 | Non-Storing Mode of Operation | | 2 | Storing Mode of Operation with no multicast support | | 3 | Storing Mode of Operation with multicast support | | | | | | All other values are unassigned | +-----+-----------------------------------------------------+ A value of 0 indicates that destination advertisement messages are disabled and the DODAG maintains only Upward routes. Figure 15: Mode of Operation (MOP) Encoding DODAGPreference (Prf): A 3-bit unsigned integer that defines how preferable the root of this DODAG is compared to other DODAG roots within the instance. DAGPreference ranges from 0x00 (least preferred) to 0x07 (most preferred). The default is 0 (least preferred). Section 8.2 describes how DAGPreference affects DIO processing. Version Number: 8-bit unsigned integer set by the DODAG root to the DODAGVersionNumber. Section 8.2 describes the rules for DODAGVersionNumbers and how they affect DIO processing. Rank: 16-bit unsigned integer indicating the DODAG Rank of the node sending the DIO message. Section 8.2 describes how Rank is set and how it affects DIO processing. RPLInstanceID: 8-bit field set by the DODAG root that indicates of which RPL Instance the DODAG is a part. Destination Advertisement Trigger Sequence Number (DTSN): 8-bit unsigned integer set by the node issuing the DIO message. The Destination Advertisement Trigger Sequence Number (DTSN) flag is used as part of the procedure to maintain Downward routes. The details of this process are described in Section 9. Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely
identifies a DODAG. The DODAGID MUST be a routable IPv6
address belonging to the DODAG root.
Unassigned bits of the DIO Base are reserved. They MUST be set to
zero on transmission and MUST be ignored on reception.
6.3.2. Secure DIO
A Secure DIO message follows the format in Figure 7, where the base
format is the DIO message shown in Figure 14.
6.3.3. DIO Options
The DIO message MAY carry valid options.
This specification allows for the DIO message to carry the following
options:
0x00 Pad1
0x01 PadN
0x02 DAG Metric Container
0x03 Routing Information
0x04 DODAG Configuration
0x08 Prefix Information
6.4. Destination Advertisement Object (DAO)
The Destination Advertisement Object (DAO) is used to propagate
destination information Upward along the DODAG. In Storing mode, the
DAO message is unicast by the child to the selected parent(s). In
Non-Storing mode, the DAO message is unicast to the DODAG root. The
DAO message may optionally, upon explicit request or error, be
acknowledged by its destination with a Destination Advertisement
Acknowledgement (DAO-ACK) message back to the sender of the DAO.
6.4.1. Format of the DAO Base Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |K|D| Flags | Reserved | DAOSequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID* + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ The '*' denotes that the DODAGID is not always present, as described below. Figure 16: The DAO Base Object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. K: The 'K' flag indicates that the recipient is expected to send a DAO-ACK back. (See Section 9.3.) D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. Flags: The 6 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. DAOSequence: Incremented at each unique DAO message from a node and echoed in the DAO-ACK message. DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field is only present when the 'D' flag is set. This field is typically only present when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use, this field need not be present.
Unassigned bits of the DAO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.6.4.2. Secure DAO
A Secure DAO message follows the format in Figure 7, where the base format is the DAO message shown in Figure 16.6.4.3. DAO Options
The DAO message MAY carry valid options. This specification allows for the DAO message to carry the following options: 0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor A special case of the DAO message, termed a No-Path, is used in Storing mode to clear Downward routing state that has been provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target.6.5. Destination Advertisement Object Acknowledgement (DAO-ACK)
The DAO-ACK message is sent as a unicast packet by a DAO recipient (a DAO parent or DODAG root) in response to a unicast DAO message.
6.5.1. Format of the DAO-ACK Base Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D| Reserved | DAOSequence | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID* + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ The '*' denotes that the DODAGID is not always present, as described below. Figure 17: The DAO ACK Base Object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. D: The 'D' flag indicates that the DODAGID field is present. This would typically only be set when a local RPLInstanceID is used. Reserved: The 7-bit field, reserved for flags. DAOSequence: Incremented at each DAO message from a node, and echoed in the DAO-ACK by the recipient. The DAOSequence is used to correlate a DAO message and a DAO ACK message and is not to be confused with the Transit Information option Path Sequence that is associated to a given Target Down the DODAG. Status: Indicates the completion. Status 0 is defined as unqualified acceptance in this specification. The remaining status values are reserved as rejection codes. No rejection status codes are defined in this specification, although status codes SHOULD be allocated according to the following guidelines in future specifications: 0: Unqualified acceptance (i.e., the node receiving the DAO-ACK is not rejected).
1-127: Not an outright rejection; the node sending the DAO-ACK
is willing to act as a parent, but the receiving node is
suggested to find and use an alternate parent instead.
127-255: Rejection; the node sending the DAO-ACK is unwilling to
act as a parent.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field is only present
when the 'D' flag is set. Typically, this field is only
present when a local RPLInstanceID is in use in order to
identify the DODAGID that is associated with the
RPLInstanceID. When a global RPLInstanceID is in use,
this field need not be present.
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set
to zero on transmission and MUST be ignored on reception.
6.5.2. Secure DAO-ACK
A Secure DAO-ACK message follows the format in Figure 7, where the
base format is the DAO-ACK message shown in Figure 17.
6.5.3. DAO-ACK Options
This specification does not define any options to be carried by the
DAO-ACK message.
6.6. Consistency Check (CC)
The CC message is used to check secure message counters and issue
challenge-responses. A CC message MUST be sent as a secured RPL
message.
6.6.1. Format of the CC Base Object
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |R| Flags | CC Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ Figure 18: The CC Base Object RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO. R: The 'R' flag indicates whether the CC message is a response. A message with the 'R' flag cleared is a request; a message with the 'R' flag set is a response. Flags: The 7 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. CC Nonce: 16-bit unsigned integer set by a CC request. The corresponding CC response includes the same CC nonce value as the request. DODAGID: 128-bit field, contains the identifier of the DODAG root. Destination Counter: 32-bit unsigned integer value indicating the sender's estimate of the destination's current security counter value. If the sender does not have an estimate, it SHOULD set the Destination Counter field to zero. Unassigned bits of the CC Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
The Destination Counter value allows new or recovered nodes to resynchronize through CC message exchanges. This is important to ensure that a Counter value is not repeated for a given security key even in the event of devices recovering from a failure that created a loss of Counter state. For example, where a CC request or other RPL message is received with an initialized counter within the message Security section, the provision of the Incoming Counter within the CC response message allows the requesting node to reset its Outgoing Counter to a value greater than the last value received by the responding node; the Incoming Counter will also be updated from the received CC response.6.6.2. CC Options
This specification allows for the CC message to carry the following options: 0x00 Pad1 0x01 PadN6.7. RPL Control Message Options
6.7.1. RPL Control Message Option Generic Format
RPL Control Message options all follow this format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 19: RPL Option Generic Format Option Type: 8-bit identifier of the type of option. The Option Type values are assigned by IANA (see Section 20.4.) Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields. Option Data: A variable length field that contains data specific to the option.
When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in the message. RPL message options may have alignment requirements. Following the convention in IPv6, options with alignment requirements are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8).6.7.2. Pad1
The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0x00 | +-+-+-+-+-+-+-+-+ Figure 20: Format of the Pad1 Option The Pad1 option is used to insert a single octet of padding into the message to enable options alignment. If more than one octet of padding is required, the PadN option should be used rather than multiple Pad1 options. NOTE! The format of the Pad1 option is a special case -- it has neither Option Length nor Option Data fields.6.7.3. PadN
The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Type = 0x01 | Option Length | 0x00 Padding... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Figure 21: Format of the Pad N Option
The PadN option is used to insert two or more octets of padding into
the message to enable options alignment. PadN option data MUST be
ignored by the receiver.
Option Type: 0x01
Option Length: For N octets of padding, where 2 <= N <= 7, the Option
Length field contains the value N-2. An Option Length of 0
indicates a total padding of 2 octets. An Option Length of 5
indicates a total padding of 7 octets, which is the maximum
padding size allowed with the PadN option.
Option Data: For N (N > 1) octets of padding, the Option Data
consists of N-2 zero-valued octets.
6.7.4. DAG Metric Container
The DAG Metric Container option MAY be present in DIO or DAO
messages, and its format is 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x02 | Option Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 22: Format of the DAG Metric Container Option
The DAG Metric Container is used to report metrics along the DODAG.
The DAG Metric Container may contain a number of discrete node, link,
and aggregate path metrics and constraints specified in [RFC6551] as
chosen by the implementer.
The DAG Metric Container MAY appear more than once in the same RPL
control message, for example, to accommodate a use case where the
Metric Data is longer than 256 bytes. More information is in
[RFC6551].
The processing and propagation of the DAG Metric Container is
governed by implementation specific policy functions.
Option Type: 0x02
Option Length: The Option Length field contains the length in octets
of the Metric Data.
Metric Data: The order, content, and coding of the DAG Metric
Container data is as specified in [RFC6551].
6.7.5. Route Information
The Route Information Option (RIO) MAY be present in DIO messages,
and it carries the same information as the IPv6 Neighbor Discovery
(ND) RIO as defined in [RFC4191]. The root of a DODAG is
authoritative for setting that information and the information is
unchanged as propagated down the DODAG. A RPL router may trivially
transform it back into an ND option to advertise in its own RAs so a
node attached to the RPL router will end up using the DODAG for which
the root has the best preference for the destination of a packet. In
addition to the existing ND semantics, it is possible for an
Objective Function to use this information to favor a DODAG whose
root is most preferred for a specific destination. The format of the
option is modified slightly (Type, Length, Prefix) in order to be
carried as a RPL option as follows:
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 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Prefix (Variable Length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Format of the Route Information Option
The RIO is used to indicate that connectivity to the specified
destination prefix is available from the DODAG root.
In the event that a RPL control message may need to specify
connectivity to more than one destination, the RIO may be repeated.
[RFC4191] should be consulted as the authoritative reference with
respect to the RIO. The field descriptions are transcribed here for
convenience:
Option Type: 0x03
Option Length: Variable, length of the option in octets excluding the
Type and Length fields. Note that this length is expressed in
units of single octets, unlike in IPv6 ND.
Prefix Length: 8-bit unsigned integer. The number of leading bits in
the prefix that are valid. The value ranges from 0 to 128.
The Prefix field has the number of bytes inferred from the
Option Length field, that must be at least the Prefix Length.
Note that in RPL, this means that the Prefix field may have
lengths other than 0, 8, or 16.
Prf: 2-bit signed integer. The Route Preference indicates whether to
prefer the router associated with this prefix over others, when
multiple identical prefixes (for different routers) have been
received. If the Reserved (10) value is received, the RIO MUST
be ignored. Per [RFC4191], the Reserved (10) value MUST NOT be
sent. ([RFC4191] restricts the Preference to just three values
to reinforce that it is not a metric.)
Resvd: Two 3-bit unused fields. They MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Route Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the
prefix is valid for route determination. A value of all one
bits (0xFFFFFFFF) represents infinity.
Prefix: Variable-length field containing an IP address or a prefix of
an IPv6 address. The Prefix Length field contains the number
of valid leading bits in the prefix. The bits in the prefix
after the prefix length (if any) are reserved and MUST be
initialized to zero by the sender and ignored by the receiver.
Note that in RPL, this field may have lengths other than 0, 8,
or 16.
Unassigned bits of the RIO are reserved. They MUST be set to zero on
transmission and MUST be ignored on reception.
6.7.6. DODAG Configuration
The DODAG Configuration option MAY be present in DIO messages, and its format is as follows: 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 = 0x04 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DIOIntMin. | DIORedun. | MaxRankIncrease | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MinHopRankIncrease | OCP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Def. Lifetime | Lifetime Unit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 24: Format of the DODAG Configuration Option The DODAG Configuration option is used to distribute configuration information for DODAG Operation through the DODAG. The information communicated in this option is generally static and unchanging within the DODAG, therefore it is not necessary to include in every DIO. This information is configured at the DODAG root and distributed throughout the DODAG with the DODAG Configuration option. Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option. This option MAY be included occasionally by the DODAG root (as determined by the DODAG root), and MUST be included in response to a unicast request, e.g. a unicast DODAG Information Solicitation (DIS) message. Option Type: 0x04 Option Length: 14 Flags: The 4-bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Authentication Enabled (A): 1-bit flag describing the security mode of the network. The bit describes whether a node must authenticate with a key authority before joining the network as a router. If the DIO is not a secure DIO, the 'A' bit MUST be zero.
Path Control Size (PCS): 3-bit unsigned integer used to configure the
number of bits that may be allocated to the Path Control field
(see Section 9.9). Note that when PCS is consulted to
determine the width of the Path Control field, a value of 1 is
added, i.e., a PCS value of 0 results in 1 active bit in the
Path Control field. The default value of PCS is
DEFAULT_PATH_CONTROL_SIZE.
DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax
of the DIO Trickle timer (see Section 8.3.1). The default
value of DIOIntervalDoublings is
DEFAULT_DIO_INTERVAL_DOUBLINGS.
DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the
DIO Trickle timer (see Section 8.3.1). The default value of
DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.
DIORedundancyConstant: 8-bit unsigned integer used to configure k of
the DIO Trickle timer (see Section 8.3.1). The default value
of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.
MaxRankIncrease: 16-bit unsigned integer used to configure
DAGMaxRankIncrease, the allowable increase in Rank in support
of local repair. If DAGMaxRankIncrease is 0, then this
mechanism is disabled.
MinHopRankIncrease: 16-bit unsigned integer used to configure
MinHopRankIncrease as described in Section 3.5.1. The default
value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.
Objective Code Point (OCP): 16-bit unsigned integer. The OCP field
identifies the OF and is managed by the IANA.
Reserved: 7-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
Default Lifetime: 8-bit unsigned integer. This is the lifetime that
is used as default for all RPL routes. It is expressed in
units of Lifetime Units, e.g., the default lifetime in seconds
is (Default Lifetime) * (Lifetime Unit).
Lifetime Unit: 16-bit unsigned integer. Provides the unit in seconds
that is used to express route lifetimes in RPL. For very
stable networks, it can be hours to days.
6.7.7. RPL Target
The RPL Target option MAY be present in DAO messages, and its format is as follows: 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 = 0x05 | Option Length | Flags | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Target Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Format of the RPL Target Option The RPL Target option is used to indicate a Target IPv6 address, prefix, or multicast group that is reachable or queried along the DODAG. In a DAO, the RPL Target option indicates reachability. A RPL Target option MAY optionally be paired with a RPL Target Descriptor option (Figure 30) that qualifies the target. A set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target options in a DAO message (where each Target option MAY be paired with a RPL Target Descriptor option as above). The structure of the DAO message, detailing how Target options are used in conjunction with Transit Information options is further described in Section 9.4. The RPL Target option may be repeated as necessary to indicate multiple targets. Option Type: 0x05 Option Length: Variable, length of the option in octets excluding the Type and Length fields. Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix Length: 8-bit unsigned integer. Number of valid leading bits in the IPv6 Prefix.
Target Prefix: Variable-length field identifying an IPv6 destination
address, prefix, or multicast group. The Prefix Length field
contains the number of valid leading bits in the prefix. The
bits in the prefix after the prefix length (if any) are
reserved and MUST be set to zero on transmission and MUST be
ignored on receipt.
6.7.8. Transit Information
The Transit Information option MAY be present in DAO messages, and
its format is as follows:
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 = 0x06 | Option Length |E| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Parent Address* +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAG Parent Address subfield is not always
present, as described below.
Figure 26: Format of the Transit Information Option
The Transit Information option is used for a node to indicate
attributes for a path to one or more destinations. The destinations
are indicated by one or more Target options that immediately precede
the Transit Information option(s).
The Transit Information option can be used for a node to indicate its
DODAG parents to an ancestor that is collecting DODAG routing
information, typically, for the purpose of constructing source
routes. In the Non-Storing mode of operation, this ancestor will be
the DODAG root, and this option is carried by the DAO message. In
the Storing mode of operation, the DODAG Parent Address subfield is
not needed, since the DAO message is sent directly to the parent.
The option length is used to determine whether or not the DODAG
Parent Address subfield is present.
A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non- storing destination advertisement operation. The node may distribute the bits in the Path Control field among different groups of DAO parents in order to signal a preference among parents. That preference may influence the decision of the DODAG root when selecting among the alternate parents/paths for constructing Downward routes. One or more Transit Information options MUST be preceded by one or more RPL Target options. In this manner, the RPL Target option indicates the child node, and the Transit Information option(s) enumerates the DODAG parents. The structure of the DAO message, further detailing how Target options are used in conjunction with Transit Information options, is further described in Section 9.4. A typical non-storing node will use multiple Transit Information options, and it will send the DAO message thus formed directly to the root. A typical storing node will use one Transit Information option with no parent field and will send the DAO message thus formed, with additional adjustments, to Path Control as detailed later, to one or multiple parents. For example, in a Non-Storing mode of operation let Tgt(T) denote a Target option for a Target T. Let Trnst(P) denote a Transit Information option that contains a parent address P. Consider the case of a non-storing Node N that advertises the self-owned targets N1 and N2 and has parents P1, P2, and P3. In that case, the DAO message would be expected to contain the sequence ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), such that the group of Target options {N1, N2} is described by the Transit Information options as having the parents {P1, P2, P3}. The non-storing node would then address that DAO message directly to the DODAG root and forward that DAO message through one of the DODAG parents: P1, P2, or P3. Option Type: 0x06 Option Length: Variable, depending on whether or not the DODAG Parent Address subfield is present. External (E): 1-bit flag. The 'E' flag is set to indicate that the parent router redistributes external targets into the RPL network. An external Target is a Target that has been learned through an alternate protocol. The external targets are listed in the Target options that immediately precede the Transit Information option. An external Target is not expected to support RPL messages and options.
Flags: The 7 bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Path Control: 8-bit bit field. The Path Control field limits the
number of DAO parents to which a DAO message advertising
connectivity to a specific destination may be sent, as well as
providing some indication of relative preference. The limit
provides some bound on overall DAO message fan-out in the LLN.
The assignment and ordering of the bits in the Path Control
also serves to communicate preference. Not all of these bits
may be enabled as according to the PCS in the DODAG
Configuration. The Path Control field is divided into four
subfields that contain two bits each: PC1, PC2, PC3, and PC4,
as illustrated in Figure 27. The subfields are ordered by
preference, with PC1 being the most preferred and PC4 being the
least preferred. Within a subfield, there is no order of
preference. By grouping the parents (as in ECMP) and ordering
them, the parents may be associated with specific bits in the
Path Control field in a way that communicates preference.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding
Path Sequence: 8-bit unsigned integer. When a RPL Target option is
issued by the node that owns the Target prefix (i.e., in a DAO
message), that node sets the Path Sequence and increments the
Path Sequence each time it issues a RPL Target option with
updated information.
Path Lifetime: 8-bit unsigned integer. The length of time in
Lifetime Units (obtained from the Configuration option) that
the prefix is valid for route determination. The period starts
when a new Path Sequence is seen. A value of all one bits
(0xFF) represents infinity. A value of all zero bits (0x00)
indicates a loss of reachability. A DAO message that contains
a Transit Information option with a Path Lifetime of 0x00 for a
Target is referred as a No-Path (for that Target) in this
document.
Parent Address (optional): IPv6 address of the DODAG parent of the
node originally issuing the Transit Information option. This
field may not be present, as according to the DODAG Mode of
Operation (Storing or Non-Storing) and indicated by the Transit
Information option length.
Unassigned bits of the Transit Information option are reserved. They
MUST be set to zero on transmission and MUST be ignored on reception.
6.7.9. Solicited Information
The Solicited Information option MAY be present in DIS messages, and
its format is as follows:
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 = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+
Figure 28: Format of the Solicited Information Option
The Solicited Information option is used for a node to request DIO
messages from a subset of neighboring nodes. The Solicited
Information option may specify a number of predicate criteria to be
matched by a receiving node. This is used by the requester to limit
the number of replies from "non-interesting" nodes. These predicates
affect whether a node resets its DIO Trickle timer, as described in
Section 8.3.
The Solicited Information option contains flags that indicate which
predicates a node should check when deciding whether to reset its
Trickle timer. A node resets its Trickle timer when all predicates
are true. If a flag is set, then the RPL node MUST check the
associated predicate. If a flag is cleared, then the RPL node MUST
NOT check the associated predicate. (If a flag is cleared, the RPL
node assumes that the associated predicate is true.)
Option Type: 0x07
Option Length: 19
V: The 'V' flag is the Version predicate. The Version predicate is
true if the receiver's DODAGVersionNumber matches the requested
Version Number. If the 'V' flag is cleared, then the Version
field is not valid and the Version field MUST be set to zero on
transmission and ignored upon receipt.
I: The 'I' flag is the InstanceID predicate. The InstanceID
predicate is true when the RPL node's current RPLInstanceID
matches the requested RPLInstanceID. If the 'I' flag is
cleared, then the RPLInstanceID field is not valid and the
RPLInstanceID field MUST be set to zero on transmission and
ignored upon receipt.
D: The 'D' flag is the DODAGID predicate. The DODAGID predicate is
true if the RPL node's parent set has the same DODAGID as the
DODAGID field. If the 'D' flag is cleared, then the DODAGID
field is not valid and the DODAGID field MUST be set to zero on
transmission and ignored upon receipt.
Flags: The 5 bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver.
Version Number: 8-bit unsigned integer containing the value of
DODAGVersionNumber that is being solicited when valid.
RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID
that is being solicited when valid.
DODAGID: 128-bit unsigned integer containing the DODAGID that is
being solicited when valid.
Unassigned bits of the Solicited Information option are reserved.
They MUST be set to zero on transmission and MUST be ignored on
reception.
6.7.10. Prefix Information
The Prefix Information Option (PIO) MAY be present in DIO messages,
and carries the information that is specified for the IPv6 ND Prefix
Information option in [RFC4861], [RFC4862], and [RFC6275] for use by
RPL nodes and IPv6 hosts. In particular, a RPL node may use this
option for the purpose of Stateless Address Autoconfiguration (SLAAC)
from a prefix advertised by a parent as specified in [RFC4862], and
advertise its own address as specified in [RFC6275]. The root of a DODAG is authoritative for setting that information. The information is propagated down the DODAG unchanged, with the exception that a RPL router may overwrite the Interface ID if the 'R' flag is set to indicate its full address in the PIO. The format of the option is modified (Type, Length, Prefix) in order to be carried as a RPL option as follows: If the only desired effect of a received PIO in a DIO is to provide the global address of the parent node to the receiving node, then the sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon receipt, the RPL will not autoconfigure an address or a connected route from the prefix [RFC4862]. As in all cases, when the 'L' bit is not set, the RPL node MAY include the prefix in PIOs it sends to its children. 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 = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 29: Format of the Prefix Information Option The PIO may be used to distribute the prefix in use inside the DODAG, e.g., for address autoconfiguration. [RFC4861] and [RFC6275] should be consulted as the authoritative reference with respect to the PIO. The field descriptions are transcribed here for convenience: Option Type: 0x08
Option Length: 30. Note that this length is expressed in units of
single octets, unlike in IPv6 ND.
Prefix Length: 8-bit unsigned integer. The number of leading bits in
the Prefix field that are valid. The value ranges from 0 to
128. The Prefix Length field provides necessary information
for on-link determination (when combined with the 'L' flag in
the PIO). It also assists with address autoconfiguration as
specified in [RFC4862], for which there may be more
restrictions on the prefix length.
L: 1-bit on-link flag. When set, it indicates that this prefix
can be used for on-link determination. When not set, the
advertisement makes no statement about on-link or off-link
properties of the prefix. In other words, if the 'L' flag is
not set, a RPL node MUST NOT conclude that an address derived
from the prefix is off-link. That is, it MUST NOT update a
previous indication that the address is on-link. A RPL node
acting as a router MUST NOT propagate a PIO with the 'L' flag
set. A RPL node acting as a router MAY propagate a PIO with
the 'L' flag not set.
A: 1-bit autonomous address-configuration flag. When set, it
indicates that this prefix can be used for stateless address
configuration as specified in [RFC4862]. When both protocols
(ND RAs and RPL DIOs) are used to carry PIOs on the same link,
it is possible to use either one for SLAAC by a RPL node. It
is also possible to make either protocol ineligible for SLAAC
operation by forcing the 'A' flag to 0 for PIOs carried in that
protocol.
R: 1-bit router address flag. When set, it indicates that the
Prefix field contains a complete IPv6 address assigned to the
sending router that can be used as parent in a target option.
The indicated prefix is the first prefix length bits of the
Prefix field. The router IPv6 address has the same scope and
conforms to the same lifetime values as the advertised prefix.
This use of the Prefix field is compatible with its use in
advertising the prefix itself, since Prefix Advertisement uses
only the leading bits. Interpretation of this flag bit is thus
independent of the processing required for the on-link (L) and
autonomous address-configuration (A) flag bits.
Reserved1: 5-bit unused field. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Valid Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that the
prefix is valid for the purpose of on-link determination. A
value of all one bits (0xFFFFFFFF) represents infinity. The
Valid Lifetime is also used by [RFC4862].
Preferred Lifetime: 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) that
addresses generated from the prefix via stateless address
autoconfiguration remain preferred [RFC4862]. A value of all
one bits (0xFFFFFFFF) represents infinity. See [RFC4862].
Note that the value of this field MUST NOT exceed the Valid
Lifetime field to avoid preferring addresses that are no longer
valid.
Reserved2: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
Prefix: An IPv6 address or a prefix of an IPv6 address. The Prefix
Length field contains the number of valid leading bits in the
prefix. The bits in the prefix after the prefix length are
reserved and MUST be initialized to zero by the sender and
ignored by the receiver. A router SHOULD NOT send a prefix
option for the link-local prefix, and a host SHOULD ignore such
a prefix option. A non-storing node SHOULD refrain from
advertising a prefix till it owns an address of that prefix,
and then it SHOULD advertise its full address in this field,
with the 'R' flag set. The children of a node that so
advertises a full address with the 'R' flag set may then use
that address to determine the content of the DODAG Parent
Address subfield of the Transit Information option.
Unassigned bits of the PIO are reserved. They MUST be set to zero on
transmission and MUST be ignored on reception.
6.7.11. RPL Target Descriptor
The RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target. 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 = 0x09 |Opt Length = 4 | Descriptor +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Descriptor (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 30: Format of the RPL Target Descriptor Option The RPL Target Descriptor option is used to qualify a target, something that is sometimes called "tagging". At most, there can be one descriptor per target. The descriptor is set by the node that injects the Target in the RPL network. It MUST be copied but not modified by routers that propagate the Target Up the DODAG in DAO messages. Option Type: 0x09 Option Length: 4 Descriptor: 32-bit unsigned integer. Opaque.
(page 63 continued on part 4)
