6. ICMPv6 RPL 制御メッセージ

このドキュメントでは、新しい ICMPv6 [RFC4443] メッセージである RPL 制御メッセージを定義します。RPL 制御メッセージはコードによって識別され、コードに依存するベース（および一連のオプション）で構成されます。

ほとんどの RPL 制御メッセージのスコープはリンクです。唯一の例外は、非格納モード（Non-Storing mode）での DAO / DAO-ACK メッセージであり、これらはマルチホップでユニキャストアドレスを使用して交換されるため、送信元アドレスと宛先アドレスの両方にグローバルアドレスまたはユニークローカルアドレスを使用します。他のすべての RPL 制御メッセージの場合、送信元アドレスはリンクローカルアドレスであり、宛先アドレスは全 RPL ノードマルチキャストアドレスまたは宛先のリンクローカルユニキャストアドレスのいずれかです。全 RPL ノードマルチキャストアドレスは、値 ff02::1a を持つ新しいアドレスです。

[RFC4443] に従って、RPL 制御メッセージは ICMPv6 ヘッダーとそれに続くメッセージボディで構成されます。メッセージボディは、図 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

RPL 制御メッセージは、タイプ 155 の ICMPv6 情報メッセージです。

コード（Code）フィールドは、RPL 制御メッセージのタイプを識別します。このドキュメントでは、以下の RPL 制御メッセージタイプのコードを定義します（セクション 20.2 を参照）：

• 0x00: DODAG 情報要請 (DIS) (セクション 6.2)

• 0x01: DODAG 情報オブジェクト (DIO) (セクション 6.3)

• 0x02: 宛先通知オブジェクト (DAO) (セクション 6.4)

• 0x03: 宛先通知オブジェクト確認応答 (DAO-ACK) (セクション 6.5)

• 0x80: セキュア DODAG 情報要請 (セクション 6.2.2)

• 0x81: セキュア DODAG 情報オブジェクト (セクション 6.3.2)

• 0x82: セキュア宛先通知オブジェクト (セクション 6.4.2)

• 0x83: セキュア宛先通知オブジェクト確認応答 (セクション 6.5.2)

• 0x8A: 整合性チェック (セクション 6.6)

ノードが不明なコードフィールドを持つ RPL 制御メッセージを受信した場合、ノードはそのメッセージを破棄しなければならず（MUST）、管理アラートを上げてもよく（MAY）、応答としていかなるメッセージも送信してはなりません（MUST NOT）。

チェックサムは [RFC4443] で指定されているように計算されます。以下で指定する RPL セキュリティ操作の場合はゼロに設定され、セキュリティフィールドを含む RPL メッセージの残りの内容がすべて設定された後に一度計算されます。

コードの上位ビット (0x80) は、RPL メッセージでセキュリティが有効になっているかどうかを示します。セキュア RPL メッセージは、図 7 に示すように、機密性と完全性をサポートする形式になっています。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |     Code      |          Checksum             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Security                            .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                             Base                              .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                           Option(s)                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: Secure RPL Control Message

このセクションの残りの部分では、現在定義されている RPL 制御メッセージのベース形式について説明し、その後に現在定義されている RPL 制御メッセージオプションについて説明します。

6.1. RPL セキュリティフィールド

各 RPL メッセージにはセキュアなバリアントがあります。セキュアバリアントは、完全性とリプレイ保護を提供するだけでなく、オプションで機密性と遅延保護も提供します。セキュリティは基本メッセージとオプションをカバーするため、セキュアメッセージでは、図 7 に示すように、セキュリティ情報はチェックサムとベースの間にあります。

セキュリティレベルと使用されているアルゴリズムは、以下のようにプロトコルメッセージで示されます。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |T|  Reserved   |   Algorithm   |KIM|Resvd| LVL |     Flags     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Counter                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                        Key Identifier                         .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 8: Security Section

メッセージ認証コード（MAC）と署名は、ICMPv6 チェックサムが一時的にゼロに設定された状態で、すべてのフィールドが定義されたセキュリティセクションを含む、非セキュアな ICMPv6 RPL 制御メッセージ全体に対する認証を提供します。暗号化は、セキュリティセクションの後の最初のバイトから始まり、パケットの最後のバイトまで続く、セキュアな RPL ICMPv6 メッセージの機密性を提供します。セキュリティ変換により、暗号化フィールド（MAC、署名など）が含まれたセキュアな ICMPv6 RPL メッセージが生成されます。つまり、セキュリティ変換自体（たとえば、使用中の署名やアルゴリズム）は、暗号化フィールドをセキュアパケットに組み込む方法を詳細に示します。セキュリティセクション自体は、それらの暗号化フィールドを明示的に運びません。セキュリティセクションの使用については、セクション 19 と 10 で詳しく説明されています。

Counter is Time (T): : カウンターの Time フラグが設定されている場合、Counter フィールドはタイムスタンプです。フラグがクリアされている場合、カウンターは増分カウンターです。セクション 10.5 では、'T' フラグと Counter フィールドの詳細について説明しています。

Reserved: : 7 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Security Algorithm (Algorithm): : セキュリティアルゴリズムフィールドは、ネットワークが使用する暗号化、MAC、および署名スキームを指定します。このフィールドのサポートされる値は次のとおりです。

      +-----------+-------------------+------------------------+
      | Algorithm |  Encryption/MAC   |        Signature       |
      +-----------+-------------------+------------------------+
      |     0     | CCM with AES-128  |      RSA with SHA-256  |
      |   1-255   |    Unassigned     |        Unassigned      |
      +-----------+-------------------+------------------------+

          Figure 9: Security Algorithm (Algorithm) Encoding

セクション 10.9 では、アルゴリズムについて詳しく説明しています。

Key Identifier Mode (KIM): : キー識別子モードは、パケット保護に使用されるキーが暗黙的に決定されるか明示的に決定されるかを示し、キー識別子フィールドの特定の表現を示す 2 ビットのフィールドです。キー識別子モードは、次の表の値のいずれかに設定されます。

       +------+-----+-----------------------------+------------+
       | 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

