Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6550

RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks

Pages: 157
Proposed Standard
Errata
Updated by:  90089010
Part 3 of 6 – Pages 30 to 63
First   Prev   Next

Top   ToC   RFC6550 - Page 30   prevText

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.
Top   ToC   RFC6550 - Page 31
   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.
Top   ToC   RFC6550 - Page 32
        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:
Top   ToC   RFC6550 - Page 33
        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:
Top   ToC   RFC6550 - Page 34
         +-----------+-------------------+------------------------+
         | 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:
Top   ToC   RFC6550 - Page 35
          +------+-----+-----------------------------+------------+
          | 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.
Top   ToC   RFC6550 - Page 36
   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.
Top   ToC   RFC6550 - Page 37
   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.
Top   ToC   RFC6550 - Page 38

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 Information

6.3. DODAG Information Object (DIO)

The DODAG Information Object carries information that allows a node to discover a RPL Instance, learn its configuration parameters,
Top   ToC   RFC6550 - Page 39
   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:
Top   ToC   RFC6550 - Page 40
           +-----+-----------------------------------------------------+
           | 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.
Top   ToC   RFC6550 - Page 41
   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.
Top   ToC   RFC6550 - Page 42

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.
Top   ToC   RFC6550 - Page 43
   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.
Top   ToC   RFC6550 - Page 44

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).
Top   ToC   RFC6550 - Page 45
       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.
Top   ToC   RFC6550 - Page 46

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.
Top   ToC   RFC6550 - Page 47
   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 PadN

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.
Top   ToC   RFC6550 - Page 48
   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
Top   ToC   RFC6550 - Page 49
   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.
Top   ToC   RFC6550 - Page 50
   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
Top   ToC   RFC6550 - Page 51
   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.
Top   ToC   RFC6550 - Page 52

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.
Top   ToC   RFC6550 - Page 53
   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.
Top   ToC   RFC6550 - Page 54

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.
Top   ToC   RFC6550 - Page 55
   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.
Top   ToC   RFC6550 - Page 56
   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.
Top   ToC   RFC6550 - Page 57
   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.
Top   ToC   RFC6550 - Page 58
   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.)
Top   ToC   RFC6550 - Page 59
   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
Top   ToC   RFC6550 - Page 60
   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
Top   ToC   RFC6550 - Page 61
   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.
Top   ToC   RFC6550 - Page 62
   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.
Top   ToC   RFC6550 - Page 63

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)

Next Section