Skip to main content

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