モード 3 (KIM=11) では、キーソースとキー識別子の有無は、以下で説明するセキュリティレベル (LVL) に依存します。セキュリティレベルが暗号化があることを示している場合、フィールドは存在します。暗号化がないことを示している場合、フィールドは存在しません。

Resvd: : 3 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Security Level (LVL): : セキュリティレベルは、提供されるパケット保護を示す 3 ビットのフィールドです。この値はパケットごとに適応でき、さまざまなレベルのデータの真正性と、オプションでデータの機密性を可能にします。KIM フィールドは、署名が使用されるかどうか、およびレベルフィールドの意味を示します。割り当てられたセキュリティレベルの値は必ずしも順序付けられていないことに注意してください。LVL の値が高いからといって、必ずしもセキュリティが強化されるわけではありません。セキュリティレベルは、次の表の値のいずれかに設定されます。

                   +---------------------------+
                   |         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

MAC 属性は、メッセージに指定された長さの MAC があることを示します。ENC 属性は、メッセージが暗号化されていることを示します。Sign 属性は、メッセージに指定された長さの署名があることを示します。

Flags: : フラグ用に予約された 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Counter: : カウンターフィールドは、パケット保護を実装し、セマンティックセキュリティの提供を可能にする暗号化メカニズムを構築するために使用される、繰り返されない 4 オクテットの値を示します。セクション 10.9.1 を参照してください。

Key Identifier: : キー識別子フィールドは、パケットの保護に使用されたキーを示します。このフィールドは、ピアツーピアキー、グループキー、署名キーなど、さまざまなレベルのパケット保護の粒度を提供します。このフィールドは、キー識別子モードフィールドで示されるように表され、次のようにフォーマットされます。

     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: : キーソースフィールドは、存在する場合、グループキーの発信元の論理識別子を示します。存在する場合、このフィールドの長さは 8 バイトです。

Key Index: : キーインデックスフィールドは、存在する場合、同じ発信元を持つ異なるキーを一意に識別することを可能にします。アクティブに使用されるキーが異なるキーインデックスを持ち、すべてのキーインデックスが 0x00 と等しくない値を持つことを確認するのは、各キー発信元の責任です。値 0x00 は、プリインストールされた共有キー用に予約されています。存在する場合、このフィールドの長さは 1 バイトです。

セキュリティセクションの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.2. DODAG 情報要請 (DIS)

DODAG 情報要請 (DIS) メッセージは、RPL ノードから DODAG 情報オブジェクトを要請するために使用される場合があります。その使用は、IPv6 近隣探索で指定されているルーター要請の使用と類似しています。ノードは DIS を使用して、近くの DODAG の近隣をプローブできます。セクション 8.3 では、ノードが DIS に応答する方法について説明します。

6.2.1. DIS ベースオブジェクトの形式

     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 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Reserved: : 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

DIS ベースの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.2.2. セキュア DIS

セキュア DIS メッセージは図 7 の形式に従います。ここで、ベース形式は図 13 に示す DIS メッセージです。

6.2.3. DIS オプション

DIS メッセージは有効なオプションを運ぶことができます（MAY）。

この仕様では、DIS メッセージが次のオプションを運ぶことを許可しています。

• 0x00 Pad1
• 0x01 PadN
• 0x07 Solicited Information (要請情報)

6.3. DODAG 情報オブジェクト (DIO)

DODAG 情報オブジェクトは、ノードが RPL インスタンスを発見し、その構成パラメーターを学習し、DODAG 親セットを選択し、DODAG を維持することを可能にする情報を運びます。

6.3.1. DIO ベースオブジェクトの形式

     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): : Grounded 'G' フラグは、通知された DODAG がアプリケーション定義の目標を満たすことができるかどうかを示します。フラグが設定されている場合、DODAG は接地されています（Grounded）。フラグがクリアされている場合、DODAG は浮動しています（Floating）。

Mode of Operation (MOP): : 動作モード (MOP) フィールドは、DODAG ルートで管理的にプロビジョニングおよび配布される RPL インスタンスの動作モードを識別します。DODAG に参加するすべてのノードは、ルーターとして完全に参加するために MOP を尊重できなければなりません。そうでない場合は、リーフとしてのみ参加しなければなりません。MOP は次の図のようにエンコードされます。

        +-----+-----------------------------------------------------+
        | 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                     |
        +-----+-----------------------------------------------------+

値 0 は、宛先通知メッセージが無効になっており、DODAG が上向きルートのみを維持することを示します。

Figure 15: Mode of Operation (MOP) Encoding

DODAGPreference (Prf): : この DODAG のルートがインスタンス内の他の DODAG ルートと比較してどの程度好ましいかを定義する 3 ビットの符号なし整数。DAGPreference の範囲は 0x00（最も好ましくない）から 0x07（最も好ましい）です。デフォルトは 0（最も好ましくない）です。セクション 8.2 では、DAGPreference が DIO 処理にどのように影響するかについて説明します。

Version Number: : DODAG ルートによって DODAGVersionNumber に設定される 8 ビットの符号なし整数。セクション 8.2 では、DODAGVersionNumber のルールと、それらが DIO 処理にどのように影響するかについて説明します。

Rank: : DIO メッセージを送信するノードの DODAG ランクを示す 16 ビットの符号なし整数。セクション 8.2 では、ランクの設定方法と、それが DIO 処理にどのように影響するかについて説明します。

RPLInstanceID: : DODAG がどの RPL インスタンスの一部であるかを示す、DODAG ルートによって設定される 8 ビットのフィールド。

Destination Advertisement Trigger Sequence Number (DTSN): : DIO メッセージを発行するノードによって設定される 8 ビットの符号なし整数。宛先通知トリガーシーケンス番号 (DTSN) フラグは、下向きルートを維持する手順の一部として使用されます。このプロセスの詳細については、セクション 9 で説明します。

