[要約] RFC 6997は、低消費電力かつ損失の多いネットワークでのポイントツーポイントルートの反応型発見に関するものです。このRFCの目的は、ネットワーク内のノード間の最適な通信経路を効率的に見つけることです。
Internet Engineering Task Force (IETF) M. Goyal, Ed.
Request for Comments: 6997 Univ. of Wisconsin Milwaukee
Category: Experimental E. Baccelli
ISSN: 2070-1721 M. Philipp
INRIA
A. Brandt
Sigma Designs
J. Martocci
Johnson Controls
August 2013
Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks
低電力および損失の多いネットワークにおけるポイントツーポイントルートのリアクティブディスカバリ
Abstract
概要
This document specifies a point-to-point route discovery mechanism, complementary to the Routing Protocol for Low-power and Lossy Networks (RPL) core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in a Low-power and Lossy Network (LLN) such that the discovered routes meet specified metrics constraints.
このドキュメントでは、ポイントツーポイントのルート検出メカニズムについて説明します。これは、低電力および損失の多いネットワーク（RPL）コア機能のルーティングプロトコルを補完するものです。このメカニズムにより、IPv6ルーターは、低電力および損失の多いネットワーク（LLN）内の1つ以上のIPv6ルーターへの「オンデマンド」ルートを検出できるため、検出されたルートは指定されたメトリック制約に適合します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの試験運用プロトコルを定義しています。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6997.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6997で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. The Use Cases ...................................................4
3. Terminology .....................................................5
4. Applicability ...................................................6
5. Functional Overview .............................................7
6. P2P Route Discovery Mode of Operation ..........................10
6.1. Setting a P2P Mode DIO ....................................10
7. P2P Route Discovery Option (P2P-RDO) ...........................15
8. The P2P Discovery Reply Object (P2P-DRO) .......................18
8.1. Secure P2P-DRO ............................................20
8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply
Object ....................................................21
9. P2P-RPL Route Discovery by Creating a Temporary DAG ............21
9.1. Joining a Temporary DAG ...................................21
9.2. Trickle Operation for P2P Mode DIOs .......................22
9.3. Processing a P2P Mode DIO .................................24
9.4. Additional Processing of a P2P Mode DIO at an
Intermediate Router .......................................26
9.5. Additional Processing of a P2P Mode DIO at the Target .....27
9.6. Processing a P2P-DRO at an Intermediate Router ............28
9.7. Processing a P2P-DRO at the Origin ........................30
10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK) ..31
11. Secure P2P-RPL Operation ......................................32
12. Packet Forwarding along a Route Discovered Using P2P-RPL ......33
13. Interoperability with Core RPL ................................34
14. Security Considerations .......................................34
15. IANA Considerations ...........................................36
15.1. Additions to Mode of Operation ...........................36
15.2. Additions to RPL Control Message Options .................36
15.3. Additions to RPL Control Codes ...........................36
16. Known Issues and Future Work ..................................37
17. Acknowledgements ..............................................37
18. References ....................................................38
18.1. Normative References .....................................38
18.2. Informative References ...................................38
Targeting Low-power and Lossy Networks (LLNs), the IPv6 Routing Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed Acyclic Graph (DAG) rooted at a single router in the network. Establishment and maintenance of a DAG are performed by routers in the LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) messages. When two arbitrary routers (neither of which is the DAG's root) need to communicate, the data packets are restricted to travel only along the links in the DAG. Such point-to-point (P2P) routing functionality may not be sufficient for several home automation [RFC5826] and building automation [RFC5867] applications, due to the following reasons:
低電力および損失の多いネットワーク（LLN）を対象としたLLN向けIPv6ルーティングプロトコル（RPL）[RFC6550]は、ネットワーク内の単一のルーターをルートとする有向非巡回グラフ（DAG）に沿ったパスを提供します。 DAGの確立と保守は、宛先指向DAG（DODAG）情報オブジェクト（DIO）メッセージを使用して、LLN内のルーターによって実行されます。 2つの任意のルーター（どちらもDAGのルートではない）が通信する必要がある場合、データパケットはDAG内のリンクに沿ってのみ移動するように制限されます。次の理由により、このようなポイントツーポイント（P2P）ルーティング機能は、いくつかのホームオートメーション[RFC5826]およびビルディングオートメーション[RFC5867]アプリケーションには不十分な場合があります。
o The need to pre-establish routes: Each potential destination in the network must declare itself as such ahead of the time a source needs to reach it.
o ルートを事前に確立する必要性：ネットワーク内の潜在的な各宛先は、ソースがそれに到達する必要がある前に、それ自体を宣言する必要があります。
o The need to route only along the links in the DAG: A DAG is built to optimize the routing cost to reach the root. Restricting P2P routes to use only the in-DAG links may result in significantly suboptimal routes and severe traffic congestion near the DAG root.
o DAG内のリンクに沿ってのみルーティングする必要性：DAGは、ルートに到達するためのルーティングコストを最適化するために構築されています。 D2G内リンクのみを使用するようにP2Pルートを制限すると、DAGルートの近くでルートが大幅に最適化されず、深刻なトラフィックの輻輳が発生する可能性があります。
This document describes an extension to core RPL (i.e., the RPL functionality described in [RFC6550]) that enables an IPv6 router in the LLN to discover routes to one or more IPv6 routers in the LLN "on demand". The discovered routes may not be the best available but are guaranteed to meet the specified routing metric constraints. Thus, such routes are considered "good enough" from the application's perspective. This reactive P2P route discovery mechanism is henceforth referred to as P2P-RPL.
このドキュメントでは、LLNのIPv6ルーターがLLNの1つまたは複数のIPv6ルーターへのルートを「オンデマンド」で検出できるようにするコアRPL（つまり、[RFC6550]で説明されているRPL機能）の拡張について説明します。検出されたルートは、最良のルートではない可能性がありますが、指定されたルーティングメトリックの制約を満たすことが保証されています。したがって、このようなルートは、アプリケーションの観点からは「十分に良い」と見なされます。このリアクティブP2Pルート検出メカニズムは、以降、P2P-RPLと呼ばれます。
A mechanism to measure the end-to-end cost of an existing route is specified in [RFC6998]. As discussed in Section 4, measuring the end-to-end cost of an existing route may help in deciding whether to initiate the discovery of a better route using P2P-RPL and the metric constraints to be used for this purpose.
既存のルートのエンドツーエンドのコストを測定するメカニズムは、[RFC6998]で指定されています。セクション4で説明したように、既存のルートのエンドツーエンドのコストを測定すると、P2P-RPLとこの目的に使用されるメトリック制約を使用して、より適切なルートの発見を開始するかどうかを決定するのに役立ちます。
One use case, common in home [RFC5826] and commercial building [RFC5867] environments, involves a device (say, a remote control) that suddenly needs to communicate with another device (say, a lamp) to which it does not already have a route (and whose network address it knows a priori). In this case, the remote control must be able to discover a route to the lamp "on demand".
家庭[RFC5826]や商業ビル[RFC5867]の環境で一般的な1つの使用例は、突然それがまだ持っていない別のデバイス（たとえば、ランプ）と通信する必要があるデバイス（たとえば、リモコン）を必要とします。ルート（およびそのネットワークアドレスがアプリオリに知っている）。この場合、リモコンは「オンデマンド」でランプへのルートを検出できる必要があります。
Another use case, common in a commercial building environment, involves a large LLN deployment where P2P communication along a particular DAG among hundreds (or thousands) of routers creates severe traffic congestion near that DAG's root. In this case, it is desirable to discover direct routes between various source-destination pairs that do not pass through the DAG's root.
商業建築環境で一般的な別の使用例は、大規模なLLN展開を含み、数百（または数千）のルーター間で特定のDAGに沿ったP2P通信が、そのDAGのルートの近くで深刻なトラフィックの輻輳を作成します。この場合、DAGのルートを通過しないさまざまな送信元と宛先のペア間の直接ルートを検出することが望ましいです。
Other use cases involve scenarios where energy or latency constraints are not satisfied by the P2P routes along an existing DAG because they involve traversing many more routers than necessary to reach the destination.
その他のユースケースには、宛先に到達するために必要以上に多くのルーターを通過するため、既存のDAGに沿ったP2Pルートによってエネルギーまたは遅延の制約が満たされないシナリオが含まれます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses terminology from [RFC6550] and [RFC6554]. Further terminology may be found in [ROLL-TERMS]. This document introduces the following terms:
さらに、このドキュメントでは、[RFC6550]と[RFC6554]の用語を使用しています。 [ROLL-TERMS]でさらに用語が見つかる場合があります。このドキュメントでは、次の用語を紹介します。
Origin: The IPv6 router initiating the P2P-RPL route discovery.
発信元：P2P-RPLルート探索を開始するIPv6ルーター。
Target: The IPv6 router at the other end point of the P2P route(s) to be discovered. A P2P-RPL route discovery can discover routes to multiple Targets at the same time.
ターゲット：検出されるP2Pルートのもう一方のエンドポイントのIPv6ルーター。 P2P-RPLルートディスカバリでは、複数のターゲットへのルートを同時に検出できます。
Intermediate Router: An IPv6 router that is neither the Origin nor a Target.
中間ルーター：オリジンでもターゲットでもないIPv6ルーター。
Forward direction: The direction from the Origin to the Target.
順方向：原点からターゲットへの方向。
Reverse direction: The direction from the Target to the Origin.
逆方向：ターゲットから原点への方向。
Forward Route: A route in the Forward direction.
転送ルート：転送方向のルート。
Reverse Route: A route in the Reverse direction.
逆ルート：逆方向のルート。
Bidirectional Route: A route that can be used in both Forward and Reverse directions.
双方向ルート：順方向と逆方向の両方で使用できるルート。
Ingress-only Interface: A network interface that can only receive packets.
入力専用インターフェース：パケットのみを受信できるネットワークインターフェース。
Egress-only Interface: A network interface that can only send packets.
出力専用インターフェース：パケットのみを送信できるネットワークインターフェース。
Source Route: A complete and ordered list of routers that can be used by a packet to travel from a source to a destination node.
送信元ルート：パケットが送信元から宛先ノードに移動するために使用できるルーターの完全で順序付けられたリスト。
Hop-by-hop Route: The route characterized by each router on the route using its routing table to determine the next hop on the route.
ホップバイホップルート：ルーティングテーブルを使用してルート上の次のホップを決定する、ルート上の各ルーターによって特徴付けられるルート。
RPL Security Configuration: The values for the Counter is Time, Security Algorithm, Key Identifier Mode, and Security Level fields, as defined in Section 6.1 of [RFC6550], inside the Security section of a secure RPL control message.
RPLセキュリティ構成：カウンターの値は、[RFC6550]のセクション6.1で定義されているように、時間、セキュリティアルゴリズム、キー識別子モード、およびセキュリティレベルのフィールドであり、セキュアRPL制御メッセージのセキュリティセクション内にあります。
A route discovery using P2P-RPL may be performed by an Origin when no route exists between itself and the Target(s) or when the existing routes do not satisfy the application requirements. P2P-RPL is designed to discover Hop-by-hop or Source Routes to one or more Targets such that the discovered routes meet the specified constraints. In some application contexts, the constraints that the discovered routes must satisfy are intrinsically known or can be specified by the application. For example, an Origin that expects its Targets to be less than 5 hops away may use "hop-count < 5" as the constraint. In other application contexts, the Origin may need to measure the cost of the existing route to a Target to determine the constraints. For example, an Origin that measures the total expected transmission count (ETX) along its current route to a Target to be 20 may use "ETX < x*20", where x is a fraction that the Origin chooses, as the constraint. A mechanism to measure the cost of an existing route between two IPv6 routers is specified in [RFC6998]. If there is no existing route between the Origin and the Target(s) or the cost measurement for the existing routes fails, the Origin will have to guess the constraints to be used in the initial route discovery. Once the initial route discovery succeeds or fails, the Origin will have a better estimate for the constraints to be used in the subsequent route discovery.
P2P-RPLを使用したルート検出は、それ自体とターゲットの間にルートが存在しない場合、または既存のルートがアプリケーションの要件を満たさない場合に、オリジンによって実行されます。 P2P-RPLは、1つ以上のターゲットへのホップバイホップまたはソースルートを検出して、検出されたルートが指定された制約を満たすように設計されています。一部のアプリケーションコンテキストでは、検出されたルートが満たす必要がある制約は、本質的に既知であるか、アプリケーションで指定できます。たとえば、ターゲットが5ホップ未満離れていることを期待しているオリジンは、「ホップカウント<5」を制約として使用できます。他のアプリケーションコンテキストでは、Originは、制約を決定するために、Targetへの既存のルートのコストを測定する必要がある場合があります。たとえば、ターゲットへの現在のルートに沿って予想される総送信数（ETX）を測定して20になるOriginは、「ETX <x * 20」を使用できます。 2つのIPv6ルーター間の既存のルートのコストを測定するメカニズムは、[RFC6998]で指定されています。 OriginとTargetの間に既存のルートがない場合、または既存のルートのコスト測定が失敗した場合、Originは最初のルート検出で使用される制約を推測する必要があります。最初のルートディスカバリが成功または失敗すると、Originは、後続のルートディスカバリで使用される制約についてより適切な推定を行います。
P2P-RPL may result in discovery of better P2P routes than those available along a global DAG designed to optimize routing cost to the DAG's root. The improvement in route quality depends on a number of factors, including the network topology, the "distance" between the Origin and the Target (in terms of the routing metrics in use), and the prevalent conditions in the network. In general, a P2P-RPL route may be better than the one along a global DAG if the Origin and the Target are nearby. Similarly, a P2P-RPL route may not be much better than the one along a global DAG if the Origin and the Target are far apart. Note that even when P2P-RPL routes are not much better than those along a global DAG, P2P-RPL routes may still be able to avoid congestion that might occur near the root if the routing takes place only along a global DAG. In general, the cost associated with a P2P-RPL route discovery (in terms of the control messages -- mostly DIOs -- generated) increases with the distance between the Origin and the Target. However, it is possible to limit the cost of route discovery by carefully setting the routing constraints, the Trickle parameters (which govern DIO generation), and the time duration for which a router maintains its membership in the temporary DAG created for the route discovery. A network designer may take into consideration both the benefits (potentially better routes; no need to maintain routes proactively; avoid congestion near the global DAG's root) and costs when using P2P-RPL. The latency associated with a P2P-RPL route discovery again depends on the distance between the Origin and the Target and on the Trickle parameters.
P2P-RPLは、DAGのルートへのルーティングコストを最適化するように設計されたグローバルDAGに沿って利用可能なルートよりも優れたP2Pルートを発見する可能性があります。ルートの品質の向上は、ネットワークトポロジ、（使用中のルーティングメトリックに関する）オリジンとターゲットの間の「距離」、およびネットワークの一般的な条件など、いくつかの要因に依存します。一般に、P2P-RPLルートは、オリジンとターゲットが近くにある場合、グローバルDAGに沿ったルートよりも優れている場合があります。同様に、P2P-RPLルートは、OriginとTargetが離れている場合、グローバルDAGに沿ったルートよりもはるかに優れているとは限りません。 P2P-RPLルートがグローバルDAGに沿ったルートよりも優れていない場合でも、ルーティングがグローバルDAGに沿ってのみ行われる場合、P2P-RPLルートはルート付近で発生する可能性がある輻輳を回避できることに注意してください。一般に、P2P-RPLルートディスカバリに関連するコスト（制御メッセージ（主にDIO）の生成）は、オリジンとターゲット間の距離に応じて増加します。ただし、ルーティング制約、トリクルパラメーター（DIO生成を制御）、およびルーターがルート検出用に作成された一時DAGのメンバーシップを維持する期間を慎重に設定することにより、ルート検出のコストを制限することが可能です。ネットワーク設計者は、P2P-RPLを使用する際の利点（潜在的に優れたルート、積極的にルートを維持する必要がない、グローバルDAGのルート付近の輻輳を回避する）とコストの両方を考慮に入れる場合があります。 P2P-RPLルートディスカバリに関連するレイテンシは、オリジンとターゲット間の距離とトリクルパラメータに依存します。
Like core RPL [RFC6550], P2P-RPL operation requires that links have bidirectional reachability. For this reason, the routers participating in a P2P-RPL route discovery must ensure that
コアRPL [RFC6550]と同様に、P2P-RPL操作では、リンクに双方向の到達可能性が必要です。このため、P2P-RPLルート検出に参加しているルーターは、
o Links that do not have bidirectional reachability do not become part of the route being discovered; and
o 双方向の到達可能性を持たないリンクは、検出されるルートの一部にはなりません。そして
o IPv6 addresses belonging to Ingress-only (or Egress-only) Interfaces do not become part of the route being discovered.
o 入力専用（または出力専用）インターフェースに属するIPv6アドレスは、ディスカバーされる経路の一部にはなりません。
This section contains a high-level description of P2P-RPL.
このセクションでは、P2P-RPLの概要について説明します。
A P2P-RPL route discovery takes place by forming a DAG rooted at the Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast DIO messages to establish a DAG. However, unlike core RPL, this DAG is temporary in nature. The routes are discovered and installed while the DAG is alive. Once the specified duration of their membership in the DAG is over, the routers leave the DAG, and hence the DAG ceases to exist. However, the installed routes are retained for their specified lifetime (which is different than the specified duration of a router's membership in the DAG) even though the DAG that caused their installation no longer exists. In P2P-RPL, the sole purpose of DAG creation is to discover routes to the Target(s), and DIOs serve as the route discovery messages. Each router joining the DAG determines a rank for itself in the DAG and ignores the subsequent DIOs received from lower-ranked (higher in numerical value) neighbors. Thus, the route discovery messages propagate away from the Origin rather than return to it. As in core RPL, DIO generation at a router is controlled by a Trickle timer [RFC6206], which allows a router to avoid generating unnecessary messages while providing protection against packet loss. P2P-RPL also uses the routing metrics [RFC6551], Objective Functions, and packet-forwarding framework [RFC6554] [RFC6553] developed for core RPL.
P2P-RPLルート検出は、オリジンをルートとするDAGを形成することによって行われます。コアRPLと同様に、P2P-RPLはIPv6リンクローカルマルチキャストDIOメッセージを使用してDAGを確立します。ただし、コアRPLとは異なり、このDAGは一時的なものです。ルートは、DAGの稼働中に検出およびインストールされます。 DAGのメンバーシップの指定された期間が終了すると、ルーターはDAGを離れるため、DAGは存在しなくなります。ただし、インストールされたルートは、インストールの原因となったDAGが存在しなくても、指定された有効期間（DAGでのルーターのメンバーシップの指定された期間とは異なります）保持されます。 P2P-RPLでは、DAG作成の唯一の目的はターゲットへのルートを検出することであり、DIOはルート検出メッセージとして機能します。 DAGに参加する各ルーターは、DAG内での自身のランクを決定し、ランクの低い（数値が大きい）ネイバーから受信した後続のDIOを無視します。したがって、ルート検出メッセージは、オリジンに戻るのではなく、オリジンから離れて伝播します。コアRPLと同様に、ルーターでのDIO生成は、トリクルタイマー[RFC6206]によって制御されます。これにより、ルーターは、パケット損失に対する保護を提供しながら、不要なメッセージの生成を回避できます。 P2P-RPLは、コアRPL用に開発されたルーティングメトリック[RFC6551]、目的関数、およびパケット転送フレームワーク[RFC6554] [RFC6553]も使用します。
An Origin may use P2P-RPL to discover routes to one or more Targets identified by one or more unicast/multicast addresses. P2P-RPL allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target. The discovered routes are guaranteed to meet the specified routing metric constraints but may not be the best available. P2P-RPL may fail to discover any route if the specified routing constraints are overly strict.
オリジンはP2P-RPLを使用して、1つ以上のユニキャスト/マルチキャストアドレスで識別される1つ以上のターゲットへのルートを検出できます。 P2P-RPLを使用すると、1つのホップバイホップルートまたはターゲットごとに最大4つのソースルートを検出できます。検出されたルートは、指定されたルーティングメトリックの制約を満たすことが保証されていますが、最適なルートとは限りません。指定されたルーティング制約が厳しすぎると、P2P-RPLがルートの検出に失敗する場合があります。
The Origin initiates a P2P-RPL route discovery by forming a temporary DAG rooted at itself. The DIOs used to create the temporary DAG are identified by a new Mode of Operation (P2P Route Discovery mode, defined in Section 6). The DIOs listing the P2P Route Discovery mode as the Mode of Operation are henceforth referred to as the P2P mode DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery Option (P2P-RDO, defined in Section 7) in which the Origin specifies the following information:
オリジンは、自身をルートとする一時的なDAGを形成することにより、P2P-RPLルートディスカバリを開始します。一時DAGの作成に使用されるDIOは、新しい操作モード（セクション6で定義されているP2Pルート検出モード）によって識別されます。動作モードとしてP2Pルート検出モードをリストするDIOは、以降、P2PモードDIOと呼ばれます。 P2PモードDIOは常に、1つだけのP2Pルート検出オプション（セクション7で定義されたP2P-RDO）を伝送します。ここで、オリジンは次の情報を指定します。
o The IPv6 address of a Target. This could be a unicast address or a multicast address. Any additional Targets may be specified by including one or more RPL Target options [RFC6550] inside the DIO.
o ターゲットのIPv6アドレス。これは、ユニキャストアドレスまたはマルチキャストアドレスです。追加のターゲットは、DIO内に1つ以上のRPLターゲットオプション[RFC6550]を含めることで指定できます。
o The nature of the route(s) to be discovered: Hop-by-hop or Source Routes. This specification allows for the discovery of one Hop-by-hop Route or up to four Source Routes per Target.
o 検出されるルートの性質：ホップバイホップまたはソースルート。この仕様により、1つのホップバイホップルートまたはターゲットごとに最大4つのソースルートを検出できます。
o The desired number of routes (if Source Routes are being discovered).
o ルートの希望数（ソースルートが検出されている場合）。
o Whether the Target(s) should send P2P Discovery Reply Object (P2P-DRO) messages (defined in Section 8) back to the Origin on receiving a DIO message. A P2P-DRO message carries a discovered Source Route back to the Origin or establishes a Hop-by-hop Route between the Origin and the Target.
o DIOメッセージの受信時に、ターゲットがP2Pディスカバリ応答オブジェクト（P2P-DRO）メッセージ（セクション8で定義）をオリジンに送信するかどうか。 P2P-DROメッセージは、発見されたソースルートをオリジンに戻すか、オリジンとターゲットの間にホップバイホップルートを確立します。
A P2P-RDO also includes the best route from the Origin that the router, generating the P2P mode DIO, has seen so far.
P2P-RDOには、P2PモードDIOを生成するルーターがこれまでに確認した、オリジンからの最適ルートも含まれています。
A P2P mode DIO MAY also carry:
P2PモードのDIOには、次の機能もあります。
o One or more Metric Container options to specify:
o 指定する1つ以上のメトリックコンテナオプション：
* The relevant routing metrics.
* 関連するルーティングメトリック。
* The constraints that the discovered route must satisfy. These constraints also limit how far the DIO messages may travel.
* 検出されたルートが満たす必要がある制約。これらの制約により、DIOメッセージの移動距離も制限されます。
o One or more RPL Target options to specify additional unicast or multicast Targets.
o 追加のユニキャストまたはマルチキャストターゲットを指定する1つ以上のRPLターゲットオプション。
As the routers join the temporary DAG, they keep track of the best route(s) (so far from the Origin) they have seen and advertise these routes, along with the corresponding routing metrics, in their P2P mode DIOs. A router, including the Target(s), discards a received P2P mode DIO if the aggregated routing metrics on the route advertised by the DIO do not satisfy the listed constraints. These constraints can be used to limit the propagation of P2P mode DIO messages. A router may also discard a received P2P mode DIO if it does not wish to be a part of the discovered route due to limited resources or due to policy reasons.
ルーターが一時的なDAGに参加すると、ルーターは（オリジンからこれまでのところ）最適なルートを追跡し、P2PモードのDIOでこれらのルートと対応するルーティングメトリックをアドバタイズします。ターゲットを含むルーターは、DIOによってアドバタイズされたルート上の集約ルーティングメトリックがリストされた制約を満たさない場合、受信したP2PモードDIOを破棄します。これらの制約を使用して、P2PモードのDIOメッセージの伝搬を制限できます。ルーターは、リソースの制限やポリシー上の理由により、検出されたルートの一部になりたくない場合、受信したP2PモードDIOを破棄する場合もあります。
When a Target receives a P2P mode DIO, it contains inside the P2P-RDO a complete Source Route from the Origin to this Target. Since the links in the discovered route have bidirectional reachability (Section 7), the Target may use the discovered route to reach the Origin. Thus, a router that provides a particular service in the LLN (e.g., an outside temperature server) could initiate a P2P-RPL route discovery listing all its potential clients as Targets, thereby allowing the clients to discover a Source Route back to the server. In this case, the Origin (the server) might want to disable the generation of P2P-DRO messages by the Targets (the clients). If the Origin has requested that P2P-DRO messages be sent back, the Target may select the discovered route in the received DIO for further processing, as described next. This document does not specify a particular method for the Target to use to select a route for further processing. Example methods include selecting any route that meets the constraints or selecting the best route(s) discovered over a certain time period.
ターゲットがP2PモードDIOを受信すると、P2P-RDO内に、オリジンからこのターゲットへの完全なソースルートが含まれます。検出されたルートのリンクには双方向の到達可能性があるため（セクション7）、ターゲットは検出されたルートを使用してオリジンに到達できます。したがって、LLNで特定のサービスを提供するルーター（外気温サーバーなど）は、すべての潜在的なクライアントをターゲットとしてリストするP2P-RPLルートディスカバリーを開始できます。これにより、クライアントはサーバーへのソースルートを検出できます。この場合、オリジン（サーバー）はターゲット（クライアント）によるP2P-DROメッセージの生成を無効にすることができます。オリジンがP2P-DROメッセージの返信を要求した場合、ターゲットは、次に説明するように、受信したDIOで検出されたルートを選択して、さらに処理することができます。このドキュメントでは、ターゲットが以降の処理のためにルートを選択するために使用する特定の方法を指定していません。方法の例には、制約を満たすルートを選択することや、特定の期間に検出された最適なルートを選択することが含まれます。
If one or more Source Routes are being discovered, the Target sends the selected Source Route(s) to the Origin via P2P-DRO messages, with one P2P-DRO message carrying one discovered route. On receiving a P2P-DRO message, the Origin stores the discovered route in its memory. This specification allows the Origin to discover up to four Source Routes per Target, thereby allowing the Origin to have sufficient ready-to-use alternatives should one or more of these routes fail. If a Hop-by-hop Route is being discovered, the Target sends a P2P-DRO message containing the selected route to the Origin. The P2P-DRO message travels back to the Origin along the selected route, establishing state for the Forward Route in the routers on the path.
1つ以上のソースルートが検出されている場合、ターゲットは選択されたソースルートをP2P-DROメッセージを介してオリジンに送信し、1つのP2P-DROメッセージが1つの検出されたルートを伝達します。 P2P-DROメッセージを受信すると、Originは発見されたルートをメモリに保存します。この仕様により、Originはターゲットごとに最大4つのソースルートを検出できるため、これらのルートの1つまたは複数に障害が発生した場合でも、Originはすぐに使用できる十分な代替手段を持つことができます。ホップバイホップルートが検出されている場合、ターゲットは選択されたルートを含むP2P-DROメッセージをオリジンに送信します。 P2P-DROメッセージは、選択されたルートに沿ってオリジンに戻り、パス上のルーターで転送ルートの状態を確立します。
The Target may request that the Origin acknowledge the receipt of a P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO-ACK) message (defined in Section 10). The Origin unicasts a P2P-DRO-ACK message to the Target. If the Target does not receive the requested P2P-DRO-ACK within a certain time interval of sending a P2P-DRO, it resends the P2P-DRO message (up to a certain number of times) carrying the same route as before.
ターゲットは、オリジンがP2P-DRO確認応答（P2P-DRO-ACK）メッセージ（セクション10で定義）を返信することにより、P2P-DROメッセージの受信を確認することを要求できます。オリジンはP2P-DRO-ACKメッセージをターゲットにユニキャストします。ターゲットは、P2P-DROを送信してから一定の時間内に要求されたP2P-DRO-ACKを受信しない場合、以前と同じルートを伝送するP2P-DROメッセージを（一定回数まで）再送信します。
The use of Trickle timers to delay the propagation of DIO messages may cause some nodes to generate these messages even when the desired routes have already been discovered. In order to preempt the generation of such unnecessary messages, the Target may set a "Stop" flag in the P2P-DRO message to let the nodes in the LLN know about the completion of the route discovery process. The routers receiving such a P2P-DRO should not generate any more DIOs for this temporary DAG, nor should they process any received DIOs for this temporary DAG in the future. However, such routers must still process the P2P-DROs received for this temporary DAG.
トリクルタイマーを使用してDIOメッセージの伝播を遅延させると、目的のルートがすでに検出されている場合でも、一部のノードでこれらのメッセージが生成されることがあります。そのような不要なメッセージの生成を回避するために、ターゲットはP2P-DROメッセージに「停止」フラグを設定して、LLNのノードにルート検出プロセスの完了を通知することができます。このようなP2P-DROを受信するルーターは、この一時的なDAGのDIOをこれ以上生成しないでください。また、将来、この一時的なDAGの受信したDIOを処理しないでください。ただし、そのようなルーターは、この一時的なDAGで受信したP2P-DROを処理する必要があります。
This section specifies a new RPL Mode of Operation (MOP), P2P Route Discovery mode (or P2P mode, for short), with value 4. A DIO message listing P2P mode as the MOP is identified as performing a P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified in Section 7).
このセクションでは、新しいRPL操作モード（MOP）、P2Pルート検出モード（略してP2Pモード）を値4で指定します。MOPとしてP2PモードをリストするDIOメッセージは、一時的なDAGを作成します。 P2PモードDIOは、正確に1つのP2Pルート検出オプション（セクション2で指定されたP2P-RDO）を伝送する必要があります。
The Base object in a P2P mode DIO message MUST be set in the following manner:
P2PモードのDIOメッセージのBaseオブジェクトは、次の方法で設定する必要があります。
o RPLInstanceID: RPLInstanceID MUST be a local value as described in Section 5.1 of [RFC6550]. The Origin chooses the RPLInstanceID to be used for a particular route discovery in accordance with the following rules:
o RPLInstanceID：[RFC6550]のセクション5.1で説明されているように、RPLInstanceIDはローカル値である必要があります。オリジンは、次のルールに従って、特定のルート検出に使用するRPLInstanceIDを選択します。
* The Origin SHOULD NOT reuse a RPLInstanceID for a route discovery if some routers might still maintain membership in the DAG that the Origin had initiated for the previous route discovery using this RPLInstanceID. As described in Section 7,
* 一部のルーターが、このRPLInstanceIDを使用して以前のルートディスカバリのために開始したDAGのメンバーシップを維持しているルーターがある場合、オリジンはルートディスカバリにRPLInstanceIDを再利用しないでください。セクション7で説明したように
a router's membership in a DAG created for a P2P-RPL route discovery lasts for the time duration (say, 't' seconds) indicated by the L field inside the P2P-RDO. In general, there is no upper bound on the time duration by when all the routers have left the DAG created for a P2P-RPL route discovery. In the specific case where the discovered route must be at most 'n' hops in length, all the routers must have left the DAG "(n+1)*t" seconds after its initiation by the Origin. In practice, all the routers should have joined the DAG within 't' seconds of its initiation (since the route discovery must complete while the Origin still belongs to the DAG), and hence all the routers should have left the DAG within "2*t" seconds of its initiation. Hence, it is usually sufficient that the Origin wait for twice the duration indicated by the L field inside the P2P-RDO used for the previous route discovery before reusing the RPLInstanceID for a new route discovery. Individual P2P-RPL deployments are encouraged to share their experience with various RPLInstanceID reuse policies to help guide the development of a Standards Track version of the protocol.
P2P-RPLルート検出用に作成されたDAG内のルーターのメンバーシップは、P2P-RDO内のLフィールドで示される期間（たとえば、 't'秒）持続します。一般に、すべてのルーターがP2P-RPLルート検出用に作成されたDAGを終了するまでの時間には上限がありません。検出されたルートの長さが最大 'n'ホップでなければならない特定のケースでは、すべてのルーターは、オリジンによる開始後、DAGが "（n + 1）* t"秒後に離れている必要があります。実際には、すべてのルーターは開始から 't'秒以内にDAGに参加しているはずです（OriginがまだDAGに属している間にルート検出が完了する必要があるため）。したがって、すべてのルーターはDAGを「2 *」以内に残しておく必要があります。開始からt秒。したがって、通常、Originは、RPLInstanceIDを新しいルートディスカバリに再利用する前に、前のルートディスカバリに使用されたP2P-RDO内のLフィールドで示される期間の2倍待つだけで十分です。個々のP2P-RPL展開では、その経験をさまざまなRPLInstanceID再利用ポリシーと共有して、プロトコルのStandards Trackバージョンの開発をガイドすることをお勧めします。
* When initiating a new route discovery to a particular Target, the Origin MUST NOT reuse the RPLInstanceID used in a previous route discovery to this Target if the state created during the previous route discovery might still exist in some routers. Note that it is possible that the previous route discovery did not succeed yet some routers still ended up creating state. The Default Lifetime and Lifetime Unit parameters in the DODAG Configuration Option specify the lifetime of the state that the routers, including the Origin and the Target, maintain for a Hop-by-hop or Source Route discovered using P2P-RPL. Suppose this lifetime is 'X' seconds. As discussed above, any state created during the previous route discovery was likely created within "2*t" seconds of its initiation. Hence, it is sufficient that the Origin lets a time duration equal to "X+2*t" seconds pass since the initiation of the previous route discovery before initiating a new route discovery to the same Target using the same RPLInstanceID.
* 特定のターゲットへの新しいルートディスカバリを開始する場合、以前のルートディスカバリ中に作成された状態が一部のルータにまだ存在する場合、オリジンはこのターゲットへの以前のルートディスカバリで使用されたRPLInstanceIDを再利用してはなりません。以前のルート検出が成功しなかった可能性があることに注意してください。それでも、一部のルーターはまだ状態を作成しています。 DODAG構成オプションのデフォルトのライフタイムおよびライフタイムユニットのパラメーターは、P2P-RPLを使用して検出されたホップバイホップまたはソースルートに対して、ルーターがオリジンとターゲットを含めて維持する状態のライフタイムを指定します。この存続期間が「X」秒であるとします。上記のように、前のルートディスカバリ中に作成された状態は、開始から「2 * t」秒以内に作成された可能性があります。したがって、Originは、前のルートディスカバリが開始されてから同じRPLInstanceIDを使用して同じターゲットへの新しいルートディスカバリを開始する前に、「X + 2 * t」秒に等しい時間を経過させるだけで十分です。
o Version Number: This field MUST be set to zero. The temporary DAG used for P2P-RPL route discovery does not exist long enough to have new versions.
o バージョン番号：このフィールドはゼロに設定する必要があります。 P2P-RPLルートディスカバリに使用される一時的なDAGは、新しいバージョンが存在するほど長く存在しません。
o Grounded (G) Flag: This flag MUST be set to one. Unlike a global RPL instance, the concept of a floating DAG, used to provide connectivity within a sub-DAG detached from a grounded DAG, does not apply to a local RPL instance. Hence, an Origin MUST always set the G flag to one when initiating a P2P-RPL route discovery.
o 固定（G）フラグ：このフラグは1に設定する必要があります。グローバルRPLインスタンスとは異なり、固定DAGから切り離されたサブDAG内で接続を提供するために使用されるフローティングDAGの概念は、ローカルRPLインスタンスには適用されません。したがって、P2P-RPLルートディスカバリを開始するとき、Originは常にGフラグを1に設定する必要があります。
Further, item 3 of Section 8.2.2.2 in [RFC6550] does not apply, and a node MUST NOT initiate a new DAG if it does not have any parent left in a P2P-RPL DAG.
さらに、[RFC6550]のセクション8.2.2.2の項目3は適用されず、P2P-RPL DAGに親が残っていない場合、ノードは新しいDAGを開始してはなりません（MUST NOT）。
o Mode of Operation (MOP): This field MUST be set to four, corresponding to P2P Route Discovery mode.
o 動作モード（MOP）：このフィールドは、P2Pルート検出モードに対応する4に設定する必要があります。
o Destination Advertisement Trigger Sequence Number (DTSN): This field MUST be set to zero on transmission and ignored on reception.
o Destination Advertisement Trigger Sequence Number（DTSN）：このフィールドは送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
o DODAGPreference (Prf): This field MUST be set to zero (least preferred).
o DODAGPreference（Prf）：このフィールドはゼロに設定する必要があります（優先度は最も低い）。
o DODAGID: This field MUST be set to an IPv6 address of the Origin.
o DODAGID：このフィールドは、オリジンのIPv6アドレスに設定する必要があります。
o The other fields in the DIO Base object can be set in the desired fashion as per the rules described in [RFC6550].
o [RFC6550]で説明されているルールに従って、DIO Baseオブジェクトの他のフィールドを希望の方法で設定できます。
A received P2P mode DIO MUST be discarded if it does not follow the above-listed rules regarding the RPLInstanceID, Version Number, G flag, MOP, and Prf fields inside the Base object.
受信したP2PモードDIOは、Baseオブジェクト内のRPLInstanceID、バージョン番号、Gフラグ、MOP、およびPrfフィールドに関する上記のルールに従っていない場合は破棄する必要があります。
The DODAG Configuration Option inside a P2P mode DIO MUST be set in the following manner:
P2PモードDIO内のDODAG構成オプションは、次の方法で設定する必要があります。
o The Origin MUST set the MaxRankIncrease parameter to zero to disable local repair of the temporary DAG. A received P2P mode DIO MUST be discarded if the MaxRankIncrease parameter inside the DODAG Configuration Option is not zero.
o Originは、一時的なDAGのローカル修復を無効にするために、MaxRankIncreaseパラメータをゼロに設定する必要があります。 DODAG構成オプション内のMaxRankIncreaseパラメーターがゼロでない場合、受信したP2PモードDIOを破棄する必要があります。
o The Origin SHOULD set the Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as recommended in Section 9.2.
o Originは、セクション9.2で推奨されているように、トリクルパラメータ（DIOIntervalDoublings、DIOIntervalMin、DIORedundancyConstant）を設定する必要があります（SHOULD）。
o The Origin sets the Default Lifetime and Lifetime Unit parameters to indicate the lifetime of the state that the routers, including the Origin and the Target(s), maintain for a Hop-by-hop or Source Route discovered using P2P-RPL.
o Originは、P2P-RPLを使用して発見されたホップバイホップまたはソースルートに対してルーターが（OriginとTargetを含めて）維持する状態のライフタイムを示すために、Default LifetimeおよびLifetime Unitパラメータを設定します。
o The Origin sets the other fields in the DODAG Configuration Option, including the Objective Code Point (OCP) identifying the Objective Function, in the desired fashion as per the rules described in [RFC6550].
o オリジンは、[RFC6550]で説明されている規則に従って、目的関数を識別する目的コードポイント（OCP）を含む、目的の方法でDODAG構成オプションの他のフィールドを設定します。
o As discussed in Section 14, P2P-RPL does not distinguish between the "preinstalled" and "authenticated" security modes described in [RFC6550]. Consequently, the Origin MUST set the Authentication Enabled (A) flag to zero. A received P2P mode DIO MUST be discarded if the A flag inside the DODAG Configuration Option is not zero.
o セクション14で説明したように、P2P-RPLは、[RFC6550]で説明されている「プリインストール」と「認証」のセキュリティモードを区別しません。したがって、Originは認証有効（A）フラグをゼロに設定する必要があります。 DODAG構成オプション内のAフラグがゼロでない場合、受信したP2PモードDIOを破棄する必要があります。
o An Intermediate Router (or a Target) MUST set various fields in the DODAG Configuration Option in the outgoing P2P mode DIOs to the values they had in the incoming P2P mode DIOs for this DAG.
o 中間ルーター（またはターゲット）は、発信P2PモードDIOのDODAG構成オプションのさまざまなフィールドを、このDAGの着信P2PモードDIOにある値に設定する必要があります。
A default DODAG Configuration Option takes effect if a P2P mode DIO does not carry an explicit one. The default DODAG Configuration Option has the following parameter values:
P2PモードDIOが明示的なものを実行しない場合、デフォルトのDODAG構成オプションが有効になります。デフォルトのDODAG構成オプションには、次のパラメーター値があります。
o Authentication Enabled: 0
o 認証有効：0
o DIOIntervalMin: 6, which translates to 64 ms as the value for the Imin parameter in a Trickle operation. This value is roughly one order of magnitude larger than the typical transmission delay on IEEE 802.15.4 links and corresponds to the recommendation in Section 9.2 for well-connected topologies.
o DIOIntervalMin：6は、トリクル操作のIminパラメーターの値として64ミリ秒に変換されます。この値は、IEEE 802.15.4リンクの一般的な伝送遅延よりも約1桁大きく、適切に接続されたトポロジに関するセクション9.2の推奨に対応しています。
o DIORedundancyConstant: 1. See the discussion in Section 9.2.
o DIORedundancyConstant：1.セクション9.2の説明を参照してください。
o MaxRankIncrease: 0 (to disable local repair of the temporary DAG).
o MaxRankIncrease：0（一時的なDAGのローカル修復を無効にするため）。
o Default Lifetime: 0xFF, to correspond to infinity.
o デフォルトのライフタイム：0xFF、無限大に対応。
o Lifetime Unit: 0xFFFF, to correspond to infinity.
o ライフタイムユニット：0xFFFF、無限大に対応。
o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default Objective Function (OF).
o 目的コードポイント：0、つまり、OF0 [RFC6552]がデフォルトの目的関数（OF）です。
o The remaining parameters have default values as specified in [RFC6550].
o 残りのパラメータには、[RFC6550]で指定されているデフォルト値があります。
Individual P2P-RPL deployments are encouraged to share their experience with these default values to help guide the development of a Standards Track version of the protocol.
個々のP2P-RPL展開では、これらのデフォルト値と経験を共有して、プロトコルの標準トラックバージョンの開発を支援することが推奨されます。
The routing metrics and constraints [RFC6551] used in P2P-RPL route discovery are included in one or more Metric Container options [RFC6550] inside the P2P mode DIO. Note that a DIO need not include a Metric Container if OF0 is the Objective Function in effect. In that case, a P2P mode DIO may still specify an upper limit on the maximum rank, that a router may have in the temporary DAG, inside the P2P-RDO.
P2P-RPLルートディスカバリで使用されるルーティングメトリックと制約[RFC6551]は、P2PモードDIO内の1つ以上のメトリックコンテナーオプション[RFC6550]に含まれています。 OF0が有効な目的関数である場合、DIOにメトリックコンテナーを含める必要がないことに注意してください。その場合、P2PモードのDIOは、P2P-RDO内の一時的なDAGにルーターが持つ可能性がある最大ランクの上限を指定する場合があります。
A P2P mode DIO:
P2PモードのGOD：
o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the specification of one unicast or multicast address for the Target. A received P2P mode DIO MUST be discarded if it does not contain exactly one P2P-RDO.
o 1つ（1つのみ）のP2P-RDOを実行する必要があります。 P2P-RDOでは、ターゲットに1つのユニキャストまたはマルチキャストアドレスを指定できます。受信したP2PモードのDIOには、P2P-RDOが1つだけ含まれていない場合は破棄する必要があります。
o MAY carry one or more RPL Target options to specify additional unicast/multicast addresses for the Target. If a unicast address is specified, it MUST be a global address or a unique-local address.
o ターゲットの追加のユニキャスト/マルチキャストアドレスを指定するために、1つ以上のRPLターゲットオプションを運ぶことができます。ユニキャストアドレスを指定する場合は、グローバルアドレスまたは一意のローカルアドレスにする必要があります。
o MAY carry one or more Metric Container options to specify routing metrics and constraints.
o ルーティングメトリックと制約を指定する1つ以上のメトリックコンテナオプションを運ぶことができます。
o MAY carry one or more Route Information Options [RFC6550]. In the context of P2P-RPL, a Route Information Option advertises to the Target(s) the Origin's connectivity to the prefix specified in the option.
o 1つ以上のルート情報オプションを運ぶことができます[RFC6550]。 P2P-RPLのコンテキストでは、ルート情報オプションは、オプションで指定されたプレフィックスへのオリジンの接続をターゲットにアドバタイズします。
o MAY carry one DODAG Configuration Option. If a P2P mode DIO does not carry an explicit DODAG Configuration Option, the default DODAG Configuration Option defined in this section is considered to be in effect.
o 1つのDODAG構成オプションを運ぶことができます。 P2PモードDIOが明示的なDODAG構成オプションを持たない場合、このセクションで定義されているデフォルトのDODAG構成オプションが有効であると見なされます。
A RPL option other than those listed above MUST be ignored when found inside a received P2P mode DIO and MUST NOT be included in the P2P mode DIOs that the receiving router generates.
上記以外のRPLオプションは、受信したP2PモードDIO内で検出された場合は無視する必要があり、受信ルーターが生成するP2PモードDIOに含めることはできません。
In accordance with core RPL, a P2P mode DIO MUST propagate via link-local multicast. The IPv6 source address in a P2P mode DIO MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554].
コアRPLに従って、P2PモードDIOはリンクローカルマルチキャストを介して伝播する必要があります。 P2PモードDIOのIPv6送信元アドレスはリンクローカルアドレスである必要があり、IPv6宛先アドレスはリンクローカルマルチキャストアドレスall-RPL-nodes [RFC6550]である必要があります。 P2PモードDIOは、ルーターがこのRPLルーティングドメイン[RFC6554]に持つすべてのインターフェイスで送信する必要があります。
This section defines a new RPL control message option: the P2P Route Discovery Option (P2P-RDO).
このセクションでは、新しいRPL制御メッセージオプションであるP2Pルート検出オプション（P2P-RDO）を定義します。
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 = 0x0a | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TargetAddr |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address[1..n] |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the P2P Route Discovery Option (P2P-RDO)
図1：P2Pルート検出オプション（P2P-RDO）のフォーマット
The format of a P2P Route Discovery Option (P2P-RDO) is illustrated in Figure 1. A P2P mode DIO and a P2P-DRO message (defined in Section 8) MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following fields:
P2Pルート検出オプション（P2P-RDO）のフォーマットを図1に示します。P2PモードDIOとP2P-DROメッセージ（セクション8で定義）は、1つのP2P-RDOを運ぶ必要があります。 P2P-RDOは次のフィールドで構成されています。
o Option Type: 0x0a.
o オプションタイプ：0x0a。
o Option Length: This field is an 8-bit unsigned integer representing the length in octets of the option, not including the Option Type and Option Length fields.
o Option Length：このフィールドは、オプションのオクテットの長さを表す8ビットの符号なし整数で、Option TypeおよびOption Lengthフィールドは含まれません。
o Reply (R): The Origin sets this flag to one to allow the Target(s) to send P2P-DRO messages back to the Origin. If this flag is set to zero, a Target MUST NOT generate any P2P-DRO messages.
o 返信（R）：オリジンはこのフラグを1に設定して、ターゲットがP2P-DROメッセージをオリジンに送信できるようにします。このフラグがゼロに設定されている場合、ターゲットはP2P-DROメッセージを生成してはなりません（MUST NOT）。
o Hop-by-hop (H): This flag is valid only if the R flag is set to one. The Origin sets this flag to one if it desires Hop-by-hop Routes. The Origin sets this flag to zero if it desires Source Routes. This specification allows for the establishment of one Hop-by-hop Route or up to four Source Routes per Target. The Hop-by-hop Route is established in the Forward direction, i.e., from the Origin to the Target. This specification does not allow for the establishment of Hop-by-hop Routes in the Reverse direction.
o ホップバイホップ（H）：このフラグは、Rフラグが1に設定されている場合にのみ有効です。オリジンは、ホップバイホップルートが必要な場合、このフラグを1に設定します。オリジンは、ソースルートが必要な場合、このフラグをゼロに設定します。この仕様により、1つのホップバイホップルートまたはターゲットごとに最大4つのソースルートを確立できます。ホップバイホップルートは、フォワード方向、つまり、オリジンからターゲットへと確立されます。この仕様では、逆方向のホップバイホップルートの確立は許可されていません。
o Number of Routes (N): This field is valid only if the R flag is set to one and the H flag is set to zero, i.e., the Targets are allowed to generate P2P-DRO messages carrying discovered Source Routes back to the Origin. In this case, the value in the N field plus one indicates the number of Source Routes that each Target should convey to the Origin. When Hop-by-hop Routes are being discovered, the N field MUST be set to zero on transmission and ignored on reception.
o ルート数（N）：このフィールドは、Rフラグが1に設定され、Hフラグがゼロに設定されている場合にのみ有効です。この場合、Nフィールドの値に1を加えた値は、各ターゲットがオリジンに伝達するソースルートの数を示します。ホップバイホップルートが検出されている場合、Nフィールドは送信時にゼロに設定され、受信時に無視される必要があります。
o Compr: This field is a 4-bit unsigned integer indicating the number of prefix octets that are elided from the Target field and the Address vector. For example, the Compr value will be zero if full IPv6 addresses are carried in the Target field and the Address vector.
o Compr：このフィールドは4ビットの符号なし整数で、Targetフィールドとアドレスベクトルから除外されるプレフィックスオクテットの数を示します。たとえば、完全なIPv6アドレスが[ターゲット]フィールドとアドレスベクターで運ばれる場合、Compr値はゼロになります。
o Lifetime (L): This is a 2-bit field that indicates the exact duration that a router joining the temporary DAG, including the Origin and the Target(s), MUST maintain its membership in the DAG. A router MUST leave the temporary DAG once the time elapsed since it joined reaches the value indicated by this field. The mapping between the value in this field and the duration of the router's membership in the temporary DAG is as follows:
o 存続期間（L）：これは、OriginとTargetを含め、一時的なDAGに参加するルーターがDAGのメンバーシップを維持する必要がある正確な期間を示す2ビットのフィールドです。参加してからの経過時間がこのフィールドで示される値に達すると、ルーターは一時的なDAGを離れる必要があります。このフィールドの値と一時的なDAGにおけるルーターのメンバーシップの期間の間のマッピングは次のとおりです。
* 0x00: 1 second
* 0x00：1秒
* 0x01: 4 seconds
* 0x01：4秒
* 0x02: 16 seconds
* 0x02：16秒
* 0x03: 64 seconds
* 0x03：64秒
The Origin sets this field based on its expectation regarding the time required for the route discovery to complete, which includes the time required for the DIOs to reach the Target(s) and the P2P-DROs to travel back to the Origin. The time required for the DIOs to reach the Target(s) would in turn depend on the Trickle parameters (Imin and the redundancy constant) as well as the expected distance (in terms of hops and/or ETX) to the Target(s). While deciding on the value in this field, the Origin should also take into account the fact that all routers joining the temporary DAG would need to stay in the DAG for this much time.
Originは、DIOがターゲットに到達するのに必要な時間とP2P-DROがOriginに戻るのに必要な時間を含む、ルート検出が完了するのに必要な時間に関する予想に基づいて、このフィールドを設定します。 DIOがターゲットに到達するために必要な時間は、トリクルパラメータ（Iminと冗長定数）と、ターゲットへの予想される距離（ホップやETXの観点から）に依存します。 。このフィールドの値を決定する際に、Originは、一時的なDAGに参加するすべてのルーターがこの時間DAGに留まる必要があるという事実も考慮する必要があります。
o MaxRank/NH:
o MaxRank / NH：
* When a P2P-RDO is included in a P2P mode DIO, this field indicates the upper limit on the integer portion of the rank (calculated using the DAGRank() macro defined in [RFC6550]) that a router may have in the temporary DAG being created. An Intermediate Router MUST NOT join a temporary DAG being created by a P2P mode DIO if the integer portion of its rank would be equal to or higher (in numerical value) than the MaxRank limit. A Target can join the temporary DAG at a rank whose integer portion is equal to the MaxRank. A router MUST discard a received P2P mode DIO if the integer part of the advertised rank equals or exceeds the MaxRank limit. A value of 0 in this field indicates that the MaxRank is infinity.
* P2P-RDOがP2PモードDIOに含まれている場合、このフィールドは、ルーターの一時的なDAGにある可能性があるランク（[RFC6550]で定義されているDAGRank()マクロを使用して計算）の整数部分の上限を示します作成した。中間ルーターは、ランクの整数部分が（数値で）MaxRank制限以上である場合、P2PモードDIOによって作成される一時的なDAGに参加してはなりません（MUST NOT）。ターゲットは、整数部分がMaxRankと等しいランクで一時DAGに参加できます。通知されたランクの整数部分がMaxRank制限以上の場合、ルーターは受信したP2PモードDIOを破棄する必要があります。このフィールドの値0は、MaxRankが無限であることを示します。
* When a P2P-RDO is included in a P2P-DRO message, this field indicates the index of the next-hop (NH) address inside the Address vector.
* P2P-RDOがP2P-DROメッセージに含まれている場合、このフィールドはアドレスベクタ内のネクストホップ（NH）アドレスのインデックスを示します。
o TargetAddr: This is an IPv6 address of the Target after eliding Compr number of prefix octets. When the P2P-RDO is included in a P2P mode DIO, this field may contain a unicast address or a multicast address. If a unicast address is specified, it MUST be a global address or a unique-local address. Any additional Target addresses can be specified by including one or more RPL Target options [RFC6550] in the DIO. When the P2P-RDO is included in a P2P-DRO, this field MUST contain a unicast global or unique-local IPv6 address of the Target generating the P2P-DRO.
o TargetAddr：これは、プレフィックスオクテットのCompr番号を省略した後のターゲットのIPv6アドレスです。 P2P-RDOがP2PモードDIOに含まれている場合、このフィールドにはユニキャストアドレスまたはマルチキャストアドレスが含まれることがあります。ユニキャストアドレスを指定する場合は、グローバルアドレスまたは一意のローカルアドレスにする必要があります。 DIOに1つ以上のRPLターゲットオプション[RFC6550]を含めることで、追加のターゲットアドレスを指定できます。 P2P-RDOがP2P-DROに含まれている場合、このフィールドには、P2P-DROを生成するターゲットのユニキャストグローバルまたは一意ローカルIPv6アドレスが含まれている必要があります。
o Address[1..n]: This is a vector of IPv6 addresses representing a complete route so far in the Forward direction:
o Address [1..n]：これは、これまでの順方向の完全なルートを表すIPv6アドレスのベクトルです。
* Each element in the Address vector has size (16 - Compr) octets and MUST contain a valid global or unique-local IPv6 address with the first Compr octets elided.
* アドレスベクトルの各要素はサイズ（16-Compr）オクテットを持ち、最初のComprオクテットが省略された有効なグローバルまたは一意のローカルIPv6アドレスを含んでいる必要があります。
* The total number of elements inside the Address vector is given by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).
* アドレスベクトル内の要素の総数は、n =（オプションの長さ-2-（16-Compr））/（16-Compr）で与えられます。
* The IPv6 address that a router adds to the vector MUST belong to the interface on which the router received the DIO containing this P2P-RDO. Further, this interface MUST NOT be an Ingress-only Interface. This allows the route accumulated in the Address vector to be a Bidirectional Route that can be used by a Target to send a P2P-DRO message to the Origin.
* ルーターがベクターに追加するIPv6アドレスは、ルーターがこのP2P-RDOを含むDIOを受信したインターフェイスに属している必要があります。さらに、このインターフェースはIngress-onlyインターフェースであってはなりません。これにより、アドレスベクトルに蓄積されたルートを、ターゲットがP2P-DROメッセージをオリジンに送信するために使用できる双方向ルートにすることができます。
* The Address vector MUST carry the accumulated route in the Forward direction, i.e., the first element in the Address vector must contain the IPv6 address of the router next to the Origin, and so on.
* アドレスベクトルは蓄積されたルートを順方向に運ぶ必要があります。つまり、アドレスベクトルの最初の要素には、オリジンの隣のルーターのIPv6アドレスが含まれている必要があります。
* The Origin and Target addresses MUST NOT be included in the Address vector.
* 起点アドレスと目標アドレスをアドレスベクトルに含めることはできません。
* A router adding its address to the vector MUST ensure that none of its addresses already exist in the vector. A Target specifying a complete route in the Address vector MUST ensure that the vector does not contain any address more than once.
* そのアドレスをベクターに追加するルーターは、そのアドレスがベクター内に既に存在していないことを確認しなければなりません。アドレスベクトルで完全なルートを指定するターゲットは、ベクトルにアドレスが2回以上含まれないようにする必要があります。
* The Address vector MUST NOT contain any multicast addresses.
* アドレスベクトルには、マルチキャストアドレスを含めてはなりません。
This section defines two new RPL control message types: the P2P Discovery Reply Object (P2P-DRO), with code 0x04; and the Secure P2P-DRO, with code 0x84. A P2P-DRO serves one of the following functions:
このセクションでは、2つの新しいRPL制御メッセージタイプを定義します。コード0x04のP2Pディスカバリ応答オブジェクト（P2P-DRO）。コード0x84のSecure P2P-DRO。 P2P-DROは、次の機能のいずれかを提供します。
o carries a discovered Source Route from a Target to the Origin;
o ターゲットからオリジンへの発見されたソースルートを運ぶ;
o establishes a Hop-by-hop Route as it travels from a Target to the Origin.
o ターゲットからオリジンに移動するときにホップバイホップルートを確立します。
A P2P-DRO message can also serve the function of letting the routers in the LLN know that a P2P-RPL route discovery is complete and no more DIO messages need to be generated for the corresponding temporary DAG. A P2P-DRO message MUST carry one (and only one) P2P-RDO whose TargetAddr field MUST contain a unicast IPv6 address of the Target that generates the P2P-DRO. A P2P-DRO message MUST travel from the Target to the Origin via link-local multicast along the route specified inside the Address vector in the P2P-RDO, as included in the P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be a link-local address, and the IPv6 destination address MUST be the link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO message MUST be transmitted on all interfaces the router has in this RPL routing domain [RFC6554].
P2P-DROメッセージは、P2P-RPLルートの検出が完了し、対応する一時的なDAGに対してこれ以上DIOメッセージを生成する必要がないことをLLNのルーターに通知する機能を果たすこともできます。 P2P-DROメッセージは、TargetAddrフィールドにP2P-DROを生成するターゲットのユニキャストIPv6アドレスが含まれている必要がある1つ（1つのみ）のP2P-RDOを運ぶ必要があります。 P2P-DROメッセージは、P2P-DROに含まれているように、P2P-RDOのアドレスベクトル内で指定されたルートに沿ってリンクローカルマルチキャストを介してターゲットからオリジンに移動する必要があります。 P2P-DROメッセージのIPv6送信元アドレスはリンクローカルアドレスでなければならず、IPv6宛先アドレスはリンクローカルマルチキャストアドレスall-RPL-nodes [RFC6550]でなければなりません（MUST）。 P2P-DROメッセージは、ルーターがこのRPLルーティングドメイン[RFC6554]に持つすべてのインターフェイスで送信する必要があります。
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 |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of the Base P2P Discovery Reply Object (P2P-DRO)
図2：基本P2Pディスカバリー応答オブジェクト（P2P-DRO）のフォーマット
The format of the base P2P Discovery Reply Object (P2P-DRO) is shown in Figure 2. A base P2P-DRO consists of the following fields:
基本P2Pディスカバリー応答オブジェクト（P2P-DRO）のフォーマットを図2に示します。基本P2P-DROは、以下のフィールドで構成されています。
o RPLInstanceID: This field provides the RPLInstanceID of the temporary DAG used for route discovery.
o RPLInstanceID：このフィールドは、ルート検出に使用される一時的なDAGのRPLInstanceIDを提供します。
o Version: This field provides the Version of the temporary DAG used for route discovery. Since a temporary DAG always has value zero for the Version, this field MUST always be set to zero.
o バージョン：このフィールドは、ルート検出に使用される一時的なDAGのバージョンを提供します。一時的なDAGは常にバージョンの値がゼロであるため、このフィールドは常にゼロに設定する必要があります。
o Stop (S): This flag, when set to one by a Target, indicates that the P2P-RPL route discovery is over. All the routers receiving such a P2P-DRO, including those not listed in the route carried inside a P2P-RDO,
o 停止（S）：このフラグは、ターゲットによって1に設定されると、P2P-RPLルート検出が終了したことを示します。このようなP2P-DROを受信するすべてのルーター（P2P-RDO内で運ばれるルートにリストされていないものも含む）、
* SHOULD NOT process any more DIOs received for this temporary DAG;
* この一時的なDAGで受信したDIOをこれ以上処理しないでください。
* SHOULD NOT generate any more DIOs for this temporary DAG;
* この一時的なDAGに対してこれ以上DIOを生成しないでください。
* SHOULD cancel any pending DIO transmissions for this temporary DAG.
* この一時的なDAGの保留中のDIO送信をキャンセルする必要があります。
Note that the Stop flag serves to stop further DIO generation/processing for a P2P-RPL route discovery but does not affect the processing of P2P-DRO messages at either the Origin or the Intermediate Routers. In other words, a router (the Origin or an Intermediate Router) MUST continue to process the P2P-DRO messages even if an earlier P2P-DRO message (with the same RPLInstanceID and DODAGID fields) had the Stop flag set to one. When set to zero, this flag does not imply anything and MUST be ignored on reception.
停止フラグは、P2P-RPLルートディスカバリの以降のDIO生成/処理を停止するのに役立ちますが、起点または中間ルーターでのP2P-DROメッセージの処理には影響しないことに注意してください。言い換えると、以前のP2P-DROメッセージ（同じRPLInstanceIDフィールドとDODAGIDフィールドを持つ）のStopフラグが1に設定されていたとしても、ルーター（Originまたは中間ルーター）はP2P-DROメッセージの処理を継続する必要があります。ゼロに設定した場合、このフラグは何も意味せず、受信時には無視する必要があります。
o Ack Required (A): This flag, when set to one by the Target, indicates that the Origin MUST unicast a P2P-DRO-ACK message (defined in Section 10) to the Target when it receives the P2P-DRO.
o Ack Required（A）：このフラグは、ターゲットによって1に設定されている場合、P2P-DROを受信したときに、オリジンがP2P-DRO-ACKメッセージ（セクション10で定義）をターゲットにユニキャストする必要があることを示します。
o Sequence Number (Seq): This 2-bit field indicates the sequence number for the P2P-DRO. This field is relevant when the A flag is set to one, i.e., the Target requests an acknowledgement from the Origin for a received P2P-DRO. The Origin includes the RPLInstanceID, the DODAGID, and the Sequence Number of the received P2P-DRO inside the P2P-DRO-ACK message it sends back to the Target.
o シーケンス番号（Seq）：この2ビットのフィールドは、P2P-DROのシーケンス番号を示します。このフィールドは、Aフラグが1に設定されている場合、つまり、ターゲットが受信したP2P-DROのオリジンからの確認応答を要求する場合に関係します。オリジンには、RPLInstanceID、DODAGID、およびターゲットに送り返すP2P-DRO-ACKメッセージ内の受信したP2P-DROのシーケンス番号が含まれます。
o Reserved: These bits are reserved for future use. These bits MUST be set to zero on transmission and MUST be ignored on reception.
o 予約済み：これらのビットは将来の使用のために予約されています。これらのビットは、送信時にゼロに設定する必要があり、受信時に無視する必要があります。
o DODAGID: This field provides the DODAGID of the temporary DAG used for route discovery. The DODAGID also identifies the Origin. The RPLInstanceID, the Version, and the DODAGID together uniquely identify the temporary DAG used for route discovery and can be copied from the DIO message advertising the temporary DAG.
o DODAGID：このフィールドは、ルート検出に使用される一時的なDAGのDODAGIDを提供します。 DODAGIDはオリジンも識別します。 RPLInstanceID、バージョン、およびDODAGIDは、ルートの検出に使用される一時DAGを一意に識別し、一時DAGをアドバタイズするDIOメッセージからコピーできます。
o Options: The P2P-DRO message:
o オプション：P2P-DROメッセージ：
* MUST carry one (and only one) P2P-RDO that MUST specify a complete route between the Target and the Origin. A received P2P-DRO message MUST be discarded if it does not contain exactly one P2P-RDO.
* ターゲットとオリジン間の完全なルートを指定する必要がある1つ（1つのみ）のP2P-RDOを運ぶ必要があります。受信したP2P-DROメッセージにP2P-RDOが1つだけ含まれていない場合は、破棄する必要があります。
* MAY carry one or more Metric Container options that contain the aggregated routing metrics values for the route specified in the P2P-RDO.
* P2P-RDOで指定されたルートの集約ルーティングメトリック値を含む1つ以上のメトリックコンテナオプションを運ぶことができます。
A RPL option other than those listed above MUST be ignored when found inside a received P2P-DRO message.
上記以外のRPLオプションは、受信したP2P-DROメッセージ内で見つかった場合は無視する必要があります。
A Secure P2P-DRO message follows the format shown in Figure 7 of [RFC6550], where the base format is the base P2P-DRO shown in Figure 2.
セキュアなP2P-DROメッセージは、[RFC6550]の図7に示されているフォーマットに従います。基本フォーマットは、図2に示されているベースP2P-DROです。
A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO, which MUST be set as defined in Section 7. Specifically, the following fields MUST be set as follows:
P2Pディスカバリ応答オブジェクトは、セクション7の定義に従って設定する必要がある1つ（1つのみ）のP2P-RDOを運ぶ必要があります。具体的には、次のフィールドを次のように設定する必要があります。
o Reply (R): This flag MUST be set to zero on transmission and ignored on reception.
o 返信（R）：このフラグは送信時にゼロに設定し、受信時には無視する必要があります。
o Hop-by-Hop (H): The H flag in the P2P-RDO included in a P2P-DRO message MUST have the same value as the H flag in the P2P-RDO inside the corresponding DIO message.
o ホップバイホップ（H）：P2P-DROメッセージに含まれるP2P-RDOのHフラグは、対応するDIOメッセージ内のP2P-RDOのHフラグと同じ値を持つ必要があります。
o Number of Routes (N): This field MUST be set to zero on transmission and ignored on reception.
o ルート数（N）：このフィールドは、送信時にはゼロに設定され、受信時には無視される必要があります。
o Lifetime (L): This field MUST be set to zero on transmission and ignored on reception.
o ライフタイム（L）：このフィールドは、送信時にゼロに設定されなければならず、受信時には無視されなければなりません。
o MaxRank/NH: This field indicates the index of the next-hop address in the Address vector. When a Target generates a P2P-DRO message, the NH field is set to n = (Option Length - 2 - (16 - Compr))/ (16 - Compr).
o MaxRank / NH：このフィールドは、アドレスベクタのネクストホップアドレスのインデックスを示します。ターゲットがP2P-DROメッセージを生成すると、NHフィールドはn =（オプションの長さ-2-（16-Compr））/（16-Compr）に設定されます。
o TargetAddr: This field MUST contain a unicast global or unique-local IPv6 address of the Target generating the P2P-DRO.
o TargetAddr：このフィールドには、P2P-DROを生成するターゲットのユニキャストグローバルまたはユニークローカルIPv6アドレスを含める必要があります。
o Address[1..n]: The Address vector MUST contain a complete route between the Origin and the Target such that the first element in the vector contains the IPv6 address of the router next to the Origin and the last element contains the IPv6 address of the router next to the Target.
o Address [1..n]：アドレスベクトルには、起点とターゲット間の完全なルートが含まれている必要があります。これにより、ベクトルの最初の要素には起点の隣のルーターのIPv6アドレスが含まれ、最後の要素にはターゲットの隣のルーター。
This section details the P2P-RPL route discovery operation.
このセクションでは、P2P-RPLルート検出操作について詳しく説明します。
All the routers participating in a P2P-RPL route discovery, including the Origin and the Target(s), MUST join the temporary DAG being created for that purpose. When a router joins a temporary DAG advertised by a P2P mode DIO, it MUST maintain its membership in the temporary DAG for the duration indicated by the L field inside the P2P-RDO. The only purpose of a temporary DAG's existence is to facilitate the P2P-RPL route discovery process. The temporary DAG MUST NOT be used to route data packets. In other words, joining a temporary DAG does not allow a router to provision routing table entries listing the router's parents in the temporary DAG as the next hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is not applicable when the DAG is a temporary DAG created for the purpose of a P2P-RPL route discovery).
P2P-RPLルートディスカバリに参加しているすべてのルーターは、オリジンとターゲットを含め、その目的のために作成されている一時的なDAGに参加する必要があります。ルーターがP2PモードDIOによってアドバタイズされた一時的なDAGに参加する場合、ルーターは、P2P-RDO内のLフィールドによって示される期間、一時的なDAGのメンバーシップを維持する必要があります。一時的なDAGが存在する唯一の目的は、P2P-RPLルート検出プロセスを容易にすることです。一時的なDAGは、データパケットのルーティングに使用してはなりません（MUST NOT）。つまり、一時DAGに参加しても、ルーターは一時DAG内のルーターの親を次のホップとしてリストするルーティングテーブルエントリをプロビジョニングできません（つまり、[RFC6550]のセクション3.2.8の最後の箇条書きは、 DAGは、P2P-RPLルート検出の目的で作成された一時的なDAGです。
Given the nature of a temporary DAG created for a P2P-RPL route discovery, this document disallows the solicitation of P2P mode DIOs using DODAG Information Solicitation (DIS) messages as described in [RFC6550]. A router participating in a P2P-RPL route discovery MUST NOT reset its Trickle timer, which controls the transmission of P2P mode DIOs in response to a multicast DIS. Also, the router MUST NOT send a P2P mode DIO in response to a unicast DIS. In other words, the rules in Section 8.3 of [RFC6550] regarding a router's response to a multicast/unicast DIS are not applicable for P2P mode DIOs.
P2P-RPLルートディスカバリ用に作成された一時的なDAGの性質上、このドキュメントでは、[RFC6550]で説明されているDODAG情報要請（DIS）メッセージを使用したP2PモードDIOの要請を禁止します。 P2P-RPLルート検出に参加しているルーターは、マルチキャストDISに応答してP2PモードDIOの送信を制御するトリクルタイマーをリセットしてはなりません（MUST NOT）。また、ルーターはユニキャストDISに応答してP2PモードDIOを送信してはなりません（MUST NOT）。つまり、マルチキャスト/ユニキャストDISに対するルーターの応答に関する[RFC6550]のセクション8.3のルールは、P2PモードDIOには適用されません。
A router MUST detach from the temporary DAG created for a P2P-RPL route discovery once the duration of its membership in the DAG has reached the value indicated by the L field inside the P2P-RDO. After receiving a P2P-DRO with the Stop flag set to one, a router SHOULD NOT send or process any more DIOs for this temporary DAG and SHOULD also cancel any pending DIO transmissions.
DAGのメンバーシップの期間がP2P-RDO内のLフィールドで示される値に達したら、ルーターはP2P-RPLルート検出用に作成された一時的なDAGから切り離す必要があります。停止フラグが1に設定されたP2P-DROを受信した後、ルーターはこの一時的なDAGのDIOをこれ以上送信または処理してはならず（SHOULD NOT）、保留中のDIO送信もキャンセルする必要があります（SHOULD）。
A RPL router uses a Trickle timer [RFC6206] to control DIO transmissions. The Trickle control of DIO transmissions provides quick resolution of any "inconsistency" while avoiding redundant DIO transmissions. The Trickle algorithm also imparts protection against loss of DIOs due to inherent lack of reliability in LLNs. When controlling the transmissions of a P2P mode DIO, a Trickle timer SHOULD follow the following rules:
RPLルーターは、トリクルタイマー[RFC6206]を使用してDIO送信を制御します。 DIO伝送のトリクル制御により、冗長なDIO伝送を回避しながら、「不整合」をすばやく解決できます。トリクルアルゴリズムは、LLNには本質的に信頼性の欠如によるDIOの損失に対する保護も提供します。 P2PモードDIOの送信を制御する場合、トリクルタイマーは次のルールに従う必要があります。
o The receipt of a P2P mode DIO that allows the router to advertise a better route (in terms of the routing metrics and the OF in use) than before is considered "inconsistent" and hence resets the Trickle timer. Note that the first receipt of a P2P mode DIO advertising a particular temporary DAG is always considered an "inconsistent" event.
o ルーターが（ルーティングメトリックと使用中のOFに関して）以前よりも優れたルートをアドバタイズできるようにするP2PモードDIOの受信は、「一貫性がない」と見なされ、トリクルタイマーがリセットされます。特定の一時DAGをアドバタイズするP2PモードDIOの最初の受信は、常に「不整合」イベントと見なされることに注意してください。
o The receipt of a P2P mode DIO from a parent in the temporary DAG is considered neither "consistent" nor "inconsistent" if it does not allow the router to advertise a better route than before. Thus, the receipt of such DIOs has no impact on the Trickle operation. Note that this document does not impose any requirements on how a router might choose its parents in the temporary DAG.
o 一時的なDAGの親からのP2PモードDIOの受信は、ルーターが以前よりも優れたルートをアドバタイズできない場合、「一貫性」も「不一致」も見なされません。したがって、このようなDIOの受信は、トリクル操作に影響を与えません。このドキュメントでは、一時DAGでルーターがその親を選択する方法について要件を課していないことに注意してください。
o The receipt of a P2P mode DIO is considered "consistent" if the source of the DIO is not a parent in the temporary DAG and either of the following conditions is true:
o P2PモードDIOの受信は、DIOのソースが一時的なDAGの親ではなく、次のいずれかの条件に該当する場合、「一貫性がある」と見なされます。
* The DIO advertises a better route than the router but does not allow the router to advertise a better route itself; or
* DIOはルーターよりも優れたルートをアドバタイズしますが、ルーターがより良いルート自体をアドバタイズすることを許可しません。または
* The DIO advertises a route as good as the route (to be) advertised by the router.
* DIOは、ルーターによってアドバタイズされる（予定される）ルートと同じようにルートをアドバタイズします。
Note that the Trickle algorithm's DIO suppression rules are in effect at all times. Hence, a P2P-RPL router may suppress a DIO transmission even if it has not made any DIO transmissions yet.
トリクルアルゴリズムのDIO抑制ルールは常に有効であることに注意してください。したがって、P2P-RPLルーターは、まだDIO送信を行っていなくても、DIO送信を抑制できます。
o The receipt of a P2P mode DIO that advertises a worse route than what the router advertises (or would advertise when it gets a chance to generate its DIO) is considered neither "consistent" nor "inconsistent", i.e., the receipt of such a DIO has no impact on the Trickle operation.
o ルーターがアドバタイズするものよりも悪いルートをアドバタイズする（またはDIOを生成する機会を得たときにアドバタイズする）P2PモードDIOの受信は、「一貫性」も「不整合」も考慮されません。つまり、そのようなDIOの受信トリクル操作には影響しません。
o The Imin parameter SHOULD be set taking into account the connectivity within the network. For highly connected networks, a small Imin value (on the order of the typical transmission delay for a DIO) may lead to congestion in the network as a large number of routers reset their Trickle timers in response to the first receipt of a DIO from the Origin. These routers would generate their DIOs within the Imin interval and cause additional routers to reset their Trickle timers and generate more DIOs. Thus, for highly connected networks, the Imin parameter SHOULD be set to a value at least one order of magnitude larger than the typical transmission delay for a DIO. For sparsely connected networks, the Imin parameter can be set to a value that is a small multiple of the typical transmission delay for a DIO. Note that the Imin value has a direct impact on the time required for a P2P-RPL route discovery to complete. In general, the time required for a P2P-RPL route discovery would increase approximately linearly with the value of the Imin parameter. Since the route discovery must complete while the Origin still belongs to the temporary DAG created for that purpose, the Origin should set the time duration for which a router maintains its membership in the temporary DAG (indicated by the L field inside the P2P-RDO) to a large enough value, taking into account the Imin value as well as the expected distance (in terms of hops and/or ETX) to the Target(s).
o Iminパラメータは、ネットワーク内の接続を考慮して設定する必要があります（SHOULD）。高度に接続されたネットワークの場合、Imin値が小さい（DIOの一般的な伝送遅延のオーダーで）と、ネットワークから輻輳が発生する可能性があります。原点。これらのルーターは、Imin間隔内にDIOを生成し、追加のルーターにトリクルタイマーをリセットして、より多くのDIOを生成させます。したがって、高度に接続されたネットワークの場合、Iminパラメータは、DIOの一般的な伝送遅延よりも少なくとも1桁大きい値に設定する必要があります（SHOULD）。疎に接続されたネットワークの場合、Iminパラメーターは、DIOの一般的な伝送遅延の小さな倍数である値に設定できます。 Imin値は、P2P-RPLルートディスカバリが完了するのに必要な時間に直接影響することに注意してください。一般に、P2P-RPLルートディスカバリに必要な時間は、Iminパラメータの値にほぼ比例して増加します。オリジンがその目的のために作成された一時DAGにまだ属している間にルート検出が完了する必要があるため、オリジンはルーターが一時DAGのメンバーシップを維持する期間を設定する必要があります（P2P-RDO内のLフィールドで示されます） Imin値とターゲットまでの予想される距離（ホップおよび/またはETXの観点から）を考慮して、十分に大きな値に設定します。
o The Imax parameter SHOULD be set to a large value (several orders of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event and would lead to the resetting of the Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, the Trickle timer may not get a chance to increase much.
o Imaxパラメータは大きな値（Imin値よりも数桁高い値）に設定する必要があり（SHOULD）、P2P-RPL動作にとって重要である可能性は低いです。これは、特定の一時的なDAGのP2PモードDIOの最初の受信は一貫性のないイベントと見なされ、トリクルタイマー期間がImin値にリセットされることになるためです。 P2P-RPLで使用されるDAGの一時的な性質を考えると、トリクルタイマーはそれほど増加する機会を得られない可能性があります。
o The recommended value of redundancy constant "k" is 1. With this value of "k", a DIO transmission will be suppressed if the router receives even a single "consistent" DIO during a timer interval. This setting for the redundancy constant is designed to reduce the number of messages generated during a route discovery process and is suitable for environments with low or moderate packet loss rates. However, this setting may result in an increase in the time required for the route discovery process to complete. A higher value for the redundancy constant may be more suitable in
o 冗長定数「k」の推奨値は1です。この「k」の値を使用すると、タイマー間隔中にルーターが単一の「一貫した」DIOを受信した場合でも、DIO送信は抑制されます。この冗長定数の設定は、ルート検出プロセス中に生成されるメッセージの数を減らすように設計されており、パケット損失率が低いまたは中程度の環境に適しています。ただし、この設定により、ルート検出プロセスの完了に必要な時間が増加する可能性があります。冗長定数の値が高いほど、
* environments with high packet loss rates; or
* パケット損失率の高い環境。または
* deployments where the time required for the route discovery process to complete needs to be as small as possible; or
* ルートディスカバリプロセスが完了するのに必要な時間をできるだけ短くする必要がある配置。または
* deployments where specific destinations are reachable only through specific Intermediate Routers (and hence these Intermediate Routers should not suppress their DIOs).
* 特定の宛先が特定の中間ルーター経由でのみ到達可能なデプロイメント（したがって、これらの中間ルーターはDIOを抑制すべきではありません）。
A particular deployment should take into account the above-mentioned factors when deciding on the value of the redundancy constant.
特定の配置では、冗長定数の値を決定する際に上記の要素を考慮する必要があります。
Individual P2P-RPL deployments are encouraged to share their experience with these rules to help guide the development of a Standards Track version of the protocol. Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant.
個々のP2P-RPL展開では、これらの経験をこれらのルールと共有して、プロトコルのStandards Trackバージョンの開発をガイドすることをお勧めします。 P2P-RPLの使用を指定する適用性ステートメントは、トリクルパラメータ、特にIminと冗長定数を設定するためのガイダンスを提供する必要があります。
The rules for DIO processing and transmission as described in Section 8 of RPL [RFC6550] apply to P2P mode DIOs as well, except as modified in this document. In particular, in accordance with Section 8.2.3 of RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is malformed, according to the rules specified in this document and in [RFC6550].
RPL [RFC6550]のセクション8で説明されているDIO処理と送信のルールは、このドキュメントで変更されている場合を除き、P2PモードDIOにも適用されます。特に、RPL [RFC6550]のセクション8.2.3に従って、このドキュメントと[RFC6550]で指定されたルールに従って、受信したP2PモードDIOが不正な形式である場合は破棄する必要があります。
The following rules for processing a received P2P mode DIO apply to both Intermediate Routers and the Target.
受信したP2PモードDIOを処理するための次のルールは、中間ルーターとターゲットの両方に適用されます。
A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO, taking into account the metric's value in both Forward and Reverse directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the P2P-DRO messages travel from the Target to the Origin along a discovered route.
ルーターは、受信したDIOを生成したネイバーとの双方向の到達可能性がない場合、受信したP2PモードのDIOをそれ以上破棄せずに破棄する必要があります。双方向の到達可能性は、リンクのルーティングメトリックの値が両方向で同じである必要があることを意味しないことに注意してください。ルーターは、順方向と逆方向の両方のメトリックの値を考慮して、受信したDIOに含まれるリンクレベルのルーティングメトリックの値を計算する必要があります（SHOULD）。検出されたルートに沿った双方向の到達可能性により、ターゲットはこのルートを使用してオリジンに到達できます。特に、P2P-DROメッセージは、発見されたルートに沿ってターゲットからオリジンに移動します。
A router MUST discard a received P2P mode DIO with no further processing:
ルーターは受信したP2PモードDIOをこれ以上処理せずに破棄しなければなりません（MUST）。
o if the DIO advertises INFINITE_RANK as defined in Section 17 of [RFC6550]
o [RFC6550]のセクション17で定義されているようにDIOがINFINITE_RANKをアドバタイズする場合
o if the integer part of the rank advertised in the DIO equals or exceeds the MaxRank limit listed in the P2P Route Discovery Option
o DIOでアドバタイズされるランクの整数部分が、P2Pルート検出オプションにリストされているMaxRank制限以上である場合
o if the routing metric values do not satisfy one or more of the mandatory route constraints listed in the DIO or if the router cannot evaluate the mandatory route constraints, e.g., if the router does not support the metrics used in the constraints
o ルーティングメトリック値がDIOにリストされている必須ルート制約の1つ以上を満たさない場合、またはルーターが必須ルート制約を評価できない場合（例：ルーターが制約で使用されるメトリックをサポートしていない場合）
o if the router previously received a P2P-DRO message with the same RPLInstanceID and DODAGID as the received DIO and with the Stop flag set to one
o ルーターが以前に、受信したDIOと同じRPLInstanceIDおよびDODAGIDを持ち、Stopフラグが1に設定されたP2P-DROメッセージを受信した場合
The router MUST check the Target addresses listed in the P2P-RDO and any RPL Target options included in the received DIO. If one of its IPv6 addresses is listed as a Target address or if it belongs to the multicast group specified as one of the Target addresses, the router considers itself a Target and processes the received DIO as specified in Section 9.5. Otherwise, the router considers itself an Intermediate Router and processes the received DIO as specified in Section 9.4.
ルーターは、P2P-RDOにリストされているターゲットアドレスと、受信したDIOに含まれているRPLターゲットオプションを確認する必要があります。 IPv6アドレスの1つがターゲットアドレスとしてリストされている場合、またはターゲットアドレスの1つとして指定されたマルチキャストグループに属している場合、ルーターはそれ自体をターゲットと見なし、セクション9.5で指定されているように受信したDIOを処理します。それ以外の場合、ルーターは自身を中間ルーターと見なし、セクション9.4で指定されているように受信したDIOを処理します。
An Intermediate Router MUST discard a received P2P mode DIO with no further processing
中間ルーターは、受信したP2PモードDIOをそれ以上処理せずに破棄する必要があります
o if the DIO is received on an Ingress-only Interface; or
o DIOが入力専用インターフェースで受信された場合。または
o if the receiving interface does not have a global or unique-local IPv6 address configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO; or
o 受信インターフェイスに、受信したDIO内のP2P-RDOのComprフィールドによって暗黙に指定されたアドレスプレフィックスで構成されたグローバルまたは一意のローカルIPv6アドレスがない場合。または
o if the router cannot uniquely identify the address prefix implied by the Compr field in the P2P-RDO (this might happen if the receiving interface has multiple global/unique-local IPv6 addresses, each configured with a different address prefix); or
o ルーターがP2P-RDOのComprフィールドによって暗示されるアドレスプレフィックスを一意に識別できない場合（これは、受信インターフェイスに複数のグローバル/ユニークローカルIPv6アドレスがあり、それぞれが異なるアドレスプレフィックスで構成されている場合に発生する可能性があります）;または
o if adding its IPv6 address to the route in the Address vector inside the P2P-RDO would result in the route containing multiple addresses belonging to this router.
o P2P-RDO内のアドレスベクタのルートにIPv6アドレスを追加すると、このルータに属する複数のアドレスを含むルートになります。
On receiving a P2P mode DIO, an Intermediate Router MUST do the following. The router MUST determine whether this DIO advertises a better route than the router itself and whether the receipt of the DIO would allow the router to advertise a better route than before. Accordingly, the router SHOULD consider this DIO as consistent/inconsistent from the Trickle perspective, as described in Section 9.2. Note that the route comparison in a P2P-RPL route discovery is performed using the parent selection rules of the OF in use as specified in Section 14 of RPL [RFC6550]. If the received DIO would allow the router to advertise a better route, the router MUST add a unicast IPv6 address of the receiving interface (after eliding Compr prefix octets) to the route in the Address vector inside the P2P-RDO and remember this route for inclusion in its future DIOs.
P2PモードDIOを受信すると、中間ルーターは以下を実行する必要があります。ルーターは、このDIOがルーター自体よりも優れたルートをアドバタイズするかどうか、およびDIOの受信によりルーターが以前よりも優れたルートをアドバタイズできるかどうかを決定する必要があります。したがって、ルータは、セクション9.2で説明されているように、トリクルの観点からこのDIOを一貫性/非一貫性があると見なすべきです。 P2P-RPLルートディスカバリでのルート比較は、RPL [RFC6550]のセクション14で指定されている使用中のOFの親選択ルールを使用して実行されることに注意してください。受信したDIOによってルーターがより適切なルートをアドバタイズできる場合、ルーターは受信インターフェイスのユニキャストIPv6アドレスを（Comprプレフィックスオクテットを削除した後）P2P-RDO内のアドレスベクターのルートに追加し、このルートを覚えておかなければなりません（MUST）。将来のDIOに含める。
When an Intermediate Router adds an IPv6 address to a route, it MUST ensure that
中間ルーターがIPv6アドレスをルートに追加するとき、それはそれを保証しなければなりません
o the IPv6 address is a unicast global or unique-local IPv6 address assigned to the interface on which the DIO containing the route was received;
o IPv6アドレスは、ルートを含むDIOが受信されたインターフェースに割り当てられたユニキャストグローバルまたはユニークローカルIPv6アドレスです。
o the IPv6 address was configured with the address prefix implied by the Compr field in the P2P-RDO inside the received DIO.
o IPv6アドレスは、受信したDIO内のP2P-RDOのComprフィールドによって暗示されるアドレスプレフィックスで構成されました。
To improve the diversity of the routes being discovered, an Intermediate Router SHOULD keep track of multiple routes (as long as all these routes are the best seen so far), one of which SHOULD be selected in a uniform random manner for inclusion in the P2P-RDO inside the router's next DIO. Note that the route accumulation in a P2P mode DIO MUST take place even if the Origin does not want any P2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO is set to zero). This is because the Target may still be able to use the accumulated route as a Source Route to reach the Origin.
発見されるルートの多様性を改善するために、中間ルーターは複数のルートを追跡する必要があります（これらすべてのルートがこれまでのところ最もよく見られる限り）。そのうちの1つはP2Pに含めるために一様にランダムに選択する必要があります（SHOULD）。 -ルーターの次のDIO内のRDO。オリジンがP2P-DROメッセージの生成を望まない場合（つまり、P2P-RDO内のRフラグがゼロに設定されている場合）でも、P2PモードDIOでのルートの蓄積が行われる必要があることに注意してください。これは、ターゲットが累積ルートをソースルートとして使用して、オリジンに到達できる可能性があるためです。
The Target MAY remember the discovered route contained in the P2P-RDO in the received DIO for use as a Source Route to reach the Origin. The lifetime of this Source Route is specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option currently in effect. This lifetime can be extended (or shortened) appropriately, following a hint from an upper-layer protocol.
ターゲットは、オリジンに到達するためのソースルートとして使用するために、受信したDIOのP2P-RDOに含まれる検出されたルートを記憶する場合があります。このソースルートのライフタイムは、現在有効なDODAG構成オプション内のデフォルトのライフタイムおよびライフタイムユニットパラメーターによって指定されます。このライフタイムは、上位プロトコルからのヒントに従って、適切に延長（または短縮）できます。
If the Reply flag inside the P2P-RDO in the received DIO is set to one, the Target MUST select one or more discovered routes and send one or more P2P-DRO messages, carrying one discovered route each, back to the Origin. If the H flag inside the P2P-RDO is set to one, the Target needs to select one route and send a P2P-DRO message along this route back to the Origin. As this P2P-DRO message travels back to the Origin, the routers on the path establish a hop-by-hop routing state, thereby establishing a Hop-by-hop Route in the Forward direction. If the H flag is set to zero, the number of Source Routes to be selected (and the number of P2P-DRO messages to be sent back) is given by one plus the value of the N field in the P2P-RDO. The Target may select the discovered route inside the received DIO as one or more of the routes that would be carried inside a P2P-DRO message back to the Origin. This document does not prescribe a particular method for the Target to select the routes. Example methods include selecting each route that meets the specified routing constraints until the desired number of routes has been selected, or selecting the best routes discovered over a certain time period. If multiple routes are to be selected, the Target SHOULD avoid selecting routes that have large segments in common.
受信したDIOのP2P-RDO内の返信フラグが1に設定されている場合、ターゲットは1つ以上の発見されたルートを選択し、1つ以上のP2P-DROメッセージを送信し、発見されたルートを1つずつ送信して、オリジンに戻す必要があります。 P2P-RDO内のHフラグが1に設定されている場合、ターゲットは1つのルートを選択し、このルートに沿ってP2P-DROメッセージをオリジンに送信する必要があります。このP2P-DROメッセージがオリジンに戻ると、パス上のルーターがホップバイホップのルーティング状態を確立し、それにより、フォワード方向のホップバイホップルートが確立されます。 Hフラグがゼロに設定されている場合、選択されるソースルートの数（および送り返されるP2P-DROメッセージの数）は、1にP2P-RDOのNフィールドの値を足したもので与えられます。ターゲットは、受信したDIO内で発見されたルートを、P2P-DROメッセージ内でオリジンに返送される1つ以上のルートとして選択できます。このドキュメントでは、ターゲットがルートを選択するための特定の方法を規定していません。方法の例には、目的の数のルートが選択されるまで、指定されたルーティング制約を満たす各ルートを選択すること、または特定の期間にわたって検出された最適なルートを選択することが含まれます。複数のルートを選択する場合、ターゲットは、共通の大きなセグメントを持つルートを選択しないようにする必要があります。
If the Target selects the route contained in the P2P-RDO in the received DIO, it sends a P2P-DRO message back to the Origin (identified by the DODAGID field in the DIO). The P2P-DRO message MUST include a P2P-RDO that contains the selected route inside the Address vector. Various fields inside the P2P-RDO MUST be set as specified in Section 8.2. The Target MAY set the A flag inside the P2P-DRO message to one if it desires the Origin to send back a P2P-DRO-ACK message on receiving the P2P-DRO. In this case, the Target waits for the duration of P2P_DRO_ACK_WAIT_TIME for the P2P-DRO-ACK message to arrive. Failure to receive the P2P-DRO-ACK message within this time duration causes the Target to retransmit the P2P-DRO message. The Target MAY retransmit the P2P-DRO message in this fashion up to MAX_P2P_DRO_RETRANSMISSIONS times. Both P2P_DRO_ACK_WAIT_TIME and MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be chosen based on the characteristics of individual deployments. Note that all P2P-DRO transmissions and retransmissions MUST take place while the Target is still a part of the temporary DAG created for the route discovery. A Target MUST NOT transmit a P2P-DRO if it no longer belongs to this DAG.
ターゲットが受信したDIOのP2P-RDOに含まれるルートを選択した場合、ターゲットはP2P-DROメッセージをオリジンに送信します（DIOのDODAGIDフィールドで識別されます）。 P2P-DROメッセージには、アドレスベクトル内の選択されたルートを含むP2P-RDOを含める必要があります。 P2P-RDO内のさまざまなフィールドは、セクション8.2で指定されているように設定する必要があります。ターゲットは、オリジンがP2P-DROの受信時にP2P-DRO-ACKメッセージを送り返すことを望む場合、P2P-DROメッセージ内のAフラグを1に設定できます。この場合、ターゲットはP2P-DRO-ACKメッセージが到着するまでP2P_DRO_ACK_WAIT_TIMEの間待機します。この期間内にP2P-DRO-ACKメッセージを受信できなかった場合、ターゲットはP2P-DROメッセージを再送信します。ターゲットは、最大でMAX_P2P_DRO_RETRANSMISSIONS回、この方法でP2P-DROメッセージを再送信できます。 P2P_DRO_ACK_WAIT_TIMEとMAX_P2P_DRO_RETRANSMISSIONSはどちらも、個々のデプロイメントの特性に基づいて選択される構成可能なパラメーターです。ターゲットがルートディスカバリ用に作成された一時的なDAGの一部である間に、すべてのP2P-DRO送信と再送信を実行する必要があることに注意してください。ターゲットがこのDAGに属していない場合、ターゲットはP2P-DROを送信してはなりません。
The Target MAY set the Stop flag inside the P2P-DRO message to one if
ターゲットは、P2P-DROメッセージ内の停止フラグを1に設定する場合があります。
o this router is the only Target specified in the corresponding DIO, i.e., the corresponding DIO specified a unicast address of the router as the TargetAddr inside the P2P-RDO with no additional Targets specified via RPL Target options; and
o このルーターは、対応するDIOで指定された唯一のターゲットです。つまり、対応するDIOは、RPLターゲットオプションで追加のターゲットを指定せずに、ルーターのユニキャストアドレスをP2P-RDO内のTargetAddrとして指定しました。そして
o the Target has already selected the desired number of routes.
o ターゲットはすでに必要な数のルートを選択しています。
The Target MAY include a Metric Container option in the P2P-DRO message. This Metric Container contains the end-to-end routing metric values for the route specified in the P2P-RDO. The Target MUST transmit the P2P-DRO message via a link-local multicast.
ターゲットは、P2P-DROメッセージにメトリックコンテナオプションを含めることができます。このメトリックコンテナには、P2P-RDOで指定されたルートのエンドツーエンドのルーティングメトリック値が含まれています。ターゲットは、リンクローカルマルチキャストを介してP2P-DROメッセージを送信する必要があります。
A Target MUST NOT forward a P2P mode DIO any further if no other Targets are to be discovered, i.e., if a unicast IPv6 address (of this Target) is specified as the TargetAddr inside the P2P-RDO and no additional Targets are specified via RPL Target options inside the DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery as an Intermediate Router would.
他のターゲットが検出されない場合、つまり、（このターゲットの）ユニキャストIPv6アドレスがP2P-RDO内のTargetAddrとして指定されており、RPLを介して追加のターゲットが指定されていない場合、ターゲットはP2PモードDIOを転送してはなりません（MUST NOT）。このルート検出のDIO内のターゲットオプション。それ以外の場合、ターゲットは、中間ルーターと同じように、このルート検出用のDIOを生成する必要があります。
If the DODAGID field in the received P2P-DRO does not list a router's own IPv6 address, the router considers itself an Intermediate Router and MUST process the received message in the following manner:
受信したP2P-DROのDODAGIDフィールドにルーター自体のIPv6アドレスがリストされていない場合、ルーターは自身を中間ルーターと見なし、受信したメッセージを次の方法で処理する必要があります。
o The router MUST discard the received P2P-DRO with no further processing if it does not belong to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o P2P-DROのRPLInstanceIDおよびDODAGIDフィールドで識別される一時的なDAGに属していない場合、ルーターは受信したP2P-DROをそれ以上破棄せずに破棄する必要があります。
o If the Stop flag inside the received P2P-DRO is set to one, the router SHOULD NOT send or receive any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmissions.
o 受信したP2P-DRO内の停止フラグが1に設定されている場合、ルーターはこの一時的なDAGのDIOをこれ以上送信または受信してはならず（SHOULD NOT）、保留中のDIO送信をキャンセルする必要があります（SHOULD）。
o The router MUST ignore any Metric Container options contained in the P2P-DRO message.
o ルータは、P2P-DROメッセージに含まれるメトリックコンテナオプションを無視する必要があります。
o If an Address[NH] element inside the P2P-RDO lists the router's own unicast IPv6 address, the router is a part of the route carried in the P2P-RDO. In this case, the router MUST do the following:
o P2P-RDO内のAddress [NH]要素がルーター自身のユニキャストIPv6アドレスをリストする場合、ルーターはP2P-RDOで伝送されるルートの一部です。この場合、ルーターは次のことを実行する必要があります。
* To prevent loops, the router MUST discard the P2P-DRO message with no further processing if the Address vector in the P2P-RDO includes multiple IPv6 addresses assigned to the router's interfaces.
* ループを防ぐために、P2P-RDOのアドレスベクトルにルーターのインターフェイスに割り当てられた複数のIPv6アドレスが含まれている場合、ルーターはP2P-DROメッセージを破棄せずに処理する必要があります。
* If the H flag inside the P2P-RDO is set to one, the router MUST store the state for the Forward Hop-by-hop Route carried inside the P2P-RDO. This state consists of:
* P2P-RDO内のHフラグが1に設定されている場合、ルーターは、P2P-RDO内で運ばれる転送ホップバイホップルートの状態を格納する必要があります。この状態は以下で構成されます。
+ the RPLInstanceID and the DODAGID fields of the P2P-DRO
+ P2P-DROのRPLInstanceIDおよびDODAGIDフィールド
+ the route's destination, the Target (identified by the TargetAddr field inside the P2P-RDO)
+ ルートの宛先であるターゲット（P2P-RDO内のTargetAddrフィールドで識別）
+ the IPv6 address of the next hop, Address[NH+1] (unless the NH value equals the number of elements in the Address vector, in which case the Target itself is the next hop)
+ ネクストホップのIPv6アドレス、Address [NH + 1]（NH値がアドレスベクトルの要素数と等しくない場合。この場合、ターゲット自体がネクストホップです）
This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery.
このホップバイホップのルーティング状態は、このルート検出のためにP2PモードDIOで使用されるDODAG構成オプション内のデフォルトのライフタイムおよびライフタイムユニットパラメーターで指定されたライフタイムの終わりに期限切れになる必要があります。
* If the router already maintains a Hop-by-hop state listing the Target as the destination and carrying the same RPLInstanceID and DODAGID fields as the received P2P-DRO, and the next-hop information in the state does not match the next hop indicated in the received P2P-DRO, the router MUST discard the P2P-DRO message with no further processing. Note that this situation would occur in the following two cases:
* ルータがすでにターゲットを宛先としてリストし、受信したP2P-DROと同じRPLInstanceIDおよびDODAGIDフィールドを運ぶホップバイホップ状態を維持しており、状態のネクストホップ情報がに示されているネクストホップと一致しない場合受信したP2P-DRO、ルータはそれ以上の処理なしでP2P-DROメッセージを破棄しなければなりません（MUST）。この状況は、次の2つの場合に発生することに注意してください。
+ When the route listed in the Address vector inside the P2P-RDO contains a previously undetected loop. In this case, this rule causes the P2P-DRO messages to be discarded.
+ P2P-RDO内のアドレスベクターにリストされているルートに、以前に検出されなかったループが含まれている場合。この場合、このルールによりP2P-DROメッセージが破棄されます。
+ When a Hop-by-hop Route between the Origin and the Target, previously established using the same RPLInstanceID and DODAGID as the route currently being established, still exists and at least partially overlaps the route currently being established.
+ 現在確立されているルートと同じRPLInstanceIDとDODAGIDを使用して以前に確立された、オリジンとターゲット間のホップバイホップルートがまだ存在し、現在確立されているルートと少なくとも部分的に重複している場合。
* The router MUST decrement the NH field inside the P2P-RDO and send the P2P-DRO message further via link-local multicast.
* ルータは、P2P-RDO内のNHフィールドをデクリメントし、リンクローカルマルチキャストを介してP2P-DROメッセージをさらに送信する必要があります。
When a router receives a P2P-DRO message that lists its IPv6 address in the DODAGID field, the router recognizes itself as the Origin for the corresponding P2P-RPL route discovery, notes the Target that originated this message (from the TargetAddr field inside the P2P-RDO), and processes the message in the following manner:
ルーターは、IPv6アドレスをDODAGIDフィールドにリストするP2P-DROメッセージを受信すると、対応するP2P-RPLルートディスカバリのオリジンとして自身を認識し、このメッセージを発信したターゲットを（P2P内のTargetAddrフィールドから）確認します-RDO）、次の方法でメッセージを処理します。
o The Origin MUST discard the received P2P-DRO with no further processing if it no longer belongs to the temporary DAG identified by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o Originは、受信したP2P-DROのRPLInstanceIDおよびDODAGIDフィールドによって識別される一時的なDAGに属していない場合、受信したP2P-DROをそれ以上破棄せずに破棄する必要があります。
o If the Stop flag inside the received P2P-DRO is set to one, the Origin SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD cancel any pending DIO transmissions.
o 受信したP2P-DRO内の停止フラグが1に設定されている場合、Originはこの一時DAGに対してこれ以上DIOを生成してはならず（SHOULD NOT）、保留中のDIO送信をキャンセルする必要があります（SHOULD）。
o If the P2P-RDO inside the P2P-DRO has the H flag set to zero, the Address vector inside the P2P-RDO contains a Source Route to this Target. The Origin MUST set the lifetime of this Source Route to the value specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option in the P2P mode DIOs used for this route discovery. This lifetime could be extended (or shortened) appropriately, following a hint from an upper-layer protocol.
o P2P-DRO内のP2P-RDOのHフラグがゼロに設定されている場合、P2P-RDO内のアドレスベクトルには、このターゲットへのソースルートが含まれます。オリジンは、このソースルートのライフタイムを、このルートディスカバリに使用されるP2PモードDIOのDODAG構成オプション内のデフォルトライフタイムおよびライフタイムユニットパラメータで指定された値に設定する必要があります。このライフタイムは、上位層プロトコルからのヒントに従って、適切に延長（または短縮）できます。
o If the P2P-RDO inside the P2P-DRO has the H flag set to one, the P2P-DRO message is establishing a Hop-by-hop Route to this Target, and the Origin MUST store in its memory the state for this Hop-by-hop Route in the manner described in Section 9.6. This Hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. A Standards Track version of P2P-RPL may consider specifying a signaling mechanism that will allow the Origin to extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route, following a suitable hint from an upper-layer protocol.
o P2P-DRO内のP2P-RDOのHフラグが1に設定されている場合、P2P-DROメッセージはこのターゲットへのホップバイホップルートを確立しており、オリジンはこのホップの状態をメモリに保存する必要があります。セクション9.6に記載されている方法によるホップバイルート。このホップバイホップのルーティング状態は、このルート検出のためにP2PモードDIOで使用されるDODAG構成オプション内のデフォルトのライフタイムおよびライフタイムユニットパラメーターで指定されたライフタイムの終わりに期限切れになる必要があります。 Standards TrackバージョンのP2P-RPLは、上位層プロトコルからの適切なヒントに従って、OriginがP2P-RPLホップバイホップルートの寿命を延長（または短縮）できるシグナリングメカニズムの指定を検討する場合があります。
o If the received P2P-DRO message contains one or more Metric Container options, the Origin MAY store the values of the routing metrics associated with the discovered route in its memory. This information may be useful in formulating the constraints for any future P2P-RPL route discovery to this Target.
o 受信したP2P-DROメッセージに1つ以上のメトリックコンテナオプションが含まれている場合、Originは、検出されたルートに関連付けられたルーティングメトリックの値をメモリに格納できます（MAY）。この情報は、このターゲットへの将来のP2P-RPLルート検出の制約を定式化するのに役立つ場合があります。
o If the A flag is set to one in the received P2P-DRO message, the Origin MUST generate a P2P-DRO-ACK message as described in Section 10 and unicast the message to the Target. The Origin MAY use the route just discovered to send the P2P-DRO-ACK message to the Target. Section 12 describes how a packet may be forwarded along a Source/Hop-by-hop Route discovered using P2P-RPL.
o 受信したP2P-DROメッセージでAフラグが1に設定されている場合、Originはセクション10で説明されているようにP2P-DRO-ACKメッセージを生成し、メッセージをターゲットにユニキャストしなければなりません。オリジンは、P2P-DRO-ACKメッセージをターゲットに送信するために、検出されたばかりのルートを使用する場合があります。セクション12では、P2P-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DODAGID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the Base P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK)
図3：基本P2Pディスカバリ応答オブジェクト確認の形式（P2P-DRO-ACK）
A P2P-DRO message may fail to reach the Origin due to a number of reasons. Unlike the DIO messages, which benefit from Trickle-controlled retransmissions, the P2P-DRO messages are prone to loss due to unreliable packet transmission in LLNs. Since a P2P-DRO message travels via link-local multicast, it cannot use link-level acknowledgements to improve the reliability of its transmission. Also, an Intermediate Router may drop the P2P-DRO message (e.g., because of its inability to store the state for the Hop-by-hop Route that the P2P-DRO is establishing). To protect against the potential failure of a P2P-DRO message to reach the Origin, the Target MAY request that the Origin send back a P2P-DRO Acknowledgement (P2P-DRO-ACK) message on receiving a P2P-DRO message. Failure to receive such an acknowledgement within the P2P_DRO_ACK_WAIT_TIME interval of sending the P2P-DRO message forces the Target to resend the message (as described in Section 9.5).
P2P-DROメッセージは、いくつかの理由でオリジンに到達できない場合があります。トリクル制御の再送信の恩恵を受けるDIOメッセージとは異なり、P2P-DROメッセージは、LLNでの信頼性の低いパケット送信が原因で失われる傾向があります。 P2P-DROメッセージはリンクローカルマルチキャストを介して送信されるため、リンクレベルの確認応答を使用して送信の信頼性を向上させることはできません。また、中間ルーターはP2P-DROメッセージをドロップする場合があります（たとえば、P2P-DROが確立しているホップバイホップルートの状態を保存できないため）。 P2P-DROメッセージがオリジンに到達する可能性のある障害から保護するために、ターゲットは、オリジンがP2P-DROメッセージの受信時にP2P-DRO確認応答（P2P-DRO-ACK）メッセージを返信することを要求できます（MAY）。 P2P-DROメッセージを送信してからP2P_DRO_ACK_WAIT_TIME間隔内にそのような確認応答を受信できなかった場合、ターゲットは強制的にメッセージを再送信します（セクション9.5を参照）。
This section defines two new RPL control message types: the P2P-DRO Acknowledgement (P2P-DRO-ACK), with code 0x05; and the Secure P2P-DRO-ACK, with code 0x85. A P2P-DRO-ACK message MUST travel as a unicast message from the Origin to the Target. The IPv6 source and destination addresses used in a P2P-DRO-ACK message MUST be global or unique-local. The format of a base P2P-DRO-ACK message is shown in Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same values as the corresponding fields in the P2P-DRO message. The field marked as "Reserved" MUST be set to zero on transmission and MUST be ignored on reception. A Secure P2P-DRO-ACK message follows the format shown in Figure 7 of [RFC6550], where the base format is the same as the base P2P-DRO-ACK shown in Figure 3.
このセクションでは、2つの新しいRPL制御メッセージタイプを定義します。P0P-DRO確認応答（P2P-DRO-ACK）とコード0x05です。セキュアP2P-DRO-ACK、コード0x85。 P2P-DRO-ACKメッセージは、オリジンからターゲットへのユニキャストメッセージとして移動する必要があります。 P2P-DRO-ACKメッセージで使用されるIPv6送信元アドレスと宛先アドレスは、グローバルまたは一意ローカルである必要があります。基本P2P-DRO-ACKメッセージのフォーマットを図3に示します。P2P-DRO-ACKメッセージのさまざまなフィールドには、P2P-DROメッセージの対応するフィールドと同じ値を指定する必要があります。 「予約済み」とマークされたフィールドは、送信時にゼロに設定する必要があり、受信時には無視する必要があります。セキュアなP2P-DRO-ACKメッセージは、[RFC6550]の図7に示す形式に従います。基本形式は、図3に示す基本P2P-DRO-ACKと同じです。
Each RPL control message type, including those defined in this document, has a secure version. A secure RPL control message is identified by the value 1 in the most significant bit of the Code field. Each secure RPL control message contains a Security section (see Figures 7 and 8 of [RFC6550]) whose contents are described in Section 6.1 of [RFC6550]. Sections 6.1, 10, and 19 of [RFC6550] describe core RPL's security apparatus. These sections are applicable to P2P-RPL's secure operation as well, except as constrained in this section.
このドキュメントで定義されているものを含め、各RPLコントロールメッセージタイプには、安全なバージョンがあります。安全なRPL制御メッセージは、コードフィールドの最上位ビットの値1によって識別されます。各セキュアRPL制御メッセージには、セキュリティセクション（[RFC6550]の図7および8を参照）が含まれ、その内容は[RFC6550]のセクション6.1で説明されています。 [RFC6550]のセクション6.1、10、および19は、コアRPLのセキュリティ装置について説明しています。これらのセクションは、このセクションで制限されている場合を除き、P2P-RPLのセキュアな動作にも適用されます。
Core RPL allows a router to decide locally on a per-packet basis whether to use security and, if yes, what Security Configuration (see definition in Section 3) to use (the only exception being the requirement to send a Secure DIO in response to a Secure DIS; see Section 10.2 of [RFC6550]). In contrast, this document requires that routers participating in a P2P-RPL route discovery follow the Origin's lead regarding security. The Origin decides whether to use security, and the particular Security Configuration to be used for this purpose. All the routers participating in this route discovery MUST generate only secure control messages if the Origin so decides and MUST use for this purpose the Security Configuration that the Origin chose. The Origin MUST NOT set the "Key Identifier Mode" field inside the chosen Security Configuration to value 1, since this setting indicates the use of a per-pair key, which is not suitable for securing messages that travel by (link-local) multicast (e.g., DIOs) or that travel over multiple hops (e.g., P2P-DROs). The Origin MUST use the chosen Security Configuration to secure all the control messages (DIOs and P2P-DRO-ACKs) it generates.
コアRPLにより、ルーターはパケットごとにローカルでセキュリティを使用するかどうかを決定し、使用する場合は、どのセキュリティ構成（セクション3の定義を参照）を使用するかを決定できます（唯一の例外は、応答としてセキュアDIOを送信する必要があることです）安全なDIS。[RFC6550]のセクション10.2をご覧ください）。対照的に、このドキュメントでは、P2P-RPLルートディスカバリに参加しているルーターが、セキュリティに関するオリジンの先導に従う必要があります。オリジンは、セキュリティを使用するかどうか、およびこの目的で使用される特定のセキュリティ構成を決定します。このルート検出に参加するすべてのルーターは、Originが決定した場合にのみ安全な制御メッセージを生成する必要があり、Originが選択したセキュリティ構成をこの目的で使用する必要があります。オリジンは、選択されたセキュリティ構成内の「キー識別子モード」フィールドを値1に設定してはなりません（この設定はペアごとのキーの使用を示すため、（リンクローカル）マルチキャストで移動するメッセージのセキュリティ保護には適していません） （例：DIO）または複数のホップ（例：P2P-DRO）を経由するもの。オリジンは、選択したセキュリティ構成を使用して、生成するすべての制御メッセージ（DIOおよびP2P-DRO-ACK）を保護する必要があります。
A router MUST NOT join the temporary DAG being created for a P2P-RPL route discovery if:
次の場合、ルーターはP2P-RPLルート検出用に作成されている一時的なDAGに参加してはなりません（MUST NOT）。
o it receives both secure and unsecure DIOs or Secure DIOs with different Security Configurations pertaining to this route discovery (i.e., referring to the same RPLInstanceID and DODAGID combination) prior to joining; or
o 参加する前に、このルート検出に関連するセキュリティ構成が異なる（つまり、同じRPLInstanceIDとDODAGIDの組み合わせを参照する）セキュアと非セキュアの両方のDIOまたはセキュアDIOを受け取ります。または
o it cannot use the Security Configuration found in the Secure DIOs pertaining to this route discovery.
o このルート検出に関連するセキュアDIOにあるセキュリティ構成を使用することはできません。
When a router (an Intermediate Router or a Target) joins a temporary DAG being created using Secure DIOs, it MUST remember the common Security Configuration used in the received Secure DIOs and MUST use this configuration to secure all the control messages (DIOs and P2P-DROs) it generates.
ルーター（中間ルーターまたはターゲット）がセキュアDIOを使用して作成されている一時的なDAGに参加する場合、受信したセキュアDIOで使用される一般的なセキュリティ構成を記憶し、この構成を使用してすべての制御メッセージ（DIOおよびP2P- DRO）生成します。
If an Intermediate Router (or a Target) encounters a control message (a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route discovery that is either not secure or does not follow the Security Configuration the router remembers for this route discovery, the router MUST enter the "lock down" mode for the remainder of its stay in this temporary DAG. An Intermediate Router (or a Target) in the "lock down" mode MUST NOT generate or process any control messages (irrespective of the Security Configuration used) pertaining to this route discovery. If the Origin receives a control message (a P2P-DRO) that does not follow the Security Configuration the Origin has chosen for this route discovery, it MUST discard the received message with no further processing.
中間ルーター（またはターゲット）が、安全ではないか、ルーターが記憶しているセキュリティ構成に従っていないこのルート検出に関連する制御メッセージ（DIOまたはP2P-DROまたはP2P-DRO-ACK）を検出した場合このルート検出では、ルーターはこの一時的なDAGでの残りの滞在のために「ロックダウン」モードに入る必要があります。 「ロックダウン」モードの中間ルーター（またはターゲット）は、このルート検出に関連する（使用されるセキュリティ構成に関係なく）制御メッセージを生成または処理してはなりません（MUST NOT）。オリジンがこのルートディスカバリ用に選択したセキュリティ設定に従わない制御メッセージ（P2P-DRO）を受信した場合、それ以上の処理を行わずに受信メッセージを破棄する必要があります。
An Origin uses the Source Routing Header (SRH) [RFC6554] to send a packet along a Source Route discovered using P2P-RPL.
オリジンは、ソースルーティングヘッダー（SRH）[RFC6554]を使用して、P2P-RPLを使用して検出されたソースルートに沿ってパケットを送信します。
Travel along a Hop-by-hop Route, established using P2P-RPL, requires specifying the RPLInstanceID and the DODAGID (of the temporary DAG used for the route discovery) to identify the route. This is because a P2P-RPL route discovery does not use globally unique RPLInstanceID values, and hence both the RPLInstanceID (a local value assigned by the Origin) and the DODAGID (an IPv6 address of the Origin) are required to uniquely identify a P2P-RPL Hop-by-hop Route to a particular destination.
P2P-RPLを使用して確立されたホップバイホップルートに沿って移動するには、ルートを識別するためにRPLInstanceIDとDODAGID（ルート探索に使用される一時的なDAGの）を指定する必要があります。これは、P2P-RPLルートディスカバリがグローバルに一意のRPLInstanceID値を使用しないため、RPLInstanceID（Originによって割り当てられたローカル値）とDODAGID（OriginのIPv6アドレス）の両方がP2P-特定の宛先へのRPLホップバイホップルート。
An Origin includes a RPL option [RFC6553] inside the IPv6 Hop-by-Hop Options header of a packet to send it along a Hop-by-hop Route established using P2P-RPL. For this purpose, the Origin MUST set the DODAGID of the temporary DAG used for the route discovery as the source IPv6 address of the packet. Further, the Origin MUST specify inside the RPL option the RPLInstanceID of the temporary DAG used for the route discovery and set the O flag inside the RPL option to one. On receiving this packet, an Intermediate Router checks the O flag and correctly infers the source IPv6 address of the packet as the DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, the RPLInstanceID, and the destination address to identify the routing state to be used to forward the packet further.
Originは、パケットのIPv6ホップバイホップオプションヘッダー内にRPLオプション[RFC6553]を含み、P2P-RPLを使用して確立されたホップバイホップルートに沿って送信します。この目的のために、Originは、ルート検出に使用される一時的なDAGのDODAGIDをパケットのソースIPv6アドレスとして設定する必要があります。さらに、Originは、RPLオプション内でルート検出に使用される一時的なDAGのRPLInstanceIDを指定し、RPLオプション内のOフラグを1に設定する必要があります。このパケットを受信すると、中間ルーターはOフラグをチェックし、パケットのソースIPv6アドレスをホップバイホップルートのDODAGIDとして正しく推測します。次に、ルーターはDODAGID、RPLInstanceID、および宛先アドレスを使用して、パケットをさらに転送するために使用されるルーティング状態を識別します。
This section describes how RPL routers that implement P2P-RPL interact with RPL routers that do not. In general, P2P-RPL operation does not affect core RPL operation, and vice versa. However, core RPL does allow a router to join a DAG as a leaf node even if it does not understand the Mode of Operation (MOP) used in the DAG. Thus, a RPL router that does not implement P2P-RPL may conceivably join a temporary DAG being created for a P2P-RPL route discovery as a leaf node and maintain its membership even though the DAG no longer exists. This may impose a drain on the router's memory. However, such RPL-only leaf nodes do not interfere with P2P-RPL route discovery, since a leaf node may only generate a DIO advertising an INFINITE_RANK and all routers implementing P2P-RPL are required to discard such DIOs. Note that core RPL does not require that a router join a DAG whose MOP it does not understand. Moreover, RPL routers in a particular deployment may have strict restrictions on the DAGs they may join, thereby mitigating the problem.
このセクションでは、P2P-RPLを実装するRPLルーターが、RPLルーターと相互作用しない方法について説明します。一般に、P2P-RPL操作はコアRPL操作に影響せず、その逆も同様です。ただし、コアRPLでは、DAGで使用される動作モード（MOP）を理解していない場合でも、ルーターをリーフノードとしてDAGに参加させることができます。したがって、P2P-RPLを実装していないRPLルーターは、P2P-RPLルート探索用に作成されている一時的なDAGをリーフノードとして結合し、DAGが存在しなくなってもメンバーシップを維持する可能性があります。これにより、ルーターのメモリが消耗する可能性があります。ただし、リーフノードはINFINITE_RANKをアドバタイズするDIOのみを生成する可能性があり、P2P-RPLを実装するすべてのルーターはこのようなDIOを破棄する必要があるため、このようなRPLのみのリーフノードはP2P-RPLルートの検出に干渉しません。コアRPLでは、ルーターがMOPが理解できないDAGに参加する必要がないことに注意してください。さらに、特定の展開のRPLルーターは、それらが参加する可能性があるDAGに厳格な制限がある場合があり、それによって問題が軽減されます。
The P2P-RPL mechanism described in this document works best when all the RPL routers in the LLN implement P2P-RPL. In general, the ability to discover routes, as well as the quality of discovered routes, would deteriorate with the fraction of RPL routers that implement P2P-RPL.
このドキュメントで説明されているP2P-RPLメカニズムは、LLNのすべてのRPLルーターがP2P-RPLを実装している場合に最適に機能します。一般に、ルートを検出する機能と検出されたルートの品質は、P2P-RPLを実装するRPLルーターの割合によって低下します。
In general, the security considerations for the operation of P2P-RPL are similar to those for the operation of RPL (as described in Section 19 of the RPL specification [RFC6550]). Sections 6.1 and 10 of [RFC6550] describe RPL's security framework, which provides data confidentiality, authentication, replay protection, and delay protection services. This security framework can also be used in P2P-RPL after taking into account the constraints specified in Section 11. P2P-RPL requires that all routers participating in a secure route discovery use the Security Configuration chosen by the Origin. The intention is to avoid compromising the overall security of a route discovery due to some routers using a weaker Security Configuration. With the "lock down" mechanism as described in Section 11 in effect, it is unlikely that an Origin would accept a route discovered under a Security Configuration other than the one it intended. Any attempt to use a different Security Configuration (than the one the Origin intended) is likely to result, in the worst case, in the failure of the route discovery process. In the best-case scenario, any such attempt by a rogue router would result in its neighbors entering the "lock down" mode and acting as firewalls to allow the route discovery to proceed in the remaining network.
一般に、P2P-RPLの操作に関するセキュリティの考慮事項は、RPLの操作に関するものと同様です（RPL仕様[RFC6550]のセクション19で説明）。 [RFC6550]のセクション6.1および10は、データの機密性、認証、再生保護、および遅延保護サービスを提供するRPLのセキュリティフレームワークについて説明しています。このセキュリティフレームワークは、セクション11で指定された制約を考慮した後、P2P-RPLでも使用できます。P2P-RPLでは、セキュアルートディスカバリに参加するすべてのルーターが、オリジンによって選択されたセキュリティ構成を使用する必要があります。これは、一部のルーターがより弱いセキュリティ構成を使用しているために、ルート検出の全体的なセキュリティが損なわれるのを避けるためです。セクション11で説明した「ロックダウン」メカニズムが有効になっていると、Originが意図したもの以外のセキュリティ構成で発見されたルートを受け入れる可能性は低くなります。 （Originが意図したものとは異なる）セキュリティ構成を使用しようとすると、最悪の場合、ルート検出プロセスが失敗する可能性があります。最良のシナリオでは、不正なルーターによるそのような試みはすべて、ネイバーが「ロックダウン」モードになり、ファイアウォールとして機能して、ルート検出を残りのネットワークで続行できるようにします。
The RPL specification [RFC6550] describes three modes of security: unsecured, preinstalled, and authenticated. In the unsecured mode, secure control messages are not used, and the only available security is the security provided by the link-layer protocols. In the preinstalled mode, all the nodes use a preinstalled group key to join a secure DAG as the "routers" or "hosts", where the term "router" means a node that is capable of forwarding packets received from its parents or children in the DAG, and the term "host" refers to nodes that cannot function as "routers". In the authenticated mode, the nodes can join a secure DAG as "hosts" using the preinstalled key but then need to authenticate themselves to a key server to obtain the key that will allow them to work as "routers". The temporary DAG created for a P2P-RPL discovery cannot be used for routing packets. Hence, it is not meaningful to say that a node joins this DAG as a "router" or a "host" in the sense defined above. Hence, in P2P-RPL, there is no distinction between the preinstalled and authenticated modes. A router can join a temporary DAG created for a secure P2P-RPL route discovery only if it can support the Security Configuration in use, which also specifies the key in use. It does not matter whether the key is preinstalled or dynamically acquired. The router must have the key in use before it can join the DAG being created for a secure P2P-RPL route discovery.
RPL仕様[RFC6550]には、セキュリティ保護されていない、プレインストールされている、認証されているという3つのセキュリティモードが記述されています。安全でないモードでは、安全な制御メッセージは使用されず、利用可能な唯一のセキュリティは、リンク層プロトコルによって提供されるセキュリティです。プレインストールモードでは、すべてのノードがプレインストールされたグループキーを使用して、「ルーター」または「ホスト」として安全なDAGに参加します。「ルーター」という用語は、その親または子から受信したパケットを転送できるノードを意味しますDAG、および「ホスト」という用語は、「ルーター」として機能できないノードを指します。認証モードでは、ノードはプリインストールされたキーを使用して「ホスト」として安全なDAGに参加できますが、「ルーター」として機能するためのキーを取得するには、キーサーバーに対して自身を認証する必要があります。 P2P-RPLディスカバリー用に作成された一時DAGは、パケットのルーティングに使用できません。したがって、ノードが上記で定義された意味で「ルーター」または「ホスト」としてこのDAGに参加すると言っても意味がありません。したがって、P2P-RPLでは、プリインストールモードと認証モードの違いはありません。ルーターは、使用中のキーを指定する使用中のセキュリティ構成をサポートできる場合にのみ、安全なP2P-RPLルート検出用に作成された一時的なDAGに参加できます。キーがプリインストールされているか、動的に取得されるかは関係ありません。ルーターは、安全なP2P-RPLルート検出のために作成されるDAGに参加する前に、使用中のキーを持っている必要があります。
If a rogue router can support the Security Configuration in use (in particular, if it knows the key in use), it can join the secure P2P-RPL route discovery and cause various types of damage. Such a rogue router could advertise false information in its DIOs in order to include itself in the discovered route(s). It could generate bogus P2P-DRO messages carrying bad routes or maliciously modify genuine P2P-DRO messages it receives. A rogue router acting as the Origin could launch denial-of-service attacks against the LLN deployment by initiating fake P2P-RPL route discoveries; in this type of scenario, RPL's authenticated mode of operation, where a node can obtain the key to use for a P2P-RPL route discovery only after proper authentication, would be useful.
不正なルーターが使用中のセキュリティ構成をサポートできる場合（特に、使用中のキーを知っている場合）は、安全なP2P-RPLルート検出に参加し、さまざまな種類の損傷を引き起こす可能性があります。このような不正なルーターは、発見されたルートに自分自身を含めるために、DIOで誤った情報をアドバタイズする可能性があります。不正なルートを運ぶ偽のP2P-DROメッセージを生成したり、受信した本物のP2P-DROメッセージを悪意を持って変更したりする可能性があります。オリジンとして機能する不正なルーターは、偽のP2P-RPLルート検出を開始することにより、LLN展開に対してサービス拒否攻撃を開始する可能性があります。このタイプのシナリオでは、適切な認証後にのみノードがP2P-RPLルート検出に使用するキーを取得できるRPLの認証された動作モードが役立ちます。
Since a P2P-DRO message travels along a Source Route specified inside the message, some of the security concerns that led to the deprecation of Type 0 routing headers [RFC5095] may apply. To avoid the possibility of a P2P-DRO message traveling in a routing loop, this document requires that each Intermediate Router confirm that the Source Route listed inside the message does not contain any routing loop involving itself before the router could forward the message further. As specified in Section 9.6, this check involves the router making sure that its IPv6 addresses do not appear multiple times inside the Source Route with one or more other IPv6 addresses in between.
P2P-DROメッセージはメッセージ内で指定されたソースルートに沿って移動するため、タイプ0ルーティングヘッダー[RFC5095]の廃止につながったセキュリティ上の懸念が適用される場合があります。 P2P-DROメッセージがルーティングループ内を移動する可能性を回避するために、このドキュメントでは、各中間ルーターが、メッセージ内にリストされているソースルートに、自身を含むルーティングループが含まれていないことを確認してから、ルーターがさらにメッセージを転送できるようにする必要があります。セクション9.6で指定されているように、このチェックでは、1つ以上の他のIPv6アドレスを間に挟んでソースルート内でIPv6アドレスが複数回出現しないことをルーターが確認します。
This document defines a new Mode of Operation, entitled "P2P Route Discovery Mode of Operation" (see Section 6), assigned a value of 4 from the "Mode of Operation" space [RFC6550].
このドキュメントは、「P2P Route Discovery Mode of Operation」（セクション6を参照）というタイトルの新しい操作モードを定義し、「Mode of Operation」スペース[RFC6550]から値4を割り当てます。
+-------+---------------------------------------+---------------+
| Value | Description | Reference |
+-------+---------------------------------------+---------------+
| 4 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+
Mode of Operation
動作モード
This document defines a new RPL option: "P2P Route Discovery" (see Section 7), assigned a value of 0x0a from the "RPL Control Message Options" space [RFC6550].
このドキュメントは新しいRPLオプションを定義します： "P2P Route Discovery"（セクション7を参照）、 "RPL Control Message Options"スペース[RFC6550]から0x0aの値を割り当てます。
+-------+---------------------+---------------+
| Value | Meaning | Reference |
+-------+---------------------+---------------+
| 0x0a | P2P Route Discovery | This document |
+-------+---------------------+---------------+
RPL Control Message Options
RPLコントロールメッセージオプション
This document defines the following new RPL messages:
このドキュメントでは、次の新しいRPLメッセージを定義します。
o "P2P Discovery Reply Object" (see Section 8), assigned a value of 0x04 from the "RPL Control Codes" space [RFC6550].
o 「RPL Control Codes」スペース[RFC6550]から0x04の値が割り当てられた「P2P Discovery Reply Object」（セクション8を参照）
o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a value of 0x84 from the "RPL Control Codes" space [RFC6550].
o 「Secure P2P Discovery Reply Object」（セクション8.1を参照）、「RPL Control Codes」スペース[RFC6550]から0x84の値を割り当てました。
o "P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x05 from the "RPL Control Codes" space [RFC6550].
o 「P2P Discovery Reply Object Acknowledgement」（セクション10を参照）、「RPL Control Codes」スペース[RFC6550]から0x05の値を割り当てました。
o "Secure P2P Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x85 from the "RPL Control Codes" space [RFC6550].
o 「Secure P2P Discovery Reply Object Acknowledgement」（セクション10を参照）、「RPL Control Codes」スペース[RFC6550]から0x85の値を割り当てました。
+--------+----------------------------------------+-----------------+
| Code | Description | Reference |
+--------+----------------------------------------+-----------------+
| 0x04 | P2P Discovery Reply Object | This document |
| 0x84 | Secure P2P Discovery Reply Object | This document |
| 0x05 | P2P Discovery Reply Object | This document |
| | Acknowledgement | |
| 0x85 | Secure P2P Discovery Reply Object | This document |
| | Acknowledgement | |
+--------+----------------------------------------+-----------------+
RPL Control Codes
RPL制御コード
This document is presented as an Experimental specification to facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P route discovery is considered useful or necessary. It is anticipated that, once sufficient operational experience has been gained, this specification will be revised to progress it on to the Standards Track. Experience reports regarding P2P-RPL implementation and deployment are encouraged, particularly with respect to:
このドキュメントは、リアクティブP2Pルートディスカバリが有用または必要であると見なされるLLNシナリオでP2P-RPLの展開を容易にするための実験的仕様として提示されています。十分な運用経験が得られたら、この仕様が改訂されて標準トラックに進むことが予想されます。 P2P-RPLの実装と展開に関する経験報告は、特に以下に関して推奨されます。
o Secure P2P-RPL operation (Section 11);
o 安全なP2P-RPL操作（セクション11）。
o Rules governing Trickle operation (Section 9.2);
o トリクル操作を管理するルール（セクション9.2）。
o Values in the default DODAG Configuration Option (Section 6.1);
o デフォルトのDODAG構成オプションの値（セクション6.1）。
o The RPLInstanceID reuse policy (Section 6.1);
o RPLInstanceID再利用ポリシー（セクション6.1）。
o Utility and implementation complexity of allowing multiple Target addresses in a P2P-RPL route discovery.
o P2P-RPLルートディスカバリで複数のターゲットアドレスを許可することのユーティリティと実装の複雑さ。
The authors gratefully acknowledge the contributions of the following individuals (in alphabetical order) in the development of this document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell, Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin Stiemerling, Pascal Thubert, Hristo Valev, and JP Vasseur.
著者は、このドキュメントの作成における以下の個人の貢献（アルファベット順）に感謝します：ドミニクバーセル、ヤコブブロン、セドリックショーヴェネット、トーマスクラウゼン、ロバートクレイジー、ラルフドロムス、エイドリアンファレル、スティーブンファレル、ブライアンハーバーマン、テッドHumpal、Richard Kelsey、Phil Levis、Charles Perkins、Joseph Reddy、Michael Richardson、Zach Shelby、Martin Stiemerling、Pascal Thubert、Hristo Valev、JP Vasseur。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206] Levis、P.、Clauseen、T.、Hui、J.、Gnawali、O。、およびJ. Ko、「トリクルアルゴリズム」、RFC 6206、2011年3月。
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012.
[RFC6550]冬、T.、Thubert、P.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年3月。
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks", RFC 6551, March 2012.
[RFC6551] Vasseur、JP。、Kim、M.、Pister、K.、Dejean、N。、およびD. Barthel、「低電力および損失の多いネットワークでのパス計算に使用されるルーティングメトリック」、RFC 6551、2012年3月。
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012.
[RFC6554] Hui、J.、Vasseur、JP。、Culler、D.、and V. Manral、 "An IPv6 Routing Header for Source Routes with the Routing Protocol for Routing-Power and Lossy Networks（RPL）"、RFC 6554、 2012年3月。
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, December 2007.
[RFC5095] Abley、J.、Savola、P。、およびG. Neville-Neil、「Deprecation of Type 0 Routing Headers in IPv6」、RFC 5095、2007年12月。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826] Brandt、A.、Buron、J。、およびG. Porcu、「低電力および損失の多いネットワークにおけるホームオートメーションルーティング要件」、RFC 5826、2010年4月。
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010.
[RFC5867] Martocci、J.、De Mil、P.、Riou、N。、およびW. Vermeylen、「Building Automation Routing Requirements in Low-Power and Lossy Networks」、RFC 5867、2010年6月。
[RFC6552] Thubert, P., "Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6552, March 2012.
[RFC6552] Thubert、P。、「低電力および損失の多いネットワーク（RPL）のルーティングプロトコルの目的関数ゼロ」、RFC 6552、2012年3月。
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams", RFC 6553, March 2012.
[RFC6553] Hui、J.、JP。 Vasseur、「データプレーンデータグラムでRPL情報を伝送するための低電力および損失の多いネットワーク（RPL）オプションのルーティングプロトコル」、RFC 6553、2012年3月。
[RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci, "A Mechanism to Measure the Routing Metrics along a Point-to-Point Route in a Low-Power and Lossy Network", RFC 6998, August 2013.
[RFC6998] Goyal、M.、Ed。、Baccelli、E.、Brandt、A。、およびJ. Martocci、「低電力で損失の多いネットワークでポイントツーポイントルートに沿ってルーティングメトリックを測定するメカニズム"、RFC 6998、2013年8月。
[ROLL-TERMS] Vasseur, JP., "Terminology in Low power And Lossy Networks", Work in Progress, March 2013.
[ロール用語] Vasseur、JP、「低電力および損失の多いネットワークの用語」、作業中、2013年3月。
Authors' Addresses
著者のアドレス
Mukul Goyal (editor) University of Wisconsin Milwaukee 3200 N. Cramer St. Milwaukee, WI 53201 USA
Mukul Goyal（編集者）ウィスコンシン大学ミルウォーキー3200 N. Cramer St.ミルウォーキー、WI 53201米国
Phone: +1-414-229-5001
EMail: mukul@uwm.edu
Emmanuel Baccelli INRIA
エマニュエルバチェリINRIA
Phone: +33-169-335-511
EMail: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/
Matthias Philipp INRIA
マティアスフィリップINRIA
Phone: +33-169-335-511
EMail: matthias-philipp@gmx.de
Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen, Dk-2100 Denmark
Anders Brandt Sigma Designs Emdrupvej 26A、1。コペンハーゲン、DK-2100デンマーク
Phone: +45-29609501
EMail: abr@sdesigns.dk
Jerald Martocci Johnson Controls 507 E. Michigan Street Milwaukee, WI 53202 USA
じぇらｌｄ まｒとっし じょｈんそん こんｔろｌｓ ５０７ え。 みちがん Ｓｔれえｔ みゎうけえ、 うぃ ５３２０２ うさ
Phone: +1-414-524-4010
EMail: jerald.p.martocci@jci.com