Flags: : フラグ用に予約された 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Reserved: : 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

DODAGID: : DODAG を一意に識別する、DODAG ルートによって設定される 128 ビットの IPv6 アドレス。DODAGID は、DODAG ルートに属するルーティング可能な IPv6 アドレスでなければなりません（MUST）。

DIO ベースの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.3.2. セキュア DIO

セキュア DIO メッセージは図 7 の形式に従います。ここで、ベース形式は図 14 に示す DIO メッセージです。

6.3.3. DIO オプション

DIO メッセージは有効なオプションを運ぶことができます（MAY）。

この仕様では、DIO メッセージが次のオプションを運ぶことを許可しています。

• 0x00 Pad1
• 0x01 PadN
• 0x02 DAG Metric Container
• 0x03 Routing Information
• 0x04 DODAG Configuration
• 0x08 Prefix Information

6.4. 宛先通知オブジェクト (DAO)

宛先通知オブジェクト (DAO) は、宛先情報を DODAG に沿って上向きに伝播するために使用されます。格納モードでは、DAO メッセージは子から選択された親にユニキャストされます。非格納モードでは、DAO メッセージは DODAG ルートにユニキャストされます。DAO メッセージは、明示的な要求またはエラーに応じて、オプションで、その宛先によって宛先通知確認応答 (DAO-ACK) メッセージで DAO の送信者に確認応答される場合があります。

6.4.1. DAO ベースオブジェクトの形式

     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: : DIO から学習した、DODAG に関連付けられたトポロジインスタンスを示す 8 ビットのフィールド。

K: : 'K' フラグは、受信者が DAO-ACK を送り返すことが期待されていることを示します。（セクション 9.3 を参照。）

D: : 'D' フラグは、DODAGID フィールドが存在することを示します。ローカル RPLInstanceID が使用される場合、このフラグを設定しなければなりません（MUST）。

Flags: : Flags フィールドの残りの 6 ビットの未使用ビットは、フラグ用に予約されています。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Reserved: : 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

DAOSequence: : ノードからの一意の DAO メッセージごとに増分され、DAO-ACK メッセージでエコーされます。

DODAGID (optional): : DODAG を一意に識別する、DODAG ルートによって設定される 128 ビットの符号なし整数。このフィールドは、'D' フラグが設定されている場合にのみ存在します。通常、このフィールドは、RPLInstanceID に関連付けられた DODAGID を識別するために、ローカル RPLInstanceID が使用されている場合にのみ存在します。グローバル RPLInstanceID が使用されている場合、このフィールドは存在する必要はありません。

DAO ベースの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.4.2. セキュア DAO

セキュア DAO メッセージは図 7 の形式に従います。ここで、ベース形式は図 16 に示す DAO メッセージです。

6.4.3. DAO オプション

DAO メッセージは有効なオプションを運ぶことができます（MAY）。

この仕様では、DAO メッセージが次のオプションを運ぶことを許可しています。

• 0x00 Pad1
• 0x01 PadN
• 0x05 RPL Target
• 0x06 Transit Information
• 0x09 RPL Target Descriptor

No-Path と呼ばれる DAO メッセージの特殊なケースは、格納モードで DAO 操作を通じてプロビジョニングされた下向きルーティング状態をクリアするために使用されます。No-Path は、そのターゲットへの到達可能性の喪失を示すために、0x00000000 のライフタイムを持つ Target オプションと関連する Transit Information オプションを運びます。

6.5. 宛先通知オブジェクト確認応答 (DAO-ACK)

DAO-ACK メッセージは、ユニキャスト DAO メッセージに応答して、DAO 受信者（DAO 親または DODAG ルート）によってユニキャストパケットとして送信されます。

6.5.1. DAO-ACK ベースオブジェクトの形式

     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: : DIO から学習した、DODAG に関連付けられたトポロジインスタンスを示す 8 ビットのフィールド。

D: : 'D' フラグは、DODAGID フィールドが存在することを示します。これは通常、ローカル RPLInstanceID が使用される場合にのみ設定されます。

Reserved: : フラグ用に予約された 7 ビットのフィールド。

DAOSequence: : ノードからの DAO メッセージごとに増分され、受信者によって DAO-ACK でエコーされます。DAOSequence は、DAO メッセージと DAO ACK メッセージを相関させるために使用され、DODAG を下る特定のターゲットに関連付けられた Transit Information オプションのパスシーケンスと混同してはなりません。

Status: : 完了を示します。ステータス 0 は、この仕様では無条件の受け入れとして定義されています。残りのステータス値は拒否コードとして予約されています。この仕様では拒否ステータスコードは定義されていませんが、将来の仕様では次のガイドラインに従ってステータスコードを割り当てる必要があります（SHOULD）。

*   0: 無条件の受け入れ（つまり、DAO-ACK を受信したノードは拒否されません）。

*   1-127: 完全な拒否ではありません。DAO-ACK を送信するノードは親として機能する意思がありますが、受信ノードは代わりに代替の親を見つけて使用することをお勧めします。

*   127-255: 拒否。DAO-ACK を送信するノードは親として機能する意思がありません。

DODAGID (optional): : DODAG を一意に識別する、DODAG ルートによって設定される 128 ビットの符号なし整数。このフィールドは、'D' フラグが設定されている場合にのみ存在します。通常、このフィールドは、RPLInstanceID に関連付けられた DODAGID を識別するために、ローカル RPLInstanceID が使用されている場合にのみ存在します。グローバル RPLInstanceID が使用されている場合、このフィールドは存在する必要はありません。

DAO-ACK ベースの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.5.2. セキュア DAO-ACK

セキュア DAO-ACK メッセージは図 7 の形式に従います。ここで、ベース形式は図 17 に示す DAO-ACK メッセージです。

6.5.3. DAO-ACK オプション

この仕様では、DAO-ACK メッセージによって運ばれるオプションは定義されていません。

6.6. 整合性チェック (CC)

CC メッセージは、セキュアメッセージカウンターを確認し、チャレンジレスポンスを発行するために使用されます。CC メッセージは、セキュア RPL メッセージとして送信されなければなりません（MUST）。

6.6.1. CC ベースオブジェクトの形式

     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: : DIO から学習した、DODAG に関連付けられたトポロジインスタンスを示す 8 ビットのフィールド。

R: : 'R' フラグは、CC メッセージが応答であるかどうかを示します。'R' フラグがクリアされたメッセージは要求です。'R' フラグが設定されたメッセージは応答です。

Flags: : Flags フィールドの残りの 7 ビットの未使用ビットは、フラグ用に予約されています。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

CC Nonce: : CC 要求によって設定される 16 ビットの符号なし整数。対応する CC 応答には、要求と同じ CC ナンス値が含まれます。

DODAGID: : DODAG ルートの識別子を含む 128 ビットのフィールド。

Destination Counter: : 宛先の現在のセキュリティカウンター値の送信者の推定を示す 32 ビットの符号なし整数値。送信者が推定値を持っていない場合、Destination Counter フィールドをゼロに設定する必要があります（SHOULD）。

CC ベースの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

Destination Counter 値により、新しいノードまたは回復したノードは、CC メッセージ交換を通じて再同期できます。これは、カウンター状態の喪失を引き起こした障害からデバイスが回復した場合でも、特定のセキュリティキーに対してカウンター値が繰り返されないようにするために重要です。たとえば、CC 要求または他の RPL メッセージがメッセージセキュリティセクション内の初期化されたカウンターとともに受信された場合、CC 応答メッセージ内の Incoming Counter の提供により、要求ノードはその Outgoing Counter を応答ノードが受信した最後の値よりも大きい値にリセットできます。Incoming Counter も受信した CC 応答から更新されます。

6.6.2. CC オプション

この仕様では、CC メッセージが次のオプションを運ぶことを許可しています。

• 0x00 Pad1
• 0x01 PadN

6.7. RPL 制御メッセージオプション

6.7.1. RPL 制御メッセージオプションの一般的な形式

RPL 制御メッセージオプションはすべて次の形式に従います。

     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 ビット識別子。Option Type 値は IANA によって割り当てられます（セクション 20.4 を参照）。

Option Length: : Option Type フィールドと Length フィールドを含まない、オプションの長さ（オクテット単位）を表す 8 ビットの符号なし整数。

Option Data: : オプションに固有のデータを含む可変長フィールド。

Option Type 値が受信者によって認識されないオプションを含む RPL メッセージを処理する場合、受信者は認識されないオプションを黙って無視し（MUST）、次のオプションの処理を続行して、メッセージ内の残りのオプションを正しく処理しなければなりません（MUST）。

RPL メッセージオプションには、アライメント要件がある場合があります。IPv6 の規則に従い、アライメント要件のあるオプションは、各オプションの Option Data フィールド内のマルチオクテット値が自然な境界（つまり、幅 n オクテットのフィールドは、n = 1、2、4、または 8 の場合、ヘッダーの先頭から n オクテットの整数倍に配置される）に配置されるように、パケット内でアライメントされます。

6.7.2. Pad1

Pad1 オプションは、DIS、DIO、DAO、DAO-ACK、および CC メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     0
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |   Type = 0x00 |
    +-+-+-+-+-+-+-+-+

                Figure 20: Format of the Pad1 Option

Pad1 オプションは、オプションのアライメントを可能にするために、メッセージに 1 オクテットのパディングを挿入するために使用されます。複数のパディングオクテットが必要な場合は、複数の Pad1 オプションではなく PadN オプションを使用する必要があります。

注意！Pad1 オプションの形式は特殊なケースであり、Option Length フィールドも Option Data フィールドもありません。

6.7.3. PadN

PadN オプションは、DIS、DIO、DAO、DAO-ACK、および CC メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

PadN オプションは、オプションのアライメントを可能にするために、メッセージに 2 つ以上のパディングオクテットを挿入するために使用されます。PadN オプションデータは、受信者によって無視されなければなりません（MUST）。

Option Type: : 0x01

Option Length: : N オクテットのパディングの場合（2 <= N <= 7）、Option Length フィールドには値 N-2 が含まれます。Option Length が 0 の場合は、合計 2 オクテットのパディングを示します。Option Length が 5 の場合は、合計 7 オクテットのパディングを示します。これは、PadN オプションで許可される最大パディングサイズです。

Option Data: : N (N > 1) オクテットのパディングの場合、Option Data は N-2 個のゼロ値オクテットで構成されます。

6.7.4. DAG メトリックコンテナ

DAG メトリックコンテナオプションは、DIO または DAO メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

DAG メトリックコンテナは、DODAG に沿ってメトリックを報告するために使用されます。DAG メトリックコンテナには、実装者が選択した [RFC6551] で指定された個別のノード、リンク、および集約パスメトリックと制約がいくつか含まれる場合があります。

DAG メトリックコンテナは、たとえば Metric Data が 256 バイトより長いユースケースに対応するために、同じ RPL 制御メッセージに複数回表示される場合があります（MAY）。詳細については [RFC6551] にあります。

DAG メトリックコンテナの処理と伝播は、実装固有のポリシー関数によって管理されます。

Option Type: : 0x02

Option Length: : Option Length フィールドには、Metric Data の長さ（オクテット単位）が含まれます。

Metric Data: : DAG メトリックコンテナデータの順序、内容、およびコーディングは、[RFC6551] で指定されているとおりです。

6.7.5. ルーティング情報

ルーティング情報オプション (RIO) は、DIO メッセージに存在する場合があり（MAY）、[RFC4191] で定義されている IPv6 近隣探索 (ND) RIO と同じ情報を運びます。DODAG のルートはその情報を設定する権限があり、情報は DODAG を下って伝播されるときに変更されません。RPL ルーターは、それを ND オプションに簡単に変換して独自の RA で通知できるため、RPL ルーターに接続されたノードは、ルートがパケットの宛先に対して最も優先される DODAG を使用することになります。既存の ND セマンティクスに加えて、目的関数がこの情報を使用して、特定の宛先に対してルートが最も優先される DODAG を優先することが可能です。オプションの形式は、次のように RPL オプションとして運ばれるように少し変更されています（タイプ、長さ、プレフィックス）。

     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

RIO は、指定された宛先プレフィックスへの接続が DODAG ルートから利用可能であることを示すために使用されます。

RPL 制御メッセージが複数の宛先への接続を指定する必要がある場合、RIO は繰り返される場合があります。

RIO に関する信頼できる参照として [RFC4191] を参照する必要があります。ここでは、便宜上、フィールドの説明を転記します。

Option Type: : 0x03

Option Length: : 可変。タイプフィールドと長さフィールドを除く、オプションの長さ（オクテット単位）。IPv6 ND とは異なり、この長さは単一オクテットの単位で表されることに注意してください。

Prefix Length: : 8 ビットの符号なし整数。プレフィックス内の有効な先行ビットの数。値の範囲は 0 から 128 です。Prefix フィールドには、Option Length フィールドから推測されるバイト数があり、少なくとも Prefix Length である必要があります。RPL では、これは Prefix フィールドが 0、8、または 16 以外の長さを持つ可能性があることを意味することに注意してください。

Prf: : 2 ビットの符号付き整数。ルート優先度は、（異なるルーターに対して）複数の同一のプレフィックスが受信された場合に、このプレフィックスに関連付けられたルーターを他のルーターよりも優先するかどうかを示します。予約済み (10) の値が受信された場合、RIO は無視されなければなりません（MUST）。[RFC4191] に従い、予約済み (10) の値を送信してはなりません（MUST NOT）。（[RFC4191] では、優先度をメトリックではないことを強調するために、わずか 3 つの値に制限しています。）

Resvd: : 2 つの 3 ビット未使用フィールド。これらは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Route Lifetime: : 32 ビットの符号なし整数。プレフィックスがルート決定に有効である時間（パケットが送信された時間を基準とした秒単位）。すべて 1 のビットの値 (0xFFFFFFFF) は無限を表します。

Prefix: : IP アドレスまたは IPv6 アドレスのプレフィックスを含む可変長フィールド。Prefix Length フィールドには、プレフィックス内の有効な先行ビットの数が含まれます。プレフィックス長より後のプレフィックス内のビット（ある場合）は予約されており、送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません。RPL では、このフィールドは 0、8、または 16 以外の長さを持つ可能性があることに注意してください。

RIO の未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.7.6. DODAG 構成

DODAG 構成オプションは、DIO メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

DODAG 構成オプションは、DODAG を介して DODAG 操作の構成情報を配布するために使用されます。

このオプションで伝達される情報は、DODAG 内で一般に静的で不変であるため、すべての DIO に含める必要はありません。この情報は DODAG ルートで構成され、DODAG 構成オプションを使用して DODAG 全体に配布されます。DODAG ルート以外のノードは、DODAG 構成オプションを伝播するときにこの情報を変更してはなりません（MUST NOT）。このオプションは、DODAG ルートによって（DODAG ルートによって決定されるように）時折含まれる場合があり（MAY）、ユニキャスト要求（たとえば、ユニキャスト DODAG 情報要請 (DIS) メッセージ）への応答に含まれなければなりません（MUST）。

Option Type: : 0x04

Option Length: : 14

Flags: : Flags フィールドの残りの 4 ビットの未使用ビットは、フラグ用に予約されています。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Authentication Enabled (A): : ネットワークのセキュリティモードを記述する 1 ビットのフラグ。このビットは、ノードがルーターとしてネットワークに参加する前に、キー機関で認証する必要があるかどうかを示します。DIO がセキュア DIO でない場合、'A' ビットはゼロでなければなりません（MUST）。

Path Control Size (PCS): : パス制御フィールドに割り当てることができるビット数を構成するために使用される 3 ビットの符号なし整数（セクション 9.9 を参照）。PCS を参照してパス制御フィールドの幅を決定する場合、値 1 が加算されることに注意してください。つまり、PCS 値 0 は、パス制御フィールドの 1 つのアクティブビットになります。PCS のデフォルト値は DEFAULT_PATH_CONTROL_SIZE です。

DIOIntervalDoublings: : DIO トリクルタイマーの Imax を構成するために使用される 8 ビットの符号なし整数（セクション 8.3.1 を参照）。DIOIntervalDoublings のデフォルト値は DEFAULT_DIO_INTERVAL_DOUBLINGS です。

DIOIntervalMin: : DIO トリクルタイマーの Imin を構成するために使用される 8 ビットの符号なし整数（セクション 8.3.1 を参照）。DIOIntervalMin のデフォルト値は DEFAULT_DIO_INTERVAL_MIN です。

DIORedundancyConstant: : DIO トリクルタイマーの k を構成するために使用される 8 ビットの符号なし整数（セクション 8.3.1 を参照）。DIORedundancyConstant のデフォルト値は DEFAULT_DIO_REDUNDANCY_CONSTANT です。

MaxRankIncrease: : ローカル修復をサポートするためのランクの許容増加である DAGMaxRankIncrease を構成するために使用される 16 ビットの符号なし整数。DAGMaxRankIncrease が 0 の場合、このメカニズムは無効になります。

MinHopRankIncrease: : セクション 3.5.1 で説明されているように MinHopRankIncrease を構成するために使用される 16 ビットの符号なし整数。MinHopRankInc のデフォルト値は DEFAULT_MIN_HOP_RANK_INCREASE です。

Objective Code Point (OCP): : 16 ビットの符号なし整数。OCP フィールドは OF を識別し、IANA によって管理されます。

Reserved: : 7 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Default Lifetime: : 8 ビットの符号なし整数。これは、すべての RPL ルートのデフォルトとして使用されるライフタイムです。ライフタイム単位で表されます。たとえば、秒単位のデフォルトライフタイムは (Default Lifetime) * (Lifetime Unit) です。

Lifetime Unit: : 16 ビットの符号なし整数。RPL でルートライフタイムを表すために使用される単位（秒単位）を提供します。非常に安定したネットワークの場合、数時間から数日になる可能性があります。

6.7.7. RPL ターゲット

RPL ターゲットオプションは、DAO メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

RPL ターゲットオプションは、DODAG に沿って到達可能または照会されるターゲット IPv6 アドレス、プレフィックス、またはマルチキャストグループを示すために使用されます。DAO では、RPL ターゲットオプションは到達可能性を示します。

RPL ターゲットオプションは、ターゲットを修飾する RPL ターゲット記述子オプション（図 30）とオプションでペアにすることができます（MAY）。

1 つ以上のトランジット情報オプション（セクション 6.7.8）のセットは、DAO メッセージ内の 1 つ以上のターゲットオプションのセットの直後に続く場合があります（MAY）（ここで、各ターゲットオプションは上記のように RPL ターゲット記述子オプションとペアにすることができます（MAY））。ターゲットオプションをトランジット情報オプションと組み合わせて使用する方法を詳述する DAO メッセージの構造については、セクション 9.4 でさらに説明します。

RPL ターゲットオプションは、複数のターゲットを示すために必要に応じて繰り返すことができます。

Option Type: : 0x05

Option Length: : 可変。タイプフィールドと長さフィールドを除く、オプションの長さ（オクテット単位）。

Flags: : フラグ用に予約された 8 ビットの未使用フィールド。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Prefix Length: : 8 ビットの符号なし整数。IPv6 プレフィックス内の有効な先行ビットの数。

Target Prefix: : IPv6 宛先アドレス、プレフィックス、またはマルチキャストグループを識別する可変長フィールド。Prefix Length フィールドには、プレフィックス内の有効な先行ビットの数が含まれます。プレフィックス長より後のプレフィックス内のビット（ある場合）は予約されており、送信時にゼロに設定されなければならず（MUST）、受信時に無視されなければなりません（MUST）。

6.7.8. トランジット情報

トランジット情報オプションは、DAO メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

トランジット情報オプションは、ノードが 1 つ以上の宛先へのパスの属性を示すために使用されます。宛先は、トランジット情報オプションの直前にある 1 つ以上のターゲットオプションによって示されます。

トランジット情報オプションは、ノードが DODAG ルーティング情報を収集している先祖（通常はソースルートを構築するため）に DODAG 親を示すために使用できます。非格納モードの動作では、この先祖は DODAG ルートになり、このオプションは DAO メッセージによって運ばれます。格納モードの動作では、DAO メッセージは親に直接送信されるため、DODAG 親アドレスサブフィールドは必要ありません。オプションの長さは、DODAG 親アドレスサブフィールドが存在するかどうかを判断するために使用されます。

複数の DAO 親を持つ非格納ノードは、非格納宛先通知操作の一部として、各 DAO 親のトランジット情報オプションを含めることができます（MAY）。ノードは、親間の優先順位を通知するために、パス制御フィールドのビットを DAO 親の異なるグループ間で分散させることができます。その優先順位は、下向きルートを構築するための代替の親/パスの中から選択する際の DODAG ルートの決定に影響を与える可能性があります。

1 つ以上のトランジット情報オプションの前には、1 つ以上の RPL ターゲットオプションが必要です（MUST）。このようにして、RPL ターゲットオプションは子ノードを示し、トランジット情報オプションは DODAG 親を列挙します。ターゲットオプションをトランジット情報オプションと組み合わせて使用する方法をさらに詳述する DAO メッセージの構造については、セクション 9.4 でさらに説明します。

一般的な非格納ノードは複数のトランジット情報オプションを使用し、このように形成された DAO メッセージをルートに直接送信します。一般的な格納ノードは、親フィールドのない 1 つのトランジット情報オプションを使用し、このように形成された DAO メッセージを、後で詳しく説明するようにパス制御に追加の調整を加えて、1 つまたは複数の親に送信します。

たとえば、非格納モードの動作では、Tgt(T) をターゲット T のターゲットオプションとします。Trnst(P) を親アドレス P を含むトランジット情報オプションとします。自己所有ターゲット N1 と N2 を通知し、親 P1、P2、P3 を持つ非格納ノード N の場合を考えます。その場合、DAO メッセージにはシーケンス ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))) が含まれると予想されます。これにより、ターゲットオプションのグループ {N1, N2} は、親 {P1, P2, P3} を持つものとしてトランジット情報オプションによって記述されます。非格納ノードは、その DAO メッセージを DODAG ルートに直接アドレス指定し、DODAG 親の 1 つ（P1、P2、または P3）を介してその DAO メッセージを転送します。

Option Type: : 0x06

Option Length: : DODAG 親アドレスサブフィールドが存在するかどうかによって可変。

External (E): : 1 ビットのフラグ。'E' フラグは、親ルーターが外部ターゲットを RPL ネットワークに再配布することを示すために設定されます。外部ターゲットは、代替プロトコルを通じて学習されたターゲットです。外部ターゲットは、トランジット情報オプションの直前にあるターゲットオプションにリストされます。外部ターゲットは、RPL メッセージとオプションをサポートすることは期待されていません。

Flags: : Flags フィールドの残りの 7 ビットの未使用ビットは、フラグ用に予約されています。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Path Control: : 8 ビットのビットフィールド。パス制御フィールドは、特定の宛先への接続を通知する DAO メッセージを送信できる DAO 親の数を制限し、相対的な優先順位のいくつかの兆候を提供します。この制限は、LLN における全体的な DAO メッセージのファンアウトに何らかの境界を提供します。パス制御内のビットの割り当てと順序付けは、優先順位を伝えるためにも役立ちます。DODAG 構成の PCS に従って、これらのビットのすべてが有効になるわけではありません。パス制御フィールドは、図 27 に示すように、それぞれ 2 ビットを含む 4 つのサブフィールド PC1、PC2、PC3、および PC4 に分割されます。サブフィールドは優先順位順になっており、PC1 が最も優先され、PC4 が最も優先されません。サブフィールド内では、優先順位はありません。親をグループ化（ECMP のように）して順序付けることにより、親は優先順位を伝える方法でパス制御フィールドの特定のビットに関連付けることができます。

                                 0 1 2 3 4 5 6 7
                                +-+-+-+-+-+-+-+-+
                                |PC1|PC2|PC3|PC4|
                                +-+-+-+-+-+-+-+-+

          Figure 27: Path Control Preference Subfield Encoding

Path Sequence: : 8 ビットの符号なし整数。RPL ターゲットオプションがターゲットプレフィックスを所有するノードによって発行される場合（つまり、DAO メッセージ内）、そのノードはパスシーケンスを設定し、更新された情報を含む RPL ターゲットオプションを発行するたびにパスシーケンスを増分します。

Path Lifetime: : 8 ビットの符号なし整数。プレフィックスがルート決定に有効である時間（構成オプションから取得されたライフタイム単位）。期間は、新しいパスシーケンスが表示されたときに始まります。すべて 1 のビットの値 (0xFF) は無限を表します。すべて 0 のビットの値 (0x00) は、到達可能性の喪失を示します。ターゲットのパスライフタイムが 0x00 であるトランジット情報オプションを含む DAO メッセージは、このドキュメントでは（そのターゲットの）No-Path と呼ばれます。

Parent Address (optional): : もともとトランジット情報オプションを発行したノードの DODAG 親の IPv6 アドレス。このフィールドは、DODAG 動作モード（格納または非格納）およびトランジット情報オプションの長さによって示されるように、存在しない場合があります。

トランジット情報オプションの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.7.9. 要請情報

要請情報オプションは、DIS メッセージに存在する場合があり（MAY）、その形式は次のとおりです。

     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

要請情報オプションは、ノードが隣接ノードのサブセットから DIO メッセージを要求するために使用されます。要請情報オプションは、受信ノードによって一致されるいくつかの述語基準を指定できます。これは、要求者が「面白くない」ノードからの応答数を制限するために使用されます。これらの述語は、セクション 8.3 で説明されているように、ノードが DIO トリクルタイマーをリセットするかどうかに影響します。

要請情報オプションには、トリクルタイマーをリセットするかどうかを決定するときにノードがチェックする必要がある述語を示すフラグが含まれています。すべての述語が真の場合、ノードはトリクルタイマーをリセットします。フラグが設定されている場合、RPL ノードは関連する述語をチェックしなければなりません（MUST）。フラグがクリアされている場合、RPL ノードは関連する述語をチェックしてはなりません（MUST NOT）。（フラグがクリアされている場合、RPL ノードは関連する述語が真であると想定します。）

Option Type: : 0x07

Option Length: : 19

V: : 'V' フラグはバージョン述語です。受信者の DODAGVersionNumber が要求されたバージョン番号と一致する場合、バージョン述語は真です。'V' フラグがクリアされている場合、バージョンフィールドは無効であり、バージョンフィールドは送信時にゼロに設定され、受信時に無視されなければなりません（MUST）。

I: : 'I' フラグはインスタンス ID 述語です。RPL ノードの現在の RPLInstanceID が要求された RPLInstanceID と一致する場合、インスタンス ID 述語は真です。'I' フラグがクリアされている場合、RPLInstanceID フィールドは無効であり、RPLInstanceID フィールドは送信時にゼロに設定され、受信時に無視されなければなりません（MUST）。

D: : 'D' フラグは DODAGID 述語です。RPL ノードの親セットが DODAGID フィールドと同じ DODAGID を持っている場合、DODAGID 述語は真です。'D' フラグがクリアされている場合、DODAGID フィールドは無効であり、DODAGID フィールドは送信時にゼロに設定され、受信時に無視されなければなりません（MUST）。

Flags: : Flags フィールドの残りの 5 ビットの未使用ビットは、フラグ用に予約されています。このフィールドは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Version Number: : 有効な場合に要請されている DODAGVersionNumber の値を含む 8 ビットの符号なし整数。

RPLInstanceID: : 有効な場合に要請されている RPLInstanceID を含む 8 ビットの符号なし整数。

DODAGID: : 有効な場合に要請されている DODAGID を含む 128 ビットの符号なし整数。

要請情報オプションの未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.7.10. プレフィックス情報

プレフィックス情報オプション (PIO) は、DIO メッセージに存在する場合があり（MAY）、RPL ノードおよび IPv6 ホストが使用するために [RFC4861]、[RFC4862]、および [RFC6275] の IPv6 ND プレフィックス情報オプションで指定された情報を運びます。特に、RPL ノードは、[RFC4862] で指定されているように親によって通知されたプレフィックスからのステートレスアドレス自動構成 (SLAAC) の目的でこのオプションを使用し、[RFC6275] で指定されているように独自のアドレスを通知する場合があります。DODAG のルートはその情報を設定する権限があります。情報は DODAG を下って変更されずに伝播されますが、例外として、PIO 内の完全なアドレスを示すために 'R' フラグが設定されている場合、RPL ルーターはインターフェイス ID を上書きする場合があります（MAY）。オプションの形式は、次のように RPL オプションとして運ばれるように変更されています（タイプ、長さ、プレフィックス）。

受信した DIO 内の PIO の唯一の望ましい効果が、親ノードのグローバルアドレスを受信ノードに提供することである場合、送信者は 'A' および 'L' ビットをリセットし、'R' ビットを設定します。受信すると、RPL はプレフィックス [RFC4862] からアドレスまたは接続ルートを自動構成しません。すべての場合と同様に、'L' ビットが設定されていない場合、RPL ノードは子に送信する PIO にプレフィックスを含めることができます（MAY）。

     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

PIO は、たとえばアドレス自動構成のために、DODAG 内で使用されているプレフィックスを配布するために使用できます。

PIO に関する信頼できる参照として [RFC4861] および [RFC6275] を参照する必要があります。ここでは、便宜上、フィールドの説明を転記します。

Option Type: : 0x08

Option Length: : 30。IPv6 ND とは異なり、この長さは単一オクテットの単位で表されることに注意してください。

Prefix Length: : 8 ビットの符号なし整数。Prefix フィールド内の有効な先行ビットの数。値の範囲は 0 から 128 です。Prefix Length フィールドは、オンリンク決定に必要な情報を提供します（PIO の 'L' フラグと組み合わせた場合）。また、[RFC4862] で指定されているアドレス自動構成も支援します。これには、プレフィックス長にさらに制限がある場合があります。

L: : 1 ビットのオンリンクフラグ。設定されている場合、このプレフィックスがオンリンク決定に使用できることを示します。設定されていない場合、アドバタイズメントはプレフィックスのオンリンクまたはオフリンクのプロパティについて何も述べません。つまり、'L' フラグが設定されていない場合、RPL ノードはプレフィックスから派生したアドレスがオフリンクであると結論付けてはなりません（MUST NOT）。つまり、アドレスがオンリンクであるという以前の表示を更新してはなりません（MUST NOT）。ルーターとして機能する RPL ノードは、'L' フラグが設定された PIO を伝播してはなりません（MUST NOT）。ルーターとして機能する RPL ノードは、'L' フラグが設定されていない PIO を伝播する場合があります（MAY）。

A: : 1 ビットの自律アドレス構成フラグ。設定されている場合、このプレフィックスが [RFC4862] で指定されているステートレスアドレス構成に使用できることを示します。両方のプロトコル（ND RA と RPL DIO）を使用して同じリンクで PIO を運ぶ場合、RPL ノードによる SLAAC にどちらか一方を使用できます。そのプロトコルで運ばれる PIO の 'A' フラグを 0 に強制することにより、どちらかのプロトコルを SLAAC 操作の対象外にすることも可能です。

R: : 1 ビットのルーターアドレスフラグ。設定されている場合、Prefix フィールドに、ターゲットオプションで親として使用できる送信ルーターに割り当てられた完全な IPv6 アドレスが含まれていることを示します。示されたプレフィックスは、Prefix フィールドの最初の Prefix Length ビットです。ルーター IPv6 アドレスは同じスコープを持ち、通知されたプレフィックスと同じライフタイム値に準拠します。Prefix フィールドのこの使用法は、プレフィックス自体を通知する場合の使用法と互換性があります。プレフィックス通知では先行ビットのみが使用されるためです。したがって、このフラグビットの解釈は、オンリンク (L) および自律アドレス構成 (A) フラグビットに必要な処理とは無関係です。

Reserved1: : 5 ビットの未使用フィールド。これは送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Valid Lifetime: : 32 ビットの符号なし整数。プレフィックスがオンリンク決定の目的で有効である時間（パケットが送信された時間を基準とした秒単位）。すべて 1 のビットの値 (0xFFFFFFFF) は無限を表します。Valid Lifetime は [RFC4862] でも使用されます。

Preferred Lifetime: : 32 ビットの符号なし整数。ステートレスアドレス自動構成を介してプレフィックスから生成されたアドレスが優先され続ける時間（パケットが送信された時間を基準とした秒単位）[RFC4862]。すべて 1 のビットの値 (0xFFFFFFFF) は無限を表します。[RFC4862] を参照してください。このフィールドの値は、もはや有効ではないアドレスを優先しないように、Valid Lifetime フィールドを超えてはならないことに注意してください（MUST NOT）。

Reserved2: : このフィールドは未使用です。送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません（MUST）。

Prefix: : IPv6 アドレスまたは IPv6 アドレスのプレフィックス。Prefix Length フィールドには、プレフィックス内の有効な先行ビットの数が含まれます。プレフィックス長より後のプレフィックス内のビットは予約されており、送信者によってゼロに初期化されなければならず（MUST）、受信者によって無視されなければなりません。ルーターはリンクローカルプレフィックスのプレフィックスオプションを送信すべきではなく（SHOULD NOT）、ホストはそのようなプレフィックスオプションを無視すべきです（SHOULD）。非格納ノードは、そのプレフィックスのアドレスを所有するまでプレフィックスの通知を控えるべきであり（SHOULD）、その後、このフィールドで完全なアドレスを通知し（SHOULD）、'R' フラグを設定する必要があります。そのように 'R' フラグを設定して完全なアドレスを通知するノードの子は、そのアドレスを使用して、トランジット情報オプションの DODAG 親アドレスサブフィールドの内容を決定できます。

PIO の未割り当てビットは予約されています。送信時にはゼロに設定されなければならず（MUST）、受信時には無視されなければなりません（MUST）。

6.7.11. RPL ターゲット記述子

RPL ターゲットオプションの直後には、その特定のターゲットを修飾する 1 つの不透明な記述子が続く場合があります（MAY）。

     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

RPL ターゲット記述子オプションは、ターゲットを修飾するために使用されます。これは、「タグ付け」と呼ばれることもあります。

ターゲットごとに最大 1 つの記述子を含めることができます。記述子は、RPL ネットワークにターゲットを注入するノードによって設定されます。DAO メッセージでターゲットを DODAG の上に伝播するルーターによってコピーされなければなりませんが、変更されてはなりません（MUST）。

Option Type: : 0x09

Option Length: : 4

Descriptor: : 32 ビットの符号なし整数。不透明。