Internet Engineering Task Force (IETF) T. Winter, Ed.
Request for Comments: 6550
Category: Standards Track P. Thubert, Ed.
ISSN: 2070-1721 Cisco Systems
A. Brandt
Sigma Designs
J. Hui
Arch Rock Corporation
R. Kelsey
Ember Corporation
P. Levis
Stanford University
K. Pister
Dust Networks
R. Struik
Struik Security Consultancy
JP. Vasseur
Cisco Systems
R. Alexander
Cooper Power Systems
March 2012
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
Abstract
抽象
Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available.
低消費電力とロッシーネットワーク（LLNs）がルータおよびそれらの相互接続の両方が制約されたネットワークのクラスです。 LLNルータは、典型的には、処理能力、メモリ、及びエネルギー（バッテリ電源）の制約で動作します。彼らの配線は、高損失率、低データレート、および不安定性を特徴としています。 LLNsは、ルータの数千人に数十から何から構成されています。サポートされているトラフィックフローはLLN内部（LLN内部デバイスとの間の）ポイントツーポイント、ポイントツーマルチポイント、およびマルチポイントツーポイント（LLN内部デバイスのサブセットに中央制御ポイントから）（からデバイスを含みます）中央制御ポイントに向かっ。この文書では、メカニズムを提供する低消費電力と非可逆ネットワークのIPv6ルーティングプロトコル（RPL）を、指定することにより、マルチポイント・ツー・ポイントから中央制御点に向けLLN内部デバイスからのトラフィックだけでなく、ポイント・ツー・マルチポイントトラフィックLLN内部の機器への中央制御ポイントがサポートされています。ポイントツーポイントトラフィックのサポートも可能です。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（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/rfc6550.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6550で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................8
1.1. Design Principles ..........................................8
1.2. Expectations of Link-Layer Type ...........................10
2. Terminology ....................................................10
3. Protocol Overview ..............................................13
3.1. Topologies ................................................13
3.1.1. Constructing Topologies ............................13
3.1.2. RPL Identifiers ....................................14
3.1.3. Instances, DODAGs, and DODAG Versions ..............14
3.2. Upward Routes and DODAG Construction ......................16
3.2.1. Objective Function (OF) ............................17
3.2.2. DODAG Repair .......................................17
3.2.3. Security ...........................................17
3.2.4. Grounded and Floating DODAGs .......................18
3.2.5. Local DODAGs .......................................18
3.2.6. Administrative Preference ..........................18
3.2.7. Data-Path Validation and Loop Detection ............18
3.2.8. Distributed Algorithm Operation ....................19
3.3. Downward Routes and Destination Advertisement .............19
3.4. Local DODAGs Route Discovery ..............................20
3.5. Rank Properties ...........................................20
3.5.1. Rank Comparison (DAGRank()) ........................21
3.5.2. Rank Relationships .................................22
3.6. Routing Metrics and Constraints Used by RPL ...............23
3.7. Loop Avoidance ............................................24
3.7.1. Greediness and Instability .........................24
3.7.2. DODAG Loops ........................................26
3.7.3. DAO Loops ..........................................27
4. Traffic Flows Supported by RPL .................................27
4.1. Multipoint-to-Point Traffic ...............................27
4.2. Point-to-Multipoint Traffic ...............................27
4.3. Point-to-Point Traffic ....................................27
5. RPL Instance ...................................................28
5.1. RPL Instance ID ...........................................29
6. ICMPv6 RPL Control Message .....................................30
6.1. RPL Security Fields .......................................32
6.2. DODAG Information Solicitation (DIS) ......................38
6.2.1. Format of the DIS Base Object ......................38
6.2.2. Secure DIS .........................................38
6.2.3. DIS Options ........................................38
6.3. DODAG Information Object (DIO) ............................38
6.3.1. Format of the DIO Base Object ......................39
6.3.2. Secure DIO .........................................41
6.3.3. DIO Options ........................................41
6.4. Destination Advertisement Object (DAO) ....................41
6.4.1. Format of the DAO Base Object ......................42
6.4.2. Secure DAO .........................................43
6.4.3. DAO Options ........................................43
6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) .................................................43
6.5.1. Format of the DAO-ACK Base Object ..................44
6.5.2. Secure DAO-ACK .....................................45
6.5.3. DAO-ACK Options ....................................45
6.6. Consistency Check (CC) ....................................45
6.6.1. Format of the CC Base Object .......................46
6.6.2. CC Options .........................................47
6.7. RPL Control Message Options ...............................47
6.7.1. RPL Control Message Option Generic Format ..........47
6.7.2. Pad1 ...............................................48
6.7.3. PadN ...............................................48
6.7.4. DAG Metric Container ...............................49
6.7.5. Route Information ..................................50
6.7.6. DODAG Configuration ................................52
6.7.7. RPL Target .........................................54
6.7.8. Transit Information ................................55
6.7.9. Solicited Information ..............................58
6.7.10. Prefix Information ................................59
6.7.11. RPL Target Descriptor .............................63
7. Sequence Counters ..............................................63
7.1. Sequence Counter Overview .................................63
7.2. Sequence Counter Operation ................................64
8. Upward Routes ..................................................66
8.1. DIO Base Rules ............................................67
8.2. Upward Route Discovery and Maintenance ....................67
8.2.1. Neighbors and Parents within a DODAG Version .......67
8.2.2. Neighbors and Parents across DODAG Versions ........68
8.2.3. DIO Message Communication ..........................73
8.3. DIO Transmission ..........................................74
8.3.1. Trickle Parameters .................................75
8.4. DODAG Selection ...........................................75
8.5. Operation as a Leaf Node ..................................75
8.6. Administrative Rank .......................................76
9. Downward Routes ................................................77
9.1. Destination Advertisement Parents .........................77
9.2. Downward Route Discovery and Maintenance ..................78
9.2.1. Maintenance of Path Sequence .......................79
9.2.2. Generation of DAO Messages .........................79
9.3. DAO Base Rules ............................................80
9.4. Structure of DAO Messages .................................80
9.5. DAO Transmission Scheduling ...............................83
9.6. Triggering DAO Messages ...................................83
9.7. Non-Storing Mode ..........................................84
9.8. Storing Mode ..............................................85
9.9. Path Control ..............................................86
9.9.1. Path Control Example ...............................88
9.10. Multicast Destination Advertisement Messages .............89
10. Security Mechanisms ...........................................90
10.1. Security Overview ........................................90
10.2. Joining a Secure Network .................................91
10.3. Installing Keys ..........................................92
10.4. Consistency Checks .......................................93
10.5. Counters .................................................93
10.6. Transmission of Outgoing Packets .........................94
10.7. Reception of Incoming Packets ............................95
10.7.1. Timestamp Key Checks ..............................97
10.8. Coverage of Integrity and Confidentiality ................97
10.9. Cryptographic Mode of Operation ..........................98
10.9.1. CCM Nonce .........................................98
10.9.2. Signatures ........................................99
11. Packet Forwarding and Loop Avoidance/Detection ................99
11.1. Suggestions for Packet Forwarding ........................99
11.2. Loop Avoidance and Detection ............................101
11.2.1. Source Node Operation ............................102
11.2.2. Router Operation .................................102
12. Multicast Operation ..........................................104
13. Maintenance of Routing Adjacency .............................105
14. Guidelines for Objective Functions ...........................106
14.1. Objective Function Behavior .............................106
15. Suggestions for Interoperation with Neighbor Discovery .......108
16. Summary of Requirements for Interoperable Implementations ....109
16.1. Common Requirements .....................................109
16.2. Operation as a RPL Leaf Node (Only) .....................110
16.3. Operation as a RPL Router ...............................110
16.3.1. Support for Upward Routes (Only) .................110
16.3.2. Support for Upward Routes and Downward
Routes in Non-Storing ............................110
16.3.3. Support for Upward Routes and Downward
Routes in Storing Mode ...........................111
16.4. Items for Future Specification ..........................111
17. RPL Constants and Variables ..................................112
18. Manageability Considerations .................................113
18.1. Introduction ............................................114
18.2. Configuration Management ................................115
18.2.1. Initialization Mode ..............................115
18.2.2. DIO and DAO Base Message and Options
Configuration ....................................115
18.2.3. Protocol Parameters to Be Configured on
Every Router in the LLN ..........................116
18.2.4. Protocol Parameters to Be Configured on
Every Non-DODAG-Root .............................117
18.2.5. Parameters to Be Configured on the DODAG Root ....117
18.2.6. Configuration of RPL Parameters Related
to DAO-Based Mechanisms ..........................118
18.2.7. Configuration of RPL Parameters Related
to Security Mechanisms ...........................119
18.2.8. Default Values ...................................119
18.3. Monitoring of RPL Operation .............................120
18.3.1. Monitoring a DODAG Parameters ....................120
18.3.2. Monitoring a DODAG Inconsistencies and
Loop Detection ...................................121
18.4. Monitoring of the RPL Data Structures ...................121
18.4.1. Candidate Neighbor Data Structure ................121
18.4.2. Destination-Oriented Directed Acyclic
Graph (DODAG) Table ..............................122
18.4.3. Routing Table and DAO Routing Entries ............122
18.5. Fault Management ........................................123
18.6. Policy ..................................................124
18.7. Fault Isolation .........................................125
18.8. Impact on Other Protocols ...............................125
18.9. Performance Management ..................................126
18.10. Diagnostics ............................................126
19. Security Considerations ......................................126
19.1. Overview ................................................126
20. IANA Considerations ..........................................128
20.1. RPL Control Message .....................................128
20.2. New Registry for RPL Control Codes ......................128
20.3. New Registry for the Mode of Operation (MOP) ............129
20.4. RPL Control Message Option ..............................130
20.5. Objective Code Point (OCP) Registry .....................131
20.6. New Registry for the Security Section Algorithm .........131
20.7. New Registry for the Security Section Flags .............132
20.8. New Registry for Per-KIM Security Levels ................132
20.9. New Registry for DODAG Informational
Solicitation (DIS) Flags ................................133
20.10. New Registry for the DODAG Information Object
(DIO) Flags ............................................134
20.11. New Registry for the Destination Advertisement
Object (DAO) Flags .....................................134
20.12. New Registry for the Destination Advertisement
Object (DAO) Flags .....................................135
20.13. New Registry for the Consistency Check (CC) Flags ......135
20.14. New Registry for the DODAG Configuration Option Flags ..136
20.15. New Registry for the RPL Target Option Flags ...........136
20.16. New Registry for the Transit Information Option Flags ..137
20.17. New Registry for the Solicited Information
Option Flags ...........................................137
20.18. ICMPv6: Error in Source Routing Header .................138
20.19. Link-Local Scope Multicast Address .....................138
21. Acknowledgements .............................................138
22. Contributors .................................................139
23. References ...................................................139
23.1. Normative References ....................................139
23.2. Informative References ..................................140
Appendix A. Example Operation ....................................143
A.1. Example Operation in Storing Mode with Node-Owned
Prefixes .................................................143
A.1.1. DIO Messages and PIO ..............................144
A.1.2. DAO Messages ......................................145
A.1.3. Routing Information Base ..........................145
A.2. Example Operation in Storing Mode with Subnet-Wide
Prefix ...................................................146
A.2.1. DIO Messages and PIO ..............................147
A.2.2. DAO Messages ......................................148
A.2.3. Routing Information Base ..........................148
A.3. Example Operation in Non-Storing Mode with Node-Owned
Prefixes .................................................149
A.3.1. DIO Messages and PIO ..............................150
A.3.2. DAO Messages ......................................150
A.3.3. Routing Information Base ..........................151
A.4. Example Operation in Non-Storing Mode with
Subnet-Wide Prefix .......................................151
A.4.1. DIO Messages and PIO ..............................152
A.4.2. DAO Messages ......................................153
A.4.3. Routing Information Base ..........................153
A.5. Example with External Prefixes ...........................154
Low-power and Lossy Networks (LLNs) consist largely of constrained nodes (with limited processing power, memory, and sometimes energy when they are battery operated or energy scavenging). These routers are interconnected by lossy links, typically supporting only low data rates, that are usually unstable with relatively low packet delivery rates. Another characteristic of such networks is that the traffic patterns are not simply point-to-point, but in many cases point-to-multipoint or multipoint-to-point. Furthermore, such networks may potentially comprise up to thousands of nodes. These characteristics offer unique challenges to a routing solution: the IETF ROLL working group has defined application-specific routing requirements for a Low-power and Lossy Network (LLN) routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].
低消費電力とロッシーネットワーク（LLNs）（これらは電池作動又はエネルギースカベンジングされた場合に限られた処理能力、メモリ、時にはエネルギーで）制約ノードから大きく構成されています。これらのルータは、通常、比較的低いパケット配信率と不安定で、通常は低いデータレートをサポートする非可逆リンクによって相互接続されています。そのようなネットワークの他の特徴は、トラフィックパターンは、単に、ポイント・ツー・ポイントされていないことを、多くの場合、ポイント・ツー・マルチポイント又はマルチポイントツーポイントです。さらに、そのようなネットワークは、潜在的に数千ノードまで含むことができます。 、IETF ROLLワーキンググループは、[RFC5867]で指定された低消費電力とロッシーネットワーク（LLN）ルーティングプロトコルのアプリケーション固有のルーティングの要件、[RFC5826]、[RFC5673]を定義している：これらの特性は、ルーティングソリューションに特有の課題を提供しますそして、[RFC5548]。
This document specifies the IPv6 Routing Protocol for LLNs (RPL). Note that although RPL was specified according to the requirements set forth in the aforementioned requirement documents, its use is in no way limited to these applications.
この文書では、LLNs（RPL）のためのIPv6ルーティングプロトコルを指定します。 RPLは、上記の要件の文書に記載された要件に応じて指定されたが、その使用は、これらのアプリケーションに限定されるものではないことに注意してください。
RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548].
RPLは、[RFC5867]で綴ら要件、[RFC5826]、[RFC5673]、および[RFC5548]に合致することを目的に設計されました。
A network may run multiple instances of RPL concurrently. Each such instance may serve different and potentially antagonistic constraints or performance criteria. This document defines how a single instance operates.
ネットワークは、同時にRPLの複数のインスタンスを実行することができます。このような各インスタンスは異なる、潜在的アンタゴニスト制約または性能基準を果たすことができます。この文書では、単一のインスタンスがどのように動作するかを定義します。
In order to be useful in a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Examples of such objectives include minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing Objective Functions. A RPL implementation, in support of a particular LLN application, will include the necessary Objective Function(s) as required by the application.
LLNアプリケーションドメインの広い範囲で有用であるために、RPLは、ルーティング最適化の目的から、パケット処理および転送を分離します。そのような目的の例には、最小限のエネルギー、待ち時間を最小化、または満足の制約を含みます。この文書では、RPLの動作モードを説明します。他のコンパニオン文書は目的関数をルーティング指定します。 RPLの実装は、特定のLLNアプリケーションをサポートするために、アプリケーションによって要求される必要な目的関数（複数可）を含むであろう。
RPL operations require bidirectional links. In some LLN scenarios, those links may exhibit asymmetric properties. It is required that the reachability of a router be verified before the router can be used as a parent. RPL expects an external mechanism to be triggered during the parent selection phase in order to verify link properties and neighbor reachability. Neighbor Unreachability Detection (NUD) is such a mechanism, but alternates are possible, including
RPLの操作は、双方向リンクが必要です。いくつかのLLNのシナリオでは、これらのリンクは、非対称な特性を示すことができます。ルータが親として使用することができます前に、ルータの到達可能性を検証する必要があります。 RPLは、外部機構は、リンク特性および近隣到達可能性を検証するために親の選択段階中にトリガされることを期待します。近隣到達不能検出（NUD）は、このような機構であるが、代替案が可能である、を含みます
Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from lower layers via Layer 2 (L2) triggers like [RFC5184]. In a general fashion, a detection mechanism that is reactive to traffic is favored in order to minimize the cost of monitoring links that are not being used.
レイヤ2（L2）を介して双方向フォワーディング検出（BFD）[RFC5881]及び下層からヒントは、[RFC5184]のようにトリガします。一般的な方法では、トラフィックに反応性である検出メカニズムが使用されていない監視リンクのコストを最小限に抑えるために好まれています。
RPL also expects an external mechanism to access and transport some control information, referred to as the "RPL Packet Information", in data packets. The RPL Packet Information is defined in Section 11.2 and enables the association of a data packet with a RPL Instance and the validation of RPL routing states. The RPL option [RFC6553] is an example of such mechanism. The mechanism is required for all packets except when strict source routing is used (that is for packets going Downward in Non-Storing mode as detailed further in Section 9), which by nature prevents endless loops and alleviates the need for the RPL Packet Information. Future companion specifications may propose alternate ways to carry the RPL Packet Information in the IPv6 packets and may extend the RPL Packet Information to support additional features.
RPLはまた、いくつかの制御情報にアクセスして輸送するための外部機構を想定し、データパケットに、「RPLパケット情報」という。 RPLパケット情報は、セクション11.2で定義され、RPLインスタンスとデータパケットとRPLルーティング状態の検証の関連付けを可能にします。 RPLオプション[RFC6553]はそのような機構の一例です。機構は、自然に無限ループを防止し、RPLパケット情報の必要性を軽減する厳密なソースルーティングが使用されている場合を除き、すべてのパケット（セクション9にさらに詳述されるように、その非保存モード下方に向かうパケットのためのものである）のために必要とされます。将来のコンパニオン仕様はIPv6パケットでRPLパケット情報を運ぶために別の方法を提案することができるし、追加機能をサポートするために、RPLパケット情報を延長することができます。
RPL provides a mechanism to disseminate information over the dynamically formed network topology. This dissemination enables minimal configuration in the nodes, allowing nodes to operate mostly autonomously. This mechanism uses Trickle [RFC6206] to optimize the dissemination as described in Section 8.3.
RPLは、動的に形成されたネットワークトポロジを介して情報を発信するためのメカニズムを提供します。この普及は、ノードが主に自律的に動作することができ、ノードで最小限の構成を可能にします。このメカニズムは、セクション8.3で説明したように普及を最適化するために、トリクル[RFC6206]を使用します。
In some applications, RPL assembles topologies of routers that own independent prefixes. Those prefixes may or may not be aggregatable depending on the origin of the routers. A prefix that is owned by a router is advertised as on-link.
一部のアプリケーションでは、RPLは、独立したプレフィックスを所有するルータのトポロジを組み立てます。これらの接頭辞は、またはルータの起源に応じて、集約可能であってもなくてもよいです。ルータによって所有されるプレフィックスはオンリンクとしてアドバタイズされます。
RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet. A source can inject information about the subnet to be disseminated by RPL, and that source is authoritative for that subnet. Because many LLN links have non-transitive properties, a common prefix that RPL disseminates over the subnet must not be advertised as on-link.
RPLは、共通の接頭辞で、そのサブネット内のルートに一緒にサブネットをバインドする機能が導入されました。ソースは、RPLによって播種されるサブネットに関する情報を注入することができ、そしてその源は、そのサブネットの権威です。多くのLLNリンクは非推移性質を持っているので、RPLは、サブネット上で発信する共通のプレフィックスはオンリンクとしてアドバタイズしてはいけません。
In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) information such as the [RFC4861] Prefix Information Option (PIO) and the [RFC4191] Route Information Option (RIO). ND information that is disseminated by RPL conserves all its original semantics for router to host, with limited extensions for router to router, though it is not to be confused with routing advertisements and it is never to be directly redistributed in another routing protocol. A RPL node often combines host and router behaviors. As a host, it will process the options as specified in [RFC4191], [RFC4861], [RFC4862], and [RFC6275]. As a router, the RPL node may advertise the information
具体的には、RPLは、[RFC4861]プレフィックス情報オプション（PIO）と[RFC4191]ルート情報オプション（RIO）などのIPv6近隣探索（ND）情報を発信してもよいです。それは、ルーティング広告と混同しないようにして、それが直接、別のルーティングプロトコルに再配布されることはありませんけれどもRPLによって広められるND情報は、ルータにルータのための限られた拡張子を持つ、ホストするルータのすべての元の意味を節約します。 RPLノードは、多くの場合、ホストとルータの動作を組み合わせたものです。 [RFC4191]、[RFC4861]、[RFC4862]及び[RFC6275]で指定されるようにホストとして、それはオプションを処理します。ルータとして、RPLノードは情報を広告します
from the options as required for the specific link, for instance, in an ND Router Advertisement (RA) message, though the exact operation is out of scope.
オプションの正確な動作が範囲外であるが、特定のリンクのために、例えば、NDルータ広告（RA）メッセージで要求されます。
A set of companion documents to this specification will provide further guidance in the form of applicability statements specifying a set of operating points appropriate to the Building Automation, Home Automation, Industrial, and Urban application scenarios.
この仕様のコンパニオン文書のセットはビルディングオートメーション、ホームオートメーション、産業、都市アプリケーションシナリオに適切な動作点のセットを指定する適用文の形で更なるガイダンスを提供します。
In compliance with the layered architecture of IP, RPL does not rely on any particular features of a specific link-layer technology. RPL is designed to be able to operate over a variety of different link layers, including ones that are constrained, potentially lossy, or typically utilized in conjunction with highly constrained host or router devices, such as but not limited to, low-power wireless or PLC (Power Line Communication) technologies.
IPの階層化アーキテクチャに準拠して、RPLは、特定のリンク層技術の任意の特定の機能に依存しません。 RPLは、潜在的損失性、制約されるものを含む異なるリンク層、様々なにわたって動作することができるように設計された、または一般的に高度に制約されたホストまたはルータデバイスと共に利用が、これらに限定されるものなどではなく、低消費電力無線されるか、またはPLC（電力線通信）技術。
Implementers may find [RFC3819] a useful reference when designing a link-layer interface between RPL and a particular link-layer technology.
RPL及び特定のリンク層技術との間のリンク層インタフェースを設計するときImplementersは[RFC3819]の有用な参照を見つけることができます。
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 RFC 2119 [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL RFC 2119 [RFC2119]に記載されているように「この文書に解釈されるべきです。
Additionally, this document uses terminology from [ROLL-TERMS], and introduces the following terminology:
また、この文書は、[ROLL-TERMS]から用語を使用し、以下の用語が導入されています。
DAG: Directed Acyclic Graph. A directed graph having the property that all edges are oriented in such a way that no cycles exist. All edges are contained in paths oriented toward and terminating at one or more root nodes.
DAG：有向非循環グラフ。すべてのエッジがないサイクルが存在しないように配向される特性を有する有向グラフ。すべてのエッジは、パスに向けおよび1つまたは複数のルートノードで終端に含まれます。
DAG root: A DAG root is a node within the DAG that has no outgoing edge. Because the graph is acyclic, by definition, all DAGs must have at least one DAG root and all paths terminate at a DAG root.
DAGルート：DAGルートが何も発信エッジを有していないDAG内のノードです。グラフは非環式であるため、定義により、すべてのDAGは、少なくとも一つのDAGルートを持たなければならず、すべてのパスは、DAGのルートで終端します。
Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root (the DODAG root) with no outgoing edges.
宛先指向DAG（DODAG）：なし発信エッジを持つ単一のDAGルート（DODAGルート）における単一の宛先をルートDAG、すなわち、。
DODAG root: A DODAG root is the DAG root of a DODAG. The DODAG root may act as a border router for the DODAG; in particular, it may aggregate routes in the DODAG and may redistribute DODAG routes into other routing protocols.
DODAGルート：DODAGルートはDODAGのDAGルートです。 DODAGルートはDODAGのための境界ルータとして動作することができます。特に、DODAG内のルートを集約することができ、他のルーティングプロトコルにDODAGルートを再配布してもよいです。
Virtual DODAG root: A Virtual DODAG root is the result of two or more RPL routers, for instance, 6LoWPAN Border Routers (6LBRs), coordinating to synchronize DODAG state and act in concert as if they are a single DODAG root (with multiple interfaces), with respect to the LLN. The coordination most likely occurs between powered devices over a reliable transit link, and the details of that scheme are out of scope for this specification (to be defined in future companion specifications).
仮想DODAGルート：仮想DODAGルートが二つ以上のRPLのルータの結果であり、例えば、6LoWPAN境界ルータ（6LBRs）、それらは（複数のインタフェースを持つ）単一DODAGルートであるかのように協調してDODAG状態と作用を同期させるために調整、LLNに関する。コーディネートは、最も可能性の高い信頼性のトランジットリンク上での受電装置との間で発生すると、そのスキームの詳細については、（将来のコンパニオン規格で定義する）は、この仕様書の範囲外です。
Up: Up refers to the direction from leaf nodes towards DODAG roots, following DODAG edges. This follows the common terminology used in graphs and depth-first-search, where vertices further from the root are "deeper" or "down" and vertices closer to the root are "shallower" or "up".
最大：最大DODAGエッジ以下DODAG根に向かってリーフノードからの方向を指します。これは、グラフと深さ優先検索さらにルートから頂点が「より深い」または「ダウン」と根に近い頂点が「浅い」または「アップ」されている、で使用される一般的な用語に従います。
Down: Down refers to the direction from DODAG roots towards leaf nodes, in the reverse direction of DODAG edges. This follows the common terminology used in graphs and depth-first-search, where vertices further from the root are "deeper" or "down" and vertices closer to the root are "shallower" or "up".
ダウン：ダウンDODAGエッジの逆方向に、リーフノードに向かってDODAG根からの方向を指します。これは、グラフと深さ優先検索さらにルートから頂点が「より深い」または「ダウン」と根に近い頂点が「浅い」または「アップ」されている、で使用される一般的な用語に従います。
Rank: A node's Rank defines the node's individual position relative to other nodes with respect to a DODAG root. Rank strictly increases in the Down direction and strictly decreases in the Up direction. The exact way Rank is computed depends on the DAG's Objective Function (OF). The Rank may analogously track a simple topological distance, may be calculated as a function of link metrics, and may consider other properties such as constraints.
ランク：ノードのランクDODAGルートに対して他のノードへのノードの個々の位置を規定します。ランクは、厳密に下方向に増加し、厳密にアップ方向に減少します。ランクが計算され、正確な方法は、DAGの目的関数（OF）によって異なります。ランクを同様に、単純なトポロジー距離を追跡することができるリンクメトリックの関数として計算することができる、そのような制約のような他の特性を考慮することができます。
Objective Function (OF): An OF defines how routing metrics, optimization objectives, and related functions are used to compute Rank. Furthermore, the OF dictates how parents in the DODAG are selected and, thus, the DODAG formation.
目的関数（OF）：OFは、どのようにルーティングメトリック、最適化の目標を定義し、関連する関数は、ランクを計算するために使用されます。また、OFはDODAGに親が、このように、DODAG形成が選択され、どのように指示します。
Objective Code Point (OCP): An OCP is an identifier that indicates which Objective Function the DODAG uses.
目的コードポイント（OCP）OCPはDODAGが使用対物た機能を示す識別子です。
RPLInstanceID: A RPLInstanceID is a unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function.
RPLインスタンスID：I RPLインスタンスIDは、ネットワーク内で一意の識別子です。同じRPLInstanceIDとDODAGsは、同じ目的関数を共有しています。
RPL Instance: A RPL Instance is a set of one or more DODAGs that share a RPLInstanceID. At most, a RPL node can belong to one DODAG in a RPL Instance. Each RPL Instance operates independently of other RPL Instances. This document describes operation within a single RPL Instance.
RPLインスタンス：RPLインスタンスはRPLInstanceIDを共有する1つまたは複数のDODAGsのセットです。せいぜい、RPLノードは、RPLインスタンス内の1つのDODAGに属することができます。各RPLインスタンスは、独立して、他のRPLインスタンスの動作します。この文書は、単一のRPLインスタンス内での動作を説明します。
DODAGID: A DODAGID is the identifier of a DODAG root. The DODAGID is unique within the scope of a RPL Instance in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.
DODAGID：DODAGIDはDODAGルートの識別子です。 DODAGIDはLLNにおけるRPLインスタンスのスコープ内で一意です。タプル（RPLInstanceID、DODAGID）が一意DODAGを識別する。
DODAG Version: A DODAG Version is a specific iteration ("Version") of a DODAG with a given DODAGID.
DODAGバージョン：DODAGバージョンは、与えられたDODAGIDとDODAGの特定の繰り返し（「バージョン」）です。
DODAGVersionNumber: A DODAGVersionNumber is a sequential counter that is incremented by the root to form a new Version of a DODAG. A DODAG Version is identified uniquely by the (RPLInstanceID, DODAGID, DODAGVersionNumber) tuple.
DODAGVersionNumber：DODAGVersionNumberはDODAGの新しいバージョンを形成するために、ルートによってインクリメントされ、順次カウンタです。 DODAGバージョン（RPLInstanceID、DODAGID、DODAGVersionNumber）タプルによって一意に識別されます。
Goal: The Goal is an application-specific goal that is defined outside the scope of RPL. Any node that roots a DODAG will need to know about this Goal to decide whether or not the Goal can be satisfied. A typical Goal is to construct the DODAG according to a specific Objective Function and to keep connectivity to a set of hosts (e.g., to use an Objective Function that minimizes a metric and is connected to a specific database host to store the collected data).
目標：目標は、RPLの範囲外で定義されているアプリケーション固有の目標です。根DODAGが目標を満たすことができるかどうかを決定するために、この目標について知っておく必要があります任意のノード。典型的な目標は、特定の目的関数に従ってDODAGを構築すると、ホスト（例えば、メトリックを最小化し、収集したデータを格納するために、特定のデータベース・ホストに接続されている目的関数を使用する）のセットへの接続を維持することです。
Grounded: A DODAG is grounded when the DODAG root can satisfy the Goal.
接地：DODAGルートが目標を満たすことができるときDODAGが接地されています。
Floating: A DODAG is floating if it is not grounded. A floating DODAG is not expected to have the properties required to satisfy the goal. It may, however, provide connectivity to other nodes within the DODAG.
フローティング：それは接地されていない場合DODAGが浮いています。浮動DODAGは、目標を満たすために必要な特性を有することが期待されていません。しかしながら、DODAG内の他のノードへの接続性を提供することができます。
DODAG parent: A parent of a node within a DODAG is one of the immediate successors of the node on a path towards the DODAG root. A DODAG parent's Rank is lower than the node's. (See Section 3.5.1).
DODAG親：DODAG内のノードの親がDODAGルートに向かって経路上のノードの直接の後継の一つです。 DODAG親のランクは、ノードのより低いです。 （3.5.1項を参照してください）。
Sub-DODAG: The sub-DODAG of a node is the set of other nodes whose paths to the DODAG root pass through that node. Nodes in the sub-DODAG of a node have a greater Rank than that node. (See Section 3.5.1).
サブDODAG：ノードのサブDODAGはDODAGルートへのパスそのノードを通過する他のノードの集合です。ノードのサブDODAG内のノードは、そのノードよりも高いランクを有します。 （3.5.1項を参照してください）。
Local DODAG: Local DODAGs contain one and only one root node, and they allow that single root node to allocate and manage a RPL Instance, identified by a local RPLInstanceID, without coordination with other nodes. Typically, this is done in order to optimize routes to a destination within the LLN. (See Section 5).
ローカルDODAG：ローカルDODAGsは唯一1つのルートノード含まれ、それらは、単一のルートノードを割り当て、他のノードとの調整なしにローカルRPLInstanceIDによって識別RPLインスタンスを管理することを可能にします。典型的には、これはLLN内の宛先へのルートを最適化するために行われます。 （第5章を参照してください）。
Global DODAG: A Global DODAG uses a global RPLInstanceID that may be coordinated among several other nodes. (See Section 5).
グローバルDODAG：グローバルDODAGは、いくつかの他のノード間で調整することができるグローバルRPLInstanceIDを使用します。 （第5章を参照してください）。
DIO: DODAG Information Object (see Section 6.3)
DIO：DODAG情報オブジェクト（セクション6.3を参照してください）
DAO: Destination Advertisement Object (see Section 6.4)
DAO：デスティネーション広告オブジェクト（セクション6.4を参照してください）
DIS: DODAG Information Solicitation (see Section 6.2)
DIS：DODAG情報要請（6.2節を参照してください）
CC: Consistency Check (see Section 6.6)
CC：整合性チェック（6.6節を参照してください）
As they form networks, LLN devices often mix the roles of host and router when compared to traditional IP networks. In this document, "host" refers to an LLN device that can generate but does not forward RPL traffic; "router" refers to an LLN device that can forward as well as generate RPL traffic; and "node" refers to any RPL device, either a host or a router.
彼らはネットワークを形成するなど、従来のIPネットワークと比較すると、LLNデバイスは、多くの場合、ホストとルータの役割を混ぜます。この文書では、「ホスト」が発生することができますが、RPLトラフィックを転送しませんLLNデバイスを指します。 「ルータ」は、転送ならびにRPLのトラフィックを生成することができるLLN装置を指します。そして、「ノード」は、任意のRPLデバイス、ホスト又はルータのいずれかを指します。
The aim of this section is to describe RPL in the spirit of [RFC4101]. Protocol details can be found in further sections.
このセクションの目的は、[RFC4101]の精神にRPLを記述することです。プロトコルの詳細は、さらにセクションに記載されています。
This section describes the basic RPL topologies that may be formed, and the rules by which these are constructed, i.e., the rules governing DODAG formation.
このセクションでは、これらが構築されることにより形成することができる基本的なRPLトポロジ、及びルール、即ち、DODAG形成を支配するルールを記述する。
LLNs, such as Radio Networks, do not typically have predefined topologies, for example, those imposed by point-to-point wires, so RPL has to discover links and then select peers sparingly.
このような無線ネットワークなどLLNsは、典型的には、例えば、RPLので、ポイント・ツー・ポイント配線によって課せられるものは、リンクを発見した後、難ピアを選択しなければならない、予め定義されたトポロジを有していません。
In many cases, because Layer 2 ranges overlap only partially, RPL forms non-transitive / Non-Broadcast Multi-Access (NBMA) network topologies upon which it computes routes.
レイヤ2の範囲が部分的にのみ重なるため、多くの場合において、RPLは、それがルートを計算し、その上に非推移/非ブロードキャストマルチアクセス（NBMA）ネットワークトポロジを形成します。
RPL routes are optimized for traffic to or from one or more roots that act as sinks for the topology. As a result, RPL organizes a topology as a Directed Acyclic Graph (DAG) that is partitioned into one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. If the DAG has multiple roots, then it is expected that the roots are federated by a common backbone, such as a transit link.
RPLルートへ、またはトポロジのためのシンクとして作用する1つのまたは複数の根からのトラフィック用に最適化されています。結果として、RPLは、1つ以上の宛先指向のDAG（DODAGs）、シンクごとにDODAGに分割される有向非巡回グラフ（DAG）のようなトポロジーを整理します。 DAGが複数のルートを持っている場合、根が、そのようなトランジットリンクとして、共通のバックボーンによって統合されることが期待されます。
RPL uses four values to identify and maintain a topology:
RPLは、トポロジを特定し、維持するために、四つの値を使用しています：
o The first is a RPLInstanceID. A RPLInstanceID identifies a set of one or more Destination Oriented DAGs (DODAGs). A network may have multiple RPLInstanceIDs, each of which defines an independent set of DODAGs, which may be optimized for different Objective Functions (OFs) and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance. All DODAGs in the same RPL Instance use the same OF.
o最初RPLInstanceIDです。 RPLInstanceIDは、1つ以上の宛先指向のDAG（DODAGs）のセットを識別する。ネットワークは、異なる目的関数（のOF）及び/又はアプリケーションのために最適化されてもよいDODAGsの独立したセットを定義それぞれが複数RPLInstanceIDsを有していてもよいです。 RPLInstanceIDで識別DODAGsのセットは、RPLインスタンスと呼ばれています。同じRPLインスタンスのすべてのDODAGsは同じOFを使用します。
o The second is a DODAGID. The scope of a DODAGID is a RPL Instance. The combination of RPLInstanceID and DODAGID uniquely identifies a single DODAG in the network. A RPL Instance may have multiple DODAGs, each of which has an unique DODAGID.
O目はDODAGIDあります。 DODAGIDの範囲は、RPLインスタンスです。 RPLInstanceIDとDODAGIDの組み合わせが一意のネットワーク内の単一DODAGを識別する。 RPLインスタンスは一意DODAGIDをそれぞれ有する複数DODAGsを有していてもよいです。
o The third is a DODAGVersionNumber. The scope of a DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed from the DODAG root, by incrementing the DODAGVersionNumber. The combination of RPLInstanceID, DODAGID, and DODAGVersionNumber uniquely identifies a DODAG Version.
O第三はDODAGVersionNumberあります。 DODAGVersionNumberの範囲はDODAGです。 DODAGは時々DODAGVersionNumberを増分することによって、DODAGルートから再構成される。 RPLInstanceID、DODAGID、及びDODAGVersionNumberの組み合わせが一意DODAGバージョンを識別する。
o The fourth is Rank. The scope of Rank is a DODAG Version. Rank establishes a partial order over a DODAG Version, defining individual node positions with respect to the DODAG root.
O 4番目のランクがあります。ランクの範囲はDODAGバージョンです。ランクはDODAGルートに対する個々のノードの位置を規定する、DODAG版上半順序を確立します。
A RPL Instance contains one or more DODAG roots. A RPL Instance may provide routes to certain destination prefixes, reachable via the DODAG roots or alternate paths within the DODAG. These roots may operate independently, or they may coordinate over a network that is not necessarily as constrained as an LLN.
RPLインスタンスは、一つ以上のDODAG根が含まれています。 RPLインスタンスDODAG内DODAG根または代替経路を介して到達可能な特定の宛先プレフィックスへのルートを提供することができます。これらの根は、独立して動作することができる、またはそれらはLLNとして制約として必ずしもではないネットワークを介して調整することができます。
A RPL Instance may comprise:
RPLインスタンスを含むことができます。
o a single DODAG with a single root
単一のルートを持つ単一のDODAG O
* For example, a DODAG optimized to minimize latency rooted at a single centralized lighting controller in a Home Automation application.
*例えば、DODAGホームオートメーションアプリケーションにおける単一の集中照明コントローラをルート待ち時間を最小にするように最適化されました。
o multiple uncoordinated DODAGs with independent roots (differing DODAGIDs)
O独立したルーツを持つ複数のまとまりのないDODAGs（DODAGIDs異なります）
* For example, multiple data collection points in an urban data collection application that do not have suitable connectivity to coordinate with each other or that use the formation of multiple DODAGs as a means to dynamically and autonomously partition the network.
*例えば、互いに座標またはそれが動的かつ自律的にネットワークを分割するための手段として複数DODAGsの形成を使用するための適切な接続を持たない都市データ収集アプリケーション内の複数のデータ収集ポイント。
o a single DODAG with a virtual root that coordinates LLN sinks (with the same DODAGID) over a backbone network.
O LLNを調整する仮想ルートを持つ単一DODAGは、バックボーンネットワークを介して（同じDODAGIDで）シンク。
* For example, multiple border routers operating with a reliable transit link, e.g., in support of an IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) application, that are capable of acting as logically equivalent interfaces to the sink of the same DODAG.
同じDODAGのシンクに論理的に等価なインターフェースとして作用することが可能なIPv6の低消費電力無線パーソナルエリアネットワーク（6LoWPAN）アプリケーションをサポートするために、例えば、信頼性のトランジットリンクで動作*たとえば、複数の境界ルータ、。
o a combination of the above as suited to some application scenario.
いくつかのアプリケーションシナリオに適した、上記の組み合わせO。
Each RPL packet is associated with a particular RPLInstanceID (see Section 11.2) and, therefore, RPL Instance (Section 5). The provisioning or automated discovery of a mapping between a RPLInstanceID and a type or service of application traffic is out of scope for this specification (to be defined in future companion specifications).
各RPLパケットは、特定のRPLInstanceID（第11.2節を参照）、したがって、RPLインスタンス（セクション5）に関連しています。プロビジョニングまたはRPLInstanceIDとアプリケーショントラフィックの種類やサービスとの間のマッピングの自動検出は、（将来コンパニオン仕様で定義する）本明細書の範囲外です。
Figure 1 depicts an example of a RPL Instance comprising three DODAGs with DODAG roots R1, R2, and R3. Each of these DODAG roots advertises the same RPLInstanceID. The lines depict connectivity between parents and children.
図1は、DODAG根R1、R2、およびR3で三DODAGsを含むRPLインスタンスの例を示します。これらDODAG根のそれぞれは、同じRPLInstanceIDをアドバタイズします。行は、親と子の間の接続を示しています。
Figure 2 depicts how a DODAGVersionNumber increment leads to a new DODAG Version. This depiction illustrates a DODAGVersionNumber increment that results in a different DODAG topology. Note that a new DODAG Version does not always imply a different DODAG topology. To accommodate certain topology changes requires a new DODAG Version, as described later in this specification.
図2は、DODAGVersionNumber増分が新しいDODAGバージョンにつながる方法を示しています。この描写は異なるDODAGトポロジになりDODAGVersionNumber増分を示しています。新しいDODAGバージョンは、常に異なるDODAGトポロジーを意味するものではないことに注意してください。この仕様書で後述するように、特定のトポロジの変更に対応するためには、新しいDODAGバージョンが必要です。
In the following examples, please note that tree-like structures are depicted for simplicity, although the DODAG structure allows for each node to have multiple parents when the connectivity supports it.
接続がそれをサポートしている場合、各ノードが複数の親を持っているためDODAG構造ができますが、以下の例では、ツリー状の構造が単純化のために描かれていることに注意してください。
+----------------------------------------------------------------+
| |
| +--------------+ |
| | | |
| | (R1) | (R2) (R3) |
| | / \ | /| \ / | \ |
| | / \ | / | \ / | \ |
| | (A) (B) | (C) | (D) ... (F) (G) (H) |
| | /|\ |\ | / | / |\ |\ | | |
| | : : : : : | : (E) : : : `: : |
| | | / \ |
| +--------------+ : : |
| DODAG |
| |
+----------------------------------------------------------------+
RPL Instance
Figure 1: RPL Instance
図1：RPLインスタンス
+----------------+ +----------------+
| | | |
| (R1) | | (R1) |
| / \ | | / |
| / \ | | / |
| (A) (B) | \ | (A) |
| /|\ / |\ | ------\ | /|\ |
| : : (C) : : | \ | : : (C) |
| | / | \ |
| | ------/ | \ |
| | / | (B) |
| | | |\ |
| | | : : |
| | | |
+----------------+ +----------------+
Version N Version N+1
Figure 2: DODAG Version
図2：DODAGバージョン
RPL provisions routes Up towards DODAG roots, forming a DODAG optimized according to an Objective Function (OF). RPL nodes construct and maintain these DODAGs through DODAG Information Object (DIO) messages.
目的関数（OF）に従って最適化DODAG形成DODAG根に向かってRPL規定経路上、。 RPLはDODAG情報オブジェクト（DIO）メッセージを介してこれらのDODAGsを構築し、維持するノード。
The Objective Function (OF) defines how RPL nodes select and optimize routes within a RPL Instance. The OF is identified by an Objective Code Point (OCP) within the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints, which are themselves defined in [RFC6551], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 14, [RFC6551], [RFC6552], and related companion specifications.
目的関数（OF）は、RPLは、選択ノードとRPLインスタンス内のルートを最適化する方法を定義します。 OFは、DIOの設定オプション内の目的コードポイント（OCP）によって識別されます。ノード自体がDODAGルートからのノードの距離を近似ランクと呼ばれる値に、[RFC6551]で定義された1つのまたは複数のメトリックと制約を、変換方法を定義しました。またOFノードが親を選択する方法を定義します。さらなる詳細は、セクション14、[RFC6551]、[RFC6552]、および関連するコンパニオン仕様に見出すことができます。
A DODAG root institutes a global repair operation by incrementing the DODAGVersionNumber. This initiates a new DODAG Version. Nodes in the new DODAG Version can choose a new position whose Rank is not constrained by their Rank within the old DODAG Version.
DODAGルート機関DODAGVersionNumberをインクリメントすることにより、グローバルな修復操作。これは、新しいDODAGバージョンを開始します。新しいDODAGバージョンのノードは、そのランク古いDODAGバージョン内でのランクによって制約されていない新しい位置を選択することができます。
RPL also supports mechanisms that may be used for local repair within the DODAG Version. The DIO message specifies the necessary parameters as configured from and controlled by policy at the DODAG root.
RPLはまたDODAGバージョン内のローカル修復に使用することができるメカニズムをサポートしています。構成されDODAGルートにポリシーによって制御されるDIOメッセージは、必要なパラメータを指定します。
RPL supports message confidentiality and integrity. It is designed such that link-layer mechanisms can be used when available and appropriate; yet, in their absence, RPL can use its own mechanisms. RPL has three basic security modes.
RPLは、メッセージの機密性と整合性をサポートしています。これは、利用可能な場合、適切なリンク層メカニズムを使用することができるように設計されます。まだ、彼らの不在では、RPLは独自のメカニズムを使用することができます。 RPLは、三つの基本的なセキュリティモードを持っています。
In the first, called "unsecured", RPL control messages are sent without any additional security mechanisms. Unsecured mode does not imply that the RPL network is unsecure: it could be using other present security primitives (e.g., link-layer security) to meet application security requirements.
「無担保」と呼ばれ、最初に、RPL制御メッセージは、任意の追加のセキュリティメカニズムなしで送信されます。アプリケーションのセキュリティ要件を満たすために、他の現在のセキュリティプリミティブ（例えば、リンク・レイヤ・セキュリティ）を使用することができる：セキュリティで保護されていないモードでは、RPLのネットワークが非セキュアであることを意味しません
In the second, called "preinstalled", nodes joining a RPL Instance have preinstalled keys that enable them to process and generate secured RPL messages.
「プリインストールされている」と呼ばれる第二では、RPLインスタンスに参加するノードが処理して確保RPLメッセージを生成することを可能にキーがプリインストールされています。
The third mode is called "authenticated". In authenticated mode, nodes have preinstalled keys as in preinstalled mode, but the preinstalled key may only be used to join a RPL Instance as a leaf. Joining an authenticated RPL Instance as a router requires obtaining a key from an authentication authority. The process by which this key is obtained is out of scope for this specification. Note that this specification alone does not provide sufficient detail for a RPL implementation to securely operate in authenticated mode. For a RPL implementation to operate securely in authenticated mode, it is necessary for a future companion specification to detail the mechanisms by which a node obtains/requests the authentication material (e.g., key, certificate) and to determine from where that material should be obtained. See also Section 10.3.
第三モードは、「認証済み」と呼ばれています。認証されたモードでは、ノードは、プリインストールされているモードのようにキーをプレインストールされているが、プリインストールされているキーは、リーフとしてRPLインスタンスを結合するために使用することができます。ルータとして認証RPLインスタンスに参加する認証局からキーを取得する必要です。このキーが取得されるプロセスは、本明細書の範囲外です。 RPLの実装がセキュアに認証モードで動作するだけでは、この仕様は十分な詳細を提供しないことに注意してください。認証されたモードで確実に動作するRPLの実装のため、それは将来のコンパニオン仕様に必要な細部にノード/認証材料（例えば、鍵、証明書）を要求し、その材料が得られるべき場所から決定するために取得するメカニズム。 10.3節も参照してください。
DODAGs can be grounded or floating: the DODAG root advertises which is the case. A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal. A floating DODAG is not expected to satisfy the goal; in most cases, it only provides routes to nodes within the DODAG. Floating DODAGs may be used, for example, to preserve interconnectivity during repair.
DODAGsは接地又はフローティングさせることができる。DODAGルートはケースであるアドバタイズ。接地DODAGは、アプリケーションで定義された目標を満たすために必要とされるホストへの接続を提供しています。浮動DODAGは目標を満足することが期待されていません。ほとんどの場合、それが唯一のDODAG内のノードへのルートを提供します。フローティングDODAGsは修復中に相互接続性を維持するために、例えば、使用することができます。
RPL nodes can optimize routes to a destination within an LLN by forming a Local DODAG whose DODAG root is the desired destination. Unlike global DAGs, which can consist of multiple DODAGs, local DAGs have one and only one DODAG and therefore one DODAG root. Local DODAGs can be constructed on demand.
RPLノードは、そのDODAGルート所望の宛先であるローカルDODAGを形成することにより、LLN内の宛先へのルートを最適化することができます。複数DODAGsからなることができるグローバルのDAGとは異なり、ローカルのDAGは、唯一のDODAGので、1つのDODAGルートを持っています。ローカルDODAGsは、オンデマンドで構築することができます。
An implementation/deployment may specify that some DODAG roots should be used over others through an administrative preference. Administrative preference offers a way to control traffic and engineer DODAG formation in order to better support application requirements or needs.
実装/展開は、いくつかのDODAGの根は、管理好みによって他の人の上に使用されるべきであることを指定してもよいです。管理プリファレンスは、トラフィックを制御し、より良いサポートアプリケーションの要件やニーズに順にDODAG形成を設計する方法を提供しています。
The low-power and lossy nature of LLNs motivates RPL's use of on-demand loop detection using data packets. Because data traffic can be infrequent, maintaining a routing topology that is constantly up to date with the physical topology can waste energy. Typical LLNs exhibit variations in physical connectivity that are transient and innocuous to traffic, but that would be costly to track closely from the control plane. Transient and infrequent changes in connectivity need not be addressed by RPL until there is data to send. This aspect of RPL's design draws from existing, highly used LLN protocols as well as extensive experimental and deployment evidence on its efficacy.
低消費電力とLLNsの非可逆な性質は、データパケットを使用して、オンデマンドループ検出のRPLの使用を動機付けます。データトラフィックはまれなることがあるので、常に物理トポロジーと最新であるルーティングトポロジを維持することは、エネルギーを無駄にすることができます。典型的なLLNsは、トラフィックへの過渡的かつ無害である物理的な接続性の変化を示すが、それは、コントロールプレーンから密接に追跡するために、コストがかかります。送信するデータがあるまで接続における過渡とまれ変更はRPLによって対処する必要はありません。 RPLのデザインのこの局面は、既存の、非常に使用LLNプロトコルだけでなく、その有効性に関する広範な実験と展開証拠から描画します。
The RPL Packet Information that is transported with data packets includes the Rank of the transmitter. An inconsistency between the routing decision for a packet (Upward or Downward) and the Rank relationship between the two nodes indicates a possible loop. On receiving such a packet, a node institutes a local repair operation.
データパケットで搬送されるRPLパケット情報は、送信機のランクを含みます。パケットのルーティング決定との間の矛盾（上方または下方）と、2つのノード間の順位関係が可能ループを示します。そのようなパケット、ノード機関ローカル修復操作を受信します。
For example, if a node receives a packet flagged as moving in the Upward direction, and if that packet records that the transmitter is of a lower (lesser) Rank than the receiving node, then the receiving node is able to conclude that the packet has not progressed in the Upward direction and that the DODAG is inconsistent.
例えば、ノードは、上方向に移動するようにフラグが付けられたパケットを受信した場合、及び送信機は、受信ノードよりも低い（小さい）ランクであることパケットレコード場合、受信ノードは、パケットが有していると結論することができます上方向に及びDODAGが矛盾していることを進んでいません。
A high-level overview of the distributed algorithm, which constructs the DODAG, is as follows:
次のようにDODAGを構築する分散アルゴリズムの高レベルの概要は、次のとおりです。
o Some nodes are configured to be DODAG roots, with associated DODAG configurations.
O一部のノードは、関連DODAG構成で、DODAG根となるように構成されています。
o Nodes advertise their presence, affiliation with a DODAG, routing cost, and related metrics by sending link-local multicast DIO messages to all-RPL-nodes.
Oノードは、すべての-RPL-ノードにリンクローカルマルチキャストDIOメッセージを送信することにより、その存在、DODAGとの提携、ルーティングコスト、および関連するメトリックをアドバタイズします。
o Nodes listen for DIOs and use their information to join a new DODAG (thus, selecting DODAG parents), or to maintain an existing DODAG, according to the specified Objective Function and Rank of their neighbors.
Oノードは、指定された目的関数とその隣人のランクに応じて、のDIOをリッスンし（したがって、DODAGの親を選択）新しいDODAGに参加するために自分の情報を使用するか、または既存のDODAGを維持します。
o Nodes provision routing table entries, for the destinations specified by the DIO message, via their DODAG parents in the DODAG Version. Nodes that decide to join a DODAG can provision one or more DODAG parents as the next hop for the default route and a number of other external routes for the associated instance.
Oノードの提供はDODAGバージョンでのDODAGの両親を経て、DIOメッセージで指定された宛先には、テーブルのエントリをルーティングします。デフォルトルートと関連するインスタンスのための他の外部経路の数のための次のホップとしてDODAGプロビジョニングでき一つ以上DODAG親に参加することを決定ノード。
RPL uses Destination Advertisement Object (DAO) messages to establish Downward routes. DAO messages are an optional feature for applications that require point-to-multipoint (P2MP) or point-to-point (P2P) traffic. RPL supports two modes of Downward traffic: Storing (fully stateful) or Non-Storing (fully source routed); see Section 9. Any given RPL Instance is either storing or non-storing. In both cases, P2P packets travel Up toward a DODAG root then Down to the final destination (unless the destination is on the Upward route). In the Non-Storing case, the packet will travel all the way to a DODAG root before traveling Down. In the Storing case, the packet may be directed Down towards the destination by a common ancestor of the source and the destination prior to reaching a DODAG root.
RPLは、下向きのルートを確立するために、先の広告オブジェクト（DAO）のメッセージを使用しています。 DAOメッセージは、ポイント・ツー・マルチポイント（P2MP）またはポイントツーポイント（P2P）トラフィックを必要とするアプリケーションのためのオプション機能です。 RPLは、下向きトラフィックの二つのモードをサポートします。保管（完全にステートフル）または非保存を（完全にソースをルーティング）。任意の与えられたRPLインスタンスが保存または非保存のいずれかである、セクション9を参照してください。両方の場合において、P2Pパケットは、最終的な宛先（宛先が上向きの経路上にある場合を除く）にまでDODAGルートに向かって移動します。非保存の場合には、パケットが下る前に、すべての道DODAGルートに移動します。収納ケースでは、パケットがソースとDODAGルートに到達する前に、先の共通の祖先によって宛先に向けて下向きにしてもよいです。
As of the writing of this specification, no implementation is expected to support both Storing and Non-Storing modes of operation. Most implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. Other modes of operation, such as a hybrid mix of Storing and Non-Storing mode, are out of scope for this specification and may be described in other companion specifications.
この仕様書の執筆時点では、何の実装は、操作の両方の保存および非保存モードをサポートすることが期待されていません。ほとんどの実装だけ下向きのルート、非保存モードのいずれかをサポートしないことが予想、または専用モードを格納しています。そのようなモードの保存および非保存のハイブリッドミックスとしての動作の他のモードは、本明細書の範囲外であり、他のコンパニオン仕様に記載されてもよいです。
This specification describes a basic mode of operation in support of P2P traffic. Note that more optimized P2P solutions may be described in companion specifications.
この仕様は、P2Pトラフィックのサポートに動作の基本モードを説明しています。より最適化されたP2Pソリューションはコンパニオン仕様書に記述することができることに注意してください。
Optionally, a RPL network can support on-demand discovery of DODAGs to specific destinations within an LLN. Such Local DODAGs behave slightly differently than Global DODAGs: they are uniquely defined by the combination of DODAGID and RPLInstanceID. The RPLInstanceID denotes whether a DODAG is a Local DODAG.
必要に応じて、RPLネットワークはLLN内の特定の宛先にDODAGsのオンデマンド検出をサポートすることができます。このようなローカルDODAGsは少し異なるグローバルDODAGsよりも動作します。彼らは、一意DODAGIDとRPLInstanceIDの組み合わせによって定義されています。 RPLInstanceIDはDODAGローカルDODAGであるかどうかを示しています。
The Rank of a node is a scalar representation of the location of that node within a DODAG Version. The Rank is used to avoid and detect loops and, as such, must demonstrate certain properties. The exact calculation of the Rank is left to the Objective Function. Even though the specific computation of the Rank is left to the Objective Function, the Rank must implement generic properties regardless of the Objective Function.
ノードのランクはDODAG版内のそのノードの位置のスカラー表示です。ランクは、次のような、特定の特性を示さなければなりません、ループを回避および検出するために使用されます。ランクの正確な計算は、目的関数に委ねられています。ランクの具体的な計算は、目的関数に任されていても、ランクに関係なく、目的関数の一般的なプロパティを実装する必要があります。
In particular, the Rank of the nodes must monotonically decrease as the DODAG Version is followed towards the DODAG destination. In that regard, the Rank can be considered a scalar representation of the location or radius of a node within a DODAG Version.
DODAGバージョンがDODAG先に向かって続いているように、特に、ノードのランクは単調に減少しなければなりません。その点で、ランクDODAG版内のノードの位置や半径のスカラー表現と考えることができます。
The details of how the Objective Function computes Rank are out of scope for this specification, although that computation may depend, for example, on parents, link metrics, node metrics, and the node configuration and policies. See Section 14 for more information.
その計算は親、リンクメトリックは、ノード・メトリック、およびノード構成およびポリシーに、例えば、依存し得るが、目的関数がランクを計算する方法の詳細は、本明細書の範囲外です。詳細については、セクション14を参照してください。
The Rank is not a path cost, although its value can be derived from and influenced by path metrics. The Rank has properties of its own that are not necessarily those of all metrics:
その値は由来し、パスメトリックによって影響を受けることができるがランクは、パスコストはありません。ランクは、必ずしもすべてのメトリックのそれではない、独自のプロパティがあります。
Type: The Rank is an abstract numeric value.
タイプ：ランク抽象的な数値です。
Function: The Rank is the expression of a relative position within a DODAG Version with regard to neighbors, and it is not necessarily a good indication or a proper expression of a distance or a path cost to the root.
関数：ランク隣人に関してDODAG版内の相対位置の表現であり、必ずしも良好な指標又は距離の適切な発現またはルートへのパスコストはありません。
Stability: The stability of the Rank determines the stability of the routing topology. Some dampening or filtering is RECOMMENDED to keep the topology stable; thus, the Rank does not necessarily change as fast as some link or node metrics would. A new DODAG Version would be a good opportunity to reconcile the discrepancies that might form over time between metrics and Ranks within a DODAG Version.
安定性：ランクの安定性は、ルーティングトポロジの安定性を決定します。いくつかの減衰またはフィルタリングが安定したトポロジーを維持することが推奨されます。したがって、ランクは必ずしもだろういくつかのリンクまたはノードのメトリックほど速く変化しません。新しいDODAGバージョンはDODAGバージョン内のメトリックとランク間の時間をかけて形成するかもしれない矛盾を調整する良い機会でしょう。
Properties: The Rank is incremented in a strictly monotonic fashion, and it can be used to validate a progression from or towards the root. A metric, like bandwidth or jitter, does not necessarily exhibit this property.
ランクは厳密に単調に増加され、ルートからかに向けて進行を検証するために使用することができますプロパティ。メトリックは、帯域幅やジッタのように、必ずしもこの性質を示しません。
Abstract: The Rank does not have a physical unit, but rather a range of increment per hop, where the assignment of each increment is to be determined by the Objective Function.
要約：ランクは、物理的な単位ではなく、各増分の割当が目的関数によって決定されるホップ毎の増分の範囲を有していません。
The Rank value feeds into DODAG parent selection, according to the RPL loop-avoidance strategy. Once a parent has been added, and a Rank value for the node within the DODAG has been advertised, the node's further options with regard to DODAG parent selection and movement within the DODAG are restricted in favor of loop avoidance.
ランク値は、RPLループ回避の戦略に従って、DODAG親選択に供給する。親が追加されている、とDODAG内のノードのためのランク値が公示された後、DODAG内DODAG親の選択や移動に関してノードの更なるオプションは、ループ回避に有利に制限されています。
Rank may be thought of as a fixed-point number, where the position of the radix point between the integer part and the fractional part is determined by MinHopRankIncrease. MinHopRankIncrease is the minimum increase in Rank between a node and any of its DODAG parents. A DODAG root provisions MinHopRankIncrease. MinHopRankIncrease creates a trade-off between hop cost precision and the maximum number of hops a network can support. A very large MinHopRankIncrease, for example, allows precise characterization of a given hop's effect on Rank but cannot support many hops.
ランクは、整数部分と小数部分との間の小数点の位置がMinHopRankIncreaseによって決定される固定小数点数、と考えることができます。 MinHopRankIncreaseは、ノードとそのDODAG親のいずれかとの間のランクの最小の増加です。 DODAGルート規定MinHopRankIncrease。 MinHopRankIncreaseはホップコスト精度とネットワークがサポートできる最大ホップ数の間のトレードオフを作成します。非常に大きなMinHopRankIncreaseは、例えば、ランク上の所定のホップの効果の正確な特性評価を可能にするが、多くのホップをサポートすることはできません。
When an Objective Function computes Rank, the Objective Function operates on the entire (i.e., 16-bit) Rank quantity. When Rank is compared, e.g., for determination of parent relationships or loop detection, the integer portion of the Rank is to be used. The integer portion of the Rank is computed by the DAGRank() macro as follows, where floor(x) is the function that evaluates to the greatest integer less than or equal to x:
目的関数がランクを計算するとき、目的関数は、全体（すなわち、16ビット）ランク量に動作します。ランクを比較すると、例えば、親の関係やループ検出の決定のために、ランクの整数部分が使用されます。ランクの整数部分は、フロア（x）はx以下の最大の整数を求める関数であり、次のようにDAGRank（）マクロによって計算されます。
DAGRank(rank) = floor(rank/MinHopRankIncrease)
DAGRank（ランク）=床（ランク/ MinHopRankIncrease）
For example, if a 16-bit Rank quantity is decimal 27, and the MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 1. The integer part of the Rank is 1 and the fractional part is 11/16.
16ビットのランク量が27進であり、たとえば、MinHopRankIncreaseは小数16、次いでDAGRank（27）=フロア（1.6875）= 1ランクの整数部分が1であり、小数部分は11/16であります。
Following the conventions in this document, using the macro DAGRank(node) may be interpreted as DAGRank(node.rank), where node.rank is the Rank value as maintained by the node.
マクロDAGRank（ノード）を使用して、本書での表記法を以下にnode.rankノードによって維持されるようランク値であるDAGRank（node.rank）、と解釈することができます。
A Node A has a Rank less than the Rank of a Node B if DAGRank(A) is less than DAGRank(B).
DAGRank（A）はDAGRank（B）未満である場合、ノードAは、ノードBのランクよりも低いランクを有します。
A Node A has a Rank equal to the Rank of a Node B if DAGRank(A) is equal to DAGRank(B).
ノードAはDAGRank（A）はDAGRank（B）に等しい場合、ノードBのランクに等しいランクを有します。
A Node A has a Rank greater than the Rank of a Node B if DAGRank(A) is greater than DAGRank(B).
DAGRank（A）はDAGRank（B）より大きい場合、ノードAは、ノードBのランクよりも大きなランクを有します。
Rank computations maintain the following properties for any nodes M and N that are neighbors in the LLN:
ランク計算がLLNに隣接している任意のノードMおよびNについては、次の特性を維持します。
DAGRank(M) is less than DAGRank(N):
DAGRank（M）はDAGRank（N）未満です。
In this case, the position of M is closer to the DODAG root than the position of N. Node M may safely be a DODAG parent for Node N without risk of creating a loop. Further, for a Node N, all parents in the DODAG parent set must be of a Rank less than DAGRank(N). In other words, the Rank presented by a Node N MUST be greater than that presented by any of its parents.
この場合、Mの位置は、安全ループを作成するリスクなしにノードN用DODAG親であってもよいN.ノードMの位置よりDODAGルートに近いです。さらに、ノードNのために、DODAG親セット内のすべての親がDAGRank（N）よりも小さいランクでなければなりません。言い換えれば、ノードNが提示ランクは、その両親のいずれかによって提示よりも大きくなければなりません。
DAGRank(M) equals DAGRank(N):
DAGRank（M）はDAGRank（N）に等しいです。
In this case, the positions of M and N within the DODAG and with respect to the DODAG root are similar or identical. Routing through a node with equal Rank may cause a routing loop (i.e., if that node chooses to route through a node with equal Rank as well).
この場合、DODAG内およびDODAGルートに対するM及びNの位置は、類似または同一です。同じランクのノードを介してルーティングするルーティングループを引き起こす可能性があり（すなわち、そのノードが同様に等しいランクを有するノードを介して経路を選択した場合）。
DAGRank(M) is greater than DAGRank(N):
DAGRank（M）はDAGRank（N）よりも大きいです。
In this case, the position of M is farther from the DODAG root than the position of N. Further, Node M may in fact be in the sub-DODAG of Node N. If Node N selects Node M as DODAG parent, there is a risk of creating a loop.
ノードNはDODAG親としてノードMを選択した場合、この場合、Mの位置がNの位置よりDODAGルートから遠いまた、ノードMは、実際に存在し、ノードNのサブDODAGであってもよいですループを作成するリスク。
As an example, the Rank could be computed in such a way so as to closely track ETX (expected transmission count, a fairly common routing metric used in LLN and defined in [RFC6551]) when the metric that an Objective Function minimizes is ETX, or latency, or in a more complicated way as appropriate to the Objective Function being used within the DODAG.
密接にETXを追跡するように、目的関数が最小化することメトリックがETXである場合、一例として、ランクは、（送信回数、LLNに使用かなり一般的なルーティングメトリックを期待して、[RFC6551]で定義される）ような方法で計算することができますまたは待ち時間は、またはより複雑な方法で目的関数として適切ではDODAG内で使用されています。
Routing metrics are used by routing protocols to compute shortest paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) and OSPF ([RFC4915]) use static link metrics. Such link metrics can simply reflect the bandwidth or can also be computed according to a polynomial function of several metrics defining different link characteristics. Some routing protocols support more than one metric: in the vast majority of the cases, one metric is used per (sub-)topology. Less often, a second metric may be used as a tiebreaker in the presence of Equal Cost Multiple Paths (ECMPs). The optimization of multiple metrics is known as an NP-complete problem and is sometimes supported by some centralized path computation engine.
ルーティングメトリックは、最短経路を計算するために、ルーティングプロトコルによって使用されています。 IS-ISのような（[RFC5120]）とOSPF内部ゲートウェイプロトコル（のIGP）は（[RFC4915]）静的リンクメトリックを使用します。そのようなリンクメトリックは、単に帯域幅を反映することができ、または、異なるリンク特性を定義するいくつかの指標の多項式関数に従って計算することができます。いくつかのルーティングプロトコルは、複数のメトリックをサポートしています。ほとんどの場合には、1つのメトリックは、（サブ）トポロジごとに使用されます。あまり、第二メトリックは、等コストマルチパス（ECMPs）の存在下でタイブレーカーとして使用することができます。複数のメトリックの最適化は、NP完全問題として知られており、時にはいくつかの集中型経路計算エンジンによって支持されています。
In contrast, LLNs do require the support of both static and dynamic metrics. Furthermore, both link and node metrics are required. In the case of RPL, it is virtually impossible to define one metric, or even a composite metric, that will satisfy all use cases.
これとは対照的に、LLNsは、静的および動的メトリックの両方のサポートを必要とします。さらに、両方のリンク及びノードのメトリックが必要とされます。 RPLの場合には、すべてのユースケースを満たす1つのメトリック、あるいは複合メトリックを定義することは事実上不可能です。
In addition, RPL supports constraint-based routing where constraints may be applied to both link and nodes. If a link or a node does not satisfy a required constraint, it is "pruned" from the candidate neighbor set, thus leading to a constrained shortest path.
また、RPLは、制約は、リンクとノードの両方に適用することができる制約ベースのルーティングをサポートします。リンクまたはノードが必要な制約を満たしていない場合、それは、このように拘束最短経路をもたらす、候補隣接セットから「剪定」されます。
An Objective Function specifies the objectives used to compute the (constrained) path. Furthermore, nodes are configured to support a set of metrics and constraints and select their parents in the DODAG according to the metrics and constraints advertised in the DIO messages. Upstream and Downstream metrics may be merged or advertised separately depending on the OF and the metrics. When they are advertised separately, it may happen that the set of DIO parents is different from the set of DAO parents (a DAO parent is a node to which unicast DAO messages are sent). Yet, all are DODAG parents with regard to the rules for Rank computation.
目的関数は（制約）のパスを計算するために使用目的を指定します。さらに、ノードは、メトリックおよび制約のセットをサポートし、DIOメッセージでアドバタイズ指標や制約に従ってDODAGで両親を選択するように構成されています。上流および下流のメトリックは、マージ又はおよび指標に応じて別々にアドバタイズされてもよいです。それらは別々にアドバタイズされる場合、それはDIOの親のセットがDAO親のセットとは異なることがある（DAO親は、ユニキャストDAOメッセージが送信されるノードです）。しかし、すべてがランク計算のための規則に関してDODAG両親です。
The Objective Function is decoupled from the routing metrics and constraints used by RPL. Whereas the OF dictates rules such as DODAG parent selection, load balancing, and so on, the set of metrics and/or constraints used, and thus those that determine the preferred path, are based on the information carried within the DAG container option in DIO messages.
目的関数はRPLで使用されるルーティングメトリックと制約から切り離されます。 OFは、DODAG親選択としてルール、ロードバランシングなど、メトリックおよび/または制約のセットが使用され、したがって、好ましい経路を決定するものを指示し、一方、DIOにおけるDAGコンテナオプション内で搬送される情報に基づいていますメッセージ。
The set of supported link/node constraints and metrics is specified in [RFC6551].
サポートリンク/ノード制約およびメトリックのセットは[RFC6551]で指定されています。
Example 1: Shortest path: path offering the shortest end-to-end delay.
実施例1：最短パス：最短エンドツーエンド遅延を提供パス。
Example 2: Shortest Constrained path: the path that does not traverse any battery-operated node and that optimizes the path reliability.
実施例2：最短パス制約：任意のバッテリ駆動ノードを横断し、そのパスの信頼性を最適化しないパス。
RPL tries to avoid creating loops when undergoing topology changes and includes Rank-based data-path validation mechanisms for detecting loops when they do occur (see Section 11 for more details). In practice, this means that RPL guarantees neither loop-free path selection nor tight delay convergence times, but it can detect and repair a loop as soon as it is used. RPL uses this loop detection to ensure that packets make forward progress within the DODAG Version and trigger repairs when necessary.
RPLは、トポロジの変更を受けたときにループを作成しないようにしようとすると（詳細については、セクション11を参照）、それらが発生したときにループを検出するためのランクベースのデータパス検証機構を含みます。実際には、これは、RPLは、どちらもループフリーパス選択もタイトな遅延収束時間を保証することを意味し、それは、すぐにそれが使用されているように、ループを検出し、修復することができます。 RPLは、パケットがDODAGバージョン内前進を作成し、必要なときに修理をトリガーすることを保証するために、このループ検出を使用しています。
A node is greedy if it attempts to move deeper (increase Rank) in the DODAG Version in order to increase the size of the parent set or improve some other metric. Once a node has joined a DODAG Version, RPL disallows certain behaviors, including greediness, in order to prevent resulting instabilities in the DODAG Version.
それは、親セットのサイズを大きくまたはいくつかの他のメトリックを改善するためにDODAG版で（ランクを増加させる）より深く移動しようとするノードが貪欲です。ノードがDODAG版に参加した後、RPLはDODAGバージョンで得られた不安定性を防止するために、貪欲を含む特定の動作を、禁止します。
Suppose a node is willing to receive and process a DIO message from a node in its own sub-DODAG and, in general, a node deeper than itself. In this case, a possibility exists that a feedback loop is created, wherein two or more nodes continue to try and move in the DODAG Version while attempting to optimize against each other. In some cases, this will result in instability. It is for this reason that RPL limits the cases where a node may process DIO messages from deeper nodes to some form of local repair. This approach creates an
ノードは、自身よりも深く、一般的には、ノードを受信して処理DIOメッセージをノードからそれ自身のサブDODAG及びても構わないと思っていると仮定する。この場合、可能性は、二つ以上のノードが試してみて、お互いに対して最適化しようとした際にDODAG版に移動していき、前記フィードバックループが作成されることに存在します。いくつかのケースでは、これは不安定になります。これは、RPLは、ノードがローカル修復のいくつかのフォームに、より深いノードからDIOメッセージを処理することができる場合を制限この理由のためです。このアプローチは、作成されます
"event horizon", whereby a node cannot be influenced beyond some limit into an instability by the action of nodes that may be in its own sub-DODAG.
ノードは、自身のサブDODAGであってもよく、ノードの作用によって不安定にいくつかの限界を超えて影響を受けることができない「イベント地平線」、。
(A) (A) (A)
|\ |\ |\
| `-----. | `-----. | `-----.
| \ | \ | \
(B) (C) (B) \ | (C)
\ | | /
`-----. | | .-----'
\| |/
(C) (B)
-1- -2- -3-
ー１ー ー２ー ー３ー
Figure 3: Greedy DODAG Parent Selection
図3：貪欲DODAGの親の選択
Figure 3 depicts a DODAG in three different configurations. A usable link between (B) and (C) exists in all three configurations. In Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a DODAG parent for Node (B).
図3は、3つの異なる構成でDODAGを示します。 （B）及び（C）の間に使用可能なリンクは、すべての3つの構成に存在します。図3-1に、ノード（A）はDODAGノードの親（B）及び（C）です。図3-2に、ノード（A）はDODAGノードの親（B）及び（C）であり、ノード（B）は、ノード（C）用DODAG親です。図3-3において、ノード（A）はDODAGノードの親（B）及び（C）であり、ノード（C）は、ノード（B）用DODAG親です。
If a RPL node is too greedy, in that it attempts to optimize for an additional number of parents beyond its most preferred parents, then an instability can result. Consider the DODAG illustrated in Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but we will consider the case when they are operating under the greedy condition that will try to optimize for two parents.
それはその最も好ましい両親を超えた両親の追加の数を最適化しようとすることでRPLノードは、あまりにも貪欲であれば、不安定性が発生することができます。図3-1に示すDODAGを考えます。この例では、ノード（B）及び（C）は、ほとんどのDODAGの親としてノード（A）を好むかもしれないが、彼らは両親のために最適化しようとする貪欲な条件の下で動作しているとき、私たちはケースを考えてみます。
o Let Figure 3-1 be the initial condition.
O図3-1は、初期条件とします。
o Suppose Node (C) first is able to leave the DODAG and rejoin at a lower Rank, taking both Nodes (A) and (B) as DODAG parents as depicted in Figure 3-2. Now Node (C) is deeper than both Nodes (A) and (B), and Node (C) is satisfied to have two DODAG parents.
Oノード（C）第DODAGを残し、図3-2に示すようDODAG親として両方のノード（A）及び（B）をとり、低いランクで再結合することが可能であると仮定する。今ノード（C）は、ノード（A）及び（B）の両方よりも深くされ、ノード（C）は、二つのDODAGの親を持つことが満たされています。
o Suppose Node (B), in its greediness, is willing to receive and process a DIO message from Node (C) (against the rules of RPL), and then Node (B) leaves the DODAG and rejoins at a lower Rank, taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is deeper than both Nodes (A) and (C) and is satisfied with two DAG parents.
Oノード（B）は、その貪欲に、（RPLのルールに対する）ノード（C）から受信し、DIOメッセージを処理する意思があると仮定し、次に、ノード（B）がDODAGを出て、より低いランクで再結合、服用ノード（A）と（C）両方DODAG親として。今ノード（B）が両方のノード（A）及び（C）よりも深くであり、2人のDAGの両親に満足しています。
o Then, Node (C), because it is also greedy, will leave and rejoin deeper, to again get two parents and have a lower Rank then both of them.
O次に、ノード（C）、それも貪欲であるためには、再び2人の親を取得し、それらの両方を下のランクを持っているために、離れて、より深い再結合します。
o Next, Node (B) will again leave and rejoin deeper, to again get two parents.
O次に、ノード（B）は、再び、再び2人の親を取得するには、離れて、より深い再結合します。
o Again, Node (C) leaves and rejoins deeper.
O再び、ノード（C）が出て、より深い再結合します。
o The process will repeat, and the DODAG will oscillate between Figure 3-2 and Figure 3-3 until the nodes count to infinity and restart the cycle again.
O処理が繰り返され、そしてDODAGノードまで図3-2と図3-3との間で振動無限にカウントし、再びサイクルを再開します。
o This cycle can be averted through mechanisms in RPL:
Oこのサイクルは、RPLに機構を介して回避することができます。
* Nodes (B) and (C) stay at a Rank sufficient to attach to their most preferred parent (A) and don't go for any deeper (worse) alternate parents (Nodes are not greedy).
*ノード（B）及び（C）は、その最も好ましいの親（A）に接続するのに十分なランクに滞在し、任意の深い（より悪い）代替親（ノードは貪欲ではありません）のために行っていません。
* Nodes (B) and (C) do not process DIO messages from nodes deeper than themselves (because such nodes are possibly in their own sub-DODAGs).
*ノード（B）と（そのようなノードは、独自のサブDODAGsにおそらくあるので）それ自体よりも深いノードからDIOメッセージを処理しない（C）。
These mechanisms are further described in Section 8.2.2.4.
これらのメカニズムは、さらに、セクション8.2.2.4で説明されています。
A DODAG loop may occur when a node detaches from the DODAG and reattaches to a device in its prior sub-DODAG. In particular, this may happen when DIO messages are missed. Strict use of the DODAGVersionNumber can eliminate this type of loop, but this type of loop may possibly be encountered when using some local repair mechanisms.
ノードはDODAGから分離し、その前のサブDODAG内のデバイスに再接続するときDODAGループが発生する可能性があります。 DIOメッセージが失われたときに特に、これは起こるかもしれません。 DODAGVersionNumberの厳密な使用は、このタイプのループを排除することができ、いくつかのローカルの修復メカニズムを使用する場合、ループのこのタイプは、おそらく遭遇することができます。
For example, consider the local repair mechanism that allows a node to detach from the DODAG, advertise a Rank of INFINITE_RANK (in order to poison its routes / inform its sub-DODAG), and then reattach to the DODAG. In some of these cases, the node may reattach to its own prior-sub-DODAG, causing a DODAG loop, because the poisoning may fail if the INFINITE_RANK advertisements are lost in the LLN environment. (In this case, the Rank-based data-path validation mechanisms would eventually detect and trigger correction of the loop).
例えば、ノードはDODAGから離脱することを可能にするローカルの修復メカニズムを検討し、次にDODAGに再付着（/そのルートを被毒そのサブDODAGを知らせるために）INFINITE_RANKのランクを広告します。 INFINITE_RANK広告がLLN環境で失われた場合中毒が失敗する可能性があるため、これらの場合のいくつかでは、ノードは、DODAGループを引き起こし、前サブDODAG独自に再付着することができます。 （この場合、ランクベースのデータパス検証メカニズムは、最終的に検出するであろうとループのトリガ補正）。
A DAO loop may occur when the parent has a route installed upon receiving and processing a DAO message from a child, but the child has subsequently cleaned up the related DAO state. This loop happens when a No-Path (a DAO message that invalidates a previously announced prefix, see Section 6.4.3) was missed and persists until all state has been cleaned up. RPL includes an optional mechanism to acknowledge DAO messages, which may mitigate the impact of a single DAO message being missed. RPL includes loop detection mechanisms that mitigate the impact of DAO loops and trigger their repair. (See Section 11.2.2.3.)
親は子からDAOメッセージを受信して処理する際にインストールされた経路を有する場合DAOループが発生することがあり、しかし、子供は、その後、関連するDAO状態をクリーンアップしています。このループはありませんパス（以前に発表した接頭辞を無効にDAOメッセージは、6.4.3項を参照）場合に発生逃し、すべての状態がクリーンアップされるまで持続しました。 RPLは見逃されている単一DAOメッセージの影響を軽減することができる、DAOメッセージを確認するための任意の機構を含みます。 RPLは、DAOの影響ループとその修復を誘発緩和ループ検出機構を含みます。 （11.2.2.3項を参照してください。）
RPL supports three basic traffic flows: multipoint-to-point (MP2P), point-to-multipoint (P2MP), and point-to-point (P2P).
マルチポイント・ツー・ポイント（MP2P）、ポイント・ツー・マルチポイント（P2MP）、およびポイントツーポイント（P2P）：RPLが流れて三つの基本的なトラフィックをサポートしています。
Multipoint-to-point (MP2P) is a dominant traffic flow in many LLN applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]). The destinations of MP2P flows are designated nodes that have some application significance, such as providing connectivity to the larger Internet or core private IP network. RPL supports MP2P traffic by allowing MP2P destinations to be reached via DODAG roots.
マルチポイント・ツー・ポイント（MP2P）多くのLLNアプリケーション（[RFC5867]、[RFC5826]、[RFC5673]及び[RFC5548]）における支配的なトラフィックフローです。 MP2Pフローの目的地は、このような大規模インターネットまたはコアプライベートIPネットワークへの接続を提供するなど、いくつかのアプリケーションの重要性を持っているノードを、指定されています。 RPLは、MP2P先がDODAG根を介して到達できるようにすることによってMP2Pトラフィックをサポートしています。
Point-to-multipoint (P2MP) is a traffic pattern required by several LLN applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]). RPL supports P2MP traffic by using a destination advertisement mechanism that provisions Down routes toward destinations (prefixes, addresses, or multicast groups), and away from roots. Destination advertisements can update routing tables as the underlying DODAG topology changes.
ポイントツーマルチポイント（P2MP）は、いくつかのLLNアプリケーション（[RFC5867]、[RFC5826]、[RFC5673]及び[RFC5548]）によって必要とされるトラフィックパターンです。 RPLは、その規定ダウン離れ根から目的地（プレフィックス、アドレス、またはマルチキャストグループ）、およびに向けてルートを先の広告メカニズムを使用してP2MPトラフィックをサポートしています。先の広告は、基礎となるDODAGトポロジの変更などのルーティングテーブルを更新することができます。
RPL DODAGs provide a basic structure for point-to-point (P2P) traffic. For a RPL network to support P2P traffic, a root must be able to route packets to a destination. Nodes within the network may also have routing tables to destinations. A packet flows towards a root until it reaches an ancestor that has a known route to the destination. As pointed out later in this document, in the most constrained case (when nodes cannot store routes), that common ancestor may be the DODAG root. In other cases, it may be a node closer to both the source and destination.
RPLのDODAGsは、ポイントツーポイント（P2P）トラフィックのための基本的な構造を提供します。 RPLのネットワークは、P2Pトラフィックをサポートするために、ルートは目的地までの経路のパケットにできなければなりません。ネットワーク内のノードはまた、宛先にルーティングテーブルを持っていることがあります。目的地への既知の経路を有する祖先に到達するまでのパケットがルートに向かって流れます。このドキュメントで指摘したように、最も制約ケース（ノードがルートを保存することができない場合）に、その共通の祖先はDODAGルートであってもよいです。他の場合には、近いソースと宛先の両方のノードであってもよいです。
RPL also supports the case where a P2P destination is a 'one-hop' neighbor.
RPLはまた、P2P先が「1ホップ」隣人である場合をサポートしています。
RPL neither specifies nor precludes additional mechanisms for computing and installing potentially more optimal routes to support arbitrary P2P traffic.
RPLは、どちらを指定することも、コンピューティングおよび任意P2Pトラフィックをサポートするために、潜在的により最適なルートをインストールするための追加のメカニズムを妨げます。
Within a given LLN, there may be multiple, logically independent RPL Instances. A RPL node may belong to multiple RPL Instances, and it may act as a router in some and as a leaf in others. This document describes how a single instance behaves.
与えられたLLN内では、複数の、論理的に独立したRPLインスタンスがあるかもしれません。 RPLノードは、複数のRPLインスタンスに属していてもよいし、それはいくつかのルータとして、他のリーフとして作用することができます。この文書では、単一のインスタンスがどのように動作するかを説明します。
There are two types of RPL Instances: Local and Global. RPL divides the RPLInstanceID space between Global and Local instances to allow for both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL Instances are coordinated, have one or more DODAGs, and are typically long-lived. Local RPL Instances are always a single DODAG whose singular root owns the corresponding DODAGID and allocates the local RPLInstanceID in a unilateral manner. Local RPL Instances can be used, for example, for constructing DODAGs in support of a future on-demand routing solution. The mode of operation of Local RPL Instances is out of scope for this specification and may be described in other companion specifications.
ローカルおよびグローバル：RPLインスタンスの2種類があります。 RPLはRPLInstanceIDsの協調と一方的な割り当ての両方を可能にするために、グローバルとローカルのインスタンス間RPLInstanceIDスペースを分割します。グローバルRPLインスタンスは、コーディネート一つ以上のDODAGsを持っており、一般的に長寿命ですされています。ローカルRPLインスタンスは常にその特異根対応DODAGIDを所有し、一方的なやり方でローカルRPLInstanceIDを割り当て、単一のDODAGです。ローカルRPLインスタンスは、将来のオンデマンドルーティングソリューションのサポートにDODAGsを構築するため、例えば、使用することができます。ローカルRPLインスタンスの動作モードは、本明細書の範囲外であり、他のコンパニオン仕様に記載されてもよいです。
The definition and provisioning of RPL Instances are out of scope for this specification. Guidelines may be application and implementation specific, and they are expected to be elaborated in future companion specifications. Those operations are expected to be such that data packets coming from the outside of the RPL network can unambiguously be associated to at least one RPL Instance and be safely routed over any instance that would match the packet.
RPLインスタンスの定義とプロビジョニングは、この仕様の範囲外です。ガイドラインは、特定のアプリケーションおよび実装することができ、それらは将来のコンパニオン仕様に詳述されることが期待されます。これらの操作は、RPLのネットワークの外部から来るデータパケットは明白少なくとも一つRPLインスタンスに関連付けることができ、安全にパケットに一致する任意のインスタンスにルーティングされるようであることが期待されます。
Control and data packets within RPL network are tagged to unambiguously identify of which RPL Instance they are a part.
RPLネットワーク内の制御およびデータパケットが明確RPLインスタンスそれらが一部であると識別するためにタグ付けされます。
Every RPL control message has a RPLInstanceID field. Some RPL control messages, when referring to a local RPLInstanceID as defined below, may also include a DODAGID.
すべてのRPL制御メッセージはRPLInstanceIDフィールドがあります。以下に定義されるようなローカルRPLInstanceIDに言及する場合、いくつかのRPL制御メッセージは、DODAGIDを含んでもよいです。
Data packets that flow within the RPL network expose the RPLInstanceID as part of the RPL Packet Information that RPL requires, as further described in Section 11.2. For data packets coming from outside the RPL network, the ingress router determines the RPLInstanceID and places it into the resulting packet that it injects into the RPL network.
RPLネットワーク内のフローのデータパケットは、RPLは、さらなるセクション11.2に記載され、必要であることRPLパケット情報の一部としてRPLInstanceIDを露出させます。 RPLのネットワークの外部から到来するデータパケットに対して、入口ルータは、RPLネットワークに注入することRPLInstanceID、得られたパケットに場所を決定します。
A global RPLInstanceID MUST be unique to the whole LLN. Mechanisms for allocating and provisioning global RPLInstanceID are out of scope for this specification. There can be up to 128 Global instance in the whole network. Local instances are always used in conjunction with a DODAGID (which is either given explicitly or implicitly in some cases), and up 64 Local instances per DODAGID can be supported. Local instances are allocated and managed by the node that owns the DODAGID, without any explicit coordination with other nodes, as further detailed below.
グローバルRPLInstanceIDは全体LLNに固有でなければなりません。グローバルRPLInstanceIDを割り当て、プロビジョニングのための機構は、本明細書の範囲外です。ネットワーク全体で最大128のグローバルインスタンスが存在する場合があります。ローカルインスタンスは常に（いくつかのケースでは、明示的または暗黙的に与えられているのいずれか）DODAGIDと組み合わせて使用され、そしてDODAGIDあたり最大64のローカルインスタンスをサポートすることができます。以下にさらに詳述されるように、ローカルインスタンスは、他のノードとの明示的な調整なし、DODAGIDを所有するノードによって割り当て及び管理されています。
A global RPLInstanceID is encoded in a RPLInstanceID field as follows:
次のようにグローバルRPLInstanceIDはRPLInstanceIDフィールドでエンコードされています。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+
Figure 4: RPLInstanceID Field Format for Global Instances
図4：グローバル・インスタンスのRPLInstanceIDフィールドのフォーマット
A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it MUST be unique for that DODAGID. The DODAGID used to configure the local RPLInstanceID MUST be a reachable IPv6 address of the node, and it MUST be used as an endpoint of all communications within that Local instance.
地元RPLInstanceIDはDODAGIDを所有しているノードによって自動設定されると、それはそのDODAGIDに対して一意でなければなりません。 DODAGIDノードの到達可能なIPv6アドレスでなければなりませんローカルRPLInstanceIDを構成するために使用され、それがそのローカル・インスタンス内のすべての通信のエンドポイントとして使用されなければなりません。
A local RPLInstanceID is encoded in a RPLInstanceID field as follows:
次のようにローカルRPLInstanceIDはRPLInstanceIDフィールドに符号化されます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+
Figure 5: RPLInstanceID Field Format for Local Instances
図5：ローカルインスタンスのRPLInstanceIDフィールドのフォーマット
The 'D' flag in a local RPLInstanceID is always set to 0 in RPL control messages. It is used in data packets to indicate whether the DODAGID is the source or the destination of the packet. If the 'D' flag is set to 1, then the destination address of the IPv6 packet MUST be the DODAGID. If the 'D' flag is cleared, then the source address of the IPv6 packet MUST be the DODAGID.
ローカルRPLInstanceIDに「D」フラグは常にRPL制御メッセージに0に設定されています。 DODAGIDソースまたはパケットの宛先であるかどうかを示すために、データパケットに使用されます。 「D」フラグが1に設定されている場合、IPv6パケットの宛先アドレスがDODAGIDなければなりません。 「D」フラグがクリアされている場合、IPv6パケットの送信元アドレスはDODAGIDなければなりません。
For example, consider a Node A that is the DODAG root of a Local RPL Instance, and has allocated a local RPLInstanceID. By definition, all traffic traversing that Local RPL Instance will either originate or terminate at Node A. In this case, the DODAGID will be the reachable IPv6 address of Node A. All traffic will contain the address of Node A, and thus the DODAGID, in either the source or destination address. Thus, the local RPLInstanceID may indicate that the DODAGID is equivalent to either the source address or the destination address by setting the 'D' flag appropriately.
たとえば、ローカルRPLインスタンスのDODAGルートで、地元RPLInstanceIDを割り当てたノードAを検討します。定義では、ローカルRPLインスタンスはこの場合、ノードAで発信または終了するかという通過するすべてのトラフィックは、DODAGIDは、すべてのトラフィックは、ノードAのアドレスが含まれていますノードAの到達可能なIPv6アドレスも、ひいてはDODAGIDます送信元または宛先アドレスのいずれかインチしたがって、ローカルRPLInstanceIDはDODAGID元アドレス又は適切に「D」フラグを設定することにより、宛先アドレスのいずれかと等価であることを示すことができます。
This document defines the RPL control message, a new ICMPv6 [RFC4443] message. A RPL control message is identified by a code and composed of a base that depends on the code (and a series of options).
この文書では、RPL制御メッセージ、新規のICMPv6 [RFC4443]メッセージを定義します。 RPL制御メッセージは、コードによって識別されたコードに依存ベース（およびオプションのシリーズ）で構成されています。
Most RPL control messages have the scope of a link. The only exception is for the DAO / DAO-ACK messages in Non-Storing mode, which are exchanged using a unicast address over multiple hops and thus uses global or unique-local addresses for both the source and destination addresses. For all other RPL control messages, the source address is a link-local address, and the destination address is either the all-RPL-nodes multicast address or a link-local unicast address of the destination. The all-RPL-nodes multicast address is a new address with a value of ff02::1a.
ほとんどのRPL制御メッセージは、リンクの範囲を持っています。唯一の例外は、複数のホップにわたってユニキャストアドレスを使用して交換され、非保存モードでDAO / DAO-ACKメッセージのためであり、従って、ソースと宛先アドレスの両方に対してグローバルまたはユニークローカルアドレスを使用します。他のすべてのRPL制御メッセージの場合、送信元アドレスがリンクローカルアドレスであり、宛先アドレスは、全RPLノードマルチキャストアドレスまたは宛先のリンクローカルユニキャストアドレスのいずれかです。すべて-RPLノードマルチキャストアドレスはFF02 :: 1aの値を持つ新しいアドレスです。
In accordance with [RFC4443], the RPL Control Message consists of an ICMPv6 header followed by a message body. The message body is comprised of a message base and possibly a number of options as illustrated in Figure 6.
[RFC4443]に従って、RPL制御メッセージはメッセージ本体に続くのICMPv6ヘッダーで構成されています。図6に示すように、メッセージボディは、メッセージベースおよびおそらくオプションの数で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: RPL Control Message
図6：RPL制御メッセージ
The RPL control message is an ICMPv6 information message with a Type of 155.
RPL制御メッセージ155の種類のICMPv6情報メッセージです。
The Code field identifies the type of RPL control message. This document defines codes for the following RPL control message types (see Section 20.2)):
コードフィールドは、RPL制御メッセージのタイプを識別する。この文書は、以下のRPL制御メッセージタイプ（セクション20.2を参照））のためのコードを定義します。
o 0x00: DODAG Information Solicitation (Section 6.2)
Oは0x00：DODAG情報要請（6.2節）
o 0x01: DODAG Information Object (Section 6.3)
0x01のO：DODAG情報オブジェクト（6.3節）
o 0x02: Destination Advertisement Object (Section 6.4)
O 0×02：デスティネーション広告オブジェクト（6.4節）
o 0x03: Destination Advertisement Object Acknowledgment (Section 6.5)
O 0x03の：デスティネーション広告オブジェクト応答（6.5節）
o 0x80: Secure DODAG Information Solicitation (Section 6.2.2)
Oは0x80：セキュアDODAG情報要請（6.2.2項）
o 0x81: Secure DODAG Information Object (Section 6.3.2)
O 0x81と：セキュアDODAG情報オブジェクト（6.3.2）
o 0x82: Secure Destination Advertisement Object (Section 6.4.2)
O 0x82と：セキュア先広告オブジェクト（6.4.2項）
o 0x83: Secure Destination Advertisement Object Acknowledgment (Section 6.5.2)
0x83のO：セキュア先広告オブジェクト応答（セクション6.5.2）
o 0x8A: Consistency Check (Section 6.6)
0x8A O：整合性チェック（6.6節）
If a node receives a RPL control message with an unknown Code field, the node MUST discard the message without any further processing, MAY raise a management alert, and MUST NOT send any messages in response.
ノードは、未知のコードフィールドでRPL制御メッセージを受信した場合、ノードは、管理アラートを上げることができる、任意のさらなる処理せずにメッセージを捨てなければなりません、それに応答して任意のメッセージを送ってはいけません。
The checksum is computed as specified in [RFC4443]. It is set to zero for the RPL security operations specified below and computed once the rest of the content of the RPL message including the security fields is all set.
[RFC4443]で指定されたチェックサムが計算されます。これは、RPLのセキュリティオペレーション以下に指定し、セキュリティ分野など、RPLメッセージの内容の残りの部分が全てセットになると計算のためにゼロに設定されています。
The high order bit (0x80) of the code denotes whether the RPL message has security enabled. Secure RPL messages have a format to support confidentiality and integrity, illustrated in Figure 7.
コードの上位ビット（0x80の）がRPLメッセージは、セキュリティが有効になっているかどうかを示しています。 RPLメッセージは、図7に示す、機密性と整合性をサポートするためのフォーマットを持って固定します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Security .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Secure RPL Control Message
図7：RPL制御メッセージをセキュア
The remainder of this section describes the currently defined RPL control message Base formats followed by the currently defined RPL Control Message options.
このセクションの残りの部分は、現在定義されているRPL制御メッセージのオプションが続く現在定義されているRPL制御メッセージの基本フォーマットを記述する。
Each RPL message has a secure variant. The secure variants provide integrity and replay protection as well as optional confidentiality and delay protection. Because security covers the base message as well as options, in secured messages the security information lies between the checksum and base, as shown in Figure 7.
各RPLメッセージは、安全なバリエーションがあります。安全な変異体は、完全性とリプレイ保護だけでなく、オプションの機密性と遅延保護を提供します。セキュリティは、ベースメッセージ、ならびにオプションをカバーするので、図7に示すように、保護されたメッセージにセキュリティ情報は、チェックサムとベースとの間にあります。
The level of security and the algorithms in use are indicated in the protocol messages as described below:
後述のようにセキュリティのレベルおよび使用中のアルゴリズムは、プロトコル・メッセージに示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | Algorithm |KIM|Resvd| LVL | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Section
図8：セキュリティ・セクション
Message Authentication Codes (MACs) and signatures provide authentication over the entire unsecured ICMPv6 RPL control message, including the Security section with all fields defined, but with the ICMPv6 checksum temporarily set to zero. Encryption provides confidentiality of the secured RPL ICMPv6 message starting at the first byte after the Security section and continuing to the last byte of the packet. The security transformation yields a secured ICMPv6 RPL message with the inclusion of the cryptographic fields (MAC, signature, etc.). In other words, the security transformation itself (e.g., the Signature and/or Algorithm in use) will detail how to incorporate the cryptographic fields into the secured packet. The Security section itself does not explicitly carry those cryptographic fields. Use of the Security section is further detailed in Sections 19 and 10.
メッセージ認証コード（MAC）と署名が定義されたすべてのフィールドを持つセキュリティ部を含む全体の無担保のICMPv6 RPL制御メッセージ、上に認証を提供するが、一時的にゼロに設定されたICMPv6チェックサムを有します。暗号化は確保RPL ICMPv6メッセージは、セキュリティセクションの後の最初のバイトから開始し、パケットの最後のバイトに続くの機密性を提供します。セキュリティの変換は、暗号化フィールド（MAC、署名など）を含めることで固定のICMPv6 RPLメッセージをもたらします。換言すれば、セキュリティの変換自体（使用中の例えば、署名及び/又はアルゴリズム）を確保パケットに暗号フィールドを詳細組み込むためする方法。セキュリティセクション自体は、明示的にそれらの暗号化フィールドを運ぶことはありません。 [セキュリティ]セクションの使用はさらに、セクション19および10に詳述されています。
Counter is Time (T): If the counter's Time flag is set, then the Counter field is a timestamp. If the flag is cleared, then the counter is an incrementing counter. Section 10.5 describes the details of the 'T' flag and Counter field.
カウンターは、時間（T）である：カウンタのタイムフラグが設定されている場合、カウンタフィールドは、タイムスタンプです。フラグがクリアされている場合、カウンタはインクリメントカウンタです。 10.5節は「T」フラグとカウンタフィールドの詳細について説明します。
Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：7ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Security Algorithm (Algorithm): The Security Algorithm field specifies the encryption, MAC, and signature scheme the network uses. Supported values of this field are as follows:
セキュリティアルゴリズム（アルゴリズム）：セキュリティアルゴリズムフィールドは、暗号化、MACを指定し、署名方式は、ネットワークを使用しています。次のようにこのフィールドのサポートされる値は以下のとおりです。
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned |
+-----------+-------------------+------------------------+
Figure 9: Security Algorithm (Algorithm) Encoding
図9：セキュリティアルゴリズム（アルゴリズム）エンコーディング
Section 10.9 describes the algorithms in greater detail.
10.9節は、より詳細にアルゴリズムを説明します。
Key Identifier Mode (KIM): The Key Identifier Mode is a 2-bit field that indicates whether the key used for packet protection is determined implicitly or explicitly and indicates the particular representation of the Key Identifier field. The Key Identifier Mode is set one of the values from the table below:
キー識別子モード（KIM）：キー識別子モードパケットを保護するために使用されるキーを明示的または暗黙的に決定されているかどうかを示し、キー識別子フィールドの特定の表現を示す2ビットのフィールドです。キー識別子モードは、下記の表からのいずれかの値に設定されています。
+------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key |
| | | | Identifier |
| | | | Length |
| | | | (octets) |
+------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | |
| | | field. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 1 | 01 | Per-pair key used. | 0 |
| | | Key determined by source | |
| | | and destination of packet. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is not present. | |
+------+-----+-----------------------------+------------+
| 2 | 10 | Group key used. | 9 |
| | | Key determined by Key Index | |
| | | and Key Source Identifier. | |
| | | | |
| | | Key Source is present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, |
| | | it uses a group key, Key | |
| | | Index and Key Source | |
| | | specify key. | |
| | | | |
| | | Key Source may be present. | |
| | | Key Index may be present. | |
+------+-----+-----------------------------+------------+
Figure 10: Key Identifier Mode (KIM) Encoding
図10：キー識別子モード（KIM）をコードします
In Mode 3 (KIM=11), the presence or absence of the Key Source and Key Identifier depends on the Security Level (LVL) described below. If the Security Level indicates there is encryption, then the fields are present; if it indicates there is no encryption, then the fields are not present.
モード3（KIM = 11）において、キーソースとキー識別子の有無を以下に説明するセキュリティレベル（LVL）に依存します。セキュリティレベルは、暗号化があることを示す場合には、フィールドが存在しています。それは、暗号化がないことを示している場合、そのフィールドは存在しません。
Resvd: 3-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resvd：3ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Security Level (LVL): The Security Level is a 3-bit field that indicates the provided packet protection. This value can be adapted on a per-packet basis and allows for varying levels of data authenticity and, optionally, for data confidentiality. The KIM field indicates whether signatures are used and the meaning of the Level field. Note that the assigned values of Security Level are not necessarily ordered -- a higher value of LVL does not necessarily equate to increased security. The Security Level is set to one of the values in the tables below:
セキュリティレベル（LVL）：セキュリティレベルは、与えられたパケットの保護を示す3ビットのフィールドです。この値は、パケット単位で適応し、データの機密性のために、必要に応じて、データの真正性の様々なレベルを可能とすることができます。 KIMフィールドには、署名が使用されているかどうかを示し、レベルのフィールドの意味。 LVLの高い値は、必ずしもセキュリティの向上に一致しない - セキュリティレベルの割り当てられた値は、必ずしも発注されていないことに注意してください。セキュリティレベルは、以下の表の値のいずれかに設定されます。
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-7 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2 | Sign-2048 | 256 |
| 3 | ENC-Sign-2048 | 256 |
| 4-7 | Unassigned | N/A |
+-------+---------------+-----+
Figure 11: Security Level (LVL) Encoding
図11：セキュリティレベル（LVL）エンコーディング
The MAC attribute indicates that the message has a MAC of the specified length. The ENC attribute indicates that the message is encrypted. The Sign attribute indicates that the message has a signature of the specified length.
MAC属性は、メッセージが指定した長さのMACを持っていることを示しています。 ENC属性は、メッセージが暗号化されていることを示しています。サイン属性は、メッセージは、指定された長さの署名を有することを示します。
Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：フラグのために予約さ8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Counter: The Counter field indicates the non-repeating 4-octet value used to construct the cryptographic mechanism that implements packet protection and allows for the provision of semantic security. See Section 10.9.1.
カウンター：カウンターフィールドは、パケットの保護を実装し、セマンティック担保の提供を可能にし、暗号化メカニズムを構築するために使用される非反復4オクテットの値を示しています。 10.9.1項を参照してください。
Key Identifier: The Key Identifier field indicates which key was used to protect the packet. This field provides various levels of granularity of packet protection, including peer-to-peer keys, group keys, and signature keys. This field is represented as indicated by the Key Identifier Mode field and is formatted as follows:
キー識別子：キー識別子フィールドは、パケットを保護するために使用されたキーを示します。このフィールドは、ピア・ツー・ピアの鍵、グループ鍵、および署名キーを含むパケット保護の粒度の様々なレベルを提供します。このフィールドは、キー識別子Modeフィールドによって示されるように表され、次のようにフォーマットされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Source .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Index .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key Identifier
図12：キー識別子
Key Source: The Key Source field, when present, indicates the logical identifier of the originator of a group key. When present, this field is 8 bytes in length.
キー出典：キーソースフィールド、存在する場合、グループキーの創始者の論理識別子を示します。存在する場合、このフィールドは長さが8バイトです。
Key Index: The Key Index field, when present, allows unique identification of different keys with the same originator. It is the responsibility of each key originator to make sure that actively used keys that it issues have distinct key indices and that all key indices have a value unequal to 0x00. Value 0x00 is reserved for a preinstalled, shared key. When present this field is 1 byte in length.
キーインデックス：キーインデックスフィールドは、存在する場合、同じ発信元と異なるキーを一意に識別することができます。積極的に問題が明確なキーのインデックスを持っており、すべてのキーのインデックスが0x00のに等しくない値を持っているキーを使用していることを確認するために、各キー発信者の責任です。値は0x00がプリインストールされ、共有キー用に予約されています。存在する場合、このフィールドの長さは1バイトです。
Unassigned bits of the Security section are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
[セキュリティ]セクションの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The DODAG Information Solicitation (DIS) message may be used to solicit a DODAG Information Object from a RPL node. Its use is analogous to that of a Router Solicitation as specified in IPv6 Neighbor Discovery; a node may use DIS to probe its neighborhood for nearby DODAGs. Section 8.3 describes how nodes respond to a DIS.
DODAG情報要請（DIS）メッセージは、RPLノードからDODAG情報オブジェクトを求めるために使用することができます。 IPv6の近隣探索に指定され、その使用は、ルータ要請のものと類似です。ノードは、近くのDODAGsのためにその近傍を探るためにDISを使用することができます。 8.3節では、ノードがDISへの対応方法を説明します。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The DIS Base Object
図13：DIS基本オブジェクト
Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：フラグのために予約さ8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Unassigned bits of the DIS Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
DISベースの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
A Secure DIS message follows the format in Figure 7, where the base format is the DIS message shown in Figure 13.
セキュアDISメッセージは、基本フォーマットは、図13に示すDISメッセージである。図7において、フォーマットに従います。
The DIS message MAY carry valid options.
DISメッセージは、有効なオプションを運ぶことができます。
This specification allows for the DIS message to carry the following options:
この仕様は、以下のオプションを運ぶためにDISメッセージが可能になります：
0x00 Pad1 0x01 PadN 0x07 Solicited Information
PAD1は0x00 0x01の0x07のPADN要請情報
The DODAG Information Object carries information that allows a node to discover a RPL Instance, learn its configuration parameters, select a DODAG parent set, and maintain the DODAG.
DODAG情報オブジェクトは、ノードが、RPLインスタンスを発見し、その設定パラメータを学び、DODAGの親セットを選択し、DODAGを維持することを可能にする情報を運びます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 14: The DIO Base Object
図14：DIO基本オブジェクト
Grounded (G): The Grounded 'G' flag indicates whether the DODAG advertised can satisfy the application-defined goal. If the flag is set, the DODAG is grounded. If the flag is cleared, the DODAG is floating.
（G）を接地：接地「G」フラグはDODAGがアプリケーション定義の目標を満たすことができるアドバタイズかどうかを示します。フラグが設定されている場合、DODAGは接地されています。フラグがクリアされている場合、DODAGが浮いています。
Mode of Operation (MOP): The Mode of Operation (MOP) field identifies the mode of operation of the RPL Instance as administratively provisioned at and distributed by the DODAG root. All nodes who join the DODAG must be able to honor the MOP in order to fully participate as a router, or else they must only join as a leaf. MOP is encoded as in the figure below:
動作モード（MOP）：動作モード（MOP）フィールドとして管理にプロビジョニングおよびDODAGルートによって分配RPLインスタンスの動作モードを識別する。 DODAGに参加するすべてのノードは完全にルータとして参加するためにMOPを称えることができなければならない、または他の彼らは、リーフとして加入しなければなりません。 MOPは、下図のようにコード化されています。
+-----+-----------------------------------------------------+
| MOP | Description |
+-----+-----------------------------------------------------+
| 0 | No Downward routes maintained by RPL |
| 1 | Non-Storing Mode of Operation |
| 2 | Storing Mode of Operation with no multicast support |
| 3 | Storing Mode of Operation with multicast support |
| | |
| | All other values are unassigned |
+-----+-----------------------------------------------------+
A value of 0 indicates that destination advertisement messages are disabled and the DODAG maintains only Upward routes.
0の値は、先の広告メッセージが無効になっているとDODAGだけ上向きのルートを維持していることを示しています。
Figure 15: Mode of Operation (MOP) Encoding
図15：動作モード（MOP）をコードします
DODAGPreference (Prf): A 3-bit unsigned integer that defines how preferable the root of this DODAG is compared to other DODAG roots within the instance. DAGPreference ranges from 0x00 (least preferred) to 0x07 (most preferred). The default is 0 (least preferred). Section 8.2 describes how DAGPreference affects DIO processing.
DODAGPreference（PRF）：このDODAGのルートは、インスタンス内の他のDODAG根と比較する方法を好ましい定義、3ビットの符号なし整数。 DAGPreferenceは0x00の（最も好ましい）から0x07の（最も好ましい）の範囲です。デフォルト値は0（最も好ましい）です。 8.2節ではDAGPreferenceはDIO処理をどのように影響するかについて説明します。
Version Number: 8-bit unsigned integer set by the DODAG root to the DODAGVersionNumber. Section 8.2 describes the rules for DODAGVersionNumbers and how they affect DIO processing.
バージョン番号：DODAGVersionNumberにDODAGルートにより設定された8ビットの符号なし整数。 8.2節はDODAGVersionNumbersとどのように彼らはDIO処理に影響を与えるためのルールを説明しています。
Rank: 16-bit unsigned integer indicating the DODAG Rank of the node sending the DIO message. Section 8.2 describes how Rank is set and how it affects DIO processing.
ランク：DIOメッセージを送信するノードのDODAG順位を示す16ビットの符号なし整数。 8.2節ではランクが設定されているか、それはDIO処理をどのように影響するかについて説明します。
RPLInstanceID: 8-bit field set by the DODAG root that indicates of which RPL Instance the DODAG is a part.
RPLInstanceID：RPLインスタンスDODAGがその一部である示しDODAGルートにより設定された8ビットのフィールド。
Destination Advertisement Trigger Sequence Number (DTSN): 8-bit unsigned integer set by the node issuing the DIO message. The Destination Advertisement Trigger Sequence Number (DTSN) flag is used as part of the procedure to maintain Downward routes. The details of this process are described in Section 9.
先広告トリガーシーケンス番号（DTSN）：DIOメッセージを発行するノードによって設定された8ビットの符号なし整数。先広告トリガーシーケンス番号（DTSN）フラグが下方経路を維持するための手順の一部として使用されます。このプロセスの詳細については、第9章で説明されています。
Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：フラグのために予約さ8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
DODAGID: 128-bit IPv6 address set by a DODAG root that uniquely identifies a DODAG. The DODAGID MUST be a routable IPv6 address belonging to the DODAG root.
DODAGID一意DODAGを識別するDODAGルートにより設定された128ビットのIPv6アドレス。 DODAGIDはDODAGルートに属するルーティング可能なIPv6アドレスでなければなりません。
Unassigned bits of the DIO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
DIOベースの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
A Secure DIO message follows the format in Figure 7, where the base format is the DIO message shown in Figure 14.
セキュアDIOメッセージベースのフォーマットは図14に示さDIOメッセージである。図7において、フォーマットに従います。
The DIO message MAY carry valid options.
DIOメッセージは、有効なオプションを運ぶことができます。
This specification allows for the DIO message to carry the following options:
この仕様は、以下のオプションを運ぶためにDIOメッセージが可能になります：
0x00 Pad1 0x01 PadN 0x02 DAG Metric Container 0x03 Routing Information 0x04 DODAG Configuration 0x08 Prefix Information
PAD1は0x00 0x01の0x02のPADN DAGメトリックルーティング情報コンテナ0x03の0x04を0x08にプレフィックスDODAG設定情報
The Destination Advertisement Object (DAO) is used to propagate destination information Upward along the DODAG. In Storing mode, the DAO message is unicast by the child to the selected parent(s). In Non-Storing mode, the DAO message is unicast to the DODAG root. The DAO message may optionally, upon explicit request or error, be acknowledged by its destination with a Destination Advertisement Acknowledgement (DAO-ACK) message back to the sender of the DAO.
先の広告オブジェクト（DAO）はDODAGに沿って上方に宛先情報を伝播するために使用されます。モードの保存では、DAOメッセージは、選択された親（複数可）に子供がユニキャストされます。非保存モードでは、DAOメッセージはDODAGルートへのユニキャストです。 DAOメッセージは必要に応じて、明示的な要求またはエラーの際に、先バックDAOの送信者に広告応答（DAO-ACK）メッセージをその宛先によって確認することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAGID is not always present, as described below.
「*」以下に説明するようにDODAGIDは、常に存在していないことを示しています。
Figure 16: The DAO Base Object
図16：DAO基本オブジェクト
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.
RPLInstanceID：DIOから学んだように、DODAGに関連付けられているトポロジインスタンスを示す8ビットのフィールド。
K: The 'K' flag indicates that the recipient is expected to send a DAO-ACK back. (See Section 9.3.)
K「K」フラグは、受信者がバックDAO-ACKを送信することが期待されていることを示しています。 （セクション9.3を参照してください。）
D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used.
D：「D」フラグはDODAGIDフィールドが存在することを示します。ローカルRPLInstanceIDが使用される場合、このフラグを設定しなければなりません。
Flags: The 6 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールド内の未使用の残りの6ビットは、フラグのために予約されています。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Reserved: 8-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
DAOSequence: Incremented at each unique DAO message from a node and echoed in the DAO-ACK message.
DAO配列：ノードから各一意DAOメッセージでインクリメントおよびDAO-ACKメッセージにエコー。
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field is only present when the 'D' flag is set. This field is typically only present when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use, this field need not be present.
DODAGID（オプション）：一意DODAGを識別するDODAGルートにより設定された128ビットの符号なし整数。 「D」フラグが設定されている場合、このフィールドにのみ存在します。ローカルRPLInstanceIDはRPLInstanceIDに関連付けられDODAGIDを識別するために、使用されている場合、このフィールドは、典型的にのみ存在します。グローバルRPLInstanceIDが使用されている場合は、このフィールドが存在する必要はありません。
Unassigned bits of the DAO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
DAOベースの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
A Secure DAO message follows the format in Figure 7, where the base format is the DAO message shown in Figure 16.
セキュアDAOメッセージベースのフォーマットは図16に示されているDAOメッセージである。図7において、フォーマットに従います。
The DAO message MAY carry valid options.
DAOメッセージは、有効なオプションを運ぶことができます。
This specification allows for the DAO message to carry the following options:
この仕様は、以下のオプションを運ぶためにDAOメッセージが可能になります：
0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor
0x00のパッド1が0x01 0x05のパッドN RPLターゲット0x06の交通情報0x09のRPLターゲット記述子
A special case of the DAO message, termed a No-Path, is used in Storing mode to clear Downward routing state that has been provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that Target.
DAOメッセージの特別な場合は、無パスと呼ばれる、DAO操作によってプロビジョニングされた下向きのルーティング状態をクリアするモードを保存に使用されます。無パスは、ターゲットオプションとそのターゲットへの到達性の喪失を示すために、0x00000000のの寿命と関連した交通情報オプションを運びます。
The DAO-ACK message is sent as a unicast packet by a DAO recipient (a DAO parent or DODAG root) in response to a unicast DAO message.
DAO-ACKメッセージは、ユニキャストDAOメッセージに応答して、DAOの受信者（DAO親またはDODAGルート）によってユニキャストパケットとして送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAGID is not always present, as described below.
「*」以下に説明するようにDODAGIDは、常に存在していないことを示しています。
Figure 17: The DAO ACK Base Object
図17：DAO ACK基本オブジェクト
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.
RPLInstanceID：DIOから学んだように、DODAGに関連付けられているトポロジインスタンスを示す8ビットのフィールド。
D: The 'D' flag indicates that the DODAGID field is present. This would typically only be set when a local RPLInstanceID is used.
D：「D」フラグはDODAGIDフィールドが存在することを示します。ローカルRPLInstanceIDが使用されているとき、これは一般的にのみ設定されます。
Reserved: The 7-bit field, reserved for flags.
予約：フラグのために予約さ7ビットのフィールド、。
DAOSequence: Incremented at each DAO message from a node, and echoed in the DAO-ACK by the recipient. The DAOSequence is used to correlate a DAO message and a DAO ACK message and is not to be confused with the Transit Information option Path Sequence that is associated to a given Target Down the DODAG.
DAOSequence：ノードから各DAOメッセージでインクリメントされ、受信者によってDAO-ACKでエコー。 DAOSequenceは、DAOメッセージとDAO ACKメッセージを相関させるために使用され、与えられたターゲットダウンDODAGに関連付けられているトランジット情報オプションのパスシーケンスと混同しないようにしています。
Status: Indicates the completion. Status 0 is defined as unqualified acceptance in this specification. The remaining status values are reserved as rejection codes. No rejection status codes are defined in this specification, although status codes SHOULD be allocated according to the following guidelines in future specifications:
ステータス：終了したことを示します。ステータス0は、この仕様で修飾されていない受諾として定義されます。残りのステータス値は、拒絶コードとして予約されています。ステータスコードは将来の仕様には、次のガイドラインに従って割り当てられるべきであるが全く拒絶反応の状態コードは、本明細書中で定義されていません。
0: Unqualified acceptance (i.e., the node receiving the
DAO-ACK is not rejected).
1-127: Not an outright rejection; the node sending the DAO-ACK is willing to act as a parent, but the receiving node is suggested to find and use an alternate parent instead. 127-255: Rejection; the node sending the DAO-ACK is unwilling to act as a parent.
1-127：未あからさまな拒否。 DAO-ACKを送信するノードは、親として機能する意思があるが、受信ノードではなく、代替親を見つけて使用することが提案されています。 127から255：拒絶。 DAO-ACKを送信するノードは、親としての役割を果たすために不本意です。
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field is only present when the 'D' flag is set. Typically, this field is only present when a local RPLInstanceID is in use in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use, this field need not be present.
DODAGID（オプション）：一意DODAGを識別するDODAGルートにより設定された128ビットの符号なし整数。 「D」フラグが設定されている場合、このフィールドにのみ存在します。ローカルRPLInstanceIDはRPLInstanceIDに関連付けられDODAGIDを識別するために使用されている場合、典型的には、このフィールドは存在しています。グローバルRPLInstanceIDが使用されている場合は、このフィールドが存在する必要はありません。
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
DAO-ACKベースの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
A Secure DAO-ACK message follows the format in Figure 7, where the base format is the DAO-ACK message shown in Figure 17.
セキュアDAO-ACKメッセージは、ベース・フォーマットは、図17に示すDAO-ACKメッセージである。図7において、フォーマットに従います。
This specification does not define any options to be carried by the DAO-ACK message.
この仕様は、DAO-ACKメッセージによって運ばれる任意のオプションを定義していません。
The CC message is used to check secure message counters and issue challenge-responses. A CC message MUST be sent as a secured RPL message.
CCメッセージは、安全なメッセージカウンタと発行チャレンジ応答をチェックするために使用されます。 CCメッセージは、セキュリティで保護された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 |R| Flags | CC Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 18: The CC Base Object
図18：CCベースオブジェクト
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.
RPLInstanceID：DIOから学んだように、DODAGに関連付けられているトポロジインスタンスを示す8ビットのフィールド。
R: The 'R' flag indicates whether the CC message is a response. A message with the 'R' flag cleared is a request; a message with the 'R' flag set is a response.
R「R」フラグは、CCメッセージが応答であるかどうかを示します。クリア「R」フラグを有するメッセージが要求です。 「R」フラグが設定されたメッセージが応答です。
Flags: The 7 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールド内の未使用の残りの7ビットは、フラグのために予約されています。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
CC Nonce: 16-bit unsigned integer set by a CC request. The corresponding CC response includes the same CC nonce value as the request.
CCナンス：CC要求により設定された16ビットの符号なし整数。対応CC応答は要求と同じCCのノンス値を含みます。
DODAGID: 128-bit field, contains the identifier of the DODAG root.
DODAGID：128ビットのフィールドは、DODAGルートの識別子が含まれています。
Destination Counter: 32-bit unsigned integer value indicating the sender's estimate of the destination's current security counter value. If the sender does not have an estimate, it SHOULD set the Destination Counter field to zero.
先カウンター：先の現在のセキュリティカウンタ値の送信者の推定値を示す32ビットの符号なし整数値。送信者が見積もりを持っていない場合、それはゼロに先カウンタフィールドを設定する必要があります。
Unassigned bits of the CC Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
CCベースの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The Destination Counter value allows new or recovered nodes to resynchronize through CC message exchanges. This is important to ensure that a Counter value is not repeated for a given security key even in the event of devices recovering from a failure that created a loss of Counter state. For example, where a CC request or other RPL message is received with an initialized counter within the message Security section, the provision of the Incoming Counter within the CC response message allows the requesting node to reset its Outgoing Counter to a value greater than the last value received by the responding node; the Incoming Counter will also be updated from the received CC response.
先のカウンタ値は、新規または回復したノードは、CCメッセージ交換を通じて再同期することができます。これは、カウンタ値が偶数カウンター状態の損失を作成し、障害からの回復のデバイスの場合に、特定のセキュリティキーのために繰り返されていないことを確認することが重要です。 CC要求または他のRPLメッセージがメッセージセキュリティセクション内で初期化カウンタで受信される場合、例えば、CC応答メッセージ内の受信カウンタを設けることは、要求ノードが最後より大きい値に、その送信カウンタをリセットすることができ応答ノードによって受信された値。受信カウンタは、受信したCC応答から更新されます。
This specification allows for the CC message to carry the following options:
この仕様は、以下のオプションを運ぶためのCCメッセージが可能になります：
0x00 Pad1 0x01 PadN
0x00の0x01のパッド1 PADN
RPL Control Message options all follow this format:
RPL制御メッセージのオプションはすべて、この形式に従います。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 19: RPL Option Generic Format
図19：RPLオプションの一般的なフォーマット
Option Type: 8-bit identifier of the type of option. The Option Type values are assigned by IANA (see Section 20.4.)
オプションタイプ：オプションのタイプの8ビットの識別子。オプションタイプの値はIANAによって割り当てられます（項20.4を参照してください。）
Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields.
オプション長さ：8ビットの符号なし整数、オプションのタイプと長さフィールドを含まないオプションのオクテットの長さを表します。
Option Data: A variable length field that contains data specific to the option.
オプションデータ：オプションに固有のデータが含まれている可変長フィールド。
When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in the message.
オプションタイプ値は、受信機によって認識されていないオプションを含むRPLメッセージを処理するとき、受信機は静かに認識できないオプションを無視し、正しくメッセージ内の任意の残りのオプションを処理し、次のオプションを処理し続けなければなりません。
RPL message options may have alignment requirements. Following the convention in IPv6, options with alignment requirements are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8).
RPLのメッセージオプションは、アライメント要件を有することができます。 IPv6における慣例以下、アラインメント要件にオプションは、パケットに配列されているような自然境界上の各オプションの秋のオプションデータフィールド内のマルチオクテットの値が（すなわち、幅nオクテットのフィールドは、nオクテットの整数倍で配置されていることヘッダの開始から、用のn = 1、2、4、または8）。
The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows:
パッド1オプションは、DIS、DIO、DAO、DAO-ACK、およびCCメッセージに存在していてもよく、以下のようにその形式は次のとおりです。
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0x00 |
+-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad1 Option
図20：パッド1オプションのフォーマット
The Pad1 option is used to insert a single octet of padding into the message to enable options alignment. If more than one octet of padding is required, the PadN option should be used rather than multiple Pad1 options.
パッド1のオプションは、オプションの位置合わせを可能にするために、メッセージにパディングの単一オクテットを挿入するために使用されます。パディングの複数のオクテットが必要な場合は、パッドNオプションではなく、複数のパッド1オプションよりも使用する必要があります。
NOTE! The format of the Pad1 option is a special case -- it has neither Option Length nor Option Data fields.
注意！パッド1オプションのフォーマットは、特殊なケースである - それはどちらもオプションの長さもオプションのデータフィールドがあります。
The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows:
パッドNオプションはDIS、DIO、DAO、DAO-ACK、およびCCメッセージに存在していてもよく、以下のようにその形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x01 | Option Length | 0x00 Padding...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 21: Format of the Pad N Option
図21：パッドNオプションのフォーマット
The PadN option is used to insert two or more octets of padding into the message to enable options alignment. PadN option data MUST be ignored by the receiver.
パッドNオプションは、オプションの位置合わせを可能にするために、メッセージにパディングの2つの以上のオクテットを挿入するために使用されます。パッドNオプションデータは、受信機で無視しなければなりません。
Option Type: 0x01
オプションタイプ：0×01
Option Length: For N octets of padding, where 2 <= N <= 7, the Option Length field contains the value N-2. An Option Length of 0 indicates a total padding of 2 octets. An Option Length of 5 indicates a total padding of 7 octets, which is the maximum padding size allowed with the PadN option.
オプション長さ：パディングのNオクテットのために、ここで、2 <= N <= 7、オプション長フィールドは値N-2を含んでいます。 0のオプションの長さは2つのオクテットの総数パディングを示しています。 5のオプションの長さは、パッドNオプションで許容される最大パディングサイズである7つのオクテットの総数パディングを示しています。
Option Data: For N (N > 1) octets of padding, the Option Data consists of N-2 zero-valued octets.
オプションデータは：パディングのN（N> 1）のオクテットは、オプションデータは、N-2ゼロ値のオクテットで構成されています。
The DAG Metric Container option MAY be present in DIO or DAO messages, and its format is as follows:
DAGメトリックコンテナオプションは、DIOまたはDAOのメッセージに存在していてもよく、以下のようにその形式は次のとおりです。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x02 | Option Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 22: Format of the DAG Metric Container Option
図22：DAGメトリックコンテナオプションのフォーマット
The DAG Metric Container is used to report metrics along the DODAG. The DAG Metric Container may contain a number of discrete node, link, and aggregate path metrics and constraints specified in [RFC6551] as chosen by the implementer.
DAGメトリックコンテナDODAGに沿ってメトリックを報告するために使用されます。 DAGメトリックコンテナは、別個のノード、リンク、および集約パスメトリックと実装者によって選択されたように[RFC6551]で指定された制約の数を含んでいてもよいです。
The DAG Metric Container MAY appear more than once in the same RPL control message, for example, to accommodate a use case where the Metric Data is longer than 256 bytes. More information is in [RFC6551].
DAGメトリックコンテナメトリックデータが256バイト以上であるユースケースに対応するために、例えば、同じRPL制御メッセージに複数回表示されることがあります。詳しくは、[RFC6551]です。
The processing and propagation of the DAG Metric Container is governed by implementation specific policy functions.
DAGメトリック容器の処理及び伝播は、実装固有のポリシー関数によって支配されます。
Option Type: 0x02
オプションタイプ：0×02
Option Length: The Option Length field contains the length in octets of the Metric Data.
オプションの長さ：オプション長フィールドはメトリックデータのオクテットの長さが含まれています。
Metric Data: The order, content, and coding of the DAG Metric Container data is as specified in [RFC6551].
メトリックデータ：[RFC6551]で指定されるように順番、コンテンツ、およびDAGメトリックコンテナデータの符号化があります。
The Route Information Option (RIO) MAY be present in DIO messages, and it carries the same information as the IPv6 Neighbor Discovery (ND) RIO as defined in [RFC4191]. The root of a DODAG is authoritative for setting that information and the information is unchanged as propagated down the DODAG. A RPL router may trivially transform it back into an ND option to advertise in its own RAs so a node attached to the RPL router will end up using the DODAG for which the root has the best preference for the destination of a packet. In addition to the existing ND semantics, it is possible for an Objective Function to use this information to favor a DODAG whose root is most preferred for a specific destination. The format of the option is modified slightly (Type, Length, Prefix) in order to be carried as a RPL option as follows:
ルート情報オプション（RIO）はDIOメッセージ中に存在してもよく、それは、[RFC4191]で定義されたIPv6近隣探索（ND）RIOと同じ情報を運びます。 DODAGの根はその情報を設定するための権限を持っているとDODAGを下に伝播するような情報は変更されません。 RPLルータは自明ので、RPLルータに接続されたノードがルートは、パケットの宛先のための最良の好みを持っているDODAGを使用して終了します、独自のRAに宣伝するためNDオプションに戻ってそれを変換することができます。目的関数は、ルートの特定の宛先のための最も好ましいDODAGを支持するために、この情報を使用するため、既存のNDセマンティクスに加えて、それが可能です。オプションのフォーマットは次のようにRPLオプションとして実施されるためにわずかに（タイプ、長さ、プレフィックス）修正されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x03 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Prefix (Variable Length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: Format of the Route Information Option
図23：ルート情報オプションのフォーマット
The RIO is used to indicate that connectivity to the specified destination prefix is available from the DODAG root.
RIOは、指定した宛先プレフィックスにその接続性を示すために使用されるDODAGのルートから入手可能です。
In the event that a RPL control message may need to specify connectivity to more than one destination, the RIO may be repeated.
RPL制御メッセージが複数の宛先への接続を指定する必要があるかもしれないこと場合に、RIOを繰り返すことができます。
[RFC4191] should be consulted as the authoritative reference with respect to the RIO. The field descriptions are transcribed here for convenience:
[RFC4191]はRIOに対する権限の基準と相談すべきです。フィールドの説明は、便宜上、ここで転写されています。
Option Type: 0x03
オプションタイプ：0×03
Option Length: Variable, length of the option in octets excluding the Type and Length fields. Note that this length is expressed in units of single octets, unlike in IPv6 ND.
オプション長：変数、タイプと長さフィールドを除くオクテット内のオプションの長さ。 IPv6のNDとは異なり、この長さは単一オクテット単位で表されることに留意されたいです。
Prefix Length: 8-bit unsigned integer. The number of leading bits in the prefix that are valid. The value ranges from 0 to 128. The Prefix field has the number of bytes inferred from the Option Length field, that must be at least the Prefix Length. Note that in RPL, this means that the Prefix field may have lengths other than 0, 8, or 16.
プレフィックス長：8ビットの符号なし整数。有効な接頭辞の一流のビット数。値は、プレフィックスフィールドは、少なくともプレフィックス長でなければならないオプション長フィールドから推測されたバイト数を有して0から128の範囲です。 RPLに、このプレフィックスフィールドが8、又は16、0以外の長さを有していてもよいことを意味することに留意されたいです。
Prf: 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. If the Reserved (10) value is received, the RIO MUST be ignored. Per [RFC4191], the Reserved (10) value MUST NOT be sent. ([RFC4191] restricts the Preference to just three values to reinforce that it is not a metric.)
PRF：2ビット符号付き整数。ルート設定は（異なるルータの）複数の同一のプレフィックスが受信された他のものの上にこのプレフィックスに関連付けられているルータを好むかどうかを示します。予約（10）値を受信した場合、RIOは無視しなければなりません。 [RFC4191]、予約（10）値を送信してはいけません。 （[RFC4191]は、それがメトリックではないことを強化するために、わずか3の値に優先を制限します）。
Resvd: Two 3-bit unused fields. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Resvd：2つの3ビットの未使用フィールド。彼らは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Route Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xFFFFFFFF) represents infinity.
ルートの有効期間：32ビット符号なし整数。プレフィクスがルート決意のために有効である（パケットが送信される時刻に対する）秒単位の時間の長さ。全ての1つのビットの値（0xFFFFFFFFの）は無限を表します。
Prefix: Variable-length field containing an IP address or a prefix of an IPv6 address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero by the sender and ignored by the receiver. Note that in RPL, this field may have lengths other than 0, 8, or 16.
接頭辞：IPアドレスまたはIPv6アドレスのプレフィックスを含む可変長フィールド。プレフィックス長フィールドはプレフィックスに有効な先行ビットの数が含まれています。プレフィックス長（もしあれば）の後プレフィックスのビットは予約されており、送信者によってゼロに初期化し、受信機で無視しなければなりません。 RPLに、このフィールドは8、又は16、0以外の長さを有することができることに留意されたいです。
Unassigned bits of the RIO are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
RIOの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The DODAG Configuration option MAY be present in DIO messages, and its format is as follows:
DODAG設定オプションは、DIOメッセージ中に存在することができる、と次のようにその形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| Flags |A| PCS | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankIncrease |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinHopRankIncrease | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Def. Lifetime | Lifetime Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Format of the DODAG Configuration Option
図24：DODAG設定オプションのフォーマット
The DODAG Configuration option is used to distribute configuration information for DODAG Operation through the DODAG.
DODAG設定オプションがDODAGを通じてDODAG操作の構成情報を配布するために使用されます。
The information communicated in this option is generally static and unchanging within the DODAG, therefore it is not necessary to include in every DIO. This information is configured at the DODAG root and distributed throughout the DODAG with the DODAG Configuration option. Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option. This option MAY be included occasionally by the DODAG root (as determined by the DODAG root), and MUST be included in response to a unicast request, e.g. a unicast DODAG Information Solicitation (DIS) message.
このオプションで通信される情報は、したがって、すべてのDIOに含める必要はなく、DODAG内概して静的で不変です。この情報はDODAGのルートに設定され、DODAG設定オプションを指定してDODAG全体に分散されます。 DODAG設定オプションを伝播する際DODAGルート以外のノードは、この情報を変更してはいけません。このオプションは、（DODAGルートによって決定される）DODAGルートによって時折含まれてもよく、例えば、ユニキャスト要求に対する応答に含まれなければなりませんユニキャストDODAG情報要請（DIS）メッセージ。
Option Type: 0x04
オプションタイプ：0×04
Option Length: 14
オプションの長さ：14
Flags: The 4-bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールド内の未使用の残りの4ビットは、フラグのために予約されています。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Authentication Enabled (A): 1-bit flag describing the security mode of the network. The bit describes whether a node must authenticate with a key authority before joining the network as a router. If the DIO is not a secure DIO, the 'A' bit MUST be zero.
認証有効（A）：ネットワークのセキュリティモードを記述する1ビットのフラグ。ビットは、ノードがルータなどのネットワークに参加する前に、キーの権限を認証する必要があるかどうかについて説明します。 DIOが安全DIOない場合、「」ビットはゼロでなければなりません。
Path Control Size (PCS): 3-bit unsigned integer used to configure the number of bits that may be allocated to the Path Control field (see Section 9.9). Note that when PCS is consulted to determine the width of the Path Control field, a value of 1 is added, i.e., a PCS value of 0 results in 1 active bit in the Path Control field. The default value of PCS is DEFAULT_PATH_CONTROL_SIZE.
経路制御サイズ（PCS）：経路制御フィールドに割り当てられるビット数を設定するために使用される3ビットの符号なし整数（セクション9.9を参照）。 PCSは、パス制御フィールドの幅を決定するために参照される場合、1の値が加算されることに注意し、経路制御フィールドの1アクティブビットにおける0の結果、すなわち、PCS値。 PCSのデフォルト値はDEFAULT_PATH_CONTROL_SIZEです。
DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax of the DIO Trickle timer (see Section 8.3.1). The default value of DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.
DIOIntervalDoublings：DIOトリクルタイマの値Imaxを設定するために使用される8ビットの符号なし整数（セクション8.3.1を参照）。 DIOIntervalDoublingsのデフォルト値はDEFAULT_DIO_INTERVAL_DOUBLINGSです。
DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the DIO Trickle timer (see Section 8.3.1). The default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.
DIOIntervalMin：DIOトリクルタイマの値Iminを設定するために使用される8ビットの符号なし整数（セクション8.3.1を参照）。 DIOIntervalMinのデフォルト値はDEFAULT_DIO_INTERVAL_MINです。
DIORedundancyConstant: 8-bit unsigned integer used to configure k of the DIO Trickle timer (see Section 8.3.1). The default value of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT.
DIORedundancyConstant：DIOトリクルタイマーのKを構成するために使用される8ビットの符号なし整数（セクション8.3.1を参照）。 DIORedundancyConstantのデフォルト値はDEFAULT_DIO_REDUNDANCY_CONSTANTです。
MaxRankIncrease: 16-bit unsigned integer used to configure DAGMaxRankIncrease, the allowable increase in Rank in support of local repair. If DAGMaxRankIncrease is 0, then this mechanism is disabled.
MaxRankIncrease：DAGMaxRankIncrease、地元の修理のサポートでランク許容上昇を構成するために使用される16ビットの符号なし整数。 DAGMaxRankIncreaseが0である場合、このメカニズムが無効になっています。
MinHopRankIncrease: 16-bit unsigned integer used to configure MinHopRankIncrease as described in Section 3.5.1. The default value of MinHopRankInc is DEFAULT_MIN_HOP_RANK_INCREASE.
MinHopRankIncrease：セクション3.5.1で説明したようにMinHopRankIncreaseを構成するために使用される16ビットの符号なし整数。 MinHopRankIncのデフォルト値はDEFAULT_MIN_HOP_RANK_INCREASEです。
Objective Code Point (OCP): 16-bit unsigned integer. The OCP field identifies the OF and is managed by the IANA.
目的コードポイント（OCP）：16ビット符号なし整数。 OCPフィールドがOF識別し、IANAによって管理されています。
Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
予約：7ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Default Lifetime: 8-bit unsigned integer. This is the lifetime that is used as default for all RPL routes. It is expressed in units of Lifetime Units, e.g., the default lifetime in seconds is (Default Lifetime) * (Lifetime Unit).
デフォルトの有効期間：8ビットの符号なし整数。これは、すべてのRPLルートのデフォルトとして使用される寿命です。それは、生涯単位の単位で表され、例えば、秒のデフォルトの有効期間は、（デフォルトのライフタイム）*（生涯単位）です。
Lifetime Unit: 16-bit unsigned integer. Provides the unit in seconds that is used to express route lifetimes in RPL. For very stable networks, it can be hours to days.
生涯単位：16ビットの符号なし整数。 RPLにルートの寿命を表現するために使用されている秒の単位を提供します。非常に安定したネットワークの場合、それは数時間から数日することができます。
The RPL Target option MAY be present in DAO messages, and its format is as follows:
RPLターゲットオプションは、DAOメッセージ中に存在することができる、と次のようにその形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Target Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Format of the RPL Target Option
図25：RPLターゲットオプションのフォーマット
The RPL Target option is used to indicate a Target IPv6 address, prefix, or multicast group that is reachable or queried along the DODAG. In a DAO, the RPL Target option indicates reachability.
RPLターゲットオプションが到達可能かDODAGに沿って、照会されたターゲットのIPv6アドレス、プレフィックス、またはマルチキャストグループを示すために使用されます。 DAOでは、RPLターゲットオプションは、到達可能性を示しています。
A RPL Target option MAY optionally be paired with a RPL Target Descriptor option (Figure 30) that qualifies the target.
RPLターゲットオプションは、必要に応じてターゲットを修飾RPLターゲット記述子オプション（図30）と対にされるかもしれません。
A set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target options in a DAO message (where each Target option MAY be paired with a RPL Target Descriptor option as above). The structure of the DAO message, detailing how Target options are used in conjunction with Transit Information options is further described in Section 9.4.
一つ以上の交通情報オプション（セクション6.7.8）のセットは、直接（各ターゲットオプションは、上記のようにRPLターゲット記述子オプションと対にすることができる）DAOメッセージ内の1つまたは複数のターゲット・オプションのセットに従うことができます。ターゲットオプションは交通情報オプションと一緒に使用される方法を詳細DAOメッセージの構造は、さらに、セクション9.4に記載されています。
The RPL Target option may be repeated as necessary to indicate multiple targets.
RPLターゲットオプションは、複数のターゲットを示すために、必要に応じて繰り返すことができます。
Option Type: 0x05
オプションタイプ：0×05
Option Length: Variable, length of the option in octets excluding the Type and Length fields.
オプション長：変数、タイプと長さフィールドを除くオクテット内のオプションの長さ。
Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：フラグのために予約さ8ビットの未使用フィールド。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Prefix Length: 8-bit unsigned integer. Number of valid leading bits in the IPv6 Prefix.
プレフィックス長：8ビットの符号なし整数。 IPv6のプレフィックスで有効な先行ビットの数。
Target Prefix: Variable-length field identifying an IPv6 destination address, prefix, or multicast group. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be set to zero on transmission and MUST be ignored on receipt.
ターゲットプレフィックス：可変長フィールドは、IPv6宛先アドレス、プレフィックス、又はマルチキャストグループを識別する。プレフィックス長フィールドはプレフィックスに有効な先行ビットの数が含まれています。プレフィックス長の後にプレフィックスのビット（もしあれば）が予約されており、変速機にゼロに設定しなければならなくて、領収書の上で無視しなければなりません。
The Transit Information option MAY be present in DAO messages, and its format is as follows:
交通情報オプションは、DAOメッセージ中に存在することができる、と次のようにその形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Option Length |E| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Parent Address* +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAG Parent Address subfield is not always present, as described below.
「*」以下に説明するようにDODAGの親アドレスサブフィールドは、常に存在していないことを示しています。
Figure 26: Format of the Transit Information Option
図26：交通情報オプションのフォーマット
The Transit Information option is used for a node to indicate attributes for a path to one or more destinations. The destinations are indicated by one or more Target options that immediately precede the Transit Information option(s).
交通情報オプションは、1つの以上の宛先へのパスの属性を示すためにノードのために使用されています。目的地は、すぐに交通情報オプション（複数可）を先行する1つまたは複数のターゲットオプションで表示されます。
The Transit Information option can be used for a node to indicate its DODAG parents to an ancestor that is collecting DODAG routing information, typically, for the purpose of constructing source routes. In the Non-Storing mode of operation, this ancestor will be the DODAG root, and this option is carried by the DAO message. In the Storing mode of operation, the DODAG Parent Address subfield is not needed, since the DAO message is sent directly to the parent. The option length is used to determine whether or not the DODAG Parent Address subfield is present.
交通情報オプションは、ソースルートを構築するために、典型的には、DODAGルーティング情報を収集している祖先へのDODAGの親を示すためにノードのために使用することができます。操作の非保存モードでは、この祖先はDODAGルートとなり、このオプションはDAOメッセージによって運ばれます。 DAOメッセージが親に直接送信されるので、操作の保存モードでは、DODAG親アドレスサブフィールドは、必要とされていません。オプションの長さはDODAG親アドレスサブフィールドが存在するか否かを決定するために使用されます。
A non-storing node that has more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing destination advertisement operation. The node may distribute the bits in the Path Control field among different groups of DAO parents in order to signal a preference among parents. That preference may influence the decision of the DODAG root when selecting among the alternate parents/paths for constructing Downward routes.
複数のDAOの親を持つ非保存ノードは非保存先の広告操作の一部として、各DAOの親のための交通情報オプションを含むかもしれません。ノードは、親の間で優先度を知らせるために、DAOの親の異なるグループ間のパス制御フィールド内のビットを分配することができます。下向きの経路を構築するための代替的な親/パス間で選択する際にその嗜好はDODAGルートの決定に影響を与え得ます。
One or more Transit Information options MUST be preceded by one or more RPL Target options. In this manner, the RPL Target option indicates the child node, and the Transit Information option(s) enumerates the DODAG parents. The structure of the DAO message, further detailing how Target options are used in conjunction with Transit Information options, is further described in Section 9.4.
一つ以上のトランジット情報オプションは、一つ以上のRPLターゲットオプションを付けなければなりません。このように、RPLターゲットオプションは、子ノードを示し、トランジット情報オプション（複数可）DODAGの両親を列挙します。さらに、標的オプションは交通情報オプションと一緒に使用される方法を詳細DAOメッセージの構造は、さらに、セクション9.4に記載されています。
A typical non-storing node will use multiple Transit Information options, and it will send the DAO message thus formed directly to the root. A typical storing node will use one Transit Information option with no parent field and will send the DAO message thus formed, with additional adjustments, to Path Control as detailed later, to one or multiple parents.
典型的な非記憶ノードは、複数の交通情報オプションを使用し、従って、ルートに直接形成されたDAOメッセージを送信します。典型的な蓄積ノードは、親を持たないフィールドと1つのトランジット情報オプションを使用すると、1または複数の親に、後述するようにパス制御に、さらに調整して、このように形成されたDAOメッセージを送信します。
For example, in a Non-Storing mode of operation let Tgt(T) denote a Target option for a Target T. Let Trnst(P) denote a Transit Information option that contains a parent address P. Consider the case of a non-storing Node N that advertises the self-owned targets N1 and N2 and has parents P1, P2, and P3. In that case, the DAO message would be expected to contain the sequence ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), such that the group of Target options {N1, N2} is described by the Transit Information options as having the parents {P1, P2, P3}. The non-storing node would then address that DAO message directly to the DODAG root and forward that DAO message through one of the DODAG parents: P1, P2, or P3.
例えば、操作の非保存モードでターゲットT.レッツTrnst（P）は、Pは、非保存の場合を考えてみましょう親アドレスが含まれているトランジット情報オプションを示すためにTGT（T）がターゲットオプションを示してみましょう自己所有のターゲットN1およびN2をアドバタイズし、両親のP1、P2、およびP3を持っているノードN。その場合、DAOメッセージは、シーケンス（（TGT（N1）、TGT（N2））、（Trnst（P1）、Trnst（P2）、Trnst（P3）は））のようなその基を含有することが予想されますターゲットオプション{N1、N2は}親{P1、P2、P3}を有するものとして交通情報オプションによって記述されます。非記憶ノードは、DODAGルートに直接そのDAOメッセージに対処し、DODAGの親の1つを介してそのDAOメッセージを転送します：P1、P2、またはP3。
Option Type: 0x06
オプションタイプ：0x06で
Option Length: Variable, depending on whether or not the DODAG Parent Address subfield is present.
オプション長：可変、DODAGの親アドレスサブフィールドが存在するか否かによって異なります。
External (E): 1-bit flag. The 'E' flag is set to indicate that the parent router redistributes external targets into the RPL network. An external Target is a Target that has been learned through an alternate protocol. The external targets are listed in the Target options that immediately precede the Transit Information option. An external Target is not expected to support RPL messages and options.
外部の（E）：1ビットのフラグ。 「E」フラグは、親ルータがRPLネットワークに外部の目標を再分配することを示すために設定されています。外部ターゲットは、代替プロトコルを介して学習された標的です。外部ターゲットはすぐに交通情報オプションの前にターゲットオプションに記載されています。外部のターゲットは、RPLメッセージとオプションをサポートすることが期待されていません。
Flags: The 7 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールド内の未使用の残りの7ビットは、フラグのために予約されています。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Path Control: 8-bit bit field. The Path Control field limits the number of DAO parents to which a DAO message advertising connectivity to a specific destination may be sent, as well as providing some indication of relative preference. The limit provides some bound on overall DAO message fan-out in the LLN. The assignment and ordering of the bits in the Path Control also serves to communicate preference. Not all of these bits may be enabled as according to the PCS in the DODAG Configuration. The Path Control field is divided into four subfields that contain two bits each: PC1, PC2, PC3, and PC4, as illustrated in Figure 27. The subfields are ordered by preference, with PC1 being the most preferred and PC4 being the least preferred. Within a subfield, there is no order of preference. By grouping the parents (as in ECMP) and ordering them, the parents may be associated with specific bits in the Path Control field in a way that communicates preference.
パス制御：8ビットのビットフィールド。経路制御フィールドは、DAOの親の数を制限し、特定の宛先へのDAOメッセージ広告接続は相対的嗜好のいくつかの指標を提供するだけでなく、送信されてもよいれます。制限はLLNにおける全体的なDAOメッセージファンアウトにバインドされ、いくつかを提供します。経路制御のビットの割り当て及び順序も好みを伝えるのに役立ちます。これらのビットのすべてがDODAG設定でPCSに応じて有効にすることができるわけではありません。 PC1が最も好ましいとPC4は少なくとも好適であると、サブフィールドを優先順に並べられ、図27に示すように、PC1、PC2、PC3、およびPC4：パス制御フィールドは2ビットをそれぞれ含む4つのサブフィールドに分割されます。サブフィールド内で、優先順位の何もありません。 （ECMPのように）親をグループ化し、それらを注文することによって、親は、優先通信を行うように経路制御フィールド内の特定のビットに関連付けることができます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding
図27：パス制御優先サブフィールドのエンコーディング
Path Sequence: 8-bit unsigned integer. When a RPL Target option is issued by the node that owns the Target prefix (i.e., in a DAO message), that node sets the Path Sequence and increments the Path Sequence each time it issues a RPL Target option with updated information.
パスシーケンス：8ビットの符号なし整数。 RPLターゲットオプション（すなわち、DAOメッセージで）ターゲットプレフィックスを所有しているノードによって発行されると、そのノードは、パスシーケンスを設定し、それが更新情報をRPLターゲットオプションを発行するたびにパスシーケンスをインクリメントします。
Path Lifetime: 8-bit unsigned integer. The length of time in Lifetime Units (obtained from the Configuration option) that the prefix is valid for route determination. The period starts when a new Path Sequence is seen. A value of all one bits (0xFF) represents infinity. A value of all zero bits (0x00) indicates a loss of reachability. A DAO message that contains a Transit Information option with a Path Lifetime of 0x00 for a Target is referred as a No-Path (for that Target) in this document.
パスの有効期間：8ビットの符号なし整数。プレフィクスがルート決意のために有効であること（構成オプションから得た）生涯単位の時間の長さ。新しいパスのシーケンスが見られたときに期間が開始します。全ての1つのビットの値（0xFFでは）無限を表します。すべてのゼロ・ビット（0×00）の値は、到達可能性の損失を示します。ターゲットのための$ 00のパスの有効期間とトランジット情報オプションが含まれているDAOメッセージは、この文書に記載されている（その目標のために）ノー・パスと呼ばれています。
Parent Address (optional): IPv6 address of the DODAG parent of the node originally issuing the Transit Information option. This field may not be present, as according to the DODAG Mode of Operation (Storing or Non-Storing) and indicated by the Transit Information option length.
親アドレス（オプション）：もともと交通情報オプションを発行したノードのDODAG親のIPv6アドレス。このフィールドはDODAG動作モード（記憶または非記憶）に応じて交通情報オプションの長さによって示されるように、存在しなくてもよいです。
Unassigned bits of the Transit Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
交通情報オプションの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The Solicited Information option MAY be present in DIS messages, and its format is as follows:
要請情報オプションは、DISメッセージ中に存在することができる、と次のようにその形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+
Figure 28: Format of the Solicited Information Option
図28：要請情報オプションのフォーマット
The Solicited Information option is used for a node to request DIO messages from a subset of neighboring nodes. The Solicited Information option may specify a number of predicate criteria to be matched by a receiving node. This is used by the requester to limit the number of replies from "non-interesting" nodes. These predicates affect whether a node resets its DIO Trickle timer, as described in Section 8.3.
希望情報オプションは、近隣ノードのサブセットからDIOメッセージを要求するノードのために使用されます。希望情報オプションは、受信ノードにマッチする述語基準の数を指定することができます。これは、「非対象」ノードからの応答の数を制限するためにリクエスタによって使用されます。これらの述語は、8.3節で説明したように、ノードが、そのDIOトリクルタイマーをリセットするかどうかに影響します。
The Solicited Information option contains flags that indicate which predicates a node should check when deciding whether to reset its Trickle timer. A node resets its Trickle timer when all predicates are true. If a flag is set, then the RPL node MUST check the associated predicate. If a flag is cleared, then the RPL node MUST NOT check the associated predicate. (If a flag is cleared, the RPL node assumes that the associated predicate is true.)
要請情報オプションは、そのトリクルタイマーをリセットするかどうかを決定する際にチェックすべきノードを述語かを示すフラグが含まれています。すべての述語が真である場合、ノードは、そのトリクルタイマーをリセットします。フラグが設定されている場合、RPLノードは、関連する述語をチェックしなければなりません。フラグがクリアされている場合は、RPLノードは、関連する述語をチェックしてはなりません。 （フラグがクリアされている場合、RPLノードは、関連する述語が真であると仮定します）。
Option Type: 0x07
オプションタイプ：0x07の
Option Length: 19
オプションの長さ：19
V: The 'V' flag is the Version predicate. The Version predicate is true if the receiver's DODAGVersionNumber matches the requested Version Number. If the 'V' flag is cleared, then the Version field is not valid and the Version field MUST be set to zero on transmission and ignored upon receipt.
V：「V」フラグがバージョン述語です。受信者のDODAGVersionNumberは、要求されたバージョン番号と一致した場合にバージョン述語が真です。 「V」フラグがクリアされている場合は、バージョンフィールドが有効でないとバージョンフィールドは、送信時にゼロに設定し、受信時に無視しなければなりません。
I: The 'I' flag is the InstanceID predicate. The InstanceID predicate is true when the RPL node's current RPLInstanceID matches the requested RPLInstanceID. If the 'I' flag is cleared, then the RPLInstanceID field is not valid and the RPLInstanceID field MUST be set to zero on transmission and ignored upon receipt.
I：「I」フラグはインスタンスID述語です。 RPLノードの現在のRPLInstanceIDが要求RPLInstanceIDと一致したときにインスタンスID述語が真です。 「I」フラグがクリアされている場合、RPLInstanceIDフィールドが有効でないとRPLInstanceIDフィールドは、送信時にゼロに設定し、受信時に無視しなければなりません。
D: The 'D' flag is the DODAGID predicate. The DODAGID predicate is true if the RPL node's parent set has the same DODAGID as the DODAGID field. If the 'D' flag is cleared, then the DODAGID field is not valid and the DODAGID field MUST be set to zero on transmission and ignored upon receipt.
D：「D」フラグはDODAGID述語です。 RPLノードの親セットはDODAGIDフィールドと同じDODAGIDを持っている場合DODAGID述語が真です。 「D」フラグがクリアされている場合は、DODAGIDフィールドが有効でないとDODAGIDフィールドは、送信時にゼロに設定し、受信時に無視しなければなりません。
Flags: The 5 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールド内の未使用の残りの5ビットは、フラグのために予約されています。フィールドは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Version Number: 8-bit unsigned integer containing the value of DODAGVersionNumber that is being solicited when valid.
バージョン番号：有効な勧誘されているDODAGVersionNumberの値を含む8ビットの符号なし整数。
RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID that is being solicited when valid.
RPLInstanceID：有効要請されているRPLInstanceIDを含む8ビット符号なし整数。
DODAGID: 128-bit unsigned integer containing the DODAGID that is being solicited when valid.
DODAGID：有効要請されているDODAGIDを含む128ビットの符号なし整数。
Unassigned bits of the Solicited Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
要請情報オプションの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The Prefix Information Option (PIO) MAY be present in DIO messages, and carries the information that is specified for the IPv6 ND Prefix Information option in [RFC4861], [RFC4862], and [RFC6275] for use by RPL nodes and IPv6 hosts. In particular, a RPL node may use this option for the purpose of Stateless Address Autoconfiguration (SLAAC) from a prefix advertised by a parent as specified in [RFC4862], and
プレフィックス情報オプション（PIO）は、DIOメッセージ中に存在すること、およびRPLノードとIPv6ホストが使用するために[RFC4861]、[RFC4862]及び[RFC6275]でのIPv6 NDプレフィックス情報オプションに指定された情報を搬送するかもしれません。具体的には、RPLのノードは、[RFC4862]で指定された親によってアドバタイズプレフィックスからステートレスアドレス自動設定（SLAAC）の目的のために、このオプションを使用することができ、そして
advertise its own address as specified in [RFC6275]. The root of a DODAG is authoritative for setting that information. The information is propagated down the DODAG unchanged, with the exception that a RPL router may overwrite the Interface ID if the 'R' flag is set to indicate its full address in the PIO. The format of the option is modified (Type, Length, Prefix) in order to be carried as a RPL option as follows:
[RFC6275]で指定されるように、自身のアドレスをアドバタイズします。 DODAGの根はその情報を設定するための権威です。情報は、「R」フラグがPIOでの完全なアドレスを示すように設定されている場合RPLルータがインタフェースIDを上書きすることができることを除いて、不変DODAGダウン伝播されます。オプションのフォーマットは次のようにRPLオプションとして実施されるために（タイプ、長さ、プレフィックス）が修正されます。
If the only desired effect of a received PIO in a DIO is to provide the global address of the parent node to the receiving node, then the sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon receipt, the RPL will not autoconfigure an address or a connected route from the prefix [RFC4862]. As in all cases, when the 'L' bit is not set, the RPL node MAY include the prefix in PIOs it sends to its children.
DIOにおける受信PIOのみ、所望の効果が受信ノードに対する親ノードのグローバルアドレスを提供することである場合、送信者は「A」と「L」ビットをリセットして「R」ビットをセットします。受信すると、RPLは、アドレスまたはプレフィックス[RFC4862]から接続されたルートを自動設定しないであろう。すべてのケースのように、「L」ビットが設定されていない場合、RPLノードは、それがその子に送信するのPIOでの接頭辞を含むかもしれません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: Format of the Prefix Information Option
図29：プレフィックス情報オプションのフォーマット
The PIO may be used to distribute the prefix in use inside the DODAG, e.g., for address autoconfiguration.
PIOは、アドレス自動設定のために、例えば、DODAG内部使用にプレフィックスを配布するために使用されてもよいです。
[RFC4861] and [RFC6275] should be consulted as the authoritative reference with respect to the PIO. The field descriptions are transcribed here for convenience:
[RFC4861]及び[RFC6275]はPIOに対する権限の基準として参考にされるべきです。フィールドの説明は、便宜上、ここで転写されています。
Option Type: 0x08
オプションタイプ：0×08
Option Length: 30. Note that this length is expressed in units of single octets, unlike in IPv6 ND.
オプション長さ：この長さは、IPv6 NDとは異なり、単一オクテット単位で表される30注意。
Prefix Length: 8-bit unsigned integer. The number of leading bits in the Prefix field that are valid. The value ranges from 0 to 128. The Prefix Length field provides necessary information for on-link determination (when combined with the 'L' flag in the PIO). It also assists with address autoconfiguration as specified in [RFC4862], for which there may be more restrictions on the prefix length.
プレフィックス長：8ビットの符号なし整数。有効な接頭辞分野のリーディングビット数。値は0から128にプレフィックス長フィールドは（PIOに「L」フラグと組み合わせて）オンリンク決意するために必要な情報を提供する範囲です。また、プレフィクス長の詳細な制限がある場合があるため、[RFC4862]で指定されたアドレスの自動設定、を支援します。
L: 1-bit on-link flag. When set, it indicates that this prefix can be used for on-link determination. When not set, the advertisement makes no statement about on-link or off-link properties of the prefix. In other words, if the 'L' flag is not set, a RPL node MUST NOT conclude that an address derived from the prefix is off-link. That is, it MUST NOT update a previous indication that the address is on-link. A RPL node acting as a router MUST NOT propagate a PIO with the 'L' flag set. A RPL node acting as a router MAY propagate a PIO with the 'L' flag not set.
L：1ビットのオンリンクフラグ。設定した場合、それはこのプレフィックスがオンリンク決意のために使用することができることを示しています。設定されていない場合は、広告は接頭辞の性質リンク・オンまたはオフリンクについての声明を行うものではありません。 「L」フラグがセットされていない場合、換言すれば、RPLノードがプレフィックスに由来するアドレスがオフリンクであると結論してはいけません。つまり、アドレスがオンリンクであることを以前の表示をアップデートしてはいけません、です。ルータとして動作するRPLノードは、「L」フラグを設定してPIOを伝播してはなりません。ルータとして動作するRPLノードは、「L」フラグが設定されていないとPIOを伝搬することができます。
A: 1-bit autonomous address-configuration flag. When set, it indicates that this prefix can be used for stateless address configuration as specified in [RFC4862]. When both protocols (ND RAs and RPL DIOs) are used to carry PIOs on the same link, it is possible to use either one for SLAAC by a RPL node. It is also possible to make either protocol ineligible for SLAAC operation by forcing the 'A' flag to 0 for PIOs carried in that protocol.
：1ビットの自律アドレス設定フラグ。設定した場合、それは[RFC4862]で指定されるように、このプレフィックスはステートレスアドレス構成のために使用することができることを示しています。両方のプロトコル（NDのRASおよびRPLのDIO）は、同じリンク上のPIOを運ぶために使用される場合、RPLノードによってSLAACためのいずれかを使用することが可能です。そのプロトコルで運ばのPIO 0に「」フラグを強制することによってSLAAC動作のためのいずれかのプロトコル不適格にすることも可能です。
R: 1-bit router address flag. When set, it indicates that the Prefix field contains a complete IPv6 address assigned to the sending router that can be used as parent in a target option. The indicated prefix is the first prefix length bits of the Prefix field. The router IPv6 address has the same scope and conforms to the same lifetime values as the advertised prefix. This use of the Prefix field is compatible with its use in advertising the prefix itself, since Prefix Advertisement uses only the leading bits. Interpretation of this flag bit is thus independent of the processing required for the on-link (L) and autonomous address-configuration (A) flag bits.
R：1ビットルータのアドレスフラグ。設定した場合、それはPrefixフィールドがターゲットオプションで親として使用することができ、送信ルータに割り当てられ、完全なIPv6アドレスが含まれていることを示しています。示されたプレフィックスがプレフィックスフィールドの最初のプレフィックス長ビットです。ルーターのIPv6アドレスが同じスコープを持ち、広告を出して接頭辞と同じ寿命値に準拠しています。プレフィックス広告が唯一の先行ビットを使用しているため、Prefixフィールドの使用は、プレフィックス自体を宣伝での使用と互換性があります。このフラグビットの解釈は、オンリンク（L）に必要な処理及び自律アドレス設定（A）フラグビットのこのよう無関係です。
Reserved1: 5-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved1：5ビットの未使用フィールド。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Valid Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for the purpose of on-link determination. A value of all one bits (0xFFFFFFFF) represents infinity. The Valid Lifetime is also used by [RFC4862].
有効期間：32ビット符号なし整数。プレフィックスがオンリンク決定する目的のために有効であること（パケットが送信された時点と比較して）秒単位の時間の長さ。全ての1つのビットの値（0xFFFFFFFFの）は無限を表します。有効寿命はまた、[RFC4862]で使用されます。
Preferred Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration remain preferred [RFC4862]. A value of all one bits (0xFFFFFFFF) represents infinity. See [RFC4862]. Note that the value of this field MUST NOT exceed the Valid Lifetime field to avoid preferring addresses that are no longer valid.
好ましい寿命：32ビット符号なし整数。ステートレスアドレス自動設定を介しプレフィックスから生成されたアドレス（パケットが送信される時刻に対する）秒単位の時間の長さは、[RFC4862]を好ましいままです。全ての1つのビットの値（0xFFFFFFFFの）は無限を表します。 [RFC4862]を参照してください。このフィールドの値は、もはや有効なアドレスを好む避けるために有効寿命フィールドを超えてはならないことに注意してください。
Reserved2: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.
Reserved2：このフィールドは未使用です。これは、送信者によってゼロに初期化しなければならなくて、受信機で無視しなければなりません。
Prefix: An IPv6 address or a prefix of an IPv6 address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. A router SHOULD NOT send a prefix option for the link-local prefix, and a host SHOULD ignore such a prefix option. A non-storing node SHOULD refrain from advertising a prefix till it owns an address of that prefix, and then it SHOULD advertise its full address in this field, with the 'R' flag set. The children of a node that so advertises a full address with the 'R' flag set may then use that address to determine the content of the DODAG Parent Address subfield of the Transit Information option.
プレフィックス：IPv6アドレスまたはIPv6アドレスのプレフィックス。プレフィックス長フィールドはプレフィックスに有効な先行ビットの数が含まれています。プレフィックス長の後にプレフィックスのビットは予約されており、送信者によってゼロに初期化し、受信機で無視しなければなりません。ルータはリンクローカルプレフィックスのプレフィックスオプションを送るべきではありません、そしてホストは、prefixオプションを無視します。非保存ノードは、それがその接頭語のアドレスを所有するまでのプレフィックスを広告する控えるべきであり、それは「R」のフラグを設定して、この分野での完全なアドレスを宣伝すべきです。その「R」フラグを設定して、完全なアドレスをアドバタイズノードの子は、トランジット情報オプションのDODAG親アドレスサブフィールドの内容を決定するためにそのアドレスを使用することができます。
Unassigned bits of the PIO are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
PIOの未割り当てのビットは予約されています。彼らは、送信時にゼロに設定しなければならなくて、レセプションで無視しなければなりません。
The RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target.
RPLターゲットオプションは、すぐにその特定のターゲットを認定1つの不透明な記述が続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x09 |Opt Length = 4 | Descriptor
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: Format of the RPL Target Descriptor Option
図30：RPLターゲット記述子オプションのフォーマット
The RPL Target Descriptor option is used to qualify a target, something that is sometimes called "tagging".
RPLターゲット記述子オプションは、ターゲット、時々「タグ付け」と呼ばれているものを修飾するために使用されます。
At most, there can be one descriptor per target. The descriptor is set by the node that injects the Target in the RPL network. It MUST be copied but not modified by routers that propagate the Target Up the DODAG in DAO messages.
せいぜい、ターゲットごとに記述子が存在することができます。記述子は、RPLネットワークでターゲットを注入ノードによって設定されています。これは、コピーされたが、DAOメッセージにDODAGアップターゲットを伝播するルータによって変更されないされなければなりません。
Option Type: 0x09
オプションタイプ：0x09の
Option Length: 4
オプション長さ：4
Descriptor: 32-bit unsigned integer. Opaque.
記述：32ビット符号なし整数。不透明な。
This section describes the general scheme for bootstrap and operation of sequence counters in RPL, such as the DODAGVersionNumber in the DIO message, the DAOSequence in the DAO message, and the Path Sequence in the Transit Information option.
このセクションでは、DIOメッセージ、DAOメッセージでDAOSequence、および交通情報オプションでパスシーケンス内などDODAGVersionNumberようRPL内のシーケンスカウンターのブートストラップおよび操作のための一般的なスキームを説明します。
This specification utilizes three different sequence numbers to validate the freshness and the synchronization of protocol information:
この仕様は、新鮮さとプロトコル情報の同期を検証するために、3つの異なるシーケンス番号を利用します。
DODAGVersionNumber: This sequence counter is present in the DIO Base to indicate the Version of the DODAG being formed. The DODAGVersionNumber is monotonically incremented by the root each time the root decides to form a new Version of the DODAG in order to revalidate the integrity and allow a global repair to occur. The DODAGVersionNumber is propagated unchanged Down the DODAG as routers join the new DODAG Version. The DODAGVersionNumber is globally significant in a DODAG and indicates the Version of the DODAG in which a router is operating. An older (lesser) value indicates that the originating router has not migrated to the new DODAG Version and cannot be used as a parent once the receiving node has migrated to the newer DODAG Version.
DODAGVersionNumber：このシーケンスカウンタは、形成されるDODAGのバージョンを示すために、DIOベース中に存在します。 DODAGVersionNumberは単調ルートでルートが整合性を再検証し、グローバルな修復が起こることを可能にするためにDODAGの新しいバージョンを形成することを決定するたびにインクリメントされます。ルータは新しいDODAGバージョンに参加してDODAGVersionNumberはDODAGダウンそのまま伝播されます。 DODAGVersionNumberはDODAGで世界的に重要であり、ルータが動作しているDODAGのバージョンを示します。古い（小さい）値は、受信ノードが新しいDODAG版に移行した後、元のルータが新しいDODAGバージョンに移行していない親として使用することができないことを示しています。
DAOSequence: This sequence counter is present in the DAO Base to correlate a DAO message and a DAO ACK message. The DAOSequence number is locally significant to the node that issues a DAO message for its own consumption to detect the loss of a DAO message and enable retries.
DAOSequence：このシーケンスカウンタは、DAOメッセージとDAO ACKメッセージを相関させるDAOベース中に存在します。 DAOSequence番号はDAOメッセージの損失を検出し、再試行を有効にするために、自身の消費のためのDAOメッセージを発行ノードにローカルで重要です。
Path Sequence: This sequence counter is present in the Transit Information option in a DAO message. The purpose of this counter is to differentiate a movement where a newer route supersedes a stale one from a route redundancy scenario where multiple routes exist in parallel for the same target. The Path Sequence is globally significant in a DODAG and indicates the freshness of the route to the associated target. An older (lesser) value received from an originating router indicates that the originating router holds stale routing states and the originating router should not be considered anymore as a potential next hop for the target. The Path Sequence is computed by the node that advertises the target, that is the Target itself or a router that advertises a Target on behalf of a host, and is unchanged as the DAO content is propagated towards the root by parent routers. If a host does not pass a counter to its router, then the router is in charge of computing the Path Sequence on behalf of the host and the host can only register to one router for that purpose. If a DAO message containing the same Target is issued to multiple parents at a given point in time for the purpose of route redundancy, then the Path Sequence is the same in all the DAO messages for that same target.
パスシーケンス：このシーケンスカウンタは、DAOメッセージでトランジットInformationオプションに存在しています。このカウンタの目的は、新しいルートが複数のルートが同じターゲットに対して平行に存在する経路冗長シナリオから古くなったものを優先さ運動を区別することです。パスの順序はDODAGで世界的に重要であり、関連したターゲットへのルートの鮮度を示します。発信元ルータから受信した古い（小さい）値は、元のルータが失効ルーティング状態を保持し、元のルータは、ターゲットのための潜在的な次ホップとしてもはやみなされるべきではないことを示しています。パスのシーケンスは、ターゲット自体またはホストの代わりにターゲットをアドバタイズし、DAOのコンテンツは、親ルータによるルートに向けて伝播されるよう変更されていないルータであるターゲットをアドバタイズノード、によって計算されます。ホストがルータにカウンターを通過していない場合、ルータはホストの代わりにパスシーケンスの計算を担当しているとホストがその目的のためだけに1つのルータに登録することができます。同じターゲットを含むDAOメッセージは、経路の冗長性のために、任意の時点で複数の親に対して発行されている場合は、パスのシーケンスは、同じターゲットのすべてのDAOのメッセージでも同じです。
RPL sequence counters are subdivided in a 'lollipop' fashion [Perlman83], where the values from 128 and greater are used as a linear sequence to indicate a restart and bootstrap the counter, and the values less than or equal to 127 used as a circular sequence number space of size 128 as in [RFC1982]. Consideration is given to the mode of operation when transitioning from the linear region to the circular region. Finally, when operating in the circular region, if sequence numbers are detected to be too far apart, then they are not comparable, as detailed below.
RPLシーケンスカウンタは128より大きいからの値は、カウンタをリスタートを示し、ブートストラップする線形配列として使用される「ロリポップ」ファッション[Perlman83]に細分化、および値未満又は円形として使用さ127に等しくされています[RFC1982]のように大きさ128のシーケンス番号空間。円形領域を線形領域から移行するとき考慮が動作のモードに与えられます。下記のとおり、シーケンス番号があまりにも遠く離れたことが検出された場合最後に、円形の領域で動作しているとき、それらは、比較することはできません。
A window of comparison, SEQUENCE_WINDOW = 16, is configured based on a value of 2^N, where N is defined to be 4 in this specification.
比較、SEQUENCE_WINDOW = 16の窓は、Nは、本明細書中に4であると定義される2 ^ Nの値に基づいて構成されています。
For a given sequence counter:
与えられたシーケンスカウンタの場合：
1. The sequence counter SHOULD be initialized to an implementation defined value, which is 128 or greater prior to use. A recommended value is 240 (256 - SEQUENCE_WINDOW).
1.シーケンスカウンタが128以上で使用する前にある実装定義された値に初期化されるべきです。推奨値は、240（ - SEQUENCE_WINDOW 256）です。
2. When a sequence counter increment would cause the sequence counter to increment beyond its maximum value, the sequence counter MUST wrap back to zero. When incrementing a sequence counter greater than or equal to 128, the maximum value is 255. When incrementing a sequence counter less than 128, the maximum value is 127.
2.シーケンスカウンタの増分は、シーケンスカウンタが最大値を超えてインクリメントさせるような場合には、シーケンス・カウンタがゼロに戻ってラップする必要があります。 128以上のシーケンスカウンタを増分する場合、最大値は、シーケンスカウンタ128未満をインクリメントする場合、最大値は127で255です。
3. When comparing two sequence counters, the following rules MUST be applied:
3. 2つのシーケンスカウンタを比較すると、以下の規則が適用されなければなりません。
1. When a first sequence counter A is in the interval [128..255]
and a second sequence counter B is in [0..127]:
1. If (256 + B - A) is less than or equal to
SEQUENCE_WINDOW, then B is greater than A, A is less than
B, and the two are not equal.
2. If (256 + B - A) is greater than SEQUENCE_WINDOW, then A is greater than B, B is less than A, and the two are not equal.
2.（256 + B - A）の場合はSEQUENCE_WINDOWより大きい場合、AはBよりも大きい場合、BはA未満であり、両者は等しくありません。
For example, if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16); thus, 240 is greater than 5. As another example, if A is 250 and B is 5, then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW (16); thus, 250 is less than 5.
Aが240であり、そしてBは、次に、5である場合、例えば、（256 + 5から240）21 21 SEQUENCE_WINDOW（16）よりも大きい場合です。 Aが250であり、Bは、その後、5である場合、従って、240は、別の例として、5より大きいが、ある（256 + 5から250）11. 11 SEQUENCE_WINDOW（16）未満です。従って、250は、5未満です。
2. In the case where both sequence counters to be compared are less than or equal to 127, and in the case where both sequence counters to be compared are greater than or equal to 128:
両方の配列が比較されるカウンタ場合2. 127以下であり、そして両方の配列を比較するカウンタ場合には128以上です。
1. If the absolute magnitude of difference between the two
sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in
[RFC1982] is used to determine the relationships greater
than, less than, and equal.
2. If the absolute magnitude of difference of the two sequence counters is greater than SEQUENCE_WINDOW, then a desynchronization has occurred and the two sequence numbers are not comparable.
2. 2つのシーケンスカウンタの差の絶対値がSEQUENCE_WINDOWよりも大きい場合、非同期化が発生し、2のシーケンス番号を比較することはできません。
4. If two sequence numbers are determined not to be comparable, i.e., the results of the comparison are not defined, then a node should consider the comparison as if it has evaluated in such a way so as to give precedence to the sequence number that has most recently been observed to increment. Failing this, the node should consider the comparison as if it has evaluated in such a way so as to minimize the resulting changes to its own state.
4. 2つのシーケンス番号を比較できないと判定された場合、すなわち、比較の結果が定義されていないが、このような方法で評価しているかのようにそのシーケンス番号に優先順位を与えるように、そのノードは、比較を考慮すべきです最近インクリメントすることが観察されています。自身の状態に生じる変化を最小限にするように、このような方法で評価しているかのように、この失敗すると、ノードは、比較を検討すべきです。
This section describes how RPL discovers and maintains Upward routes. It describes the use of DODAG Information Objects (DIOs), the messages used to discover and maintain these routes. It specifies how RPL generates and responds to DIOs. It also describes DODAG Information Solicitation (DIS) messages, which are used to trigger DIO transmissions.
このセクションでは、RPLは、上向きのルートを発見し、維持する方法について説明します。それはDODAG情報オブジェクト（のDIO）、これらのルートを発見し、維持するために使用されるメッセージの使用を記載しています。これは、RPLが発生してのDIOにどのように応答するかを指定します。また、DIO送信をトリガするために使用されているDODAG情報要請（DIS）のメッセージについて説明します。
As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST provision at least one DODAG parent as a default route for the associated instance. This default route enables a packet to be forwarded Upward until it eventually hits a common ancestor from which it will be routed Downward to the destination. If the destination is not in the DODAG, then the DODAG root may be able to forward the packet using connectivity to the outside of the DODAG; if it cannot forward the packet outside, then the DODAG root has to drop it.
3.2.8項で述べたように、決定ノードは、関連するインスタンスのデフォルトルートとしてDODAGのMUST条項に少なくとも一つのDODAG親に参加します。このデフォルトルートは、それが最終的には先に下向きルーティングされます、そこから共通の祖先に当たるまで上向きに転送するパケットを可能にします。宛先がDODAGでない場合、DODAGルートはDODAGの外部への接続を使用してパケットを転送することができるかもしれません。それが外にパケットを転送することができない場合は、DODAGルートはそれをドロップすることがあります。
A DIO message can also transport explicit routing information:
DIOメッセージは、明示的なルーティング情報を搬送することができます。
DODAGID: The DODAGID is a Global or Unique Local IPv6 address of the root. A node that joins a DODAG SHOULD provision a host route via a DODAG parent to the address used by the root as the DODAGID.
DODAGID：DODAGIDは根のグローバルまたはユニークローカルIPv6アドレスです。 DODAG SHOULD提供DODAGIDとしてルートによって使用されるアドレスへDODAG親を介してホストルートを結合ノード。
RIO Prefix: The root MAY place one or more Route Information options in a DIO message. The RIO is used to advertise an external route that is reachable via the root, associated with a preference, as presented in Section 6.7.5, which incorporates the RIO from [RFC4191]. It is interpreted as a capability of the root as opposed to a routing advertisement, and it MUST NOT be redistributed in another routing protocol though it SHOULD be used by an ingress RPL router to select a DODAG when a packet is injected in a RPL domain from a node attached to that
RIOプレフィックス：ルートはDIOメッセージ内の1つまたは複数のルート情報オプションを配置することがあります。 [RFC4191]からRIOを組み込む節6.7.5に提示さRIOは、嗜好に関連したルートを介して到達可能である外部ルートをアドバタイズするために使用されます。ルーティング広告とは対照的に、それは、ルートの能力として解釈され、パケットはからRPLドメインに注入されたとき、DODAGを選択するために、入口RPLルータによって使用されるべきであるけれども、それは、別のルーティングプロトコルに再配布してはいけませんそれに取り付けられたノード
RPL router. An Objective Function MAY use the routes
advertised in RIO or the preference for those routes in order
to favor a DODAG versus another one for the same instance.
1. For the following DIO Base fields, a node that is not a DODAG root MUST advertise the same values as its preferred DODAG parent (defined in Section 8.2.1). In this way, these values will propagate Down the DODAG unchanged and advertised by every node that has a route to that DODAG root. These fields are as follows: 1. Grounded (G) 2. Mode of Operation (MOP) 3. DAGPreference (Prf) 4. Version 5. RPLInstanceID 6. DODAGID
以下DIO基本フィールドについて1、DODAGルートでないノード（セクション8.2.1で定義された）その好ましいDODAG親と同じ値をアドバタイズしなければなりません。このように、これらの値は変わらず、そのDODAGルートへのルートを持っているすべてのノードによってアドバタイズDODAGダウン伝播します。次のようにこれらのフィールドは：1（G）の動作（MOP）3. DAGPreference（PRF）4.バージョン5 RPLInstanceID 6 DODAGIDの2モード接地
2. A node MAY update the following fields at each hop: 1. Rank 2. DTSN
2.ノードは、各ホップで、次のフィールドを更新することができる：1.ランク2 DTSN
3. The DODAGID field each root sets MUST be unique within the RPL Instance and MUST be a routable IPv6 address belonging to the root.
3. DODAGIDフィールドには、各ルートのセットは、RPLインスタンス内で一意である必要があり、ルートに属するルーティング可能なIPv6アドレスでなければなりません。
Upward route discovery allows a node to join a DODAG by discovering neighbors that are members of the DODAG of interest and identifying a set of parents. The exact policies for selecting neighbors and parents is implementation dependent and driven by the OF. This section specifies the set of rules those policies must follow for interoperability.
上向きのルート発見は、ノードが関心のDODAGのメンバーである隣人を発見し、両親のセットを識別することによってDODAGに参加することができます。隣人や親を選択するための正確なポリシーは、実装に依存してOFによって駆動されます。このセクションでは、これらのポリシーは、相互運用性のために従わなければならないルールのセットを指定します。
RPL's Upward route discovery algorithms and processing are in terms of three logical sets of link-local nodes. First, the candidate neighbor set is a subset of the nodes that can be reached via link-local multicast. The selection of this set is implementation and OF dependent. Second, the parent set is a restricted subset of the candidate neighbor set. Finally, the preferred parent is a member of the parent set that is the preferred next hop in Upward routes. Conceptually, the preferred parent is a single parent; although, it may be a set of multiple parents if those parents are equally preferred and have identical Rank.
RPLの上向きの経路探索アルゴリズムと処理は、リンクローカルノードの3つの論理セットという点です。まず、候補隣接セットは、リンクローカルマルチキャストを介して到達できるノードのサブセットです。このセットの選択は、実装および依存です。第二に、親セットは、候補隣接セットの制限されたサブセットです。最後に、好ましい親上向き経路における好ましいネクストホップ親セットのメンバーです。概念的には、好適な親は、単一の親です。それらの親が等しく好適であり、同一のランクを有する場合が、複数の親の集合であってもよいです。
More precisely:
より正確に：
1. The DODAG parent set MUST be a subset of the candidate neighbor set.
1. DODAG親セットは、候補隣接セットのサブセットである必要があります。
3. A node that is not a DODAG root MAY maintain a DODAG parent set of size greater than or equal to one.
3. DODAGルートでないノードは、1以上のサイズのDODAG親セットを維持することができます。
4. A node's preferred DODAG parent MUST be a member of its DODAG parent set.
4.ノードの優先DODAG親は、そのDODAG親セットのメンバでなければなりません。
5. A node's Rank MUST be greater than all elements of its DODAG parent set.
5.ノードのランクは、そのDODAG親セットのすべての要素よりも大きくなければなりません。
6. When Neighbor Unreachability Detection (NUD) [RFC4861], or an equivalent mechanism, determines that a neighbor is no longer reachable, a RPL node MUST NOT consider this node in the candidate neighbor set when calculating and advertising routes until it determines that it is again reachable. Routes through an unreachable neighbor MUST be removed from the routing table.
近隣到達不能検出（NUD）[RFC4861]、またはそれと同等の機構は、近隣がもはや到達可能でないと判断した場合、それはそれと判断されるまで6、RPLノードが計算と広告経路ときに候補セットの隣にこのノードを考慮してはいけません再び到達可能です。到達不能なネイバーを通るルートは、ルーティングテーブルから除去されなければなりません。
These rules ensure that there is a consistent partial order on nodes within the DODAG. As long as node Ranks do not change, following the above rules ensures that every node's route to a DODAG root is loop-free, as Rank decreases on each hop to the root.
これらのルールはDODAG内のノードに一致する部分の順序があることを確認します。限りノードランクが変化しないように、上記のルールに従うことランクはルートに各ホップに減少するとDODAGルートにすべてのノードのルートは、ループフリーであることを保証します。
The OF can guide candidate neighbor set and parent set selection, as discussed in [RFC6552].
[RFC6552]で議論するようOFは、候補隣接セットおよび親セットの選択を導くことができます。
The above rules govern a single DODAG Version. The rules in this section define how RPL operates when there are multiple DODAG Versions.
上記の規則は、単一のDODAGバージョンを管理します。このセクションのルールは、複数のDODAGのバージョンが存在するとき、RPLの動作を定義します。
1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely defines a DODAG Version. Every element of a node's DODAG parent set, as conveyed by the last heard DIO message from each DODAG parent, MUST belong to the same DODAG Version. Elements of a node's candidate neighbor set MAY belong to different DODAG Versions.
1.タプル（RPLInstanceID、DODAGID、DODAGVersionNumber）が一意DODAGバージョンを定義します。ノードのDODAGの親セットのすべての要素は、各DODAG親から最後聞いたDIOメッセージにより搬送さと、同じDODAGバージョンに属している必要があります。ノードの候補隣接セットの要素は異なるDODAGのバージョンに属していてもよいです。
2. A node is a member of a DODAG Version if every element of its DODAG parent set belongs to that DODAG Version, or if that node is the root of the corresponding DODAG.
そのDODAG親セットのすべての要素がそのDODAG版に属している場合、またはそのノードは、対応するDODAGのルートである場合2.ノードはDODAG版のメンバーです。
3. A node MUST NOT send DIOs for DODAG Versions of which it is not a member.
3.ノードは、それがメンバーでないそのDODAGバージョン用のDIOを送ってはいけません。
4. DODAG roots MAY increment the DODAGVersionNumber that they advertise and thus move to a new DODAG Version. When a DODAG root increments its DODAGVersionNumber, it MUST follow the conventions of Serial Number Arithmetic as described in Section 7. Events triggering the increment of the DODAGVersionNumber are described later in this section and in Section 18.
4. DODAGの根は、彼らが宣伝していることDODAGVersionNumberをインクリメントので、新しいDODAGバージョンに移動することができます。 DODAGルートがDODAGVersionNumberをインクリメントするとき、セクションDODAGVersionNumberの増加をトリガ7.イベントこのセクションでは、セクション18に記載されているに記載されているように、それはシリアル番号演算の規則に従わなければなりません。
5. Within a given DODAG, a node that is a not a root MUST NOT advertise a DODAGVersionNumber higher than the highest DODAGVersionNumber it has heard. Higher is defined as the greater-than operator in Section 7.
与えられたDODAG、ルートはそれは聞いたことが最高DODAGVersionNumberよりも高いDODAGVersionNumberを広告してはならないではないノード内の5。上位は、第7節では大なり演算子として定義されます。
6. Once a node has advertised a DODAG Version by sending a DIO, it MUST NOT be a member of a previous DODAG Version of the same DODAG (i.e., with the same RPLInstanceID, the same DODAGID, and a lower DODAGVersionNumber). Lower is defined as the less-than operator in Section 7.
前記ノードは、DIOを送信することによってDODAG版をアドバタイズした後、それは（すなわち、同じRPLInstanceID、同じDODAGID、下部DODAGVersionNumberと）同じDODAGの前DODAG版のメンバーであってはなりません。下部セクション7における小なり演算子として定義されます。
When the DODAG parent set becomes empty on a node that is not a root, (i.e., the last parent has been removed, causing the node no longer to be associated with that DODAG), then the DODAG information should not be suppressed until after the expiration of an implementation-specific local timer. During the interval prior to suppression of the "old" DODAG state, the node will be able to observe if the DODAGVersionNumber has been incremented should any new parents appear. This will help protect against the possibility of loops that may occur if that node were to inadvertently rejoin the old DODAG Version in its own prior sub-DODAG.
DODAG親セットはルートでないノードに空になったときに、（すなわち、最後の親はもはやそのDODAGに関連付けられるノードを引き起こし、除去された）、次いでDODAG情報は後まで抑制されるべきではありません実装固有のローカルタイマの満了。以前「古い」DODAG状態の抑制期間の間、ノードは新しい親が表示されますDODAGVersionNumberがインクリメントされているかどうかを観察することができるようになります。これは、そのノードが誤って自身の前にサブDODAGに古いDODAGバージョンに再加入した場合に発生する可能性があり、ループの可能性から保護するのに役立ちます。
As the DODAGVersionNumber is incremented, a new DODAG Version spreads outward from the DODAG root. A parent that advertises the new DODAGVersionNumber cannot belong to the sub-DODAG of a node advertising an older DODAGVersionNumber. Therefore, a node can safely add a parent of any Rank with a newer DODAGVersionNumber without forming a loop.
DODAGVersionNumberがインクリメントされると、新しいDODAGバージョンはDODAGルートから外側に広がります。新しいDODAGVersionNumberをアドバタイズ親は古いDODAGVersionNumberを広告するノードのサブDODAGに属することはできません。したがって、ノードは安全にループを形成することなく、新しいDODAGVersionNumber有する任意のランクの親を追加することができます。
For example, suppose that a node has left a DODAG with DODAGVersionNumber N. Suppose that a node had a sub-DODAG and did attempt to poison that sub-DODAG by advertising a Rank of INFINITE_RANK, but those advertisements may have become lost in the
例えば、ノードは、サブDODAGを持っていたと仮定し、INFINITE_RANKのランクを広告することにより、そのサブDODAGを毒殺しようとしなかったが、それらの広告がで失われている可能性があり、ノードがDODAGVersionNumber N.でDODAGを残していると仮定
LLN. Then, if the node did observe a candidate neighbor advertising a position in that original DODAG at DODAGVersionNumber N, that candidate neighbor could possibly have been in the node's former sub-DODAG, and there is a possible case where adding that candidate neighbor as a parent could cause a loop. In this case, if that candidate neighbor is observed to advertise a DODAGVersionNumber N+1, then that candidate neighbor is certain to be safe, since it is certain not to be in that original node's sub-DODAG, as it has been able to increment the DODAGVersionNumber by hearing from the DODAG root while that original node was detached. For this reason, it is useful for the detached node to remember the original DODAG information, including the DODAGVersionNumber N.
LLN。その後、ノードはDODAGVersionNumber Nでその元DODAG内の位置を広告する候補隣人を観察しなかった場合、その候補の隣人は、おそらく、ノードの旧サブDODAGにされている可能性があり、親としてその候補隣人を追加し、可能な場合場合がありますループを引き起こす可能性があります。その候補ネイバーがDODAGVersionNumber N + 1をアドバタイズすることが観察されている場合は、この場合には、その候補隣人は、その元のノードのサブDODAGでないと特定されているのでをインクリメントすることができたように、安全であることが確実ですその元のノードが離脱しながらDODAGルートから聞くことDODAGVersionNumber。このため、DODAGVersionNumber N.含むオリジナルDODAG情報を、覚えておくことが切り離されたノードのために有用です
Exactly when a DODAG root increments the DODAGVersionNumber is implementation dependent and out of scope for this specification. Examples include incrementing the DODAGVersionNumber periodically, upon administrative intervention, or on application-level detection of lost connectivity or DODAG inefficiency.
DODAGルートはDODAGVersionNumberは実装に依存し、この仕様の範囲外である増分を正確に。例には、管理者の介入時、又は失われた接続又はDODAG非効率のアプリケーションレベルの検出に、定期的DODAGVersionNumberをインクリメント含みます。
After a node transitions to and advertises a new DODAG Version, the rules above make it unable to advertise the previous DODAG Version (prior DODAGVersionNumber) once it has committed to advertising the new DODAG Version.
ノードの遷移に、新たなDODAGバージョンをアドバタイズした後、上記のルールは、それが新しいDODAGバージョンを宣伝することを約束していたら、以前のバージョンDODAG（前DODAGVersionNumber）を宣伝することができなくなります。
1. A DODAG root without possibility to satisfy the application-defined goal MUST NOT set the Grounded bit.
アプリケーション定義の目標を満足させる可能性なし1. A DODAGルートは接地ビットを設定してはいけません。
3. A node whose DODAG parent set is empty MAY become the DODAG root of a floating DODAG. It MAY also set its DAGPreference such that it is less preferred.
3.そのDODAG親セットフローティングDODAGのDODAGルートになることが空であるノード。また、それはあまり好まれているように、そのDAGPreferenceを設定することができます。
In a deployment that uses non-LLN links to federate a number of LLN roots, it is possible to run RPL over those non-RPL links and use one router as a "backbone root". The backbone root is the virtual root of the DODAG and exposes a Rank of BASE_RANK over the backbone. All the LLN roots that are parented to that backbone root, including the backbone root if it also serves as the LLN root itself, expose a Rank of ROOT_RANK to the LLN. These virtual roots are part of the same DODAG and advertise the same DODAGID. They coordinate DODAGVersionNumbers and other DODAG parameters with the virtual root over the backbone. The method of coordination is out of scope for this specification (to be defined in future companion specifications).
LLNの根の数を連携するために、非LLNリンクを使用して、展開では、これらの非RPLリンク上でRPLを実行し、「基幹ルート」としてのルータを使用することが可能です。基幹ルートはDODAGの仮想ルートで、バックボーン上BASE_RANKのランクを公開します。それはまた、LLNルート自体として機能している場合、バックボーンルートなど、その基幹ルートに親されているすべてのLLNの根は、LLNにROOT_RANKのランクを公開します。これらの仮想根は同じDODAGの一部であり、同じDODAGIDを宣伝します。彼らはDODAGVersionNumbersとバックボーン上で仮想ルートを持つ他のDODAGパラメータを調整します。調整の方法は、（将来コンパニオン仕様で定義される）は、この仕様の範囲外です。
The Objective Function and the set of advertised routing metrics and constraints of a DAG determine how a node selects its neighbor set, parent set, and preferred parents. This selection implicitly also determines the DODAG within a DAG. Such selection can include administrative preference (Prf) as well as metrics or other considerations.
目的関数およびDAGのアドバタイズされたルーティング・メトリックと制約のセットは、ノードがネイバーセット、親セット、好ましい両親を選択する方法を決定します。この選択は、暗黙的にも、DAG内DODAGを決定します。そのような選択は、管理者の好み（PRF）、ならびに指標又は他の考慮事項を含むことができます。
If a node has the option to join a more preferred DODAG while still meeting other optimization objectives, then the node will generally seek to join the more preferred DODAG as determined by the OF. All else being equal, it is left to the implementation to determine which DODAG is most preferred (since, as a reminder, a node must only join one DODAG per RPL Instance).
ノードがまだ他の最適化目標を達成しながら、より好ましいDODAGに参加するためのオプションを持っている場合、そのノードは、一般的OFによって決定され、より好ましいDODAGに参加することを目指します。他のすべてが等しい場合、DODAGが（リマインダーとして、ノードのみRPLインスタンスごとに1つDODAGに加入しなければならないので）最も好適であるかを決定するために、実装に委ねられます。
1. A node MUST NOT advertise a Rank less than or equal to any member of its parent set within the DODAG Version.
1.ノードは、以下DODAG版内に設定親の任意のメンバーに等しいランクをアドバタイズしてはいけません。
2. A node MAY advertise a Rank lower than its prior advertisement within the DODAG Version.
2.ノードがDODAGバージョン内のその前の広告よりもランクが下の広告を出すかもしれません。
3. Let L be the lowest Rank within a DODAG Version that a given node has advertised. Within the same DODAG Version, that node MUST NOT advertise an effective Rank higher than L + DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: a node MAY advertise an INFINITE_RANK within a DODAG Version without restriction. If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease, when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK.
3. Lが与えられたノードがアドバタイズしていることをDODAGバージョン内で最低ランクとします。同じDODAGバージョンの中で、そのノードがL + DAGMaxRankIncreaseよりも高い効果的なランクを広告してはなりません。 INFINITE_RANKは、この規則の例外です：ノードは、制限なくDODAGバージョン内INFINITE_RANKを広告するかもしれません。ノードのランクがL + DAGMaxRankIncreaseで許可されているよりも高くした場合、それはランクをアドバタイズするとき、それはINFINITE_RANKとしてのランクを広告しなければなりません。
4. A node MAY, at any time, choose to join a different DODAG within a RPL Instance. Such a join has no Rank restrictions, unless that different DODAG is a DODAG Version of which this node has previously been a member; in which case, the rule of the previous bullet (3) must be observed. Until a node transmits a DIO indicating its new DODAG membership, it MUST forward packets along the previous DODAG.
4.ノードMAYは、いつでも、RPLインスタンス内の異なるDODAGに参加することを選択します。そのような参加、異なるDODAGこのノードが以前メンバーとなっていたのDODAG版でない限り、ランク無しの制約を有していません。その場合には、前回の弾丸（3）のルールが観察されなければなりません。ノードがその新しいDODAGメンバーシップを示すDIOを送信するまで、それは前DODAGに沿ってパケットを転送しなければなりません。
5. A node MAY, at any time after hearing the next DODAGVersionNumber advertised from suitable DODAG parents, choose to migrate to the next DODAG Version within the DODAG.
5.ノードMAYは、次のDODAGVersionNumberを聞いた後、任意の時点でDODAG内の次DODAGバージョンに移行することを選択し、適したDODAGの両親から宣伝しました。
Conceptually, an implementation is maintaining a DODAG parent set within the DODAG Version. Movement entails changes to the DODAG parent set. Moving Up does not present the risk to create a loop but moving Down might, so that operation is subject to additional constraints.
概念的には、実装はDODAGバージョン内で設定DODAG親を維持しています。移動はDODAG親セットへの変更を伴います。上がるその操作が追加の制約を受けているので、ループを作成するために、リスクを提示するかもしれないが、ダウン動いていません。
When a node migrates to the next DODAG Version, the DODAG parent set needs to be rebuilt for the new Version. An implementation could defer to migrate for some reasonable amount of time, to see if some other neighbors with potentially better metrics but higher Rank announce themselves. Similarly, when a node jumps into a new DODAG, it needs to construct a new DODAG parent set for this new DODAG.
ノードは、次のDODAGバージョンに移行すると、DODAG親セットは、新しいバージョンのために再構築する必要があります。実装は、潜在的により良いメトリックが、より高いランクを持つ他の隣人が自分自身を発表するかどうかを確認するために、時間のいくつかの合理的な量のために移行することを延期することができます。ノードが新しいDODAGにジャンプしたとき同様に、それはこの新しいDODAGのための新しいDODAGの親セットを構築する必要があります。
If a node needs to move Down a DODAG that it is attached to, increasing its Rank, then it MAY poison its routes and delay before moving as described in Section 8.2.2.5.
ノードは、そのランクを増加させ、それが接続されていることDODAGを下に移動する必要がある場合、それは、その経路を被毒し、セクション8.2.2.5に記載されるように移動する前に遅延させることができます。
A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version, then it must continue to observe the rule that it may not advertise a Rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. This rule must be observed so as not to create a loophole that would allow the node to effectively increment its Rank all the way to INFINITE_RANK, which may have impact on other nodes and create a resource-wasting count-to-infinity scenario.
ノードは、それが任意の制限なしの前メンバーではなかったことをどのDODAGバージョンへの参加を許可されていますが、ノードはDODAGバージョンの前にメンバーとなっている場合、それはそれは広告しないかもしれないというルールを遵守し続けなければなりませんDODAGバージョンの生活の中で任意の時点でL + DAGMaxRankIncreaseよりも高いランク。ノードが効果的に他のノードに影響を与え、資源を浪費カウントツー無限のシナリオを作成することがすべての方法INFINITE_RANKへのランクを、インクリメントすることが可能になる抜け穴を作成しないようにこのルールを守らなければなりません。
2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set.
2.ノードは、その親セット内INFINITE_RANKのランクを有する任意のノードを有してはなりません。
Although an implementation may advertise INFINITE_RANK for the purposes of poisoning, doing so is not the same as setting Rank to INFINITE_RANK. For example, a node may continue to send data packets whose RPL Packet Information includes a Rank that is not INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.
実装は中毒の目的のためにINFINITE_RANKを宣伝するかもしれないが、そうすることINFINITE_RANKにランクを設定することと同じではありません。例えば、ノードは、そのRPLパケット情報INFINITE_RANKないランクを含み、依然としてそののDIOにINFINITE_RANKを広告データパケットを送信し続けることができます。
When a (former) parent is observed to advertise a Rank of INFINITE_RANK, that (former) parent has detached from the DODAG and is no longer able to act as a parent, nor is there any way that another node may be considered to have a Rank greater-than INFINITE_RANK. Therefore, that (former) parent cannot act as a parent any longer and is removed from the parent set.
（前者）親がINFINITE_RANKのランクをアドバタイズすることが観察された場合、その（元）親DODAGから取り外し、もはや親として作用することができ、また、別のノードを有すると考えることができることをどのような方法があるましたランクより大INFINITE_RANK。したがって、その（元）親はもはや親として作用することができず、親セットから除去されます。
1. A node unable to stay connected to a DODAG within a given DODAG Version, i.e., that cannot retain non-empty parent set without violating the rules of this specification, MAY detach from this DODAG Version. A node that detaches becomes the root of its own floating DODAG and SHOULD immediately advertise this new situation in a DIO as an alternate to poisoning.
1.本明細書のルールに違反することなく、非空の親セットを保持することができない、すなわち、所与DODAG版内DODAGに接続を維持することができないノード、このDODAG版から分離してもよい（MAY）。デタッチノードは、独自のフローティングDODAGのルートになり、すぐに中毒への代替として、DIOにおけるこの新しい状況を宣伝すべきです。
1. If a node receives a DIO from one of its DODAG parents, indicating that the parent has left the DODAG, that node SHOULD stay in its current DODAG through an alternative DODAG parent, if possible. It MAY follow the leaving parent.
1.ノードが親DODAGを残していることを示し、そのDODAG両親の一方からDIOを受信した場合、可能な場合、そのノードは、代替DODAG親を通じて電流DODAGにとどまるべきです。それは残して親に従うことができます。
A DODAG parent may have moved, migrated to the next DODAG Version, or jumped to a different DODAG. A node ought to give some preference to remaining in the current DODAG, if possible via an alternate parent, but ought to follow the parent if there are no other options.
DODAGの親が移動した可能性があり、次のDODAGバージョンへの移行、または異なるDODAGに跳ね上がりました。ノードは、可能な場合、代替親を介して、現在のDODAG中に残存するために、いくつかの優先順位を与えるべきであるが、他のオプションがない場合、親に従うべきです。
When a DIO message is received, the receiving node must first determine whether or not the DIO message should be accepted for further processing, and subsequently present the DIO message for further processing if eligible.
DIOメッセージを受信すると、受信ノードは、第DIOメッセージはさらなる処理のために受け入れられるかどうかを決定する必要があり、続いて対象場合、さらなる処理のためにDIOメッセージを提示します。
1. If the DIO message is malformed, then the DIO message is not eligible for further processing and a node MUST silently discard it. (See Section 18 for error logging).
1. DIOメッセージが不正である場合、DIOメッセージは、さらなる処理の対象外であり、ノードは静かにそれを捨てなければなりません。 （エラーログについては、セクション18を参照してください）。
2. If the sender of the DIO message is a member of the candidate neighbor set and the DIO message is not malformed, the node MUST process the DIO.
2. DIOメッセージの送信者が候補隣接セットのメンバーであり、DIOメッセージが不正な形式でない場合、ノードは、DIOを処理しなければなりません。
As DIO messages are received from candidate neighbors, the neighbors may be promoted to DODAG parents by following the rules of DODAG discovery as described in Section 8.2. When a node places a neighbor into the DODAG parent set, the node becomes attached to the DODAG through the new DODAG parent node.
DIOメッセージが候補ネイバーから受信されると、隣人は8.2節で説明したようにDODAG発見のルールに従うことによって両親をDODAGに昇格することができます。ノードがDODAG親セットに隣人を置くと、ノードは新しいDODAGの親ノードを介してDODAGに付着します。
The most preferred parent should be used to restrict which other nodes may become DODAG parents. Some nodes in the DODAG parent set may be of a Rank less than or equal to the most preferred DODAG parent. (This case may occur, for example, if an energy-constrained device is at a lesser Rank but should be avoided per an optimization objective, resulting in a more preferred parent at a greater Rank.)
最も好ましい親はDODAGの親になることがあり、他のどのノード制限するために使用する必要があります。 DODAG親セット内の一部のノードが最も好ましいDODAG親以下のランクであってもよいです。 （エネルギー制約デバイスは低いランクであるが、より高いランクでより好ましい親その結果、最適化の目的ごとに回避されるべきであるならば、この場合は、例えば、発生することがあります。）
RPL nodes transmit DIOs using a Trickle timer [RFC6206]. A DIO from a sender with a lesser DAGRank that causes no changes to the recipient's parent set, preferred parent, or Rank SHOULD be considered consistent with respect to the Trickle timer.
RPLノードはトリクルタイマー[RFC6206]を使用してのDIOを送信します。受信者の親セットは、好ましい親、またはランクへの変更を引き起こさない小さいDAGRankと、送信者からのDIOはトリクルタイマーに関して一貫性の考慮されるべきです。
The following packets and events MUST be considered inconsistencies with respect to the Trickle timer, and cause the Trickle timer to reset:
次のパケットとのイベントがトリクルタイマーに関して矛盾と考えられ、およびトリクルタイマーがリセットされなければなりません：
o When a node detects an inconsistency when forwarding a packet, as detailed in Section 11.2.
パケットを転送する際に、セクション11.2で説明するように、Oノードは、矛盾を検出します。
o When a node receives a multicast DIS message without a Solicited Information option, unless a DIS flag restricts this behavior.
DISフラグは、この動作を制限しない限り、Oノードは、希望情報オプションなしマルチキャストDISメッセージを受信します。
o When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior.
Oノードは、希望情報オプションでマルチキャストDISを受信し、DISフラグは、この動作を制限しない限り、ノードは、希望情報オプション内の述語のすべてと一致した場合。
o When a node joins a new DODAG Version (e.g., by updating its DODAGVersionNumber, joining a new RPL Instance, etc.).
Oノードが新しいDODAG版に参加する場合（例えば、など、新しいRPLインスタンスに参加、そのDODAGVersionNumberを更新することにより）。
Note that this list is not exhaustive, and an implementation MAY consider other messages or events to be inconsistencies.
このリストは網羅的ではないことに注意してください、と実装が矛盾する他のメッセージやイベントを考慮することができます。
A node SHOULD NOT reset its DIO Trickle timer in response to unicast DIS messages. When a node receives a unicast DIS without a Solicited Information option, it MUST unicast a DIO to the sender in response. This DIO MUST include a DODAG Configuration option. When a node receives a unicast DIS message with a Solicited Information option and matches the predicates of that Solicited Information option, it MUST unicast a DIO to the sender in response. This unicast DIO MUST include a DODAG Configuration option. Thus, a node MAY transmit a unicast DIS message to a potential DODAG parent in order to probe for DODAG Configuration and other parameters.
ノードは、ユニキャストDISメッセージに応答して、そのDIOトリクルタイマーをリセットされることはありません。ノードは、要請情報オプションなしでユニキャストDISを受信すると、応答して送信者にDIOをユニキャストしなければなりません。このDIOはDODAG設定オプションを含まなければなりません。ノードが希望情報オプションを使用してユニキャストDISメッセージを受信し、その希望情報オプションの述部に一致したとき、それが応答して送信者にDIOをユニキャストしなければなりません。このユニキャストDIOはDODAG設定オプションを含まなければなりません。したがって、ノードはDODAG設定および他のパラメータを探索するために、潜在的なDODAG親へのユニキャストDISメッセージを送信することができます。
The configuration parameters of the Trickle timer are specified as follows:
次のようにトリクルタイマーの設定パラメータが指定されています。
Imin: learned from the DIO message as (2^DIOIntervalMin) ms. The default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.
IMIN：（2 ^ DIOIntervalMin）MSなどDIOメッセージから学びました。 DIOIntervalMinのデフォルト値はDEFAULT_DIO_INTERVAL_MINです。
Imax: learned from the DIO message as DIOIntervalDoublings. The default value of DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.
アイマックス：DIOIntervalDoublingsとしてDIOメッセージから学びました。 DIOIntervalDoublingsのデフォルト値はDEFAULT_DIO_INTERVAL_DOUBLINGSです。
k: learned from the DIO message as DIORedundancyConstant. The default value of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value of 0x00, this is to be treated as a redundancy constant of infinity in RPL, i.e., Trickle never suppresses messages.
K：DIORedundancyConstantとしてDIOメッセージから学びました。 DIORedundancyConstantのデフォルト値はDEFAULT_DIO_REDUNDANCY_CONSTANTです。 kは0×00の値を有する場合RPLにおいて、これはすなわち、トリクルメッセージを抑制したことがない、RPLに無限の冗長定数として扱われるべきです。
The DODAG selection is implementation and OF dependent. In order to limit erratic movements, and all metrics being equal, nodes SHOULD keep their previous selection. Also, nodes SHOULD provide a means to filter out a parent whose availability is detected as fluctuating, at least when more stable choices are available.
DODAGの選択は、実装および依存です。不安定な動きを制限し、すべてのメトリックが等しいために、ノードは、その前の選択を維持する必要があります。また、ノードは、可用性変動として検出される、少なくともより安定な選択肢が利用可能である親をフィルタリングする手段を提供すべきです。
When connection to a grounded DODAG is not possible or preferable for security or other reasons, scattered DODAGs MAY aggregate as much as possible into larger DODAGs in order to allow connectivity within the LLN.
接地DODAGへの接続が可能またはセキュリティまたは他の理由のために望ましくない場合、散乱DODAGsはLLN内の接続を可能にするために、より大きなDODAGsに可能な限り集約することができます。
A node SHOULD verify that bidirectional connectivity and adequate link quality is available with a candidate neighbor before it considers that candidate as a DODAG parent.
ノードは、それがDODAGの親としてその候補者を検討する前に、双方向の接続性と十分なリンク品質が候補隣人で利用可能であることを確認する必要があります。
In some cases, a RPL node may attach to a DODAG as a leaf node only. One example of such a case is when a node does not understand or does not support (policy) the RPL Instance's OF or advertised metric/ constraint. As specified in Section 18.6, related to policy function, the node may either join the DODAG as a leaf node or may not join the DODAG. As mentioned in Section 18.5, it is then recommended to log a fault.
いくつかのケースでは、RPLのノードは、リーフノードとしてDODAGに取り付けることができます。ノードは、RPLインスタンスのまたはアドバタイズメトリック/制約を理解していないか（ポリシー）をサポートしていない場合、このような場合の一例です。ポリシー機能に関連するセクション18.6で指定されるように、ノードがリーフノードとしてDODAGに参加することができるいずれかまたはDODAGに参加しないことができます。セクション18.5で述べたように、障害をログに記録することをお勧めします。
A leaf node does not extend DODAG connectivity; however, in some cases, the leaf node may still need to transmit DIOs on occasion, in particular, when the leaf node may not have always been acting as a leaf node and an inconsistency is detected.
リーフノードはDODAGの接続性を拡張しません。リーフノードは、常に葉ノードとして動作されていない可能性があり、矛盾が検出されたときにしかし、いくつかのケースでは、リーフノードはまだ、具体的には、機会にのDIOを送信する必要があるかもしれません。
A node operating as a leaf node must obey the following rules:
リーフノードとして動作ノードは、以下の規則に従わなければなりません。
3. It MAY suppress DIO transmission, unless the DIO transmission has been triggered due to detection of inconsistency when a packet is being forwarded or in response to a unicast DIS message, in which case the DIO transmission MUST NOT be suppressed.
パケットが転送またはDIO送信が抑制されてはいけません、その場合、ユニキャストDISメッセージに応答しているときDIO送信が原因矛盾の検出にトリガされていない限り3は、DIO送信を抑制することができます。
5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as described in Section 9.10.
セクション9.10に記載されているように5は「1つのホップ」近傍にマルチキャストのDAOを送信することができます。
A particular case that requires a leaf node to send a DIO is if that leaf node was a prior member of another DODAG and another node forwards a message assuming the old topology, triggering an inconsistency. The leaf node needs to transmit a DIO in order to repair the inconsistency. Note that due to the lossy nature of LLNs, even though the leaf node may have optimistically poisoned its routes by advertising a Rank of INFINITE_RANK in the old DODAG prior to becoming a leaf node, that advertisement may have become lost and a leaf node must be capable to send a DIO later in order to repair the inconsistency.
そのリーフノードが別のDODAGの前メンバーであり、別のノードが矛盾をトリガする、古いトポロジを想定メッセージを転送する場合DIOを送信するリーフノードを必要とする特定の場合です。リーフノードは、矛盾を修復するためにDIOを送信する必要があります。 LLNsの非可逆性のために、リーフノードは楽観前葉ノードになるため、古いDODAGでINFINITE_RANKのランクを広告することによって、そのルートを毒している場合であっても、その広告が失われている可能性があり、葉ノードがなければならないことに注意してください矛盾を修復するために、後にDIOを送ることができます。
In the general case, the leaf node MUST NOT advertise itself as a router (i.e., send DIOs).
一般的な場合において、リーフノードは、ルータ（すなわち、のDIOを送る）として自身をアドバタイズしてはいけません。
In some cases, it might be beneficial to adjust the Rank advertised by a node beyond that computed by the OF based on some implementation-specific policy and properties of the node. For example, a node that has a limited battery should be a leaf unless there is no other choice, and may then augment the Rank computation specified by the OF in order to expose an exaggerated Rank.
いくつかのケースでは、いくつかのインプリメンテーション固有のポリシーおよびノードの特性に基づいてOFによって計算それを超えノードによって通知ランクを調整することが有益であるかもしれません。例えば、限られたバッテリを有するノードは、他の選択肢がない場合を除き、葉であるべきで、その後誇張ランクを露出させるためにOFによって指定されたランク計算を増強することができます。
This section describes how RPL discovers and maintains Downward routes. RPL constructs and maintains Downward routes with Destination Advertisement Object (DAO) messages. Downward routes support P2MP flows, from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow toward a DODAG root (or a common ancestor) through an Upward route, then away from the DODAG root to a destination through a Downward route.
このセクションでは、RPLが下方ルートを発見し、維持する方法について説明します。 RPLは、先の広告オブジェクト（DAO）のメッセージと下向きのルートを構築し、維持します。下方へのルートは、リーフへDODAGの根から、P2MPフローをサポート。 P2Pメッセージは、次に離れDODAGルートから目的地までの下向きの経路を通って上方に経路を介してDODAGルート（または共通の祖先）に向かって流れることができる：下向きの経路はまた、P2Pフローをサポートします。
This specification describes the two modes a RPL Instance may choose from for maintaining Downward routes. In the first mode, called "Storing", nodes store Downward routing tables for their sub-DODAG. Each hop on a Downward route in a storing network examines its routing table to decide on the next hop. In the second mode, called "Non-Storing", nodes do not store Downward routing tables. Downward packets are routed with source routes populated by a DODAG root [RFC6554].
この仕様は、RPLインスタンスが下方経路を維持するために選択することができる2つのモードが記載されています。 「保存」と呼ばれる第一のモードでは、ノードは、それらのサブDODAGための下方ルーティングテーブルを格納します。記憶ネットワーク下方にルート上の各ホップは、次のホップを決定するために、そのルーティングテーブルを調べ。 「非の保存」と呼ばれる第二のモードでは、ノードは下向きルーティングテーブルを格納しないでください。下方パケットはDODAGルート[RFC6554]によって移入ソースルートを用いてルーティングされます。
RPL allows a simple one-hop P2P optimization for both storing and non-storing networks. A node may send a P2P packet destined to a one-hop neighbor directly to that node.
RPLは、記憶と非保存ネットワークの両方のためのシンプルな1ホップのP2Pの最適化を可能にします。ノードは、そのノードに直接ワンホップネイバー宛てのP2Pパケットを送信することができます。
To establish Downward routes, RPL nodes send DAO messages Upward. The next-hop destinations of these DAO messages are called "DAO parents". The collection of a node's DAO parents is called the "DAO parent set".
下向きのルートを確立するには、RPLノードは上向きDAOメッセージを送信します。これらのDAOメッセージの次のホップ先は、「DAOの親」と呼ばれています。ノードのDAOの両親のコレクションは、「DAOの親セット」と呼ばれています。
1. A node MAY send DAO messages using the all-RPL-nodes multicast address, which is an optimization to provision one-hop routing. The 'K' bit MUST be cleared on transmission of the multicast DAO.
1.ノードが提供ワンホップルーティングに最適化された全RPLノードマルチキャストアドレスを使用して、DAOメッセージを送信することができます。 「K」ビットは、マルチキャストDAOの伝送にきれいにしなければなりません。
3. In Storing mode operation, a node MUST NOT address unicast DAO messages to nodes that are not DAO parents.
3.モード動作を保存するには、ノードは、DAO親ではないノードにユニキャストDAOのメッセージの宛先を指定してはなりません。
4. In Storing mode operation, the IPv6 source and destination addresses of a DAO message MUST be link-local addresses.
モード動作を保存4.、DAOメッセージのIPv6送信元アドレスと宛先アドレスがリンクローカルアドレスでなければなりません。
5. In Non-Storing mode operation, a node MUST NOT address unicast DAO messages to nodes that are not DODAG roots.
非保存モード動作5.、ノードは、根をDODAGされていないノードにユニキャストDAOメッセージをアドレス指定してはいけません。
6. In Non-Storing mode operation, the IPv6 source and destination addresses of a DAO message MUST be a unique-local or a global address.
非保存モード動作6.、DAOメッセージのIPv6送信元アドレスと宛先アドレスは、一意のローカルまたはグローバルアドレスでなければなりません。
The selection of DAO parents is implementation and Objective Function specific.
DAOの両親の選択は、実装と目的関数固有のものです。
Destination Advertisement may be configured to be entirely disabled, or operate in either a Storing or Non-Storing mode, as reported in the MOP in the DIO message.
DIOメッセージでMOPに報告したように先の広告は、完全に無効にすること、または保存または非保存モードのいずれかで動作するように構成することができます。
1. All nodes who join a DODAG MUST abide by the MOP setting from the root. Nodes that do not have the capability to fully participate as a router, e.g., that do not match the advertised MOP, MAY join the DODAG as a leaf.
1. DODAGに参加するすべてのノードはルートから設定MOPを遵守しなければなりません。宣伝MOPと一致しない完全例えば、ルータとして参加する能力を持たないノードは、葉としてDODAGに参加することができます。
2. If the MOP is 0, indicating no Downward routing, nodes MUST NOT transmit DAO messages and MAY ignore DAO messages.
2. MOPが下向きのルーティングを示さない、0である場合、ノードは、DAOメッセージを送信してはいけませんとDAOメッセージを無視してもよいです。
3. In Non-Storing mode, the DODAG root SHOULD store source routing table entries for destinations learned from DAOs. The DODAG root MUST be able to generate source routes for those destinations learned from DAOs that were stored.
非保存のモードでは、宛先のソースルーティングテーブルエントリを格納する必要がありDODAGルートはのDAOから学びました。 DODAGルートが格納されたのDAOから学んだもの宛先のソースルートを生成できなければなりません。
4. In Storing mode, all non-root, non-leaf nodes MUST store routing table entries for destinations learned from DAOs.
目的地は、DAOをから学んだため4モードを保存するには、すべての非ルートは、非リーフノードは、ルーティングテーブルエントリを保存しなければなりません。
A DODAG can have one of several possible modes of operation, as defined by the MOP field. Either it does not support Downward routes, it supports Downward routes through source routing from DODAG roots, or it supports Downward routes through in-network routing tables.
DODAGはMOPフィールドによって定義されるように、いくつかの動作可能なモードのいずれかを有することができます。それが下のルートをサポートしていない、それはDODAGの根からソースルーティングを通って下方にルートをサポートし、またはそれは、ルーティングテーブルに、ネットワーク下向きのルートを経由のいずれかをサポート。
When Downward routes are supported through source routing from DODAG roots, it is generally expected that the DODAG root has stored the source routing information learned from DAOs in order to construct the source routes. If the DODAG root fails to store some information, then some destinations may be unreachable.
下向きルートがDODAG根からソースルーティングを介して支持されている場合、一般DODAGルートは、ソースルートを構築するためにのDAOから学習ソースルーティング情報を格納していることが期待されます。 DODAGルートはいくつかの情報を格納するのに失敗した場合、一部の宛先が到達できないことがあります。
When Downward routes are supported through in-network routing tables, the multicast operation defined in this specification may or may not be supported, also as indicated by the MOP field.
下向きルートがルーティングテーブルにネットワークを介して支持されている場合、本明細書で定義されたマルチキャスト動作はまたはMOPフィールドによって示されるとしても、サポートしてもしなくてもよいです。
When Downward routes are supported through in-network routing tables, as described in this specification, it is expected that nodes acting as routers have been provisioned sufficiently to hold the required routing table state. If a node acting as a router is unable to hold the full routing table state then the routing state is not complete, messages may be dropped as a consequence, and a fault may be logged (Section 18.5). Future extensions to RPL may elaborate on refined actions/behaviors to manage this case.
下向きの経路を介して支持されている場合に、ネットワークルーティングテーブルは、本明細書に記載されているように、ルータが必要なルーティングテーブルの状態を保持するために十分にプロビジョニングされているようにノードが作用することが予想されます。ルータとして動作するノードは完全なルーティングテーブルの状態を保持することができない場合は、ルーティング状態はメッセージが結果として破棄される可能性があり、および障害（セクション18.5）に記録されることがあり、完全なものではありません。 RPLへの将来の拡張には、このケースを管理するための洗練されたアクション/行動について詳しく説明します。
As of the writing of this specification, RPL does not support mixed-mode operation, where some nodes source route and other store routing tables: future extensions to RPL may support this mode of operation.
RPLの将来の拡張は、この動作モードをサポートすることができる。本明細書の執筆時点では、RPLは、いくつかのノードのソースルートと他の店舗のルーティングテーブルは、混在モードの動作をサポートしていません。
For each Target that is associated with (owned by) a node, that node is responsible to emit DAO messages in order to provision the Downward routes. The Target+Transit information contained in those DAO messages subsequently propagates Up the DODAG. The Path Sequence counter in the Transit information option is used to indicate freshness and update stale Downward routing information as described in Section 7.
（が所有）に関連付けられている各ターゲットノードに対して、そのノードをプロビジョニングするために下向きの経路をDAOメッセージを放出する責任があります。これらのDAOメッセージに含まれるターゲット+交通情報は、その後DODAGアップ伝播します。交通情報オプション内のパスシーケンスカウンタは、新鮮さを示し、第7章で説明したように失効下方ルーティング情報を更新するために使用されます。
For a Target that is associated with (owned by) a node, that node MUST increment the Path Sequence counter, and generate a new DAO message, when:
ノード（が所有）に関連付けられているターゲットに対する、そのノードは、パスシーケンスカウンタをインクリメントし、新しいDAOメッセージを生成する必要があります
1. the Path Lifetime is to be updated (e.g., a refresh or a no-Path).
1.パス寿命が更新される（例えば、リフレッシュ又は全くパス）。
For a Target that is associated with (owned by) a node, that node MAY increment the Path Sequence counter, and generate a new DAO message, on occasion in order to refresh the Downward routing information. In Storing mode, the node generates such a DAO to each of its DAO parents in order to enable multipath. All DAOs generated at the same time for the same Target MUST be sent with the same Path Sequence in the Transit Information.
（が所有）に関連付けられているターゲットノードについて、そのノードが下方ルーティング情報を更新するために際に、パスシーケンスカウンタをインクリメントし、新しいDAOメッセージを生成してもよいです。モードを格納する際に、ノードは、マルチパスを有効にするために、そのDAOの親の各々に、そのようなDAOを生成します。同じターゲットに対して同時に生成されたすべてのDAOは、トランジットの情報で同じパスシーケンスで送らなければなりません。
A node might send DAO messages when it receives DAO messages, as a result of changes in its DAO parent set, or in response to another event such as the expiry of a related prefix lifetime. In the case of receiving DAOs, it matters whether the DAO message is "new" or contains new information. In Non-Storing mode, every DAO message a node receives is "new". In Storing mode, a DAO message is "new" if it satisfies any of these criteria for a contained Target:
それは、このような関連プレフィックス寿命の有効期限として、そのDAOの親セットの変化の結果として、または他のイベントに応答して、DAOメッセージを受信したときにノードがDAOメッセージを送信することがあります。 DAOを受信した場合には、DAOメッセージが「新規」であるか、新たな情報が含まれているかどうか問題になります。非保存モードでは、ノードが受信したすべてのDAOのメッセージは、「新」です。モードを保存するには、DAOメッセージは、それが含まれているターゲットのためのこれらの基準のいずれかを満たしていれば、「新」です。
3. it is a No-Path DAO message that removes the last Downward route to a prefix.
3.それは、プレフィックスに最後の下向きのルートを削除しません - パスDAOメッセージです。
A node that receives a DAO message from its sub-DODAG MAY suppress scheduling a DAO message transmission if that DAO message is not new.
そのDAOメッセージが新しくない場合は、そのサブDODAGからDAOメッセージを受信したノードは、DAOメッセージ送信をスケジューリング抑制することができます。
1. If a node sends a DAO message with newer or different information than the prior DAO message transmission, it MUST increment the DAOSequence field by at least one. A DAO message transmission that is identical to the prior DAO message transmission MAY increment the DAOSequence field.
1.ノードが前DAOメッセージ送信よりも新しい、または異なる情報を有するDAOメッセージを送信する場合、それは少なくとも一つによってDAOSequenceフィールドをインクリメントしなければなりません。前DAOメッセージ送信と同一であるDAOメッセージ送信はDAOSequenceフィールドをインクリメントしてもよい（MAY）。
2. The RPLInstanceID and DODAGID fields of a DAO message MUST be the same value as the members of the node's parent set and the DIOs it transmits.
2. DAOメッセージのRPLInstanceIDとDODAGIDフィールドはノードの親セットのメンバーと、それは送信のDIOと同じ値である必要があります。
3. A node MAY set the 'K' flag in a unicast DAO message to solicit a unicast DAO-ACK in response in order to confirm the attempt.
3.ノードが試行を確認するために応答して、ユニキャストDAO-ACKを要求するユニキャストDAOメッセージに「K」フラグを設定してもよいです。
4. A node receiving a unicast DAO message with the 'K' flag set SHOULD respond with a DAO-ACK. A node receiving a DAO message without the 'K' flag set MAY respond with a DAO-ACK, especially to report an error condition.
4.「K」フラグを設定してユニキャストDAOメッセージを受信したノードは、DAO-ACKで応答すべきです。 「K」フラグを設定することなく、DAOメッセージを受信したノードは、特にエラー状態を報告するために、DAO-ACKで応答することができます。
5. A node that sets the 'K' flag in a unicast DAO message but does not receive a DAO-ACK in response MAY reschedule the DAO message transmission for another attempt, up until an implementation-specific number of retries.
前記ユニキャストDAOメッセージに「K」フラグを設定するが、応答にDAO-ACKを受信しないノードは、最大再試行の実装固有の番号まで、別の試みのためにDAOメッセージの送信を再スケジュールするかもしれません。
6. Nodes SHOULD ignore DAOs without newer sequence numbers and MUST NOT process them further.
6.ノードは、新しいシーケンス番号なしのDAOを無視すべきであるし、さらにそれらを処理してはいけません。
Unlike the Version field of a DIO, which is incremented only by a DODAG root and repeated unchanged by other nodes, DAOSequence values are unique to each node. The sequence number space for unicast and multicast DAO messages can be either the same or distinct. It is RECOMMENDED to use the same sequence number space.
DODAGルートだけインクリメントされ、他のノードによって不変繰り返されるDIOのバージョンフィールドとは異なり、DAOSequence値が各ノードに固有です。ユニキャストおよびマルチキャストDAOメッセージのシーケンス番号空間は同じまたは別個のいずれかであり得ます。同じシーケンス番号空間を使用することをお勧めします。
DAOs follow a common structure in both storing and non-storing networks. In the most general form, a DAO message may include several groups of options, where each group consists of one or more Target options followed by one or more Transit Information options.
DAOには、記憶と非保存ネットワークの両方に共通の構造に従ってください。最も一般的な形態では、DAOメッセージは、各グループは、1つまたは複数の交通情報オプションに続く1つまたは複数のターゲットオプションで構成オプションのいくつかのグループを含むことができます。
The entire group of Transit Information options applies to the entire group of Target options. Later sections describe further details for each mode of operation.
交通情報オプションのグループ全体を対象とするオプションのグループ全体に適用されます。その後のセクションでは、各動作モードのための更なる詳細を説明します。
1. RPL nodes MUST include one or more RPL Target options in each DAO message they transmit. One RPL Target option MUST have a prefix that includes the node's IPv6 address if that node needs the DODAG to provision Downward routes to that node. The RPL Target option MAY be immediately followed by an opaque RPL Target Descriptor option that qualifies it.
1. RPLノードは、それらが送信する各DAOメッセージ内の1つまたは複数のRPLターゲットオプションを含まなければなりません。一つRPLターゲットオプションは、そのノードは、そのノードに提供下向きルートにDODAGを必要とする場合は、ノードのIPv6アドレスが含まれるプレフィックスを持たなければなりません。 RPLターゲットオプションは、すぐにそれを修飾不透明RPLターゲット記述子オプションを続けてもよいです。
2. When a node updates the information in a Transit Information option for a Target option that covers one of its addresses, it MUST increment the Path Sequence number in that Transit Information option. The Path Sequence number MAY be incremented occasionally to cause a refresh to the Downward routes.
ノードはそのアドレスのいずれかをカバーし、ターゲットオプションのトランジット情報オプションの情報を更新する場合2.は、その交通情報オプションでパスシーケンス番号を増加しなければなりません。パスシーケンス番号は下向きルートにリフレッシュを引き起こすことが時折増分することができます。
3. One or more RPL Target options in a unicast DAO message MUST be followed by one or more Transit Information options. All the transit options apply to all the Target options that immediately precede them.
ユニキャストDAOメッセージで3つ以上のRPLターゲットオプションは、一つ以上の交通情報オプションが続かなければなりません。すべてのトランジットオプションは、それらをすぐに先行するすべてのターゲットオプションに適用されます。
4. Multicast DAOs MUST NOT include the DODAG Parent Address subfield in Transit Information options.
4.マルチキャストDAOには、交通情報オプションでDODAG親アドレスのサブフィールドを含んではいけません。
5. A node that receives and processes a DAO message containing information for a specific Target, and that has prior information for that Target, MUST use the Path Sequence number in the Transit Information option associated with that Target in order to determine whether or not the DAO message contains updated information per Section 7.
5.特定の標的のための情報を含むDAOメッセージを受信し、処理するノード、それは、そのターゲットのための事前情報を有するか否かを決定するために、そのターゲットに関連付けられた交通情報オプション内のパスシーケンス番号を使用する必要がありますDAOメッセージは、第7節ごとに更新情報が含まれています。
6. If a node receives a DAO message that does not follow the above rules, it MUST discard the DAO message without further processing.
前記ノードは、上記の規則に従わないDAOメッセージを受信した場合、それはさらに処理することなくDAOメッセージを破棄しなければなりません。
In Non-Storing mode, the root builds a strict source routing header, hop-by-hop, by recursively looking up one-hop information that ties a Target (address or prefix) and a transit address together. In some cases, when a child address is derived from a prefix that is owned and advertised by a parent, that parent-child relationship may be inferred by the root for the purpose of constructing the source routing header. In all other cases, it is necessary to inform the root of the transit-Target relationship from a reachable target, so as to later enable the recursive construction of the routing header. An address that is advertised as a Target in a DAO message MUST be collocated in the same router, or reachable on-link by the router that owns the address that is indicated in the associated Transit Information. The following additional rules apply to ensure the continuity of the end-to-end source route path:
非保存モードでは、ルートは、再帰的に一緒にターゲット（アドレスまたはプレフィックス）とトランジットアドレスを結びつけるワンホップ情報を検索することにより、ホップバイホップヘッダを、ルーティング厳密ソースを構築します。子アドレスを所有し、親によってアドバタイズされるプレフィックスに由来するいくつかの場合において、その親子関係は、ソース・ルーティング・ヘッダを構築するためにルートによって推測することができます。他のすべての場合において、後でルーティングヘッダの再帰的な構造を可能にするように、到達目標から通過対象関係のルートを通知する必要があります。 DAOメッセージにターゲットとして宣伝されているアドレスは、同じルータに併置、または関連する交通情報に示されているアドレスを所有しているルータによってリンク上の到達可能でなければなりません。以下の追加の規則は、エンドツーエンドのソースルートパスの連続性を保証するために適用されます。
1. The address of a parent used in the transit option MUST be taken from a PIO from that parent with the 'R' flag set. The 'R' flag in a PIO indicates that the prefix field actually contains the full parent address but the child SHOULD NOT assume that the parent address is on-link.
1.トランジットオプションで使用する親のアドレスが「R」フラグを設定してその親からPIOから取らなければなりません。 PIOでの「R」フラグはプレフィックスフィールドは、実際に完全な親アドレスが含まれていることを示しますが、子は親のアドレスがオンリンクであることを仮定するべきではありません。
2. A PIO with an 'A' flag set indicates that the RPL child node may use the prefix to autoconfigure an address. A parent that advertises a prefix in a PIO with the 'A' flag set MUST ensure that the address or the whole prefix in the PIO is reachable from the root by advertising it as a DAO target. If the parent also sets the 'L' flag indicating that the prefix is on-link, then it MUST advertise the whole prefix as Target in a DAO message. If the 'L' flag is cleared and the 'R' flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target.
「」フラグが設定された2 A PIOは、RPLの子ノードがアドレスを自動設定する接頭辞を使用することができることを示しています。 「」フラグを設定してPIOでプレフィックスをアドバタイズ親がPIOのアドレスまたは全体のプレフィックスがDAOのターゲットとしてそれを広告することにより、ルートから到達可能であることを保証しなければなりません。親はまた、プレフィックスがオンリンクであることを示す「L」フラグを設定した場合、それはDAOメッセージにターゲットとして全体プレフィックスを通知しなければなりません。 「L」フラグがクリアされ、「R」フラグがセットされ、親がPIOに自身のアドレスを提供することを示す場合、親はDAO対象としてそのアドレスをアドバタイズしなければなりません。
3. An address that is advertised as Target in a DAO message MUST be collocated in the same router or reachable on-link by the router that owns the address that is indicated in the associated Transit Information.
DAOメッセージにターゲットとして宣伝されている3.アドレスは、関連する交通情報に示されるアドレスを所有しているルータがリンク上の同じルータまたは到達可能に並置されなければなりません。
4. In order to enable an optimum compression of the routing header, the parent SHOULD set the 'R' flag in all PIOs with the 'A' flag set and the 'L' flag cleared, and the child SHOULD prefer to use as transit the address of the parent that is found in the PIO that is used to autoconfigure the address that is advertised as Target in the DAO message.
前記ルーティングヘッダの最適圧縮を可能にするために、親がクリア「」フラグがセットと「L」フラグですべてのPIOで「R」フラグを設定する必要があり、子供がトランジットとして使用することを好むべきですDAOメッセージにターゲットとして宣伝されているアドレスを自動設定するために使用されるPIOで発見された親のアドレス。
5. A router might have targets that are not known to be on-link for a parent, either because they are addresses located on an alternate interface or because they belong to nodes that are external to RPL, for instance connected hosts. In order to inject such a Target in the RPL network, the router MUST advertise itself as the DODAG Parent Address subfield in the Transit Information option for that target, using an address that is on-link for that nodes DAO parent. If the Target belongs to an external node, then the router MUST set the External 'E' flag in the Transit Information.
5.ルータは、親のためにリンクであることが知られていないターゲットがあるかもしれない、いずれかの彼らは、代替インターフェイスまたはそれらは、例えば接続されたホストのために、RPLの外部にあるノードに属しているので、位置アドレスであるからです。 RPLのネットワークで、このようなターゲットを注入するために、ルータはそれがDAOの親ノードのためにリンクされたアドレスを使用して、そのターゲットの交通情報オプションでDODAGの親アドレスサブフィールドとしての地位を宣伝しなければなりません。ターゲットは、外部ノードに属している場合、ルータはトランジットの情報に外部「E」フラグを設定しなければなりません。
A child node that has autoconfigured an address from a parent PIO with the 'L' flag set does not need to advertise that address as a DAO Target since the parent ensures that the whole prefix is already reachable from the root. However, if the 'L' flag is not set, then it is necessary, in Non-Storing mode, for the child node to inform the root of the parent-child relationship, using a reachable address of the parent, so as to enable the recursive construction of the routing header. This is done by associating an address of the parent as transit with the address of the child as Target in a DAO message.
親が全体のプレフィックスがすでにルートから到達可能であることを保証しますので、「L」フラグが設定された親PIOからアドレスを自動構成している子ノードは、DAOのターゲットとして、そのアドレスをアドバタイズする必要はありません。 「L」フラグが設定されていない場合は可能なように子ノードは、親の到達可能なアドレスを使用して、親子関係のルートを通知するためにしかし、それは、非保存モードでは、必要ですルーティングヘッダの再帰的構造。これは、DAOメッセージで、ターゲットなどの子のアドレスでのトランジットとして親のアドレスを関連付けることによって行われます。
Because DAOs flow Upward, receiving a unicast DAO can trigger sending a unicast DAO to a DAO parent.
DAOをが上向きの流れなので、ユニキャストのDAOを受信すると、DAOの親にユニキャストDAOを送信するトリガすることができます。
1. On receiving a unicast DAO message with updated information, such as containing a Transit Information option with a new Path Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO message immediately. It SHOULD delay sending the DAO message in order to aggregate DAO information from other nodes for which it is a DAO parent.
こうした新しいパスの配列とトランジット情報オプションを含むものとして、更新された情報をユニキャストDAOメッセージを受信すると1、ノードは、DAOを送るべきです。それはすぐにこのDAOメッセージを送るべきではありません。それはDAOの親であるため、他のノードからDAO情報を集約するために、DAOメッセージを送信遅らせるべきです。
2. A node SHOULD delay sending a DAO message with a timer (DelayDAO). Receiving a DAO message starts the DelayDAO timer. DAO messages received while the DelayDAO timer is active do not reset the timer. When the DelayDAO timer expires, the node sends a DAO.
2.ノードは、タイマ（DelayDAO）とDAOメッセージを送信遅らせるべきです。 DAOメッセージを受信すると、DelayDAOタイマーを開始します。 DelayDAOタイマーはタイマーをリセットしないアクティブな間DAOメッセージを受け取りました。 DelayDAOタイマーの期限が切れると、ノードは、DAOを送信します。
3. When a node adds a node to its DAO parent set, it SHOULD schedule a DAO message transmission.
3.ノードがDAO親セットにノードを追加すると、それはDAOメッセージの送信をスケジュールする必要があります。
DelayDAO's value and calculation is implementation dependent. A default value of DEFAULT_DAO_DELAY is defined in this specification.
DelayDAOの値と計算は実装依存です。 DEFAULT_DAO_DELAYのデフォルト値はこの仕様で定義されています。
Nodes can trigger their sub-DODAG to send DAO messages. Each node maintains a DAO Trigger Sequence Number (DTSN), which it communicates through DIO messages.
ノードは、DAOメッセージを送信するために彼らのサブDODAGをトリガすることができます。各ノードは、DIOメッセージを介して通信DAOトリガシーケンス番号（DTSN）を、維持します。
1. If a node hears one of its DAO parents increment its DTSN, the node MUST schedule a DAO message transmission using rules in Sections 9.3 and 9.5.
ノードがDAOの親の一方がそのDTSNをインクリメント聞く場合、ノードはセクション9.3と9.5のルールを使用して、DAOメッセージ送信をスケジュールする必要があります1。
2. In Non-Storing mode, if a node hears one of its DAO parents increment its DTSN, the node MUST increment its own DTSN.
非保存モードでは、2ノードがそのDAOの両親のいずれかがそのDTSNをインクリメント聞いた場合、ノードは自身のDTSNを増加しなければなりません。
In a Storing mode of operation, as part of routine routing table updates and maintenance, a storing node MAY increment DTSN in order to reliably trigger a set of DAO updates from its immediate children.
動作の保存モードでは、ルーチンは、ルーティングテーブルの更新と保守の一環として、記憶ノードは確実にその直下の子からDAOの更新のセットをトリガするためにDTSNをインクリメントしてもよい（MAY）。
In a Storing mode of operation, it is not necessary to trigger DAO updates from the entire sub-DODAG, since that state information will propagate hop-by-hop Up the DODAG.
動作の保存モードでは、その状態情報がホップバイホップアップDODAGを伝播するので、全体のサブDODAGからDAOの更新をトリガする必要はありません。
In a Non-Storing mode of operation, a DTSN increment will also cause the immediate children of a node to increment their DTSN in turn, triggering a set of DAO updates from the entire sub-DODAG. Typically, in a Non-Storing mode of operation, only the root would independently increment the DTSN when a DAO refresh is needed but a global repair (such as by incrementing DODAGVersionNumber) is not desired. Typically, in a Non-Storing mode of operation, all non-root nodes would increment their DTSN only when their parent(s) are observed to do so.
操作の非保存モードでは、DTSN増分はまた、全体のサブDODAGからDAOの更新のセットをトリガー、ノードの直接の子どもたちが順番に自分のDTSNをインクリメントするようになります。 DAOリフレッシュが必要とされているが（例えばDODAGVersionNumberを増分することによってなど）グローバル修復が望まれていない場合、典型的には、操作の非保存モードでは、唯一のルートは、独立DTSNをインクリメントするであろう。典型的には、操作の非保存モードでは、すべての非ルートノードは、親（複数可）はそうすることが観察された場合にのみ、そのDTSNをインクリメントするであろう。
In general, a node may trigger DAO updates according to implementation-specific logic, such as based on the detection of a Downward route inconsistency or occasionally based upon an internal timer.
一般的に、ノードは、内部タイマに基づいて下向き経路矛盾または時折の検出に基づいて、実装固有のロジックに従ってDAOの更新をトリガすることができます。
In a storing network, selecting a proper DelayDAO for triggered DAOs can greatly reduce the number of DAOs transmitted. The trigger flows Down the DODAG; in the best case, the DAOs flow Up the DODAG such that leaves send DAOs first, with each node sending a DAO message only once. Such a scheduling could be approximated by setting DelayDAO inversely proportional to Rank. Note that this suggestion is intended as an optimization to allow efficient aggregation (it is not required for correct operation in the general case).
記憶ネットワークでは、トリガのDAOのために適切なDelayDAOを選択することは非常に送信のDAOの数を減らすことができます。トリガーはDODAGを流下します。最良の場合には、DAOには、各ノードは一度だけDAOメッセージを送信すると、最初のDODAG葉が送信されるようにDAOをアップに流れます。このようなスケジューリングはランクに反比例DelayDAOを設定することにより近似することができます。この提案は、（それが一般的なケースでは、正しい動作のために必要とされない）効率的な集約を可能にする最適化として意図されていることに留意されたいです。
In Non-Storing mode, RPL routes messages Downward using IP source routing. The following rule applies to nodes that are in Non-Storing mode. Storing mode has a separate set of rules, described in Section 9.8.
IPソースルーティングを用いた下向き非保存モードでは、RPLのルートメッセージ。次のルールは非保存モードになっているノードに適用されます。モードを記憶するセクション9.8で説明された規則の別個の組を有しています。
1. The DODAG Parent Address subfield of a Transit Information option MUST contain one or more addresses. All of these addresses MUST be addresses of DAO parents of the sender.
1.交通情報オプションのDODAG親アドレスサブフィールドは、1つ以上のアドレスを含まなければなりません。これらのアドレスのすべては、送信者のDAOの両親のアドレスでなければなりません。
2. DAOs are sent directly to the root along a default route installed as part of the parent selection.
2.のDAOは、親の選択の一部としてインストールされたデフォルトルートに沿ってルートに直接送信されます。
3. When a node removes a node from its DAO parent set, it MAY generate a new DAO message with an updated Transit Information option.
ノードはそのDAOの親セットからノードを削除する3.それが更新さトランジット情報オプションで新しいDAOメッセージを生成することができます。
In Non-Storing mode, a node uses DAOs to report its DAO parents to the DODAG root. The DODAG root can piece together a Downward route to a node by using DAO parent sets from each node in the route. The Path Sequence information may be used to detect stale DAO information. The purpose of this per-hop route calculation is to minimize traffic when DAO parents change. If nodes reported complete source routes, then on a DAO parent change, the entire sub-DODAG would have to send new DAOs to the DODAG root. Therefore, in Non-Storing mode, a node can send a single DAO, although it might choose to send more than one DAO message to each of multiple DAO parents.
非保存モードでは、ノードはDODAGルートにそのDAOの両親を報告するためのDAOを使用しています。 DODAGルートは、ルートの各ノードからDAOの親セットを使用してノードに下向きの経路をつなぎ合わせることができます。パスの配列情報は、古いDAOの情報を検出するために使用することができます。このホップごとの経路計算の目的は、DAOの親が変更されたときにトラフィックを最小限に抑えることです。ノードは完全なソースルートを報告した場合には、DAOの親変化に、全体のサブDODAGはDODAGルートに新しいのDAOを送信する必要があります。それは複数のDAOの両親のそれぞれに複数のDAOメッセージを送信することを選択するかもしれませんがため、非保存モードでは、ノードは、単一DAOを送ることができます。
Nodes pack DAOs by sending a single DAO message with multiple RPL Target options. Each RPL Target option has its own, immediately following, Transit Information options.
ノードは、複数のRPLターゲットオプションを持つ単一DAOメッセージを送信することでのDAOを詰めます。各RPLターゲットオプションは、独自の、直後の、交通情報オプションがあります。
In Storing mode, RPL routes messages Downward by the IPv6 destination address. The following rules apply to nodes that are in Storing mode:
モードを保存するには、IPv6宛先アドレスにより下方RPLメッセージをルーティングします。次の規則は、モードを保存しているノードに適用されます。
1. The DODAG Parent Address subfield of a Transmit Information option MUST be empty.
1.送信情報オプションのDODAG親アドレスサブフィールドが空でなければなりません。
2. On receiving a unicast DAO, a node MUST compute if the DAO would change the set of prefixes that the node itself advertises. This computation SHOULD include consultation of the Path Sequence information in the Transit Information options associated with the DAO, to determine if the DAO message contains newer information that supersedes the information already stored at the node. If so, the node MUST generate a new DAO message and transmit it, following the rules in Section 9.5. Such a change includes receiving a No-Path DAO.
ユニキャストDAOを受信2. DAOは、ノード自身がアドバタイズプレフィックスの組を変更するならば、ノードは、計算しなければなりません。この計算は、DAOメッセージが既にノードに格納された情報を優先し、新しい情報が含まれているかどうかを決定するために、DAOに関連付けられた交通情報オプションでパスシーケンス情報の相談を含むべきです。その場合、ノードは、セクション9.5の規則に従って、新しいDAOメッセージを生成し、それを伝えなければなりません。このような変化はありません - パスDAOを受信することを含みます。
3. When a node generates a new DAO, it SHOULD unicast it to each of its DAO parents. It MUST NOT unicast the DAO message to nodes that are not DAO parents.
ノードが新しいDAOを生成する場合3.、そのDAOの親の各々にそれをユニキャストすべきです。これは、DAO親ではないノードにDAOメッセージをユニキャストしてはなりません。
4. When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message (Section 6.4.3) to that removed DAO parent to invalidate the existing route.
4.ノードがDAO親セットからノードを削除する場合、それは既存のルートを無効にするために、その除去DAO親に無パスDAOメッセージ（6.4.3項）を送信すべきです。
5. If messages to an advertised Downward address suffer from a forwarding error, Neighbor Unreachable Detection (NUD), or similar failure, a node MAY mark the address as unreachable and generate an appropriate No-Path DAO.
前記アドバタイズ下向きアドレスへメッセージが転送エラーに苦しむ場合は、近隣到達不能検出（NUD）、または同様の障害は、ノードが到達不能としてアドレスをマークし、適切な無パスDAOを生成することができます。
DAOs advertise to which destination addresses and prefixes a node has routes. Unlike in Non-Storing mode, these DAOs do not communicate information about the routes themselves: that information is stored within the network and is implicit from the IPv6 source address. When a storing node generates a DAO, it uses the stored state of DAOs it has received to produce a set of RPL Target options and their associated Transmit Information options.
DAOは、ノードがルートを持っているためにどの宛先アドレスとプレフィックス広告します。非保存モードとは異なり、これらのDAOは、ルート自身に関する情報を通信しない：その情報は、ネットワーク内に格納され、IPv6ソースアドレスから暗黙的です。記憶ノードは、DAOを生成するとき、それはRPLターゲット・オプションと関連する送信情報オプションのセットを生成するために受信したのDAOの格納された状態を使用します。
Because this information is stored within each node's routing tables, in Storing mode, DAOs are communicated directly to DAO parents, who store this information.
この情報は、モードを保存するには、各ノードのルーティングテーブル内に格納されているため、DAOを、この情報を格納するDAOの親に直接伝達されます。
A DAO message from a node contains one or more Target options. Each Target option specifies either a prefix advertised by the node, a prefix of addresses reachable outside the LLN, the address of a destination in the node's sub-DODAG, or a multicast group to which a node in the sub-DODAG is listening. The Path Control field of the Transit Information option allows nodes to request or allow for multiple Downward routes. A node constructs the Path Control field of a Transit Information option as follows:
ノードからDAOメッセージは、1つまたは複数のターゲット・オプションを含んでいます。各ターゲットオプションは、ノードによってアドバタイズプレフィックス、LLN、ノードのサブDODAGの宛先のアドレス、またはサブDODAGが待機しているノードへのマルチキャストグループ外の到達可能アドレスのプレフィックスのいずれかを指定します。交通情報オプションのパス制御フィールドは、ノードが要求したり、複数の下向きの経路を可能にすることができます。次のようにノードは、トランジット情報オプションのパス制御フィールドを構築します。
1. The bit width of the Path Control field MUST be equal to the value (PCS + 1), where PCS is specified in the control field of the DODAG Configuration option. Bits greater than or equal to the value (PCS + 1) MUST be cleared on transmission and MUST be ignored on reception. Bits below that value are considered "active" bits.
1パス制御フィールドのビット幅は、PCSがDODAG設定オプションの制御フィールドで指定された値（PCS + 1）に等しくなければなりません。値（PCS + 1）以上のビットは、送信時にクリアしなければならなくて、受信時に無視しなければなりません。その値は以下のビットが「アクティブ」ビットであると考えられます。
2. The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the patch control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated.
各グループは、同じ嗜好のDAOの親から成るパス制御フィールドを移入しながら2ノードは、論理的にそのDAOの親のグループを構築しなければなりません。これらの基は、パス制御サブフィールド（図27参照）上にDAOの親の論理マッピングを可能にする好みに従って順序付けされなければなりません。グループは、パッチ制御フィールドの全ビット幅にわたって拡張するために繰り返すことができるが、その嗜好を適切に伝達されるように、繰り返し基を含むためには、保持されなければなりません。
3. For a RPL Target option describing a node's own address or a prefix outside the LLN, at least one active bit of the Path Control field MUST be set. More active bits of the Path Control field MAY be set.
ノード自身のアドレスまたはLLN外部プレフィックスを記述するRPLターゲットオプション3.、パス制御フィールドの少なくとも1つの有効ビットがセットされなければなりません。パス制御フィールドのより積極的なビットが設定されるかもしれません。
4. If a node receives multiple DAOs with the same RPL Target option, it MUST bitwise-OR the Path Control fields it receives. This aggregated bitwise-OR represents the number of Downward routes the prefix requests.
ノードが同じRPLターゲットオプションで複数のDAOを受け取る4.場合は、ビット単位-OR、それが受信パス制御フィールドをしなければなりません。この集約されたビット単位-ORは、下向きのルートプレフィックス要求の数を表します。
5. When a node sends a DAO message to one of its DAO parents, it MUST select one or more of the bits that are set active in the subfield that is mapped to the group containing that DAO parent from the aggregated Path Control field. A given bit can only be presented as active to one parent. The DAO message it transmits to its parent MUST have these active bits set and all other active bits cleared.
5.ノードがDAOの両親のいずれかにDAOメッセージを送信すると、それは集約パスコントロールフィールドからそのDAOの親を含むグループにマッピングされるサブフィールドでアクティブに設定されているビットのうちの1つ以上を選択しなければなりません。与えられたビットは、ただ1人の親にアクティブとして提示することができます。それは親に送信DAOメッセージセットこれらのアクティブビットとクリア他のすべてのアクティブビットを持たなければなりません。
6. For the RPL Target option and DAOSequence number, the DAOs a node sends to different DAO parents MUST have disjoint sets of active Path Control bits. A node MUST NOT set the same active bit on DAOs to two different DAO parents.
RPLターゲットオプションとDAOSequence番号6.は、ノードが別のDAOの親に送信するのDAOは、アクティブパス制御ビットの互いに素な集合を持たなければなりません。ノードは、二つの異なるDAOの両親へのDAOで同じアクティブビットを設定してはいけません。
7. Path Control bits SHOULD be allocated according to the preference mapping of DAO parents onto Path Control subfields, such that the active Path Control bits, or groupings of bits, that belong to a particular Path Control subfield are allocated to DAO parents within the group that was mapped to that subfield.
7.パス制御ビットがアクティブパス制御ビット、または特定の経路制御サブフィールドに属するビットのグループは、グループ内の親をDAOへ割り当てられるように、パス制御サブフィールドにDAO親の嗜好マッピングに従って割り当てられるべきですそれは、そのサブフィールドにマッピングされました。
8. In a Non-Storing mode of operation, a node MAY pass DAOs through without performing any further processing on the Path Control field.
操作の非保存モード8.、ノードは、Path Controlフィールド上の任意の更なる処理を行うことなくのDAOを通過することができます。
9. A node MUST NOT unicast a DAO message that has no active bits in the Path Control field set. It is possible that, for a given Target option, a node does not have enough aggregate Path Control bits to send a DAO message containing that Target to each of its DAO parents, in which case those least preferred DAO Parents may not get a DAO message for that Target.
9.ノードは、Path Controlフィールドセット内のアクティブビットを有さないDAOメッセージをユニキャストしてはいけません。その場合には少なくともDAO両親好ましいのは、DAOメッセージを取得することはできません、特定のターゲットオプションで、ノードはそのDAOの両親のそれぞれにそのターゲットを含むDAOメッセージを送信するために十分な集約パス制御ビットを持っていない、ということも可能ですその目標のために。
The Path Control field allows a node to bound how many Downward routes will be generated to it. It sets a number of bits in the Path Control field equal to the maximum number of Downward routes it prefers. At most, each bit is sent to one DAO parent; clusters of bits can be sent to a single DAO parent for it to divide among its own DAO parents.
パス制御フィールドは、下向きのルートがそこに生成されますどのように多くのバウンドにノードを可能にします。それが好む下向き経路の最大数に等しい経路制御フィールド内のビット数を設定します。せいぜい、各ビットは1人のDAOの親に送信されます。それは、独自のDAOの両親の間で分割するためのビットのクラスタは、単一DAOの親に送信することができます。
A node that provisions a DAO route for a Target that has an associated Path Control field SHOULD use the content of that Path Control field in order to determine an order of preference among multiple alternative DAO routes for that Target. The Path Control field assignment is derived from preference (of the DAO parents), as determined on the basis of this node's best knowledge of the "end-to- end" aggregated metrics in the Downward direction as per the Objective Function. In Non-Storing mode the root can determine the Downward route by aggregating the information from each received DAO, which includes the Path Control indications of preferred DAO parents.
その規定に関連するパス制御フィールドは、そのターゲットのための複数の代替DAOの経路のうち優先順位を決定するために、その経路制御フィールドの内容を使用すべきであるしたターゲットのためのDAOのルートノード。目的関数の通り下方向に指標を集計「エンドツーエンド」のこのノードの最高の知識に基づいて決定されるようなパス制御フィールド割当ては、（DAO親の）嗜好に由来します。非保存モードでは、ルートは、それぞれ好ましいDAO親のパス制御指示を含むDAOを、受信からの情報を集約することにより下方経路を決定することができます。
Suppose that there is an LLN operating in Storing mode that contains a Node N with four parents, P1, P2, P3, and P4. Let N have three children, C1, C2, and C3 in its sub-DODAG. Let PCS be 7, such that there will be 8 active bits in the Path Control field: 11111111b. Consider the following example:
4人の両親、P1、P2、P3、およびP4とノードNが含まれているモードの保存で動作LLNが存在すると仮定する。 NそのサブDODAGで3人の子供、C1、C2、およびC3を持ってみましょう。 11111111B：パス制御フィールド内の8つのアクティブビットがあるだろうというように、PCSは7とします。次の例を考えてみます。
The Path Control field is split into four subfields, PC1 (11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b), such that those four subfields represent four different levels of preference per Figure 27. The implementation at Node N, in this example, groups {P1, P2} to be of equal preference to each other and the most preferred group overall. {P3} is less preferred to {P1, P2}, and more preferred to {P4}. Let Node N then perform its Path Control mapping such that:
パス制御フィールドは、4つのサブフィールド、PC1（11000000b）、PC2（00110000b）、PC3（00001100b）、およびPC4（00000011B）に分割されているこれら4つのサブフィールドは、図27のノードにおいて実装ごとに嗜好4つの異なるレベルを表すようにNは、この例では、グループ{P1、P2}は等しく優先し、全体的な最も好ましい基であることが。 {P3}は{P1、P2}にあまり好ましくない、および{P4}がより好ましいです。ノードNは、そのパス制御マッピングを実行するようにしましょう：
{P1, P2} -> PC1 (11000000b) in the Path Control field
{P3} -> PC2 (00110000b) in the Path Control field
{P4} -> PC3 (00001100b) in the Path Control field
{P4} -> PC4 (00000011b) in the Path Control field
Note that the implementation repeated {P4} in order to get complete coverage of the Path Control field.
実装は経路制御フィールドの完全なカバレッジを得るために、{P4}を繰り返していることに注意してください。
1. Let C1 send a DAO containing a Target T with a Path Control 10000000b. Node N stores an entry associating 10000000b with the Path Control field for C1 and Target T.
1. C1は、経路制御10000000bとターゲットTを含むDAOを送ってみましょう。ノードNは、C1と標的Tのための経路制御フィールドと10000000bを関連付けるエントリを格納します
2. Let C2 send a DAO containing a Target T with a Path Control 00010000b. Node N stores an entry associating 00010000b with the Path Control field for C1 and Target T.
2. C2は、経路制御00010000BとターゲットTを含むDAOを送ってみましょう。ノードNは、C1と標的Tのための経路制御フィールドと00010000Bを関連付けるエントリを格納します
3. Let C3 send a DAO containing a Target T with a Path Control 00001100b. Node N stores an entry associating 00001100b with the Path Control field for C1 and Target T.
3. C3は、経路制御00001100bとターゲットTを含むDAOを送ってみましょう。ノードNは、C1と標的Tのための経路制御フィールドと00001100bを関連付けるエントリを格納します
4. At some later time, Node N generates a DAO for Target T. Node N will construct an aggregate Path Control field by ORing together the contribution from each of its children that have given a DAO for Target T. Thus, the aggregate Path Control field has the active bits set as: 10011100b.
いくつかの後の時点で、ノードNは、ターゲットT.ノードN用のDAOは、このようにターゲットT.ためDAOを与えて、その子の各々からの寄与を一緒に論理和することにより、集約経路制御を集約パス制御フィールドを構築します4を生成しますフィールドは、として設定され、アクティブビットを有する：10011100b。
5. Node N then distributes the aggregate Path Control bits among its parents P1, P2, P3, and P4 in order to prepare the DAO messages.
前記ノードNは、その後、DAOメッセージを準備するために、その親のP1、P2、P3、及びP4のうち、集計パス制御ビットを分配します。
6. P1 and P2 are eligible to receive active bits from the most preferred subfield (11000000b). Those bits are 10000000b in the aggregate Path Control field. Node N must set the bit to one of the two parents only. In this case, Node P1 is allocated the bit and gets the Path Control field 10000000b for its DAO. There are no bits left to allocate to Node P2; thus, Node P2 would have a Path Control field of 00000000b and a DAO cannot be generated to Node P2 since there are no active bits.
6. P1とP2は、最も好ましいサブフィールド（11000000b）からアクティブビットを受信する資格があります。これらのビットは、集約パス制御フィールドに10000000bされています。ノードNは2人のだけ両親のいずれかにビットを設定する必要があります。この場合、ノードP1は、ビットを割り当て、そのDAOため10000000bパス制御フィールドを取得しています。ノードP2に割り当てるために残されたビットが存在しません。従って、ノードP2は00000000Bのパス制御フィールドを有するであろうし、アクティブなビットが存在しないので、DAOは、ノードP2に生成することができません。
7. The second-most preferred subfield (00110000b) has the active bits 00010000b. Node N has mapped P3 to this subfield. Node N may allocates the active bit to P3, constructing a DAO for P3 containing Target T with a Path Control of 00010000b.
前記第2の最も好ましいサブフィールド（00110000b）は00010000Bアクティブビットを有します。ノードNは、このサブフィールドにP3をマッピングしました。ノードNは00010000Bの経路制御を使用してターゲットTを含むP3ためDAOを構築、P3にアクティブ・ビットを割り当てることができます。
8. The third-most preferred subfield (00001100b) has the active bits 00001100b. Node N has mapped P4 to this subfield. Node N may allocate both bits to P4, constructing a DAO for P4 containing Target T with a Path Control of 00001100b.
8.サード最も好ましいサブフィールド（00001100b）は00001100bアクティブビットを有します。ノードNは、このサブフィールドにP4をマッピングしました。ノードNは、00001100bの経路制御を使用してターゲットTを含むP4ためDAOを構築、P4に両方のビットを割り当てることができます。
9. The least preferred subfield (00000011b) has no active bits. Had there been active bits, those bits would have been added to the Path Control field of the DAO constructed for P4.
9.少なくとも好ましいサブフィールド（00000011B）がアクティブビットを有しません。アクティブビットがあった、これらのビットはP4のために構築DAOのパス制御フィールドに追加されていたであろう。
10. The process of populating the DAO messages destined for P1, P2, P3, P4 with other targets (other than T) proceeds according to the aggregate Path Control fields collected for those targets.
10.（T以外の）他のターゲットとP1、P2、P3、P4宛DAOメッセージをポピュレートするプロセスは、これらのターゲットのために収集、集約パス制御フィールドに応じて進みます。
A special case of DAO operation, distinct from unicast DAO operation, is multicast DAO operation that may be used to populate '1-hop' routing table entries.
ユニキャストDAO動作は異なるDAO操作の特別な場合は、「1ホップ」ルーティング・テーブル・エントリを設定するために使用することができるマルチキャストDAO操作です。
1. A node MAY multicast a DAO message to the link-local scope all-RPL-nodes multicast address.
1.ノードは、リンクローカルスコープ全RPLノードマルチキャストアドレスにDAOメッセージをマルチキャストすることができます。
2. A multicast DAO message MUST be used only to advertise information about the node itself, i.e., prefixes directly connected to or owned by the node, such as a multicast group that the node is subscribed to or a global address owned by the node.
2.マルチキャストDAOメッセージは、そのようなノードは、ノードによって所有またはグローバルアドレスに加入されたマルチキャストグループとしてノード自体、すなわち、プレフィクスは直接接続またはノードが所有する情報をアドバタイズするためにのみ使用されなければなりません。
3. A multicast DAO message MUST NOT be used to relay connectivity information learned (e.g., through unicast DAO) from another node.
3.マルチキャストDAOメッセージが別のノードから（例えば、ユニキャストDAOを通して）学習された接続情報を中継するために使用してはいけません。
4. A node MUST NOT perform any other DAO-related processing on a received multicast DAO message; in particular, a node MUST NOT perform the actions of a DAO parent upon receipt of a multicast DAO.
前記ノードは、受信したマルチキャストDAOメッセージに他のDAO関連処理を実行してはいけません。具体的には、ノードは、マルチキャストDAOを受けて、DAOの親のアクションを実行してはなりません。
o The multicast DAO may be used to enable direct P2P communication, without needing the DODAG to relay the packets.
OマルチキャストDAOは、パケットを中継するDODAGを必要とせずに、直接P2P通信を可能にするために使用されてもよいです。
This section describes the generation and processing of secure RPL messages. The high-order bit of the RPL message code identifies whether or not a RPL message is secure. In addition to secure versions of basic control messages (DIS, DIO, DAO, DAO-ACK), RPL has several messages that are relevant only in networks that are security enabled.
このセクションでは、安全なRPLメッセージの生成および処理を説明します。 RPLメッセージコードの上位ビットは、RPLメッセージが安全であるか否かを識別する。また、基本的な制御メッセージのバージョンを確保するために（DIS、DIO、DAO、DAO-ACK）、RPLは唯一のセキュリティが有効になっているネットワークに関連するいくつかのメッセージがあります。
Implementation complexity and size is a core concern for LLNs such that it may be economically or physically impossible to include sophisticated security provisions in a RPL implementation. Furthermore, many deployments can utilize link-layer or other security mechanisms to meet their security requirements without requiring the use of security in RPL.
実装の複雑さとサイズは、RPLの実装では、高度なセキュリティ条項を含めるように、経済的または物理的に不可能であり得ることなLLNsのコアの懸念です。さらに、多くの配備は、RPLでのセキュリティの使用を必要とせずに、セキュリティ要件を満たすためにリンク層やその他のセキュリティ機構を利用することができます。
Therefore, the security features described in this document are OPTIONAL to implement. A given implementation MAY support a subset (including the empty set) of the described security features, for example, it could support integrity and confidentiality, but not signatures. An implementation SHOULD clearly specify which security mechanisms are supported, and it is RECOMMENDED that implementers carefully consider security requirements and the availability of security mechanisms in their network.
そのため、このドキュメントで説明するセキュリティ機能は実装するオプションです。所与の実装形態は、記載されているセキュリティ機能の（空集合を含む）のサブセットをサポートしてもよい。例えば、これは、完全性と機密性ではなく、署名をサポートすることができます。実装は明らかに、セキュリティ・メカニズムがサポートされているかを特定すべきである、実装者は慎重にセキュリティ要件とそのネットワークのセキュリティメカニズムの利用可能性を検討することが推奨されます。
RPL supports three security modes:
RPLは、3つのセキュリティモードをサポートしています。
o Unsecured. In this security mode, RPL uses basic DIS, DIO, DAO, and DAO-ACK messages, which do not have Security sections. As a network could be using other security mechanisms, such as link-layer security, unsecured mode does not imply all messages are sent without any protection.
無担保O。このセキュリティモードでは、RPLは、セキュリティセクションを持っていない基本的なDIS、DIO、DAO、およびDAO-ACKメッセージを、使用しています。ネットワークは、このようなリンク層セキュリティなど、他のセキュリティ・メカニズムを、使用している可能性としては、セキュリティで保護されていないモードでは、すべてのメッセージは、任意の保護なしで送信されているわけではありません。
o Preinstalled. In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a preinstalled key. Nodes use this to provide message confidentiality, integrity, and authenticity. A node may, using this preinstalled key, join the RPL network as either a host or a router.
プリインストールされているO。このセキュリティモードでは、RPLは、安全なメッセージを使用しています。 RPLインスタンスに参加するには、ノードは、プリインストールされているキーを持っている必要があります。ノードは、メッセージの機密性、完全性、および信頼性を提供するためにこれを使用しています。ノードは、このプリインストールされたキーを使用して、ホスト又はルータのいずれかとしてRPLネットワークに参加することができます。
o Authenticated. In this security mode, RPL uses secure messages. To join a RPL Instance, a node must have a preinstalled key. Nodes use this key to provide message confidentiality, integrity, and authenticity. Using this preinstalled key, a node may join the network as a host only. To join the network as a router, a node must obtain a second key from a key authority. This key authority can authenticate that the requester is allowed to be a router before providing it with the second key. Authenticated mode cannot be supported by symmetric algorithms. As of the writing of this specification, RPL supports only symmetric algorithms: authenticated mode is included for the benefit of potential future cryptographic primitives. See Section 10.3.
O認証。このセキュリティモードでは、RPLは、安全なメッセージを使用しています。 RPLインスタンスに参加するには、ノードは、プリインストールされているキーを持っている必要があります。ノードは、メッセージの機密性、完全性、および信頼性を提供するために、このキーを使用します。このプリインストールされているキーを使用して、ノードは、ホストとしてネットワークに参加することができます。ルータなどのネットワークに参加するには、ノードは、キー局から2番目のキーを取得する必要があります。このキーの権限は、要求者が、第2の鍵でそれを提供する前に、ルータであることが許可されていることを認証することができます。認証されたモードは、対称アルゴリズムでサポートすることはできません。この仕様書の執筆時点では、RPLは、対称アルゴリズムをサポートしています。認証されたモードは、潜在的な将来の暗号プリミティブの利益のために含まれています。 10.3節を参照してください。
Whether or not the RPL Instance uses unsecured mode is signaled by whether it uses secure RPL messages. Whether a secured network uses the preinstalled or authenticated mode is signaled by the 'A' bit of the DAG Configuration option.
RPLインスタンスは、セキュリティで保護されていないモードを使用するかどうかは、それが安全なRPLメッセージを使用するかどうかによって通知されます。セキュアなネットワークがプリインストールされているか、認証モードを使用するかどうかは、DAGコンフィギュレーションオプションの「」ビットによって通知されます。
This specification specifies CCM -- Counter with CBC-MAC (Cipher Block Chaining - Message Authentication Code) -- as the cryptographic basis for RPL security [RFC3610]. In this specification, CCM uses AES-128 as its underlying cryptographic algorithm. There are bits reserved in the Security section to specify other algorithms in the future.
CBC-MACとカウンタ（暗号ブロック連鎖 - - メッセージ認証コード） - この仕様は、CCMを指定RPLセキュリティ[RFC3610]のための暗号の基礎として。本明細書では、CCMは、基礎となる暗号化アルゴリズムとしてAES-128を使用します。将来的には他のアルゴリズムを指定するには、[セキュリティ]セクションで予約ビットがあります。
All secured RPL messages have either a MAC or a signature. Optionally, secured RPL messages also have encryption protection for confidentiality. Secured RPL message formats support both integrated encryption/authentication schemes (e.g., CCM) as well as schemes that separately encrypt and authenticate packets.
すべての確保RPLメッセージは、MACまたは署名のいずれかを持っています。必要に応じて、確保RPLメッセージも機密保持のための暗号化保護を持っています。固定RPLメッセージフォーマットは両方の統合された暗号化/認証方式（例えば、CCM）をサポートするだけでなく、個別に暗号化してパケットを認証方式。
RPL security assumes that a node wishing to join a secured network has been pre-configured with a shared key for communicating with neighbors and the RPL root. To join a secure RPL network, a node either listens for secure DIOs or triggers secure DIOs by sending a secure DIS. In addition to the DIO/DIS rules in Section 8, secure DIO and DIS messages have these rules:
RPLのセキュリティは、安全なネットワークへの参加を希望するノードは、隣人やRPLのルートと通信するための共有キーが事前に設定されていることを前提としています。安全なRPLネットワークに参加するには、ノードは、安全のDIOをリッスンまたはセキュアDISを送信することにより、安全なのDIOをトリガーのいずれか。第8章のDIO / DISのルールに加えて、安全なDIOとDISメッセージは、これらのルールを持っています：
1. If sent, this initial secure DIS MUST set the Key Identifier Mode field to 0 (00) and MUST set the Security Level field to 1 (001). The key used MUST be the pre-configured group key (Key Index 0x00).
1.送信された場合は、この初期のセキュアDISは、（00）を0にキー識別子Modeフィールドを設定しなければなりませんし、1（001）にセキュリティレベルのフィールドを設定しなければなりません。使用されるキーは、事前に設定されたグループ鍵（キーインデックスは0x00）でなければなりません。
2. When a node resets its Trickle timer in response to a secure DIS (Section 8.3), the next DIO it transmits MUST be a secure DIO with the same security configuration as the secure DIS. If a node receives multiple secure DIS messages before it transmits a DIO, the secure DIO MUST have the same security configuration as the last DIS to which it is responding.
ノードがセキュアDIS（セクション8.3）に応答してそのトリクルタイマーをリセットする場合2.、それが送信次DIOセキュアDISと同じセキュリティ構成のセキュアDIOなければなりません。それはDIOを送信する前に、ノードは、複数のセキュアDISメッセージを受信した場合、安全なDIOは、それが応答された最後のDISと同じセキュリティ設定がなければなりません。
3. When a node sends a DIO in response to a unicast secure DIS (Section 8.3), the DIO MUST be a secure DIO.
ノードは、ユニキャストセキュアDIS（セクション8.3）に応答してDIOを送信3. DIOセキュアDIOなければなりません。
The above rules allow a node to join a secured RPL Instance using the pre-configured shared key. Once a node has joined the DODAG using the pre-configured shared key, the 'A' bit of the Configuration option determines its capabilities. If the 'A' bit of the Configuration option is cleared, then nodes can use this preinstalled, shared key to exchange messages normally: it can issue DIOs, DAOs, etc.
上記の規則は、ノードは、事前設定された共有鍵を用いて固定RPLインスタンスに参加することを可能にします。ノードは、事前設定された共有鍵を用いてDODAGに参加した後、設定オプションの 'ビットは、その機能を決定します。コンフィギュレーションオプションの「」ビットがクリアされている場合、ノードが正常にメッセージを交換するために、このプリインストールされ、共有キーを使用することができます：それは、DAOを、などのDIOを発行することができます
If the 'A' bit of the Configuration option is set and the RPL Instance is operating in authenticated mode:
コンフィギュレーションオプションの「」ビットがセットされ、RPLインスタンスは、認証モードで動作している場合：
1. A node MUST NOT advertise a Rank besides INFINITE_RANK in secure DIOs secured with Key Index 0x00. When processing DIO messages secured with Key Index 0x00, a processing node MUST consider the advertised Rank to be INFINITE_RANK. Any other value results in the message being discarded.
1.ノードは、キーインデックスは0x00で固定し、安全なのDIOにINFINITE_RANK以外のランクを広告してはなりません。キーインデックスは0x00で固定DIOメッセージを処理すると、処理ノードはINFINITE_RANKように広告を出してランクを考慮する必要があります。メッセージ内の他の値の結果は破棄されます。
2. Secure DAOs using a Key Index 0x00 MUST NOT have a RPL Target option with a prefix besides the node's address. If a node receives a secured DAO message using the preinstalled, shared key where the RPL Target option does not match the IPv6 source address, it MUST discard the secured DAO message without further processing.
キーインデックスは0x00を使用して2.セキュアDAOには、ノードのアドレス以外の接頭辞を持つRPLターゲットオプションを持ってはいけません。ノードは、RPLターゲットオプションは、IPv6ソースアドレスと一致しないプリインストールされ、共有鍵を用いて保護されたDAOメッセージを受信した場合、それはさらなる処理なしで保護されたDAOメッセージを破棄しなければなりません。
The above rules mean that in RPL Instances where the 'A' bit is set, using Key Index 0x00, a node can join the RPL Instance as a host but not a router. A node must communicate with a key authority to obtain a key that will enable it to act as a router.
上記のルールは意味その「」ビットがキーインデックスは0x00を使用して、設定されているRPLインスタンスで、ホストとしてRPLインスタンスに参加できたノードではなく、ルータ。ノードはルータとして動作することを可能にするキーを取得するために、キーの権限と通信する必要があります。
Authenticated mode requires a would-be router to dynamically install new keys once they have joined a network as a host. Having joined as a host, the node uses standard IP messaging to communicate with an authorization server, which can provide new keys.
認証されたモードは、彼らがホストとしてネットワークに参加した後、動的に新しいキーをインストールする-だろうルータが必要です。ホストとして参加した、ノードは新しいキーを提供することができ、認証サーバーと通信するための標準的なIPメッセージングを使用しています。
The protocol to obtain such keys is out of scope for this specification and to be elaborated in future specifications. That elaboration is required for RPL to securely operate in authenticated mode.
そのようなキーを取得するためのプロトコルは、本明細書の範囲外であり、将来の仕様書に詳述されます。その精緻化が確実に認証されたモードで動作するRPLのために必要とされます。
RPL nodes send Consistency Check (CC) messages to protect against replay attacks and synchronize counters.
RPLノードは、リプレイ攻撃から保護し、カウンタを同期させるために整合性チェック（CC）メッセージを送信します。
1. If a node receives a unicast CC message with the 'R' bit cleared, and it is a member of or is in the process of joining the associated DODAG, it SHOULD respond with a unicast CC message to the sender. This response MUST have the 'R' bit set, and it MUST have the same CC nonce, RPLInstanceID, and DODAGID fields as the message it received.
ノードが「R」がクリアビットがユニキャストCCメッセージを受信し、それがメンバーであるか、または関連DODAGを接合する工程である場合に1、それは、送信者へのユニキャストのCCメッセージで応答する必要があります。この応答は、「R」ビットを設定する必要があり、それが同じCCナンス、RPLInstanceID、それが受信されたメッセージとしてDODAGIDフィールドを持たなければなりません。
2. If a node receives a multicast CC message, it MUST discard the message with no further processing.
ノードがマルチキャストCCメッセージを受信した場合2.、それはさらなる処理のメッセージを破棄しなければなりません。
Consistency Check messages allow nodes to issue a challenge-response to validate a node's current counter value. Because the CC nonce is generated by the challenger, an adversary replaying messages is unlikely to be able to generate a correct response. The counter in the Consistency Check response allows the challenger to validate the counter values it hears.
整合性チェックメッセージは、ノードは、ノードの現在のカウンタ値を検証するために、チャレンジレスポンスを発行することができます。 CCのナンスは挑戦者によって生成されるため、メッセージを再生する敵は、正しい応答を生成することができることはほとんどありません。整合性チェック応答のカウンターが挑戦者は、それが聞くカウンタ値を検証することができます。
In the simplest case, the counter value is an unsigned integer that a node increments by one or more on each secured RPL transmission. The counter MAY represent a timestamp that has the following properties:
最も単純な場合では、カウンタ値が各固定RPLの送信上の1つまたはそれ以上のノード増分その符号なし整数です。カウンターには、次のプロパティがあり、タイムスタンプを表すことができます：
2. The timestamp MUST be in 1024 Hz (binary millisecond) granularity.
2.タイムスタンプは、1024ヘルツ（バイナリミリ秒）粒状でなければなりません。
4. If the counter represents a timestamp, the counter value MUST be a value computed as follows. Let T be the timestamp, S be the start time of the key in use, and E be the end time of the key in use. Both S and E are represented using the same three rules as the timestamp described above. If E > T < S, then the counter is invalid and a node MUST NOT generate a packet. Otherwise, the counter value is equal to T-S.
前記カウンタがタイムスタンプを表している場合、カウンタ値は次のように計算された値でなければなりません。 S使用中のキーの開始時間も、そしてEは、使用中のキーの終了時間も、Tはタイムスタンプとします。 SとEの両方は、上述したタイムスタンプと同じ3つのルールを使用して表されます。 E> T <S場合は、カウンタは無効であり、ノードがパケットを生成してはなりません。そうでない場合は、カウンタ値はT-Sに等しいです。
5. If the counter represents such a timestamp, a node MAY set the 'T' flag of the Security section of secured RPL packets.
前記カウンタは、タイムスタンプを表す場合、ノードは、保護されたRPLパケットのセキュリティセクションの「T」フラグを設定してもよいです。
6. If the Counter field does not present such a timestamp, then a node MUST NOT set the 'T' flag.
前記カウンタフィールドは、タイムスタンプが存在しない場合、ノードは、「T」フラグを設定してはいけません。
7. If a node does not have a local timestamp that satisfies the above requirements, it MUST ignore the 'T' flag.
7.ノードが上記の要件を満たすローカルタイムスタンプを持っていない場合、それは「T」フラグを無視しなければなりません。
If a node supports such timestamps and it receives a message with the 'T' flag set, it MAY apply the temporal check on the received message described in Section 10.7.1. If a node receives a message without the 'T' flag set, it MUST NOT apply this temporal check. A node's security policy MAY, for application reasons, include rejecting all messages without the 'T' flag set.
ノードは、タイムスタンプをサポートしており、それは「T」フラグを設定してメッセージを受信した場合、それは、セクション10.7.1に記載の受信されたメッセージに時間的なチェックを適用してもよいです。ノードが「T」フラグが設定されていないメッセージを受信した場合、それはこの一時的なチェックを適用してはなりません。ノードのセキュリティポリシーMAYは、アプリケーション上の理由から、「T」フラグが設定されていないすべてのメッセージを拒否しています。
The 'T' flag is present because many LLNs today already maintain global time synchronization at sub-millisecond granularity for security, application, and other reasons. Allowing RPL to leverage this existing functionality when present greatly simplifies solutions to some security problems, such as delay protection.
多くのLLNsが今日すでに、セキュリティ、アプリケーション、およびその他の理由のために、サブミリ秒単位でグローバルな時刻同期を維持するため、「T」フラグが存在しています。存在する場合RPLは、この既存の機能を活用できるようにすると大幅な遅延保護など、いくつかのセキュリティ問題への解決策を簡素化します。
Given an outgoing RPL control packet and the required security protection, this section describes how RPL generates the secured packet to transmit. It also describes the order of cryptographic operations to provide the required protection.
送信RPL制御パケットと必要なセキュリティ保護を考えると、このセクションでは、RPLを送信するセキュアなパケットを生成する方法について説明します。また、必要な保護を提供するために、暗号化操作の順序を説明しています。
The requirement for security protection and the level of security to be applied to an outgoing RPL packet shall be determined by the node's security policy database. The configuration of this security policy database for outgoing packet processing is implementation specific.
セキュリティ保護のための要件と発信RPLパケットに適用されるセキュリティのレベルは、ノードのセキュリティポリシーデータベースによって決定されなければなりません。発信パケットの処理のため、このセキュリティポリシーデータベースの構成は実装固有のものです。
Where secured RPL messages are to be transmitted, a RPL node MUST set the Security section (T, Sec, KIM, and LVL) in the outgoing RPL packet to describe the protection level and security settings that are applied (see Section 6.1). The Security subfield bit of the RPL Message Code field MUST be set to indicate the secure RPL message.
確保RPLメッセージが送信される場合は、RPLノード（セクション6.1を参照）に適用されている保護レベルとセキュリティ設定を記述するために、発信RPLパケットにセキュリティセクション（T、秒、KIM、およびLVL）を設定しなければなりません。 RPLメッセージCodeフィールドのセキュリティサブフィールドのビットは、セキュアなRPLメッセージを示すために設定しなければなりません。
The counter value used in constructing the AES-128 CCM nonce (Figure 31) to secure the outgoing packet MUST be an increment of the last counter transmitted to the particular destination address.
発信パケットを確保する（図31）AES-CCM 128 nonceを構築する際に使用されるカウンタ値は、特定の宛先アドレスに送信された最後のカウンタのインクリメントでなければなりません。
Where security policy specifies the application of delay protection, the Timestamp counter used in constructing the CCM nonce to secure the outgoing packet MUST be incremented according to the rules in Section 10.5. Where a Timestamp counter is applied (indicated with the 'T' flag set), the locally maintained Timestamp counter MUST be included as part of the transmitted secured RPL message.
セキュリティポリシーは、遅延保護の適用を指定する場合は、発信パケットを確保するためにCCMナンスの構築に使用されるタイムスタンプカウンタは、セクション10.5の規則に従って増加しなければなりません。タイムスタンプカウンタが（「T」フラグを設定して示される）適用される場合、ローカルに保持タイムスタンプカウンタは、送信された固定RPLメッセージの一部として含まれなければなりません。
The cryptographic algorithm used in securing the outgoing packet shall be specified by the node's security policy database and MUST be indicated in the value of the Sec field set within the outgoing message.
発信パケットを固定に使用される暗号化アルゴリズムは、ノードのセキュリティポリシーデータベースによって指定されなければならないと送信メッセージ内に設定秒フィールドの値で示されなければなりません。
The security policy for the outgoing packet shall determine the applicable KIM and Key Identifier specifying the security key to be used for the cryptographic packet processing, including the optional use of signature keys (see Section 6.1). The security policy will also specify the algorithm (Algorithm) and level of protection (Level) in the form of authentication or authentication and encryption, and potential use of signatures that shall apply to the outgoing packet.
セキュリティキーを指定適用KIMとキー識別子を決定しなければならない発信パケットのセキュリティポリシーは、署名鍵（セクション6.1を参照）のオプションの使用を含む、暗号化パケットの処理のために使用されます。セキュリティポリシーは、認証または認証と暗号化、および発信パケットに適用されるものと署名の潜在的な使用形態でのアルゴリズム（アルゴリズム）と保護のレベル（レベル）を指定します。
Where encryption is applied, a node MUST replace the original packet payload with that payload encrypted using the security protection, key, and CCM nonce specified in the Security section of the packet.
暗号化が適用される場合、ノードは、パケットのセキュリティセクションで指定されたセキュリティ保護、キー、およびCCM nonceを使用して暗号化されているペイロードを元のパケットのペイロードを交換する必要があります。
All secured RPL messages include integrity protection. In conjunction with the security algorithm processing, a node derives either a MAC or signature that MUST be included as part of the outgoing secured RPL packet.
すべての確保RPLメッセージは、完全性保護が含まれています。セキュリティアルゴリズムの処理に関連して、ノードが発信確保RPLパケットの一部として含まれなければならないMACまたは署名のいずれかを導出します。
This section describes the reception and processing of a secured RPL packet. Given an incoming secured RPL packet, where the Security subfield bit of the RPL Message Code field is set, this section describes how RPL generates an unencrypted variant of the packet and validates its integrity.
このセクションでは、固定RPLパケットの受信及び処理を説明します。 RPLメッセージCodeフィールドのセキュリティサブフィールドビットがセットされて入ってくる確保RPLパケットを、考えると、このセクションでは、RPLは、パケットの暗号化されていないバリアントを生成し、その整合性を検証する方法を説明します。
The receiver uses the RPL security control fields to determine the necessary packet security processing. If the described level of security for the message type and originator is unknown or does not meet locally maintained security policies, a node MUST discard the packet without further processing, MAY raise a management alert, and MUST NOT send any messages in response. These policies can include security levels, keys used, source identifiers, or the lack of timestamp-based counters (as indicated by the 'T' flag). The configuration of the security policy database for incoming packet processing is out of scope for this specification (it may, for example, be defined through DIO Configuration or through out-of-band administrative router configuration).
受信機は、必要なパケットセキュリティ処理を決定するために、RPLセキュリティ制御フィールドを使用します。メッセージの種類と発信者のためのセキュリティの記述レベルが不明であるか、ローカルに保持セキュリティポリシーを満たしていない場合、ノードは、管理アラートを上げることができる、と応じて任意のメッセージを送ってはいけません、さらに処理せずにパケットを捨てなければなりません。これらのポリシーは、セキュリティレベル、使用されるキー、ソース識別子、またはタイムスタンプベースカウンタの欠如（「T」フラグによって示されるように）を含むことができます。着信パケットの処理のためのセキュリティポリシーデータベースの構成は、（それは、例えば、DIO構成を介して、またはアウトオブバンド管理ルータの設定によって定義されてもよい）本明細書の範囲外です。
Where the message Security Level (LVL) indicates an encrypted RPL message, the node uses the key information identified through the KIM field as well as the CCM nonce as input to the message payload decryption processing. The CCM nonce shall be derived from the message Counter field and other received and locally maintained information (see Section 10.9.1). The plaintext message contents shall be obtained by invoking the inverse cryptographic mode of operation specified by the Sec field of the received packet.
メッセージセキュリティレベル（LVL）は暗号化されたRPLメッセージを示している場合、ノードは、メッセージペイロード復号化処理への入力としてKIMフィールドを通じて識別キー情報ならびにCCM nonceを使用します。 CCMのノンスは、メッセージカウンタフィールドに由来し、他の受信及びローカル（セクション10.9.1を参照）の情報を維持しなければなりません。平文メッセージの内容は、受信したパケットのSECフィールドによって指定された動作の逆暗号化モードを呼び出すことによって得なければなりません。
The receiver shall use the CCM nonce and identified key information to check the integrity of the incoming packet. If the integrity check fails against the received MAC, a node MUST discard the packet.
受信機は、着信パケットの整合性をチェックするためにCCMのナンスおよび識別キー情報を使用しなければなりません。整合性チェックは、受信したMACに対して失敗した場合、ノードはパケットを捨てなければなりません。
If the received message has an initialized (zero value) counter value and the receiver has an incoming counter currently maintained for the originator of the message, the receiver MUST initiate a counter resynchronization by sending a Consistency Check response message (see Section 6.6) to the message source. The Consistency Check response message shall be protected with the current full outgoing counter maintained for the particular node address. That outgoing counter will be included within the security section of the message while the incoming counter will be included within the Consistency Check message payload.
受信したメッセージが初期化（ゼロ値）カウンタ値と受信機は、現在のメッセージの発信者のために維持着信カウンタを有している場合、受信機は、整合性チェック応答メッセージを送信することにより、カウンタの再同期を開始しなければならない（セクション6.6を参照）メッセージソース。整合性チェック応答メッセージは、特定のノードアドレス維持現在フル発信カウンターを用いて保護しなければなりません。入ってくるカウンタは、整合性チェックメッセージペイロード内に含まれることになる一方で、発信カウンタは、メッセージのセキュリティセクション内に含まれること。
Based on the specified security policy, a node MAY apply replay protection for a received RPL message. The replay check SHOULD be performed before the authentication of the received packet. The counter, as obtained from the incoming packet, shall be compared against the watermark of the incoming counter maintained for the given origination node address. If the received message counter value is non-zero and less than the maintained incoming counter watermark, a potential packet replay is indicated and the node MUST discard the incoming packet.
指定されたセキュリティポリシーに基づいて、ノードが受信RPLメッセージのリプレイ保護を適用することができます。リプレイチェックは、受信したパケットの認証の前に実行する必要があります。カウンタは、着信パケットから得られるような、所定の発信元ノードアドレス維持着信カウンタの透かしと比較しなければなりません。受信したメッセージのカウンタ値が非ゼロで維持着信カウンタ透かし未満である場合、潜在的なパケットの再生が指示されると、ノードは、着信パケットを破棄しなければなりません。
If delay protection is specified as part of the incoming packet security policy checks, the Timestamp counter is used to validate the timeliness of the received RPL message. If the incoming message Timestamp counter value indicates a message transmission time prior to the locally maintained transmission time counter for the originator address, a replay violation is indicated and the node MUST discard the incoming packet. If the received Timestamp counter value indicates a message transmission time that is earlier than the Current time less the acceptable packet delay, a delay violation is indicated and the node MUST discard the incoming packet.
遅延保護が着信パケットのセキュリティポリシーチェックの一部として指定されている場合、タイムスタンプカウンタは、受信されたRPLメッセージの適時性を検証するために使用されます。着信メッセージのタイムスタンプカウンタ値は、発信者アドレスの前に局所的に維持された送信時間カウンタへのメッセージの送信時刻を示す場合、再生違反が示され、ノードは、着信パケットを破棄しなければなりません。受信したタイムスタンプカウンタの値が現在の時刻より少ない許容されるパケット遅延より古いメッセージ送信時刻を示す場合、遅延違反が示され、ノードは、着信パケットを破棄しなければなりません。
Once a message has been decrypted, where applicable, and has successfully passed its integrity check, replay check, and optionally delay-protection checks, the node can update its local security information, such as the source's expected counter value for replay comparison.
メッセージが解読されている、適用可能な場合、および正常に整合性チェック、再生チェック、および必要に応じて遅延保護チェックを通過した後、ノードは、再生比較のためのソースの期待カウンタ値と、そのローカルセキュリティ情報を更新することができます。
A node MUST NOT update its security information on receipt of a message that fails security policy checks or other applied integrity, replay, or delay checks.
ノードは、セキュリティポリシーのチェックや他の応用の整合性、リプレイ、または遅延チェックに失敗したメッセージの受信時に、そのセキュリティ情報をアップデートしてはいけません。
If the 'T' flag of a message is set and a node has a local timestamp that follows the requirements in Section 10.5, then a node MAY check the temporal consistency of the message. The node computes the transmit time of the message by adding the counter value to the start time of the associated key. If this transmit time is past the end time of the key, the node MAY discard the message without further processing. If the transmit time is too far in the past or future compared to the local time on the receiver, it MAY discard the message without further processing.
メッセージの「T」フラグが設定され、ノードは、セクション10.5での要件を以下のローカルタイムスタンプを有している場合、ノードは、メッセージの時間的な整合性をチェックすることができます。ノードは、関連するキーの開始時にカウンタ値を加算することにより、メッセージの送信時間を計算します。この送信時間は、キーの終了時刻を過ぎている場合、ノードは、さらに処理せずにメッセージを捨てるかもしれ。送信時間は、受信機のローカル時間に比べて過去や未来にすぎている場合、それはさらに処理せずにメッセージを捨てるかもしれ。
For a RPL ICMPv6 message, the entire packet is within the scope of RPL security.
RPL ICMPv6メッセージのために、パケット全体がRPLセキュリティの範囲内です。
MACs and signatures are calculated over the entire unsecured IPv6 packet. When computing MACs and signatures, mutable IPv6 fields are considered to be filled with zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPsec Authenticated Header). MAC and signature calculations are performed before any compression that lower layers may apply.
MACおよび署名は全体のセキュリティで保護されていないIPv6パケットに対して計算されています。 MACおよび署名を計算するとき、可変のIPv6フィールドは、[RFC4302]（IPsecの認証ヘッダ）のセクション3.3.3.1に規則に従って、ゼロで充填されると考えられます。 MACと署名の計算は、下位層が適用される任意の圧縮の前に行われます。
When a RPL ICMPv6 message is encrypted, encryption starts at the first byte after the Security section and continues to the last byte of the packet. The IPv6 header, ICMPv6 header, and RPL message up to the end of the Security section are not encrypted, as they are needed to correctly decrypt the packet.
RPL ICMPv6メッセージが暗号化されている場合、暗号化はセキュリティセクションの後の最初のバイトから始まり、パケットの最後のバイトまで続きます。それらが正しくパケットを解読するのに必要とされてセキュリティセクションの最後までのIPv6ヘッダー、ICMPv6のヘッダ、およびRPLメッセージは、暗号化されていません。
For example, a node sending a message with LVL=1, KIM=0, and Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with attributes ENC-MAC-32: it encrypts the packet and appends a 32-bit MAC. The block cipher key is determined by the Key Index. The CCM nonce is computed as described in Section 10.9.1; the message to authenticate and encrypt is the RPL message starting at the first byte after the Security section and ends with the last byte of the packet. The additional authentication data starts with the beginning of the IPv6 header and ends with the last byte of the RPL Security section.
例えば、ノードは、LVL = 1、KIM = 0でメッセージを送信し、アルゴリズム= 0は、属性ENC-MAC-32とパケットを作成するために、CCMアルゴリズム[RFC3610]を使用する：それはパケットを暗号化し、32ビットを付加しますマック。ブロック暗号キーはキーインデックスによって決定されます。セクション10.9.1に記載されているようにCCMのナンスが計算されます。認証および暗号化するために、メッセージは、セキュリティセクションの後の最初のバイトから始まるRPLのメッセージであり、パケットの最後のバイトで終わります。追加の認証データは、IPv6ヘッダの先頭から始まり、RPLセキュリティ]セクションの最後のバイトで終わります。
The cryptographic mode of operation described in this specification (Algorithm = 0) is based on CCM and the block-cipher AES-128 [RFC3610]. This mode of operation is widely supported by existing implementations. CCM mode requires a nonce (CCM nonce).
この仕様（アルゴリズム= 0）で説明した動作の暗号化モードは、CCM及びブロック暗号AES-128 [RFC3610]に基づいています。この動作モードは、広く既存の実装によってサポートされています。 CCMモードは、ナンス（CCMナンス）が必要です。
A RPL node constructs a CCM nonce as follows:
次のようにRPLノードは、CCM nonceを構築します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|KIM|Resvd| LVL |
+-+-+-+-+-+-+-+-+
Figure 31: CCM Nonce
図31：CCMナンス
Source Identifier: 8 bytes. Source Identifier is set to the logical identifier of the originator of the protected packet.
ソース識別子：8バイト。ソース識別子は、保護されたパケットの発信元の論理識別子に設定されています。
Counter: 4 bytes. Counter is set to the (uncompressed) value of the corresponding field in the Security option of the RPL control message.
カウンター：4バイト。カウンターは、RPL制御メッセージのセキュリティオプションの対応するフィールドの（非圧縮）の値に設定されています。
Key Identifier Mode (KIM): 2 bits. KIM is set to the value of the corresponding field in the Security option of the RPL control message.
キー識別子モード（KIM）：2ビット。 KIMは、RPL制御メッセージのセキュリティオプションで対応するフィールドの値に設定されています。
Security Level (LVL): 3 bits. Security Level is set to the value of the corresponding field in the Security option of the RPL control message.
セキュリティレベル（LVL）：3ビット。セキュリティレベルは、RPL制御メッセージのセキュリティオプションに対応するフィールドの値に設定されています。
Unassigned bits of the CCM nonce are reserved. They MUST be set to zero when constructing the CCM nonce.
CCMのナンスの未割り当てのビットは予約されています。 CCM nonceを構築するとき、彼らはゼロに設定しなければなりません。
All fields of the CCM nonce are represented in most significant octet and most significant bit first order.
CCMのナンスのすべてのフィールドが最も重要なオクテット最上位ビットの第1の順で表現されています。
If the KIM indicates the use of signatures (a value of 3), then a node appends a signature to the data payload of the packet. The Security Level (LVL) field describes the length of this signature. The signature scheme in RPL for Security Mode 3 is an instantiation of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of [RFC3447]. As public key, it uses the pair (n,e), where n is a 2048-bit or 3072-bit RSA modulus and where e=2^{16}+1. It uses CCM mode [RFC3610] as the encryption scheme with M=0 (as a stream-cipher). Note that although [RFC3610] disallows the CCM mode with M=0, RPL explicitly allows the CCM mode with M=0 when used in conjunction with a signature, because the signature provides sufficient data authentication. Here, the CCM mode with M=0 is specified as in [RFC3610], but where the M' field in Section 2.2 MUST be set to 0. It uses the SHA-256 hash function specified in Section 6.2 of [FIPS180]. It uses the message encoding rules of Section 8.1 of [RFC3447].
KIMが署名の使用（3の値）を示している場合、ノードは、パケットのデータペイロードに署名を付加します。セキュリティレベル（LVL）フィールドは、この署名の長さを示します。 [RFC3447]のセクション8.1で定義されるようにセキュリティモード3 RPLにおける署名方式は、RSAアルゴリズム（RSASSA-PSS）のインスタンスです。公開鍵として、それは、nが2048ビット又は3072ビットのRSAモジュラスおよびe = 2 ^ {16} +1であるペアを（N、E）、使用します。これは、（ストリーム暗号として）M = 0の暗号化方式としてCCMモード[RFC3610]を使用します。 [RFC3610]はM = 0とCCMモードを禁止しているが、署名と併せて使用される場合、署名は、十分なデータ認証を提供するので、RPLは、明示的、M = 0とCCMモードを可能にすることに留意されたいです。ここで、M = 0とCCMモードは、それが[FIPS180]のセクション6.2で指定されたSHA-256ハッシュ関数を使用して、[RFC3610]のように指定されているが、セクション2.2でM」フィールドが0に設定されなければならない場合。それは、[RFC3447]のセクション8.1のメッセージの符号化規則を使用します。
Let 'a' be a concatenation of a 6-byte representation of counter and the message header. The packet payload is the right-concatenation of packet data 'm' and the signature 's'. This signature scheme is invoked with the right-concatenation of the message parts a and m, whereas the signature verification is invoked with the right-concatenation of the message parts a and m and with signature s.
「」カウンタの6バイト表現とメッセージヘッダの連結とします。パケットペイロードは、パケットデータの「m」の右連結および署名「S」です。署名検証は、メッセージ部分AとMの右連結とし、署名Sで呼び出され、一方、この署名方式は、メッセージ部分とMの右連結で呼び出されます。
RSA signatures of this form provide sufficient protection for RPL networks. If needed, alternative signature schemes that produce more concise signatures is out of scope for this specification and may be the subject of a future specification.
この形式のRSA署名はRPLネットワークのための十分な保護を提供します。必要であれば、より簡潔な署名を生成する代替署名方式は、本明細書の範囲外であり、将来の仕様の対象であってもよいです。
An implementation that supports RSA signing with either 2048-bit or 3072-bit signatures SHOULD support verification of both 2048-bit and 3072-bit RSA signatures. This is in consideration of providing an upgrade path for a RPL deployment.
2048ビット又は3072ビットのいずれかのシグネチャとRSA署名をサポートする実装は、両方の2048ビットおよび3072ビットのRSA署名の検証をサポートしなければなりません。これは、RPLの展開のためのアップグレードパスを提供することを考慮したものです。
This document specifies a routing protocol. These non-normative suggestions are provided to aid in the design of a forwarding implementation by illustrating how such an implementation could work with RPL.
この文書では、ルーティングプロトコルを指定します。これらの非規範的な提案は、そのような実装がRPLで仕事ができるかを示すことにより、転送の実装の設計を支援するために設けられています。
When forwarding a packet to a destination, precedence is given to selection of a next-hop successor as follows:
宛先にパケットを転送する際に、以下のように、優先順位は次ホップ後継者の選択に与えられます。
1. This specification only covers how a successor is selected from the DODAG Version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded. Routing outside the instance can be done as long as additional rules are put in place such as strict ordering of instances and routing protocols to protect against loops. Such rules may be defined in a separate document.
1.この仕様は、後継者が転送されるパケットのIPv6ヘッダーでマークRPLInstanceIDと一致DODAG版から選択される、方法をカバーします。インスタンス外のルーティングは限り追加のルールは、このようなループから保護するためのインスタンスおよびルーティングプロトコルの厳密な順序付けと場所に置かれて行うことができます。そのようなルールは、別の文書で定義されてもよいです。
2. If a local administrative preference favors a route that has been learned from a different routing protocol than RPL, then use that successor.
ローカル管理者の嗜好がRPLは異なるルーティングプロトコルから学習されたルートを好む場合2.は、その後継者を使用します。
3. If the packet header specifies a source route by including an RH4 header as specified in [RFC6554], then use that route. If the node fails to forward the packet with that specified source route, then that packet should be dropped. The node MAY log an error. The node may send an ICMPv6 error in Source Routing Header message to the source of the packet (see Section 20.18).
次いで、[RFC6554]で指定されるようにパケットヘッダがRH4ヘッダを含むによってソースルートを指定している場合3.、その経路を使用します。ノードは、その指定されたソース・ルートにパケットを転送するために失敗した場合、そのパケットは廃棄されなければなりません。ノードはエラーを記録することがあります。ノードは、パケットのソースにソースルーティングヘッダメッセージにICMPv6エラーを送信することができる（セクション20.18を参照）。
4. If there is an entry in the routing table matching the destination that has been learned from a multicast destination advertisement (e.g., the destination is a one-hop neighbor), then use that successor.
4.その後継を使用し、次いで、（例えば、宛先がワンホップネイバーである）マルチキャスト宛先広告から学習された宛先と一致するルーティングテーブルのエントリがある場合。
5. If there is an entry in the routing table matching the destination that has been learned from a unicast destination advertisement (e.g., the destination is located Down the sub-DODAG), then use that successor. If there are DAO Path Control bits associated with multiple successors, then consult the Path Control bits to order the successors by preference when choosing. If, for a given DAO Path Control bit, multiple successors are recorded as having asserted that bit, precedence should be given to the successor who most recently asserted that bit.
ユニキャスト宛先広告から学習された宛先と一致するルーティングテーブルのエントリがある場合（例えば、宛先は、サブDODAGダウン配置されている）5、その後継を使用します。複数の後継者に関連付けられたDAOパス制御ビットがある場合、次に選択するとき嗜好によって後継を注文するパス制御ビットを参照してください。与えられたDAOパス制御ビットのために、複数の後継者は、そのビットをアサートしたと記録されている、場合、優先順位が最も最近そのビットをアサート後継に与えられるべきです。
6. If there is a DODAG Version offering a route to a prefix matching the destination, then select one of those DODAG parents as a successor according to the OF and routing metrics.
6.先に一致するプレフィックスへのルートを提供DODAGバージョンが存在する場合、次いでに従って後継とルーティング・メトリックとしてそれらDODAGの両親のいずれかを選択します。
7. Any other as-yet-unattempted DODAG parent may be chosen for the next attempt to forward a unicast packet when no better match exists.
7.その他のような未unattempted DODAGの親は良い一致が存在しない場合、ユニキャストパケットを転送する次の試みのために選択することができます。
8. Finally, the packet is dropped. ICMP Destination Unreachable MAY be invoked (an inconsistency is detected).
8.最後に、パケットはドロップされます。 ICMP宛先到達不能は（矛盾が検出された）を呼び出すことができます。
Hop Limit MUST be decremented when forwarding per [RFC2460].
[RFC2460]あたりに転送するときにホップリミットをデクリメントしなければなりません。
Note that the chosen successor MUST NOT be the neighbor that was the predecessor of the packet (split horizon), except in the case where it is intended for the packet to change from an Upward to a Downward direction, as determined by the routing table of the node making the change, such as switching from DIO routes to DAO routes as the destination is neared in order to continue traveling toward the destination.
のルーティングテーブルによって決定されるように選択された後継者は、それが下方向に上向きに変化するパケットのために意図されている場合を除いて、パケット（スプリットホライズン）の前身隣接してはならないことに注意してください例えば先としてDAOルートにDIO経路の切り替えなどの変更を行うノードは、宛先に向かう継続するために近づいています。
RPL loop avoidance mechanisms are kept simple and designed to minimize churn and states. Loops may form for a number of reasons, e.g., control packet loss. RPL includes a reactive loop detection technique that protects from meltdown and triggers repair of broken paths.
RPLループ回避メカニズムはシンプルに保ち、解約や状態を最小限に抑えるように設計されています。ループは、例えば、いくつかの理由のための制御パケットロスを形成してもよいです。 RPLは、メルトダウンから保護し、壊れた経路の修復をトリガ反応ループ検出技術を含みます。
RPL loop detection uses RPL Packet Information that is transported within the data packets, relying on an external mechanism such as [RFC6553] that places in the RPL Packet Information in an IPv6 Hop-by-Hop option header.
RPLループ検出は、IPv6のホップバイホップオプションヘッダにRPLパケット情報に配置するような[RFC6553]などの外部機構に依存する、データパケット内に搬送されるRPLパケット情報を使用します。
The content of RPL Packet Information is defined as follows:
次のようにRPLパケット情報の内容が定義されています。
Down 'O': 1-bit flag indicating whether the packet is expected to progress Up or Down. A router sets the 'O' flag when the packet is expected to progress Down (using DAO routes), and clears it when forwarding toward the DODAG root (to a node with a lower Rank). A host or RPL leaf node MUST set the 'O' flag to 0.
「O」ダウン：1ビットのフラグは、パケットが上向きまたは下向きに進行することが予想されるかどうかを示します。 （低いランクのノードに）DODAGルートに向けて転送するとき、ルータは、パケットが（DAOルートを使用して）ダウン進行すると予想されている「O」フラグを設定し、それをクリアします。ホストまたはRPLリーフノードは、0に「O」フラグを設定しなければなりません。
Rank-Error 'R': 1-bit flag indicating whether a Rank error was detected. A Rank error is detected when there is a mismatch in the relative Ranks and the direction as indicated in the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to 0.
ランクエラー「R」：ランクエラーが検出されたか否かを示す1ビットのフラグ。 「O」ビットに示すように相対的なランクと方向のミスマッチがある場合にランクエラーが検出されます。ホストまたはRPLリーフノードは、0に「R」ビットを設定しなければなりません。
Forwarding-Error 'F': 1-bit flag indicating that this node cannot forward the packet further towards the destination. The 'F' bit might be set by a child node that does not have a route to destination for a packet with the Down 'O' bit set. A host or RPL leaf node MUST set the 'F' bit to 0.
フォワーディング・エラー「F」：このノードが宛先に向けて更なるパケットを転送できないことを示す1ビットのフラグ。 「F」ビットはダウン「O」ビットがセットされたパケットの宛先へのルートを持っていない子ノードによって設定されることがあります。ホストまたはRPLリーフノードは、0に「F」ビットを設定しなければなりません。
RPLInstanceID: 8-bit field indicating the DODAG instance along which the packet is sent.
RPLInstanceID：パケットが送信される沿っDODAGインスタンスを示す8ビットのフィールド。
SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network.
SenderRank：RPLのネットワーク内に転送するルータによってソースによって及びDAGRank（ランク）をゼロに設定した16ビットのフィールド。
If the source is aware of the RPLInstanceID that is preferred for the packet, then it MUST set the RPLInstanceID field associated with the packet accordingly; otherwise, it MUST set it to the RPL_DEFAULT_INSTANCE.
ソースは、パケットのために好ましいRPLInstanceIDを認識している場合、それはそれに応じてパケットに関連付けられRPLInstanceIDフィールドを設定しなければなりません。それ以外の場合は、RPL_DEFAULT_INSTANCEに設定する必要があります。
The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. The RPLInstanceID is part of the RPL Packet Information.
RPLInstanceIDは、パケットとソースによって関連しています。このRPLInstanceIDは、パケットがどのノードが配置され、その上にRPLインスタンスと一致しなければならない、それはホストまたはルータです。 RPLInstanceIDはRPLパケット情報の一部です。
A RPL router that forwards a packet in the RPL network MUST check if the packet includes the RPL Packet Information. If not, then the RPL router MUST insert the RPL Packet Information. If the router is an ingress router that injects the packet into the RPL network, the router MUST set the RPLInstanceID field in the RPL Packet Information. The details of how that router determines the mapping to a RPLInstanceID are out of scope for this specification and left to future specification.
パケットがRPLパケット情報が含まれている場合はRPLネットワークにパケットを転送RPLルータがチェックしなければなりません。そうでない場合には、RPLルータはRPLパケット情報を挿入しなければなりません。ルータはRPLネットワークにパケットを注入入口ルータの場合、ルータはRPLパケット情報にRPLInstanceIDフィールドを設定しなければなりません。そのルータがRPLInstanceIDへのマッピングを決定する方法の詳細については、この仕様の範囲外であり、将来の仕様に任さ。
A router that forwards a packet outside the RPL network MUST remove the RPL Packet Information.
RPLネットワーク外のパケットを転送するルータは、RPLパケット情報を削除する必要があります。
When a router receives a packet that specifies a given RPLInstanceID and the node can forward the packet along the DODAG associated to that instance, then the router MUST do so and leave the RPLInstanceID value unchanged.
ルータが所与RPLInstanceIDを指定し、ノードがそのインスタンスに関連DODAGに沿ってパケットを転送することができ、パケットを受信すると、ルータはそうと変わらRPLInstanceID値のままにしなければなりません。
If any node cannot forward a packet along the DODAG associated with the RPLInstanceID, then the node SHOULD discard the packet and send an ICMP error message.
任意のノードがRPLInstanceID関連付けられDODAGに沿ってパケットを転送できない場合、ノードはパケットを破棄し、ICMPエラーメッセージを送信するべきです。
The DODAG is inconsistent if the direction of a packet does not match the Rank relationship. A receiver detects an inconsistency if it receives a packet with either:
パケットの方向がランク関係と一致しない場合DODAGは矛盾しています。それはどちらかとパケットを受信した場合、受信機は、矛盾を検出します。
the 'O' bit set (to Down) from a node of a higher Rank.
より高いランクのノードからの（下に）「O」ビット・セット。
the 'O' bit cleared (for Up) from a node of a lower Rank.
「O」ビットは下位のノードから（アップ用）がクリア。
When the DODAG root increments the DODAGVersionNumber, a temporary Rank discontinuity may form between the next DODAG Version and the prior DODAG Version, in particular, if nodes are adjusting their Rank in the next DODAG Version and deferring their migration into the next DODAG Version. A router that is still a member of the prior DODAG Version may choose to forward a packet to a (future) parent that is in the next DODAG Version. In some cases, this could cause the parent to detect an inconsistency because the Rank-ordering in the prior DODAG Version is not necessarily the same as in the next DODAG Version, and the packet may be judged not to be making forward progress. If the sending router is aware that the chosen successor has already joined the next DODAG Version, then the sending router MUST update the SenderRank to INFINITE_RANK as it forwards the packets across the discontinuity into the next DODAG Version in order to avoid a false detection of Rank inconsistency.
DODAGルートがDODAGVersionNumberをインクリメントするとき、ノードは、次DODAGバージョンにおけるそれらのランクを調整し、次DODAGバージョンへの移行を延期する場合、一時的なランクの不連続性は、特に、次DODAGバージョンと前DODAG版との間に形成してもよいです。まだ前DODAGバージョンのメンバーであるルータは、次のDODAGバージョンである（将来の）親にパケットを転送することもできます。いくつかのケースでは、前DODAGバージョンでランク順序は、必ずしも次のDODAGバージョンと同じではないので、これは矛盾を検出するために、親を引き起こす可能性があり、かつパケットが前方に進展してはならないと判断することができます。送信ルータが選ばれた後継者が既に次のDODAGバージョンに参加したことを認識している場合は、送信ルータは、それはランクの誤検出を避けるために、次のDODAGバージョンに不連続間でパケットを転送するようINFINITE_RANKするSenderRankを更新しなければなりません。矛盾。
One inconsistency along the path is not considered a critical error and the packet may continue. However, a second detection along the path of the same packet should not occur and the packet MUST be dropped.
パスに沿って一つの矛盾は、重大なエラーとはみなされず、パケットが継続してもよいです。しかし、同じパケットの経路に沿って第2の検出は発生しないはずであり、パケットは廃棄されなければなりません。
This process is controlled by the Rank-Error bit associated with the packet. When an inconsistency is detected on a packet, if the Rank-Error bit was not set, then the Rank-Error bit is set. If it was set the packet MUST be discarded and the Trickle timer MUST be reset.
このプロセスは、パケットに関連付けられたランクのエラービットによって制御されています。矛盾がパケット上で検出された場合ランクのエラービットがセットされていなかった場合は、その後、ランク・エラー・ビットが設定されています。それが設定されている場合は、パケットを捨てなければなりませんし、トリクルタイマーをリセットする必要があります。
DAO inconsistency loop recovery is a mechanism that applies to Storing mode of operation only.
DAO矛盾ループ回復は操作のみのモードを保存するに適用される仕組みです。
In Non-Storing mode, the packets are source routed to the destination, and DAO inconsistencies are not corrected locally. Instead, an ICMP error with a new code "Error in Source Routing Header" is sent back to the root. The "Error in Source Routing Header" message has the same format as the "Destination Unreachable Message", as specified in [RFC4443]. The portion of the invoking packet that is sent back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node so that the destination in the IPv6 header is the next hop that this node could not reach.
非保存モードでは、パケットが宛先にソースルーティングされ、およびDAOの矛盾はローカルに修正されていません。代わりに、新しいコード「ソースルーティングヘッダでエラーが発生しました」とICMPエラーは、ルートに送り返されます。メッセージ「ソースルーティングヘッダのエラーが発生しました」[RFC4443]で指定されるように、「宛先到達不能メッセージ」と同じフォーマットを持っています。 IPv6ヘッダーの宛先が次のホップであるようにICMPメッセージで返送された呼び出しパケットの部分は、少なくともルーティングヘッダまで記録する必要があり、ルーティングヘッダは、このノードによって消費すべきことは、このノードができました届きません。
A DAO inconsistency happens when a router has a Downward route that was previously learned from a DAO message via a child, but that Downward route is not longer valid in the child, e.g., because that related state in the child has been cleaned up. With DAO inconsistency loop recovery, a packet can be used to recursively explore and clean up the obsolete DAO states along a sub-DODAG.
ルータは以前に子を経由してDAOメッセージから学習された下向きのルートを持っているとき、DAOの矛盾が起こるが、子のそれに関連する状態がクリーンアップされているので、その下向きのルートは、例えば、子供にはもはや有効ではありません。 DAOの矛盾ループの回復を使用すると、パケットは、再帰的にサブDODAGに沿って廃止されたDAOの状態を調査し、クリーンアップするために使用することができます。
In a general manner, a packet that goes Down should never go Up again. If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet back to the parent that passed it with the Forwarding-Error 'F' bit set and the 'O' bit left untouched. Otherwise, the router MUST silently discard the packet.
一般的に、ダウンしたパケットが再び上がることはありません。 DAOの矛盾ループの回復が適用される場合、ルータはバックフォワーディングエラー「F」ビットセットと放置「O」ビットでそれを渡された親にパケットを送るべきです。そうしないと、ルータは黙ってパケットを捨てなければなりません。
Upon receiving a packet with a Forwarding-Error bit set, the node MUST remove the routing states that caused forwarding to that neighbor, clear the Forwarding-Error bit, and attempt to send the packet again. The packet may be sent to an alternate neighbor, after the expiration of a user-configurable implementation-specific timer. If that alternate neighbor still has an inconsistent DAO state via this node, the process will recurse, this node will set the Forwarding-Error 'F' bit, and the routing state in the alternate neighbor will be cleaned up as well.
フォワーディング・エラービットを設定してパケットを受信すると、ノードは、その近隣への転送引き起こさルーティング状態を除去フォワーディングエラービットをクリアし、再度パケットを送信しようとしなければなりません。パケットは、ユーザ設定実装固有のタイマーの満了後に、代替隣人に送ることができます。その代替ネイバーがまだこのノードを介して、一貫性のないDAO状態を有する場合、プロセスは再帰的であろう、このノードは、「F」ビットを転送し、エラーを設定し、代替隣人にルーティング状態は、同様にクリーンアップされるであろう。
This section describes a multicast routing operation over an IPv6 RPL network and, specifically, how unicast DAOs can be used to relay group registrations. The same DODAG construct can be used to forward unicast and multicast traffic. This section is limited to a description of how group registrations may be exchanged and how the forwarding infrastructure operates. It does not provide a full description of multicast within an LLN and, in particular, does not describe the generation of DODAGs specifically targeted at multicast or the details of operating RPL for multicast -- that will be the subject of further specifications.
このセクションでは、ユニキャストのDAOは、グループの登録を中継するために使用することができ、具体的に、どのように、IPv6のRPLネットワーク上でマルチキャストルーティング動作を説明すると。同じDODAG構築物は、ユニキャストとマルチキャストトラフィックを転送するために使用することができます。このセクションでは、グループの登録を交換することができ、転送インフラストラクチャがどのように動作するか方法の説明に限定されます。さらに、仕様の対象となります - それは、特に、特異的にマルチキャストまたはマルチキャストのための動作RPLの詳細を対象DODAGsの生成を記載していない、LLN内マルチキャストの完全な説明を提供しません。
The multicast group registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered with the multicast group, whereas unicast traffic is passed to one child only.
マルチキャストグループ登録が搬送されるアドレスのタイプを除いてユニキャスト同一でDAOメッセージを使用します。主な違いは、ダウンして、マルチキャストトラフィックがユニキャストトラフィックのみ一人の子供に渡されたのに対し、マルチキャストグループに登録したすべての子供にコピーされていることです。
Nodes that support the RPL Storing mode of operation SHOULD also support multicast DAO operations as described below. Nodes that only support the Non-Storing mode of operation are not expected to support this section.
後述のように操作のRPL記憶モードをサポートしているノードは、マルチキャストのDAO操作をサポートする必要があります。動作のみの非保存モードをサポートするノードは、このセクションをサポートすることが期待されていません。
The multicast operation is controlled by the MOP field in the DIO.
マルチキャスト操作はDIOにMOPフィールドによって制御されています。
o If the MOP field requires multicast support, then a node that joins the RPL network as a router must operate as described in this section for multicast signaling and forwarding within the RPL network. A node that does not support the multicast operation required by the MOP field can only join as a leaf.
MOPフィールドは、マルチキャストサポートを必要とする場合RPLネットワーク内のマルチキャストシグナリング及び転送のために、このセクションで説明したように、O、次いでルータとしてRPLのネットワークに参加するノードが動作しなければなりません。 MOP分野で必要とされるマルチキャスト操作をサポートしていないノードは、葉として参加することができます。
o If the MOP field does not require multicast support, then multicast is handled by some other way that is out of scope for this specification. (Examples may include a series of unicast copies or limited-scope flooding).
MOPフィールドはマルチキャストサポートを必要としない場合は、O、その後、マルチキャストは、この仕様の範囲外であるいくつかの他の方法によって処理されます。 （例としては、ユニキャストコピーまたは制限されたスコープフラッディングのシリーズを含んでいてもよいです）。
A router might select to pass a listener registration DAO message to its preferred parent only; in which case, multicast packets coming back might be lost for all of its sub-DODAGs if the transmission fails over that link. Alternatively, the router might select copying additional parents as it would do for DAO messages advertising unicast destinations; in which case, there might be duplicates that the router will need to prune.
ルータはその好ましい親にリスナ登録DAOメッセージを渡すように選択できます。トランスミッションは、そのリンク上で障害が発生した場合、その場合には、戻ってくるマルチキャストパケットは、そのサブDODAGsのすべてのために失われる可能性があります。また、ルータは、ユニキャストの目的地を宣伝DAOメッセージに対して行うように、追加の親をコピーする選択するかもしれません。その場合には、ルータがプルーニングする必要があります重複があるかもしれません。
As a result, multicast routing states are installed in each router on the way from the listeners to the DODAG root, enabling the root to copy a multicast packet to all its children routers that had issued a DAO message including a Target option for that multicast group.
その結果、マルチキャストルーティング状態は、そのマルチキャストグループのターゲットオプションを含む、DAOメッセージを発行したすべての子ルータにマルチキャストパケットをコピーするルートを可能にDODAGルートにリスナーからの道上の各ルータに搭載されています。
For a multicast packet sourced from inside the DODAG, the packet is passed to the preferred parents, and if that fails, then to the alternates in the DODAG. The packet is also copied to all the registered children, except for the one that passed the packet. Finally, if there is a listener in the external infrastructure, then the DODAG root has to further propagate the packet into the external infrastructure.
DODAG内部から発信マルチキャストパケットの場合、パケットは優先両親に渡されており、それは、その後、DODAGで交互に失敗した場合。パケットは、パケットを通過した1を除いて、すべての登録された子どもたちにコピーされます。リスナーは、外部のインフラストラクチャに存在する場合最後に、その後、DODAGルートは、外部インフラストラクチャにパケットを伝播する必要があります。
As a result, the DODAG root acts as an automatic proxy Rendezvous Point for the RPL network and as source towards the non-RPL domain for all multicast flows started in the RPL domain. So, regardless of whether the root is actually attached to a non-RPL domain, and regardless of whether the DODAG is grounded or floating, the root can serve inner multicast streams at all times.
結果として、RPLネットワークおよびすべてのマルチキャストフローの非RPLドメイン向かっ源として自動プロキシランデブーポイントとしてDODAGルート作用は、RPLのドメインで開始しました。だから、かどうかに関係なく、ルートの実際非RPLドメインに取り付けられ、そしてかかわらずDODAGは接地又はフローティングされているかどうかのルートは常に内側マルチキャストストリームを配信することができます。
The selection of successors, along the default paths Up along the DODAG, or along the paths learned from destination advertisements Down along the DODAG, leads to the formation of routing adjacencies that require maintenance.
アップDODAGに沿って、デフォルトのパスに沿って、またはパスに沿って後継者の選択は、メンテナンスを必要とルーティング隣接関係の形成につながる、ダウンDODAGに沿って先広告から学びました。
In IGPs, such as OSPF [RFC4915] or IS-IS [RFC5120], the maintenance of a routing adjacency involves the use of keepalive mechanisms (Hellos) or other protocols such as the Bidirectional Forwarding Detection (BFD) [RFC5881] and the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130]. Unfortunately, such a proactive approach is often not desirable in constrained environments where it would lead to excessive control traffic in light of the data traffic with a negative impact on both link loads and nodes resources.
例えばOSPF [RFC4915]などのIGP、または[RFC5120] - であり、ルーティング隣接関係の維持は、キープアライブ機構（ハローズ）、または双方向フォワーディング検出（BFD）[RFC5881]及びMANETのような他のプロトコルの使用を含みます近隣探索プロトコル（NHDP）[RFC6130]。残念ながら、このような積極的なアプローチは、それがリンク負荷およびノードリソースの両方に負の影響を有するデータトラフィックに照らして過度の制御トラフィックにつながる拘束環境ではしばしば望ましくありません。
By contrast with those routing protocols, RPL does not define any keepalive mechanisms to detect routing adjacency failures: this is because in many cases, such a mechanism would be too expensive in terms of bandwidth and, even more importantly, energy (a battery-operated device could not afford to send periodic keepalives). Still RPL requires an external mechanisms to detect that a neighbor is no longer reachable. Such a mechanism should preferably be reactive to traffic in order to minimize the overhead to maintain the routing adjacency and focus on links that are actually being used.
これらのルーティングプロトコルとは対照的に、RPLは、ルーティング隣接障害を検出するために、任意のキープアライブメカニズムを定義していない。多くの場合、そのような機構がさらに重要なことは、帯域幅の面で非常に高価であることとなるので、これは、エネルギー（バッテリ駆動デバイスは）定期的にキープアライブを送信する余裕がなかったです。それでもRPLは、隣人がもはや到達可能であることを検出しないために、外部のメカニズムを必要とします。そのような機構は、ルーティング隣接関係を維持し、実際に使用されているリンクに集中するオーバーヘッドを最小限に抑えるために、トラフィックに反応性であるべきです。
Example reactive mechanisms that can be used include:
使用することができる。例えば、反応のメカニズムは、次のとおりです。
The Neighbor Unreachability Detection [RFC4861] mechanism.
近隣到達不能検出[RFC4861]メカニズム。
Layer 2 triggers [RFC5184] derived from events such as association states and L2 acknowledgements.
そのような会合状態とL2肯定応答などのイベントに由来層2つのトリガー[RFC5184]。
An Objective Function (OF), in conjunction with routing metrics and constraints, allows for the selection of a DODAG to join, and a number of peers in that DODAG as parents. The OF is used to compute an ordered list of parents. The OF is also responsible to compute the Rank of the device within the DODAG Version.
目的関数（OF）、ルーティング・メトリックおよび制約に関連して、参加するDODAGの選択、および親としてそのDODAG内のピアの数を可能にします。 OFは、両親の順序付きリストを計算するために使用されます。 OFもDODAGバージョン内のデバイスのランクを計算する責任があります。
The Objective Function is indicated in the DIO message using an Objective Code Point (OCP), and it indicates the method that must be used to construct the DODAG. The Objective Code Points are specified in [RFC6552] and related companion specifications.
目的関数は目的コードポイント（OCP）を使用して、DIOメッセージに示され、それはDODAGを構築するために使用されなければならない方法を示しています。目的のコードポイントは、[RFC6552]および関連コンパニオン仕様で指定されています。
Most Objective Functions are expected to follow the same abstract behavior at a node:
ほとんどの目的関数は、ノードで同じ抽象行動を追跡することが期待されています。
o The parent selection is triggered each time an event indicates that a potential next-hop information is updated. This might happen upon the reception of a DIO message, a timer elapse, all DODAG parents are unavailable, or a trigger indicating that the state of a candidate neighbor has changed.
親選択oをイベント電位次ホップの情報が更新されたことを示すたびにトリガされます。これは、候補ネイバーの状態が変更されたことを示すすべてのDODAGの親が使用できないDIOメッセージ、タイマー経過、またはトリガの受信時に発生する可能性があります。
o An OF scans all the interfaces on the node. Although, there may typically be only one interface in most application scenarios, there might be multiple of them and an interface might be configured to be usable or not for RPL operation. An interface can also be configured with a preference or dynamically learned to be better than another by some heuristics that might be link-layer dependent and are out of scope for this specification. Finally, an interface might or might not match a required criterion for an Objective Function, for instance, a degree of security. As a result, some interfaces might be completely excluded from the computation, for example, if those interfaces cannot satisfy some advertised constraints, while others might be more or less preferred.
スキャンのノードのすべてのインターフェイスO。典型的には、ほとんどのアプリケーション・シナリオでは1つのインタフェースだけが存在してもよい、が、そこにそれらの複数であるかもしれないとインターフェースがRPLの操作に使用可能かどうかになるように構成されるかもしれません。インターフェースはまた、有利に構成することも、または動的にリンク層依存する、本明細書の範囲外であるかもしれないいくつかのヒューリスティックにより他よりも良好であることを学んだことができます。最後に、インタフェースはあるいは、例えば、目的関数のセキュリティの度合いを必要基準に一致しない場合があります。これらのインタフェースは、いくつかのアドバタイズ制約を満たすことができない場合は他の人が多かれ少なかれ好ましいかもしれないが、結果として、いくつかのインターフェイスは完全に、例えば、計算から除外されるかもしれません。
o An OF scans all the candidate neighbors on the possible interfaces to check whether they can act as a router for a DODAG. There might be many of them and a candidate neighbor might need to pass some validation tests before it can be used. In particular, some link layers require experience on the activity with a router to enable the router as a next hop.
彼らはDODAGのためのルータとして動作することができるかどうかを確認するために可能なインターフェイス上でスキャンし、すべての候補の隣人の入出力。そこにそれらの多くであるかもしれないし、それを使用することができます前に、候補の隣人は、いくつかの検証テストに合格する必要がある場合があります。特に、いくつかのリンク層は、ネクストホップとしてルータを有効にするには、ルータとの活動の経験が必要です。
o An OF computes Rank of a node for comparison by adding to the Rank of the candidate a value representing the relative locations of the node and the candidate in the DODAG Version.
Oの候補者のランクにノードの相対的位置を表す値とDODAGバージョン内の候補を追加することによって、比較のために、ノードのランクを計算します。
* The increase in Rank must be at least MinHopRankIncrease.
*ランクの増加は、少なくともMinHopRankIncreaseでなければなりません。
* To keep loop avoidance and metric optimization in alignment, the increase in Rank should reflect any increase in the metric value. For example, with a purely additive metric, such as ETX, the increase in Rank can be made proportional to the increase in the metric.
*一直線にループ回避とメトリックの最適化を維持するには、ランクの増加は、メトリック値の増加を反映すべきです。例えば、このようなETXなどの純粋に添加メトリックと、ランクの増加は、メトリックの増加に比例して行うことができます。
* Candidate neighbors that would cause the Rank of the node to increase are not considered for parent selection.
ノードのランクが増加する原因となる*候補の隣人は、親の選択のために考慮されていません。
o Candidate neighbors that advertise an OF incompatible with the set of OFs specified by the policy functions are ignored.
ポリシー機能で指定されたのOFのセットと互換性の宣伝O候補の隣人は無視されます。
o As it scans all the candidate neighbors, the OF keeps the current best parent and compares its capabilities with the current candidate neighbor. The OF defines a number of tests that are critical to reach the objective. A test between the routers determines an order relation.
それはすべての候補の隣人をスキャンすると、O、OFは、現在の最良の親を保持し、現在の候補ネイバーとその機能を比較します。 OFは、目標を達成するために不可欠なテストの数を定義します。ルータ間の試験は、順序関係を決定します。
* If the routers are equal for that relation, then the next test is attempted between the routers,
ルータはその関係のために等しい場合*、その後、次のテストは、ルータ間で試みられ、
* Else the best of the two routers becomes the current best parent, and the scan continues with the next candidate neighbor.
*エルスつのルータの最高は、現在最高の親になり、スキャンは次の候補隣人と続きます。
* Some OFs may include a test to compare the Ranks that would result if the node joined either router.
*いくつかのofsが、ノードがルータのいずれかに参加した場合に生じるであろうランクを比較するテストを含むことができます。
o When the scan is complete, the preferred parent is elected and the node's Rank is computed as the preferred parent Rank plus the step in Rank with that parent.
スキャンが完了すると、O、好ましい親が選出され、ノードのランクは、好ましい親ランクプラスその親とのランクのステップとして計算されます。
o Other rounds of scans might be necessary to elect alternate parents. In the next rounds:
Oスキャンの他のラウンドは、代替親を選出する必要があります。次のラウンドで：
* Candidate neighbors that are not in the same DODAG are ignored.
同じDODAGではありません*候補隣人は無視されます。
* Candidate neighbors that are of greater Rank than the node are ignored.
*ノードよりも大きなランクのある候補隣人は無視されます。
* Candidate neighbors of an equal Rank to the node are ignored for parent selection.
*ノードに等しいランクの候補隣人は、親の選択のために無視されます。
* Candidate neighbors of a lesser Rank than the node are preferred.
*ノードよりも低いランクの候補ネイバーが好ましいです。
This specification directly borrows the Prefix Information Option (PIO) and the Route Information Option (RIO) from IPv6 ND. It is envisioned that, as future specifications build on this base, there may be additional cause to leverage parts of IPv6 ND. This section provides some suggestions for future specifications.
この仕様は、直接プレフィックス情報オプション（PIO）およびIPv6 NDからのルート情報オプション（RIO）を借用します。これは、将来の仕様は、このベース上に構築として、IPv6のNDのレバレッジ部分に追加の原因があるかもしれない、ということが想定されます。このセクションでは、将来の仕様のためのいくつかの提案を提供します。
First and foremost, RPL is a routing protocol. One should take great care to preserve architecture when mapping functionalities between RPL and ND. RPL is for routing only. That said, there may be persuading technical reasons to allow for sharing options between RPL and IPv6 ND in a particular implementation/deployment.
まず第一に、RPLは、ルーティングプロトコルです。一つは、RPLとNDの間で機能をマッピングする際のアーキテクチャを維持するために細心の注意を払う必要があります。 RPLは、唯一のルーティング用です。これは、特定の実装/展開でRPLとIPv6 NDの間で共有オプションを可能にするための技術的な理由が説得することができる、と述べました。
In general, the following guidelines apply:
一般的には、以下のガイドラインが適用されます。
o RPL Type codes must be allocated from the RPL Control Message Options registry.
O RPLタイプ・コードは、RPL制御メッセージのオプションレジストリから割り当てられなければなりません。
o RPL Length fields must be expressed in units of single octets, as opposed to ND Length fields, which are expressed in units of 8 octets.
8つのオクテットの単位で表されるND長フィールド、とは対照的にO RPL長フィールドは、単一オクテットの単位で表現されなければなりません。
o RPL options are generally not required to be aligned to 8-octet boundaries.
O RPLオプションは、一般的に8オクテット境界に整列させる必要はありません。
o When mapping/transposing an IPv6 ND option for redistribution as a RPL option, any padding octets should be removed when possible. For example, the Prefix Length field in the PIO is sufficient to describe the length of the Prefix field. When mapping/transposing a RPL option for redistribution as an IPv6 ND option, any such padding octets should be restored. This procedure must be unambiguous.
Oマッピング/ RPLオプションとして再配分のためのIPv6 NDオプションを転置は、任意のパディングオクテットが可能な場合は除去しなければならないとき。例えば、PIOでのプレフィックス長フィールドは、プレフィックスフィールドの長さを記述するのに十分です。 IPv6のNDオプションとして再配分のためのRPLオプションを転置/マッピングする場合、どのようにパディングオクテットが復元される必要があります。この手順は、明確なでなければなりません。
This section summarizes basic interoperability and references normative text for RPL implementations operating in one of three major modes. Implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. A fourth mode, operation as a leaf, is also possible.
この節では、3つの主要なモードのいずれかで動作するRPLの実装のための基本的な相互運用性と参照規範的なテキストをまとめました。実装は唯一の下向きのルート、非保存モードのいずれかをサポートしないことが予想、または専用モードを格納しています。第四のモード、葉のような動作も可能です。
Implementations conforming to this specification may contain different subsets of capabilities as appropriate to the application scenario. It is important for the implementer to support a level of interoperability consistent with that required by the application scenario. To this end, further guidance may be provided beyond this specification (e.g., as applicability statements), and it is understood that in some cases such further guidance may override portions of this specification.
この仕様に準拠した実装は、アプリケーションシナリオに適切に機能の異なるサブセットを含むことができます。実装者は、アプリケーションのシナリオで必要とされるものと一致し、相互運用性のレベルをサポートすることが重要です。この目的のために、更なるガイダンスは、（適用文として、例えば）本明細書超えて設けられていてもよい、いくつかのケースでは、そのようなさらなるガイダンスは、本明細書の一部を無効にしてもよいことが理解されます。
In a general case, the greatest level of interoperability may be achieved when all of the nodes in a RPL LLN are cooperating to use the same MOP, OF, metrics, and constraints, and are thus able to act as RPL routers. When a node is not capable of being a RPL router, it may be possible to interoperate in a more limited manner as a RPL leaf.
一般的な場合では、相互運用性の最大レベルは、RPL LLN内のすべてのノードが同じMOPの、メトリクス、および制約を使用するように協働し、従ってRPLルータとして作用することができるされている場合に達成されてもよいです。ノードは、RPLのルータであることが可能でない場合には、RPLの葉のように、より限定的に相互運用することが可能です。
All RPL implementations need to support the use of RPL Packet Information transported within data packets (Section 11.2). One such mechanism is described in [RFC6553].
すべてのRPLの実装は、データ・パケット（11.2）内で輸送RPLパケット情報の使用をサポートする必要があります。そのようなメカニズムは、[RFC6553]に記載されています。
RPL implementations will need to support the use of Neighbor Unreachability Detection (NUD), or an equivalent mechanism, to maintain the reachability of neighboring RPL nodes (Section 8.2.1). Alternate mechanisms may be optimized to the constrained capabilities of the implementation, such as hints from the link layer.
RPLの実装では、隣接RPLノード（セクション8.2.1）の到達可能性を維持するために、近隣到達不能検出（NUD）の使用、または同等の機構をサポートする必要があります。代替の機構は、リンク層からのヒントとして、実装の制約能力を最適化することができます。
This specification provides means to obtain a PIO and thus form an IPv6 address. When that mechanism is used, it may be necessary to perform address resolution and duplicate address detection through an external process, such as IPv6 ND [RFC4861] or 6LoWPAN ND [6LOWPAN-ND].
この仕様は、PIOを得るので、IPv6アドレスを形成するための手段を提供します。そのメカニズムが使用される場合、そのようなIPv6のND [RFC4861]または6LoWPAN ND [6LOWPAN-ND]のような外部プロセスを介してアドレス解決を実行し、アドレス検出を複製する必要があるかもしれません。
o An implementation of a leaf node (only) does not ever participate as a RPL router. Interoperable implementations of leaf nodes behave as summarized in Section 8.5.
Oリーフノードの実装では、（のみ）今までにRPLルーターとして参加していません。セクション8.5にまとめたようにリーフノードの相互運用可能な実装を振る舞います。
o Support of a particular MOP encoding is not required, although if the leaf node sends DAO messages to set up Downward routes, the leaf node should do so in a manner consistent with the mode of operation indicated by the MOP.
リーフノードが下方ルートを設定するDAOメッセージを送信した場合、リーフノードはMOPで示される動作モードと一致した方法で行うべきであるO特にMOP符号化のサポートは、必要とされません。
o Support of a particular OF is not required.
特定OFのOサポートは必要ありません。
o In summary, a leaf node does not generally issue DIO messages, it may issue DAO and DIS messages. A leaf node accepts DIO messages though it generally ignores DAO and DIS messages.
要約すると、リーフノードは、一般的にDIOメッセージを発行しないO、それはDAOとDISメッセージを発行することができます。それは一般的にDAOとDISメッセージを無視してもリーフノードは、DIOメッセージを受け付けます。
If further guidance is not available then a RPL router implementation MUST at least support the metric-less OF0 [RFC6552].
更なるガイダンスが利用できない場合は、RPLルータの実装は、少なくともメトリックレスOF0 [RFC6552]をサポートしなければなりません。
For consistent operation a RPL router implementation needs to support the MOP in use by the DODAG.
一貫性のある動作のためにRPLルータの実装はDODAGで使用されてMOPをサポートする必要があります。
All RPL routers will need to implement Trickle [RFC6206].
すべてのRPLルータはトリクル[RFC6206]を実装する必要があります。
An implementation of a RPL router that supports only Upward routes supports the following:
上方のみのルートをサポートRPLルータの実装では、次をサポートしています。
o Upward routes (Section 8)
上向き経路（セクション8）O
o MOP encoding 0 (Section 20.3)
Oモップエンコーディング0（セクション20.3）
o In summary, DIO and DIS messages are issued, and DAO messages are not issued. DIO and DIS messages are accepted, and DAO messages are ignored.
O要約すると、DIOとDISメッセージが発行され、そしてDAOメッセージが発行されていません。 DIOとDISメッセージが受け入れられ、DAOメッセージは無視されます。
16.3.2. Support for Upward Routes and Downward Routes in Non-Storing Mode
16.3.2. 非登録モードにおける上向き経路と下りルートのサポート
An implementation of a RPL router that supports Upward routes and Downward routes in Non-Storing mode supports the following:
非収納モードで上向きルートや下向きのルートをサポートしているRPLルータの実装では、次をサポートしています。
o Upward routes (Section 8)
上向き経路（セクション8）O
o Downward routes (Non-Storing) (Section 9)
O下向き経路（非記憶）（セクション9）
o MOP encoding 1 (Section 20.3)
入出力MOPエンコード1（セクション20.3）
o Source-routed Downward traffic ([RFC6554])
Oソースルート下向きのトラフィック（[RFC6554]）
o In summary, DIO and DIS messages are issued, and DAO messages are issued to the DODAG root. DIO and DIS messages are accepted, and DAO messages are ignored by nodes other than DODAG roots. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means.
O要約すると、DIOとDISメッセージが発行され、そしてDAOメッセージがDODAGルートに発行されています。 DIOとDISメッセージが受け入れられ、DAOメッセージがDODAGの根以外のノードによって無視されます。それはいくつかの代替手段によって支持されてもよいが、マルチキャストは、本明細書に記載の手段を介してサポートされていません。
An implementation of a RPL router that supports Upward routes and Downward routes in Storing mode supports the following:
モードを保存するには上向きのルートと下向きのルートをサポートしているRPLルータの実装では、次をサポートしています。
o Upward routes (Section 8)
上向き経路（セクション8）O
o Downward routes (Storing) (Section 9)
O下向き経路（記憶）（項9）
o MOP encoding 2 (Section 20.3)
入出力MOPエンコード2（セクション20.3）
o In summary, DIO, DIS, and DAO messages are issued. DIO, DIS, and DAO messages are accepted. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means.
O要約すると、DIO、DIS、およびDAOのメッセージが発行されます。 DIO、DIS、およびDAOのメッセージが受け入れられています。それはいくつかの代替手段によって支持されてもよいが、マルチキャストは、本明細書に記載の手段を介してサポートされていません。
A Storing mode implementation may be enhanced with basic multicast support through the following additions:
保存モードの実装は、以下の追加により、基本的なマルチキャストサポートを強化することができます。
o Basic Multicast Support (Section 12)
O基本的なマルチキャストのサポート（第12節）
o MOP encoding 3 (Section 20.3)
入出力MOPエンコード3（セクション20.3）
A number of items are left to future specification, including but not limited to the following:
項目数は、次のように制限を含め、将来の仕様に残されていませんが。
o How to attach a non-RPL node such as an IPv6 host, e.g., to consistently distribute at least PIO material to the attached node.
Oどのように一貫して接続されたノードに対して少なくともPIO材料を分配するために、例えば、そのようなIPv6ホストとして非RPLノードをアタッチします。
o How to obtain authentication material in support if authenticated mode is used (Section 10.3).
認証されたモードが（10.3）を使用した場合Oサポートで認証材料を入手する方法。
o Details of operation over multiple simultaneous instances.
複数の同時インスタンスを超える動作の詳細について、O。
o Advanced configuration mechanisms, such as the provisioning of RPLInstanceIDs, parameterization of Objective Functions, and parameters to control security. (It is expected that such mechanisms might extend the DIO as a means to disseminate information across the DODAG).
OようRPLInstanceIDs、目的関数のパラメータ、及びパラメータのプロビジョニングなどの高度なコンフィギュレーションメカニズムは、セキュリティを制御します。 （このような機構はDODAG横切って情報を発信するための手段としてDIOを拡張するかもしれないことが予想されます）。
The following is a summary of RPL constants and variables:
以下は、RPLの定数と変数の要約であります：
BASE_RANK: This is the Rank for a virtual root that might be used to coordinate multiple roots. BASE_RANK has a value of 0.
BASE_RANK：これは、複数のルートを調整するために使用されるかもしれない仮想ルートのためのランクです。 BASE_RANKは0の値を持ちます。
ROOT_RANK: This is the Rank for a DODAG root. ROOT_RANK has a value of MinHopRankIncrease (as advertised by the DODAG root), such that DAGRank(ROOT_RANK) is 1.
ROOT_RANK：これはDODAGルートのランクです。 （DODAGルートによってアドバタイズされる）ROOT_RANKはDAGRank（ROOT_RANK）が1であるように、MinHopRankIncreaseの値を有します。
INFINITE_RANK: This is the constant maximum for the Rank. INFINITE_RANK has a value of 0xFFFF.
INFINITE_RANK：これは、ランクのために一定の最大です。 INFINITE_RANKは値0xFFFFを持っています。
RPL_DEFAULT_INSTANCE: This is the RPLInstanceID that is used by this protocol by a node without any overriding policy. RPL_DEFAULT_INSTANCE has a value of 0.
RPL_DEFAULT_INSTANCE：これは、任意のオーバーライドポリシーなしノードによって、このプロトコルで使用されるRPLInstanceIDあります。 RPL_DEFAULT_INSTANCEは0の値を持ちます。
DEFAULT_PATH_CONTROL_SIZE: This is the default value used to configure PCS in the DODAG Configuration option, which dictates the number of significant bits in the Path Control field of the Transit Information option. DEFAULT_PATH_CONTROL_SIZE has a value of 0. This configures the simplest case limiting the fan-out to 1 and limiting a node to send a DAO message to only one parent.
DEFAULT_PATH_CONTROL_SIZE：これはトランジット情報オプションのパス制御フィールド内の有効ビット数を指示DODAG構成オプション、でPCSを構成するために使用されるデフォルト値です。 DEFAULT_PATH_CONTROL_SIZEこれは最も単純なケース1のファンアウトを制限し、唯一の親にDAOメッセージを送信するためにノードを制限することを構成する0の値を有します。
DEFAULT_DIO_INTERVAL_MIN: This is the default value used to configure Imin for the DIO Trickle timer. DEFAULT_DIO_INTERVAL_MIN has a value of 3. This configuration results in Imin of 8 ms.
DEFAULT_DIO_INTERVAL_MIN：これはDIOトリクルタイマーの値Iminを設定するために使用されるデフォルト値です。 DEFAULT_DIO_INTERVAL_MINは、8ミリ秒の値Imin 3.この設定結果の値を有します。
DEFAULT_DIO_INTERVAL_DOUBLINGS: This is the default value used to configure Imax for the DIO Trickle timer. DEFAULT_DIO_INTERVAL_DOUBLINGS has a value of 20. This configuration results in a maximum interval of 2.3 hours.
DEFAULT_DIO_INTERVAL_DOUBLINGS：これはDIOトリクルタイマーの値Imaxを設定するために使用されるデフォルト値です。 DEFAULT_DIO_INTERVAL_DOUBLINGSは、2.3時間の最大間隔で20この設定結果の値を有します。
DEFAULT_DIO_REDUNDANCY_CONSTANT: This is the default value used to configure k for the DIO Trickle timer. DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This configuration is a conservative value for Trickle suppression mechanism.
DEFAULT_DIO_REDUNDANCY_CONSTANT：これはDIOトリクルタイマーのためのkを設定するために使用されるデフォルト値です。 DEFAULT_DIO_REDUNDANCY_CONSTANTこの構成はトリクル抑制機構のために控えめな値である10の値を有します。
DEFAULT_MIN_HOP_RANK_INCREASE: This is the default value of MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value of 256. This configuration results in an 8-bit wide integer part of Rank.
DEFAULT_MIN_HOP_RANK_INCREASE：これはMinHopRankIncreaseのデフォルト値です。 DEFAULT_MIN_HOP_RANK_INCREASEはランクの8ビット幅の整数部分で256この設定結果の値を有します。
DEFAULT_DAO_DELAY: This is the default value for the DelayDAO Timer. DEFAULT_DAO_DELAY has a value of 1 second. See Section 9.5.
DEFAULT_DAO_DELAY：これはDelayDAOタイマーのデフォルト値です。 DEFAULT_DAO_DELAYは、1秒の値を有します。 9.5節を参照してください。
DIO Timer: One instance per DODAG of which a node is a member. Expiry triggers DIO message transmission. A Trickle timer with variable interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See Section 8.3.1
DIOタイマ：ノードが属しているDODAGごとに1つのインスタンス。有効期限は、DIOメッセージの送信をトリガします。中の変数区間[0、DIOIntervalMin..2 ^ DIOIntervalDoublings]とトリクルタイマー。第8.3.1項を参照してください
DAG Version Increment Timer: Up to one instance per DODAG of which the node is acting as DODAG root. May not be supported in all implementations. Expiry triggers increment of DODAGVersionNumber, causing a new series of updated DIO message to be sent. Interval should be chosen appropriate to propagation time of DODAG and as appropriate to application requirements (e.g., response time versus overhead).
DAGバージョンインクリメントタイマー：DODAGあたり1つのインスタンスまでは、そのノードがDODAGルートとして機能しています。すべての実装ではサポートされない場合があります。有効期限は、送信する更新DIOメッセージの新シリーズを引き起こし、DODAGVersionNumberの増分をトリガーします。間隔はDODAGの伝播時間に適切な、アプリケーションの要件（例えば、応答時間に対するオーバーヘッド）に適宜選択されるべきです。
DelayDAO Timer: Up to one timer per DAO parent (the subset of DODAG parents chosen to receive destination advertisements) per DODAG. Expiry triggers sending of DAO message to the DAO parent. See Section 9.5
DelayDAOタイマー：DODAGあたりDAOの親（先の広告を受信するために選ばれたDODAGの両親のサブセット）ごとに1つのタイマーまで。有効期限は、DAOの親にDAOメッセージの送信をトリガします。 9.5節を参照してください。
RemoveTimer: Up to one timer per DAO entry per neighbor (i.e., those neighbors that have given DAO messages to this node as a DODAG parent). Expiry may trigger No-Path advertisements or immediately deallocate the DAO entry if there are no DAO parents.
RemoveTimer：隣人あたりDAOエントリ（DODAGの親としてこのノードにDAOメッセージを与えている、すなわち、それらの隣人）ごとに1つのタイマーまで。有効期限はありませんパスの広告をトリガするか、すぐに何のDAOの親が存在しない場合はDAOエントリの割り当てを解除することがあります。
The aim of this section is to give consideration to the manageability of RPL, and how RPL will be operated in an LLN. The scope of this section is to consider the following aspects of manageability: configuration, monitoring, fault management, accounting, and performance of the protocol in light of the recommendations set forth in [RFC5706].
このセクションの目的は、RPLの管理に配慮することであり、どのようにRPLはLLNに運営されます。 [RFC5706]に記載された推奨事項に照らして設定、監視、障害管理、会計、及びプロトコルの性能：このセクションの範囲は、管理の次の側面を考慮することです。
Most of the existing IETF management standards are MIB modules (data models based on the Structure of Management Information (SMI)) to monitor and manage networking devices.
既存のIETF管理基準の大半は、ネットワークデバイスを監視および管理するためのMIBモジュール（管理情報（SMI）の構造に基づいたデータモデル）です。
For a number of protocols, the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols.
プロトコルの数については、IETFコミュニティは、簡易ネットワーク管理プロトコル[RFC3410]、新しいプロトコルを管理するための管理情報[RFC2578]、およびMIBのデータモデルの構造を含め、IETF標準管理フレームワークを使用しています。
As pointed out in [RFC5706], the common policy in terms of operation and management has been expanded to a policy that is more open to a set of tools and management protocols rather than strictly relying on a single protocol such as SNMP.
[RFC5706]で指摘したように、運用管理の面で共通のポリシーは、厳密SNMPなどの単一プロトコルに頼るのではなく、ツールや管理プロトコルのセットに対してより開放されているポリシーに拡張されています。
In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration.
2003年には、インターネットアーキテクチャ委員会（IAB）は、ネットワーク管理に関するワークショップを開催しました[RFC3535]いくつかのIETFネットワーク管理プロトコルの長所と短所を議論し、運用上のニーズ、特にコンフィギュレーションに比べています。
One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the time of writing, the CoRE working group is actively working on resource management of devices in LLNs. Still, it is felt that this section provides important guidance on how RPL should be deployed, operated, and managed.
論じた1つの問題は、SNMP [RFC3410]のバイナリ形式のユーザ不親切でした。 LLNsの場合には、書き込み時には、コアワーキンググループが積極的にLLNs内のデバイスのリソース管理に取り組んでいることに留意しなければなりません。それでも、このセクションでは、RPLが展開されるべきかについての重要な指針を提供することを感じた運営、および管理されています。
As stated in [RFC5706]:
[RFC5706]で述べたように：
A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified.
管理情報モデルは、プロトコルの態様は、イベントをカウントすることができ、発生する可能性のあるプロトコル固有のものイベント、どの操作の種類が許可され、設定する必要があり、そしてイベントのオペレータれ、管理可能であるかの議論を含むべきです通知する必要があります。
These aspects are discussed in detail in the following sections.
これらの態様は、以下のセクションで詳しく説明されています。
RPL will be used on a variety of devices that may have resources such as memory varying from a few kilobytes to several hundreds of kilobytes and even megabytes. When memory is highly constrained, it may not be possible to satisfy all the requirements listed in this section. Still it is worth listing all of these in an exhaustive fashion, and implementers will then determine which of these requirements could be satisfied according to the available resources on the device.
RPLはキロバイトとさえメガバイト数百、数キロバイトから変化メモリなどのリソースを有することができるさまざまなデバイスで使用されます。メモリが非常に制約されている場合は、このセクションに記載されているすべての要件を満たすことが可能ではないかもしれません。それでもそれは徹底的な方法でこれらのすべてをリストする価値がある、と実装者は、デバイス上で利用可能なリソースに応じて満足することができ、これらの要件のどれかを決定します。
This section discusses the configuration management, listing the protocol parameters for which configuration management is relevant.
このセクションでは、構成管理は、関連されたプロトコルパラメータをリスト、構成管理について説明します。
Some of the RPL parameters are optional. The requirements for configuration are only applicable for the options that are used.
RPLのパラメータの一部はオプションです。コンフィギュレーションのための要件は、使用されるオプションにのみ適用されています。
"Architectural Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually". This is especially true in LLNs where the number of devices may be large and manual configuration is infeasible. This has been taken into account in the design of RPL whereby the DODAG root provides a number of parameters to the devices joining the DODAG, thus avoiding cumbersome configuration on the routers and potential sources of misconfiguration (e.g., values of Trickle timers, etc.). Still, there are additional RPL parameters that a RPL implementation should allow to be configured, which are discussed in this section.
「インターネットの建築原理」[RFC1958]、セクション3.8、状態：「いつでも可能なオプションやパラメータを避け任意のオプションやパラメータを手動で動的ではなく、構成又は交渉されるべきです。」。これは、デバイスの数が多くてもよく、手動設定が不可能であるLLNsに特に当てはまります。これはDODAGルートは、このようにルータや設定ミスの可能性のあるソースに煩雑な設定を避け、DODAGを接合デバイスのパラメータの数を提供することにより、RPLの設計において考慮されている（例えば、等トリクルタイマーの値） 。依然として、このセクションで説明されているRPL実装が構成されることを可能にするべきである追加のRPLパラメータが存在します。
When a node is first powered up:
ノードが最初にパワーアップされている場合：
1. The node may decide to stay silent, waiting to receive DIO messages from DODAG of interest (advertising a supported OF and metrics/constraints) and not send any multicast DIO messages until it has joined a DODAG.
1.ノードは、それがDODAGに入社するまで、すべてのマルチキャストDIOメッセージを送信しない（およびメトリクス/拘束のサポート宣伝）関心のDODAGからDIOメッセージを受け取るのを待って、静かに滞在することを決定することができます。
2. The node may decide to send one or more DIS messages (optionally, requesting DIO for a specific DODAG) as an initial probe for nearby DODAGs, and in the absence of DIO messages in reply after some configurable period of time, the node may decide to root a floating DODAG and start sending multicast DIO messages.
2.ノードは、時間のいくつかの設定期間後にノードを近くDODAGsための初期プローブなどの1つまたは複数のDISメッセージ（必要に応じて、特定DODAGためDIOを要求）を送信することを決定し、応答におけるDIOメッセージの不在下でもよいです浮動DODAGをルートおよびマルチキャストDIOメッセージの送信を開始することを決定しました。
A RPL implementation SHOULD allow configuring the preferred mode of operation listed above along with the required parameters (in the second mode: the number of DIS messages and related timer).
（：DISメッセージと関連するタイマの数秒モード）RPL実装は、必要なパラメータと共に上記好ましい動作モードを設定可能にすべきです。
RPL specifies a number of protocol parameters considering the large spectrum of applications where it will be used. That said, particular attention has been given to limiting the number of these parameters that must be configured on each RPL router. Instead, a number of the default values can be used, and when required these parameters can be provided by the DODAG root thus allowing for dynamic parameter setting.
RPLは、それが使用されるアプリケーションの大規模なスペクトルを考慮したプロトコルパラメータの数を指定します。いえ、特に注意が各RPLのルータに設定されている必要があり、これらのパラメータの数を制限するに与えられています。代わりに、デフォルト値の数を使用することができ、必要な場合、これらのパラメータは、動的パラメータの設定を可能にするこのようDODAGルートによって提供することができます。
A RPL implementation SHOULD allow configuring the following routing protocol parameters. As pointed out above, note that a large set of parameters is configured on the DODAG root.
RPLの実装は、次のルーティングプロトコルパラメータを設定可能にすべきです。上記に指摘したように、パラメータの大規模なセットがDODAGルート上に設定されていることに注意してください。
A RPL implementation MUST allow configuring the following RPL parameters:
RPLの実装は、以下のRPLパラメータを設定許容しなければなりません：
o RPLInstanceID [DIO message, in DIO Base message]. Although the RPLInstanceID must be configured on the DODAG root, it must also be configured as a policy on every node in order to determine whether or not the node should join a particular DODAG. Note that a second RPLInstanceID can be configured on the node, should it become root of a floating DODAG.
[DIOベースメッセージにおけるDIOメッセージ] O RPLInstanceID。 RPLInstanceIDはDODAGルート上に設定されなければならないが、それはまた、ノードが特定のDODAGに参加するか否かを決定するために、すべてのノード上のポリシーとして設定する必要があります。それはフローティングDODAGのルートとなるべき、第RPLInstanceIDノード上に構成することができることに留意されたいです。
o List of supported Objective Code Points (OCPs)
Oサポート客観コードポイントのリスト（OCPs）
o List of supported metrics: [RFC6551] specifies a number of metrics and constraints used for the DODAG formation. Thus, a RPL implementation should allow configuring the list of metrics that a node can accept and understand. If a DIO is received with a metric and/or constraint that is not understood or supported, as specified in Section 8.5, the node would join as a leaf node.
Oサポートメトリックのリスト：[RFC6551]はDODAG形成に使用されるメトリックと制約の数を指定します。このように、RPLの実装では、ノードが受け入れ、理解できるメトリックのリストを設定できるようにすべきです。 DIOは、メトリックおよび/またはセクション8.5で指定されるように、理解またはサポートされていない制約で受信された場合、ノードはリーフノードとして参加することになります。
o Prefix Information, along with valid and preferred lifetime and the 'L' and 'A' flags. [DIO message, Prefix Information Option]. A RPL implementation SHOULD allow configuring if the Prefix Information option must be carried with the DIO message to distribute the Prefix Information for autoconfiguration. In that case, the RPL implementation MUST allow the list of prefixes to be advertised in the PIO along with the corresponding flags.
Oプレフィックス情報、有効かつ好ましい寿命と「L」と「A」のフラグと一緒に。 [DIOメッセージ、プレフィックス情報オプション]。プレフィックス情報オプションは、自動設定のためのプレフィックス情報を配布するためにDIOメッセージで運ばなければならない場合RPLの実装が設定できるようにすべきです。その場合には、RPLの実装では、接頭辞のリストは、対応するフラグと共にPIOでアドバタイズされることを可能にしなければなりません。
o Solicited Information [DIS message, in Solicited Information option]. Note that a RPL implementation SHOULD allow configuring when such messages should be sent and under which circumstances, along with the value of the RPLInstance ID, 'V'/'I'/'D' flags.
O要請情報[要請Information]オプションのDISメッセージ、]。 RPL実装がRPLInstance IDの値、「V」/「I」/「D」フラグと共に、そのようなメッセージが送信されるべきときに構成し、その状況下で可能にするはずであることに留意されたいです。
o 'K' flag: when a node should set the 'K' flag in a DAO message [DAO message, in DAO Base message].
O「K」フラグ：ノードが[用DAOベースメッセージに、DAOメッセージ] DAOメッセージに「K」フラグを設定すべきです。
o MOP (Mode of Operation) [DIO message, in DIO Base message].
入出力MOP（動作のモード）[DIOベースメッセージにおけるDIOメッセージ]。
o Route Information (and preference) [DIO message, in Route Information option]
O経路情報（嗜好）[DIOメッセージ、ルート情報オプションで】
18.2.4. Protocol Parameters to Be Configured on Every Non-DODAG-Root Router in the LLN
18.2.4. プロトコルパラメータはLLNにおけるすべての非DODAG-ルートルータで設定します
A RPL implementation MUST allow configuring the Target prefix [DAO message, in RPL Target option].
RPLの実装では、対象接頭辞[のRPLターゲットオプションでDAOメッセージを、]設定を許容しなければなりません。
Furthermore, there are circumstances where a node may want to designate a Target to allow for specific processing of the Target (prioritization, etc.). Such processing rules are out of scope for this specification. When used, a RPL implementation SHOULD allow configuring the Target Descriptor on a per-Target basis (for example, using access lists).
さらに、ノードは、ターゲット（優先順位付け、等）の具体的な処理を可能にするために、ターゲットを指定することができる状況があります。このような処理ルールはこの仕様の範囲外です。使用すると、RPLの実装では、（例えば、アクセスリストを使用して）ごとの目標に基づいて目標記述を設定可能にするべきです。
A node whose DODAG parent set is empty may become the DODAG root of a floating DODAG. It may also set its DAGPreference such that it is less preferred. Thus, a RPL implementation MUST allow configuring the set of actions that the node should initiate in this case:
そのDODAG親セット空であるノードは、フローティングDODAGのDODAGルートになることができます。また、それはあまり好まれているように、そのDAGPreferenceを設定することがあります。したがって、RPLの実装では、ノードが、この場合に開始すべきアクションのセットを設定できるようにしなければなりません。
o Start its own (floating) DODAG: the new DODAGID must be configured in addition to its DAGPreference.
新しいDODAGIDはそのDAGPreferenceに加えて構成されている必要があります。o独自の（フローティング）DODAGを開始します。
o Poison the broken path (see procedure in Section 8.2.2.5).
O（セクション8.2.2.5の手順を参照）壊れたパスを毒。
o Trigger a local repair.
Oローカル修復をトリガします。
In addition, several other parameters are configured only on the DODAG root and advertised in options carried in DIO messages.
また、他のいくつかのパラメータが唯一DODAGのルートに設定されているとDIOメッセージで運ばれたオプションに宣伝しました。
As specified in Section 8.3, a RPL implementation makes use of Trickle timers to govern the sending of DIO messages. The operation of the Trickle algorithm is determined by a set of configurable parameters, which MUST be configurable and that are then advertised by the DODAG root along the DODAG in DIO messages.
8.3節で規定されているように、RPLの実装では、DIOメッセージの送信を管理するためにトリクルタイマーを使用しています。トリクルアルゴリズムの動作は設定していなければなりません設定可能なパラメータのセットによって決定され、その後、DIOメッセージにDODAG沿っDODAGルートによって通知されます。
o DIOIntervalDoublings [DIO message, in DODAG Configuration option]
OのDIOIntervalDoublings [DIOメッセージ、DODAG構成オプションで]
o DIOIntervalMin [DIO message, in DODAG Configuration option]
O DIOIntervalMin [DIOメッセージ、DODAG構成オプションで]
o DIORedundancyConstant [DIO message, in DODAG Configuration option]
O DIORedundancyConstant [DIOメッセージ、DODAG構成オプションで]
In addition, a RPL implementation SHOULD allow for configuring the following set of RPL parameters: o Path Control Size [DIO message, in DODAG Configuration option]
また、RPLの実装では、RPLパラメータの次のセットを構成するために許可する必要があります。oパス制御サイズ[DIOメッセージ、DODAG構成オプションで]
o MinHopRankIncrease [DIO message, in DODAG Configuration option]
O MinHopRankIncrease [DIOメッセージ、DODAG構成オプションで]
o The DODAGPreference field [DIO message, DIO Base object]
DODAGPreferenceフィールドO [DIOメッセージ、DIOベースオブジェクト]
o DODAGID [DIO message, in DIO Base option] and [DAO message, when the 'D' flag of the DAO message is set]
O DODAGID [DIOベースオプションでDIOメッセージ]および[DAOメッセージの「D」フラグが設定されているDAOメッセージ]
DAG root behavior: in some cases, a node may not want to permanently act as a floating DODAG root if it cannot join a grounded DODAG. For example, a battery-operated node may not want to act as a floating DODAG root for a long period of time. Thus, a RPL implementation MAY support the ability to configure whether or not a node could act as a floating DODAG root for a configured period of time.
DAGルートの挙動：いくつかのケースでは、ノードは、それが接地DODAGに参加できない場合は永久に浮動DODAGのルートとして動作したくないかもしれません。例えば、バッテリ駆動ノードは、時間の長い期間のための浮動DODAGのルートとして動作したくないかもしれません。したがって、RPLの実装では、ノードは、時間の設定された期間のためにフローティングDODAGルートとして作用し得るか否かを設定する機能をサポートするかもしれません。
DAG Version Number Increment: a RPL implementation may allow, by configuration at the DODAG root, refreshing the DODAG states by updating the DODAGVersionNumber. A RPL implementation SHOULD allow configuring whether or not periodic or event triggered mechanisms are used by the DODAG root to control DODAGVersionNumber change (which triggers a global repair as specified in Section 3.2.2).
DAGバージョン番号インクリメント：RPLの実装はDODAGVersionNumberを更新することにより、DODAG状態をリフレッシュ、DODAGのルートに設定することにより、可能にしてもよいです。 RPLの実装では、機構は（セクション3.2.2で指定されるように、グローバルリペアをトリガ）DODAGVersionNumber変化を制御するDODAGルートで使用されるトリガ周期的またはイベントか否かを設定可能にすべきです。
DAO messages are optional and used in DODAGs that require Downward routing operation. This section deals with the set of parameters related to DAO messages and provides recommendations on their configuration.
DAOメッセージはオプションと下向きのルーティング操作を必要とDODAGsに使用されています。このセクションでは、DAOメッセージに関連するパラメータのセットを扱うとその設定に関する推奨事項を提供します。
As stated in Section 9.5, it is recommended to delay the sending of DAO message to DAO parents in order to maximize the chances to perform route aggregation. Upon receiving a DAO message, the node should thus start a DelayDAO timer. The default value is DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring the DelayDAO timer.
9.5節で述べたように、ルート集約を実行するためにチャンスを最大化するために、DAOの両親へのDAOメッセージの送信を遅らせることをお勧めします。 DAOメッセージを受信すると、ノードは、このようDelayDAOタイマを開始すべきです。デフォルト値はDEFAULT_DAO_DELAYです。 RPLの実装はDelayDAOタイマーを設定することが可能になります。
In a Storing mode of operation, a storing node may increment DTSN in order to reliably trigger a set of DAO updates from its immediate children, as part of routine routing table updates and maintenance. A RPL implementation MAY allow for configuring a set of rules specifying the triggers for DTSN increment (manual or event-based).
動作の保存モードでは、記憶ノードが確実ルーチンルーティングテーブルの更新と保守の一環として、その直下の子からDAOの更新のセットをトリガするためにDTSNをインクリメントしてもよいです。 RPL実装はDTSN増分（手動またはイベントベース）のトリガーを指定するルールのセットを構成可能にすることができます。
When a DAO entry times out or is invalidated, a node SHOULD make a reasonable attempt to report a No-Path to each of the DAO parents. That number of attempts MAY be configurable.
DAOエントリがタイムアウトするかを無効にした場合、ノードは、DAOの両親のそれぞれに無パスを報告しないための合理的な試みを行う必要があります。試みのその数は構成可能です。
An implementation should support rate-limiting the sending of DAO messages. The related parameters MAY be configurable.
実装が律速DAOメッセージの送信をサポートする必要があります。関連パラメータは、構成可能です。
As described in Section 10, the security features described in this document are optional to implement and a given implementation may support a subset (including the empty set) of the described security features.
セクション10で説明したように、本文書に記載されているセキュリティ機能を実装するために任意であり、所与の実装が記載されているセキュリティ機能の（空集合を含む）のサブセットをサポートすることができます。
To this end, an implementation supporting described security features may conceptually implement a security policy database. In support of the security mechanisms, a RPL implementation SHOULD allow for configuring a subset of the following parameters:
この目的を達成するために、説明したセキュリティ機能をサポートする実装は、概念的には、セキュリティポリシーデータベースを実装することができます。セキュリティ機構の支援では、RPLの実装は、次のパラメータのサブセットを構成するために許可する必要があり：
o Security Modes accepted [Unsecured mode, Preinstalled mode, Authenticated mode]
Oセキュリティモードは、[無担保モード、プリインストールされているモード、認証モード]を受け入れ
o KIM values accepted [Secure RPL control messages, in Security section]
O KIM値を受け入れ、[セキュリティ]セクションで、RPL制御メッセージを固定]
o Level values accepted [Secure RPL control messages, in Security section]
Oレベルの値は、[セキュリティ]セクションで、セキュアRPL制御メッセージ]を受け入れ
o Algorithm values accepted [Secure RPL control messages, in Security section]
Oアルゴリズム値は受け入れ、[セキュリティ]セクションで、RPL制御メッセージを固定]
o Key material in support of Authenticated or Preinstalled key modes.
認証済みまたはプリインストールされているキーのモードをサポートするOキー材料。
In addition, a RPL implementation SHOULD allow for configuring a DODAG root with a subset of the following parameters:
また、RPLの実装は、以下のパラメータのサブセットとDODAGルートを設定を可能にすべきです。
o Level values advertised [Secure DIO message, in Security section]
Oレベルの値が公示[セキュリティ]セクションでは、DIOメッセージをセキュア]
o KIM value advertised [Secure DIO message, in Security section]
アドバタイズO KIM値[セキュリティセクションで、DIOメッセージをセキュア]
o Algorithm value advertised [Secure DIO message, in Security section]
アドバタイズOアルゴリズム値[セキュリティセクションで、DIOメッセージをセキュア]
This document specifies default values for the following set of RPL variables: DEFAULT_PATH_CONTROL_SIZE DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_PATH_CONTROL_SIZE DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_REDUNDANCY_CONSTANT：この文書では、RPL変数の次のセットのデフォルト値を指定します
DEFAULT_MIN_HOP_RANK_INCREASE DEFAULT_DAO_DELAY
DEFAULT_MIN_HOP_RANK_INCREASE DEFAULT_DAO_DELAY
It is recommended to specify default values in protocols; that being said, as discussed in [RFC5706], default values may make less and less sense. RPL is a routing protocol that is expected to be used in a number of contexts where network characteristics such as the number of nodes and link and node types are expected to vary significantly. Thus, these default values are likely to change with the context and as the technology evolves. Indeed, LLNs' related technology (e.g., hardware, link layers) have been evolving dramatically over the past few years and such technologies are expected to change and evolve considerably in the coming years.
プロトコルのデフォルト値を指定することをお勧めします。 [RFC5706]で議論するように言われていることは、デフォルト値が少なく意味をなすことができます。 RPLは、ノードとリンク及びノードの種類の数などのネットワーク特性が大きく変化することが予想されるコンテキストの数で使用することが期待されているルーティングプロトコルです。したがって、これらのデフォルト値は、コンテキストと、技術が進化するにつれて変化する可能性があります。確かに、LLNs'関連技術（例えば、ハードウェア、リンク層）は、過去数年で劇的に進化してきたし、このような技術は、変更すると、今後数年間で大幅に進化することが期待されます。
The proposed values are not based on extensive best current practices and are considered to be conservative.
提案された値が広範囲に現在のベストプラクティスに基づいておらず、保守的であると考えられています。
Several RPL parameters should be monitored to verify the correct operation of the routing protocol and the network itself. This section lists the set of monitoring parameters of interest.
いくつかのRPLパラメータは、ルーティングプロトコルおよびネットワーク自体の正しい動作を検証するために監視されるべきです。このセクションでは、関心のあるパラメータを監視のセットを示しています。
A RPL implementation SHOULD provide information about the following parameters:
RPLの実装は、次のパラメータに関する情報を提供する必要があります。
o DODAG Version number [DIO message, in DIO Base message]
O DODAGバージョン番号[DIOベースメッセージにおけるDIOメッセージ]
o Status of the 'G' flag [DIO message, in DIO Base message]
「G」フラグのOステータス[DIOメッセージ、DIOベースメッセージに]
o Status of the MOP field [DIO message, in DIO Base message]
MOPフィールドのOステータス[DIOベースメッセージにおけるDIOメッセージ]
o Value of the DTSN [DIO message, in DIO Base message]
DTSNのO値[DIOメッセージ、DIOベースメッセージに]
o Value of the Rank [DIO message, in DIO Base message]
ランクのO値[DIOメッセージ、DIOベースメッセージに]
o DAOSequence: Incremented at each unique DAO message, echoed in the DAO-ACK message [DAO and DAO-ACK messages]
入出力DAOシーケンス：各一意DAOメッセージにおいて増分が、DAO-ACKメッセージにエコー[DAOとDAO-ACKメッセージ]
o Route Information [DIO message, Route Information Option] (list of IPv6 prefixes per parent along with lifetime and preference]
O経路情報[DIOメッセージ、ルート情報オプション（寿命と嗜好に沿って親当たりのIPv6プレフィックスのリスト]
o Trickle parameters:
トリクルパラメータO：
* DIOIntervalDoublings [DIO message, in DODAG Configuration option]
* DIOIntervalDoublings [DIOメッセージ、DODAG構成オプションで]
* DIOIntervalMin [DIO message, in DODAG Configuration option]
* DIOIntervalMin [DIOメッセージ、DODAG構成オプションで]
* DIORedundancyConstant [DIO message, in DODAG Configuration option]
* DIORedundancyConstant [DIOメッセージ、DODAG構成オプションで]
o Path Control Size [DIO message, in DODAG Configuration option]
Oパスコントロールのサイズ[DIOメッセージ、DODAG構成オプションで]
o MinHopRankIncrease [DIO message, in DODAG Configuration option]
O MinHopRankIncrease [DIOメッセージ、DODAG構成オプションで]
Values that may be monitored only on the DODAG root:
DODAGのルートにのみ監視することができる値：
o Transit Information [DAO, Transit Information option]: A RPL implementation SHOULD allow configuring whether the set of received Transit Information options should be displayed on the DODAG root. In this case, the RPL database of received Transit Information should also contain the Path Sequence, Path Control, Path Lifetime, and Parent Address.
O交通情報[DAO、交通情報オプション]：RPLの実装では、受信トランジット情報オプションのセットがDODAGのルート上に表示されるべきかどうかを設定できるようにすべきです。この場合、受信トランジット情報のRPLデータベースには、パスのシーケンス、パスのコントロール、パスの有効期間、および親アドレスが含まれている必要があります。
Detection of DODAG inconsistencies is particularly critical in RPL networks. Thus, it is recommended for a RPL implementation to provide appropriate monitoring tools. A RPL implementation SHOULD provide a counter reporting the number of a times the node has detected an inconsistency with respect to a DODAG parent, e.g., if the DODAGID has changed.
DODAGの不整合の検出は、RPLのネットワークでは特に重要です。したがって、適切な監視ツールを提供するために、RPLの実装のために推奨されます。 RPL実装はDODAGIDが変更された場合、ノードは、例えば、DODAG親に対して矛盾を検出した回数を報告するカウンタを提供すべきです。
When possible more granular information about inconsistency detection should be provided. A RPL implementation MAY provide counters reporting the number of following inconsistencies:
矛盾の検出についての可能性より細かな情報が提供されなければならないとき。 RPLの実装は、次の不整合の数を報告するカウンタを提供することができます。
o Packets received with 'O' bit set (to Down) from a node with a higher Rank
Oパケットは、より高いランクのノードからの（下に）「O」ビット・セットで受信しました
o Packets received with 'O' bit cleared (to Up) from a node with a lower Rank
Oパケットは、低いランクのノードからの（最大）「O」ビットがクリアで受信しました
o Number of packets with the 'F' bit set
「F」ビットがセットされたパケットの入出力数
o Number of packets with the 'R' bit set
「R」ビットがセットされたパケットのO数
A node in the candidate neighbor list is a node discovered by the same means and qualified to potentially become a parent (with high enough local confidence). A RPL implementation SHOULD provide a way to allow for the candidate neighbor list to be monitored with some metric reflecting local confidence (the degree of stability of the neighbors) as measured by some metrics.
候補隣接リスト内のノードは、潜在的に（十分に高い局所的な自信を持つ）親になるに同じ手段や資格によって発見されたノードです。 RPLの実装は、いくつかの指標によって測定されるように、ローカルの信頼（近隣の安定度）を反映いくつかのメトリックで監視する候補隣接リストを可能にする方法を提供するべきです。
A RPL implementation MAY provide a counter reporting the number of times a candidate neighbor has been ignored, should the number of candidate neighbors exceed the maximum authorized value.
RPLの実装が候補ネイバーが無視された回数を報告するカウンタを提供することができるが、候補隣人の数が最大許可値を超えている必要があります。
For each DODAG, a RPL implementation is expected to keep track of the following DODAG table values:
各DODAGため、RPLの実装は、以下DODAGテーブル値を追跡することが期待されます。
o RPLInstanceID
RPLInstanceID O
o DODAGID
DODAGID上
o DODAGVersionNumber
O DODAGVersionNumber
o Rank
お らんｋ
o Objective Code Point
O客観コードポイント
o A set of DODAG parents
DODAGの両親のセットO
o A set of prefixes offered Upward along the DODAG
DODAGに沿って上方に提供プレフィックスのセットO
o Trickle timers used to govern the sending of DIO messages for the DODAG
O DODAG用DIOメッセージの送信を管理するために使用されるタイマをトリクル
o List of DAO parents
DAOの両親のO一覧
o DTSN
O DTSN
o Node status (router versus leaf)
Oノードの状態（リーフルータ対）
A RPL implementation SHOULD allow for monitoring the set of parameters listed above.
RPLの実装では、上記一組のパラメータを監視するために可能にすべきです。
A RPL implementation maintains several information elements related to the DODAG and the DAO entries (for storing nodes). In the case of a non-storing node, a limited amount of information is maintained (the routing table is mostly reduced to a set of DODAG parents along with characteristics of the DODAG as mentioned above); whereas in the case of storing nodes, this information is augmented with routing entries.
RPL実装はDODAGと（ノードを格納するための）DAOエントリに関連するいくつかの情報要素を維持します。非記憶ノードの場合には、情報の制限された量は、（上述のように、ルーティングテーブルはほとんどDODAGの特性と共にDODAG親のセットに縮小される）が維持されます。ノードを記憶する場合に、一方、この情報は、ルーティングエントリが増強されます。
A RPL implementation SHOULD allow for the following parameters to be monitored:
RPLの実装は、次のパラメータを監視することを可能にする必要があります。
o Next Hop (DODAG parent)
Oネクストホップ（DODAG親）
o Next Hop Interface
Oネクストホップインターフェイス
o Path metrics value for each DODAG parent
各DODAG親のためのOパスメトリック値
A DAO Routing Table entry conceptually contains the following elements (for storing nodes only):
DAOルーティングテーブルエントリは、概念（ノードのみを格納するための）次の要素が含まれています。
o Advertising Neighbor Information
O広告ネイバー情報
o IPv6 address
O IPv6アドレス
o Interface ID to which DAO parents has this entry been reported
インタフェースID Oこのエントリが報告されているDAOは両親に
o Retry counter
Oリトライカウンタ
o Logical equivalent of DAO Content:
DAOコンテンツのO論理同等：
* DAO-Sequence
* DAOシーケンス
* Path Sequence
*パスシーケンス
* DAO Lifetime
* DAO寿命
* DAO Path Control
* DAOパス制御
o Destination Prefix (or address or Mcast Group)
O宛先プレフィクス（アドレスまたはMCASTグループまたは）
A RPL implementation SHOULD provide information about the state of each DAO Routing Table entry states.
RPLの実装では、各DAOルーティングテーブルエントリ状態の状態に関する情報を提供すべきです。
Fault management is a critical component used for troubleshooting, verification of the correct mode of operation of the protocol, and network design; also, it is a key component of network performance monitoring. A RPL implementation SHOULD allow the provision of the following information related to fault managements:
障害管理は、トラブルシューティング、プロトコルの動作の正しいモードの検証、及びネットワーク設計のために使用される重要なコンポーネントです。また、それは、ネットワークパフォーマンスの監視の重要な要素です。 RPLの実装では、障害の経営に関連する次のような情報の提供を可能にしなければなりません：
o Memory overflow along with the cause (e.g., routing tables overflow, etc.)
原因と一緒にOメモリのオーバーフロー（例えば、等ルーティングテーブルのオーバーフロー）
o Number of times a packet could not be sent to a DODAG parent flagged as valid
O回数パケットが有効であるとフラグを立てDODAG親に送信できませんでした
o Number of times a packet has been received for which the router did not have a corresponding RPLInstanceID
O回数は、パケットは、ルータが対応するRPLInstanceIDを持っていなかったために受信されています
o Number of times a local repair procedure was triggered
O回数は、ローカル修復手順がトリガされました
o Number of times a global repair was triggered by the DODAG root
O回数は、グローバルな修理がDODAGルートによって引き起こされました
o Number of received malformed messages
受信不正なメッセージのO数
o Number of seconds with packets to forward and no next hop (DODAG parent)
Oの転送するパケットとの秒数なしネクストホップ（DODAG親）
o Number of seconds without next hop (DODAG parent)
次のホップのない秒のO数（DODAG親）
o Number of times a node has joined a DODAG as a leaf because it received a DIO with a metric/constraint that was not understood and it was configured to join as a leaf node in this case (see Section 18.6)
それは（セクション18.6を参照）を理解しておらず、それはこの場合のリーフノードとして参加するように構成されたメトリック/制約とDIOを受信したため、O回数ノードがリーフとしてDODAGに参加しました
It is RECOMMENDED to report faults via at least error log messages. Other protocols may be used to report such faults.
少なくともエラー・ログ・メッセージを経由して障害を報告することをお勧めします。他のプロトコルは、このような障害を報告するために使用することができます。
Policy rules can be used by a RPL implementation to determine whether or not the node is allowed to join a particular DODAG advertised by a neighbor by means of DIO messages.
ポリシールールは、ノードは、DIOメッセージによって隣人によってアドバタイズ特定DODAGに参加することを許可されているか否かを判断するRPLの実装で使用することができます。
This document specifies operation within a single DODAG. A DODAG is characterized by the following tuple (RPLInstanceID, DODAGID). Furthermore, as pointed out above, DIO messages are used to advertise other DODAG characteristics such as the routing metrics and constraints used to build to the DODAG and the Objective Function in use (specified by OCP).
この文書では、単一DODAG内での動作を指定します。 DODAGは、以下のタプル（RPLInstanceID、DODAGID）によって特徴付けられます。上記で指摘したようにまた、DIOメッセージは、DODAG及び（OCPによって指定された）使用中の目的関数を構築するために使用されるルーティングメトリック制約などの他DODAG特性を宣伝するために使用されます。
The first policy rules consist of specifying the following conditions that a RPL node must satisfy to join a DODAG:
最初のポリシールールはRPLノードがDODAGに参加するために満たさなければならない、次の条件を指定することから成ります。
o RPLInstanceID
RPLInstanceID O
o List of supported routing metrics and constraints
サポートされているルーティング・メトリックと制約のO一覧
o Objective Function (OCP values)
O目的関数（OCP値）
A RPL implementation MUST allow configuring these parameters and SHOULD specify whether the node must simply ignore the DIO if the advertised DODAG is not compliant with the local policy or whether the node should join as the leaf node if only the list of supported routing metrics and constraints, and the OF is not supported. Additionally, a RPL implementation SHOULD allow for the addition of the DODAGID as part of the policy.
RPLの実装では、これらのパラメータを設定できるようにしなければならないと宣伝DODAGがローカルポリシーを持つかのノードがリーフノードとしてサポートされているルーティング・メトリックと制約の場合のみリストに参加する必要があるかどうかに準拠していない場合、ノードは単にDIOを無視する必要があるかどうかを指定する必要があります、とOFがサポートされていません。また、RPLの実装は、ポリシーの一部としてDODAGIDの添加を可能にすべきです。
A RPL implementation SHOULD allow configuring the set of acceptable or preferred Objective Functions (OFs) referenced by their Objective Code Points (OCPs) for a node to join a DODAG, and what action should be taken if none of a node's candidate neighbors advertise one of the configured allowable Objective Functions, or if the advertised metrics/constraint is not understood/supported. Two actions can be taken in this case:
ノードの候補隣人のどれもが、のいずれかを宣伝しない場合はRPLの実装はDODAGに参加するノードのために彼らの目的コードポイント（OCPs）によって参照許容又は好ましい目的関数（のOF）のセットを構成できるようにすべきである、とどのようなアクションが取られるべきです許容目的関数を構成し、または広告を出してメトリクス/制約が理解されていない場合は/サポート。二つのアクションは、この場合に撮影することができます。
o The node joins the DODAG as a leaf node as specified in Section 8.5.
セクション8.5で指定されたOノードがリーフノードとしてDODAGに参加します。
o The node does not join the DODAG.
OノードはDODAGに参加していません。
A node in an LLN may learn routing information from different routing protocols including RPL. In this case, it is desirable to control, via administrative preference, which route should be favored. An implementation SHOULD allow for the specification of an administrative preference for the routing protocol from which the route was learned.
LLN内のノードは、RPLを含む、異なるルーティングプロトコルからのルーティング情報を学習することができます。この場合、ルートが好まれるべき管理嗜好を介して、制御することが望ましいです。実装は、ルートが学習されたルーティングプロトコルのための管理者の好みの仕様を可能にすべきです。
Internal Data Structures: some RPL implementations may limit the size of the candidate neighbor list in order to bound the memory usage; in which case, some otherwise viable candidate neighbors may not be considered and simply dropped from the candidate neighbor list.
内部データ構造：いくつかのRPLの実装では、メモリ使用量をバインドするために、候補隣接リストのサイズを制限すること。その場合には、いくつかそうでない場合は実行可能な候補隣人は考慮されず、単に候補隣接リストから削除しました。
A RPL implementation MAY provide an indicator on the size of the candidate neighbor list.
RPLの実装では、候補隣接リストのサイズの指標を提供することができます。
It is RECOMMENDED to quarantine neighbors that start emitting malformed messages at unacceptable rates.
容認できない速度で、不正な形式のメッセージを発する開始隣人を隔離することをお勧めします。
RPL has very limited impact on other protocols. Where more than one routing protocol is required on a router, such as an LBR, it is expected for the device to support routing redistribution functions between the routing protocols to allow for reachability between the two routing domains. Such redistribution SHOULD be governed by the use of user configurable policy.
RPLは、他のプロトコルでは非常に限られた影響を与えています。複数のルーティングプロトコルがルータに要求される場合、そのようなLBRように、2つのルーティングドメイン間の到達可能性を可能にするために、ルーティングプロトコル間のルーティング再配分機能をサポートするデバイスのために期待されています。このような再配分は、ユーザ設定可能なポリシーを使用することによって決定されるべきです。
With regard to the impact in terms of traffic on the network, RPL has been designed to limit the control traffic thanks to mechanisms such as Trickle timers (Section 8.3). Thus, the impact of RPL on other protocols should be extremely limited.
ネットワーク上のトラフィックの面で影響に関しては、RPLは、トリクルタイマ（セクション8.3）のような機構への制御トラフィックのおかげを制限するように設計されています。したがって、他のプロトコルのRPLの影響は非常に制限されるべきです。
Performance management is always an important aspect of a protocol, and RPL is not an exception. Several metrics of interest have been specified by the IP Performance Monitoring (IPPM) working group: that being said, they will be hardly applicable to LLN considering the cost of monitoring these metrics in terms of resources on the devices and required bandwidth. Still, RPL implementations MAY support some of these, and other parameters of interest are listed below:
パフォーマンス管理は、常にプロトコルの重要な側面である、とRPLは例外ではありません。興味のあるいくつかのメトリックがIPのパフォーマンス監視（IPPM）ワーキンググループによって指定されています：言われていることを、彼らはLLNは、デバイスと必要な帯域幅のリソースの面でこれらのメトリックを監視するコストを考慮にはほとんど適用されます。それでも、RPLの実装は、これらのいくつかをサポートすることができ、関心のある他のパラメータは以下の通りです：
o Number of repairs and time to repair in seconds (average, variance)
修理や時間のO数秒で修復する（平均、分散）
o Number of times and time period during which a devices could not forward a packet because of a lack of a reachable neighbor in its routing table
デバイスは、そのルーティングテーブルに到達可能なネイバーの不足のパケットを転送することができませんでした、その間の時間と時間帯のO数
o Monitoring of resources consumption by RPL in terms of bandwidth and required memory
O帯域幅の面でRPLにより、リソース消費量の監視と必要なメモリ
o Number of RPL control messages sent and received
O RPL制御メッセージの数は、送受信されました
There may be situations where a node should be placed in "verbose" mode to improve diagnostics. Thus, a RPL implementation SHOULD provide the ability to place a node in and out of verbose mode in order to get additional diagnostic information.
ノードは診断を改善するために、「冗長」モードに置かれるべき状況があるかもしれません。このように、RPLの実装では、追加の診断情報を得るためににし、冗長モードの外にノードを配置する機能を提供する必要があります。
From a security perspective, RPL networks are no different from any other network. They are vulnerable to passive eavesdropping attacks and, potentially, even active tampering when physical access to a wire is not required to participate in communications. The very nature of ad hoc networks and their cost objectives impose additional security constraints, which perhaps make these networks the most difficult environments to secure. Devices are low-cost and have limited capabilities in terms of computing power, available storage, and power drain; it cannot always be assumed they have a trusted computing base or a high-quality random number generator aboard.
セキュリティの観点から、RPLネットワークは、他のネットワークからの違いはありません。彼らは、潜在的に、電線への物理的アクセスが通信に参加するために必要とされていない場合に改ざんしても、アクティブ、パッシブ盗聴攻撃に対して脆弱であると。アドホックネットワークとそのコスト目標の本質は、おそらく、これらのネットワークで最も困難な環境を確保するために作る、追加のセキュリティ制約を課します。デバイスは、低コストであり、コンピューティングパワー、使用可能なストレージ、および電力消費の面で制限された能力を持っています。常に彼らはトラステッド・コンピューティング・ベースまたは乗って高品質な乱数ジェネレータを持って想定することはできません。
Communications cannot rely on the online availability of a fixed infrastructure and might involve short-term relationships between devices that may never have communicated before. These constraints might severely limit the choice of cryptographic algorithms and protocols and influence the design of the security architecture because the establishment and maintenance of trust relationships between devices need to be addressed with care. In addition, battery lifetime and cost constraints put severe limits on the security overhead these networks can tolerate, something that is of far less concern with higher bandwidth networks. Most of these security architectural elements can be implemented at higher layers and may, therefore, be considered to be out of scope for this specification. Special care, however, needs to be exercised with respect to interfaces to these higher layers.
コミュニケーションは、固定されたインフラストラクチャのオンライン可用性に頼ることができないと前に伝えたことがないかもしれデバイス間の短期的関係を伴うかもしれません。デバイス間の信頼関係の確立と維持は、注意して対処する必要があるため、これらの制約が厳しく、暗号化アルゴリズムとプロトコルの選択を制限し、セキュリティアーキテクチャの設計に影響を与える可能性があります。また、バッテリーの寿命やコストの制約は、これらのネットワークは許容できるセキュリティ・オーバーヘッド、より高い帯域幅のネットワークとはるかに少ない懸念される何かに厳しい制限を置きます。これらのセキュリティアーキテクチャの要素のほとんどは、より高い層で実装することができ、したがって、本明細書の範囲外であると考えることができます。特別な注意が、しかし、これらのより高い層へのインターフェースに対して行使される必要があります。
The security mechanisms in this standard are based on symmetric-key and public-key cryptography and use keys that are to be provided by higher-layer processes. The establishment and maintenance of these keys are out of scope for this specification. The mechanisms assume a secure implementation of cryptographic operations and secure and authentic storage of keying material.
この標準のセキュリティメカニズムは、上位層のプロセスによって提供される対称鍵と公開鍵暗号方式と使用のキーに基づいています。これらのキーの確立と維持は、この仕様の範囲外です。メカニズムは、暗号化操作および鍵材料の安全かつ真正ストレージの安全な実装を想定します。
The security mechanisms specified provide particular combinations of the following security services:
指定されたセキュリティ・メカニズムは、次のセキュリティ・サービスの特定の組み合わせを提供します。
Data confidentiality: Assurance that transmitted information is only disclosed to parties for which it is intended.
データの機密性：保証情報を送信するだけで、それが意図されている当事者に開示されています。
Data authenticity: Assurance of the source of transmitted information (and, hereby, that information was not modified in transit).
データの信憑性：送信された情報のソースの保証（および、ここに、その情報は、転送中に変更されませんでした）。
Replay protection: Assurance that a duplicate of transmitted information is detected.
リプレイ保護：送信された情報の重複が検出されていることを保証。
Timeliness (delay protection): Assurance that transmitted information was received in a timely manner.
適時（遅延保護）：保証情報を送信したタイムリーに受信されました。
The actual protection provided can be adapted on a per-packet basis and allows for varying levels of data authenticity (to minimize security overhead in transmitted packets where required) and for optional data confidentiality. When nontrivial protection is required, replay protection is always provided.
提供される実際の保護は、パケット単位で適応し、データ真正性の様々なレベルを可能にする（必要な送信パケットのセキュリティオーバヘッドを最小限にするために）、および任意のデータの機密性のためにすることができます。自明でない保護が必要な場合は、再生保護を常に提供します。
Replay protection is provided via the use of a non-repeating value (CCM nonce) in the packet protection process and storage of some status information (originating device and the CCM nonce counter last received from that device), which allows detection of whether this particular CCM nonce value was used previously by the originating device. In addition, so-called delay protection is provided amongst those devices that have a loosely synchronized clock on board. The acceptable time delay can be adapted on a per-packet basis and allows for varying latencies (to facilitate longer latencies in packets transmitted over a multi-hop communication path).
リプレイ保護は、いくつかの状況情報のパケット保護プロセスにおける非反復値（CCMナンス）の使用及び保管を介して提供されるこの特定のかどうかの検出を可能にする、（発信側デバイスとCCMのナンスカウンタが最後にそのデバイスから受信しました） CCMのノンス値を発信側デバイスによって以前に使用しました。また、いわゆる遅延保護は、ボード上の緩やかに同期したクロックを持っているそれらのデバイス間で提供されます。許容される時間遅延は、パケット単位で適応及び待ち時間が（マルチホップ通信経路を介して送信されるパケットに長い待ち時間を容易にするために）変化させることを可能にすることができます。
Cryptographic protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and application-specific trade-offs between key storage and key maintenance costs versus the cryptographic protection provided. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key-sharing group.
暗号化保護は、従って鍵の保管及び暗号対鍵メンテナンスコストとの間のある程度の柔軟性とアプリケーション固有のトレードオフを可能にする、2つのピアデバイス（リンク鍵）またはデバイスのグループ（グループ鍵）の間で共有キーとの間で共有されるキーを使用してもよいです保護提供。グループキーは、ピアツーピア通信のために使用される場合、保護は鍵共有グループにのみ部外の機器に対してではなく潜在的な悪質なデバイスに対して提供されます。
Data authenticity may be provided using symmetric-key-based or public-key-based techniques. With public-key-based techniques (via signatures), one corroborates evidence as to the unique originator of transmitted information, whereas with symmetric-key-based techniques, data authenticity is only provided relative to devices in a key-sharing group. Thus, public-key-based authentication may be useful in scenarios that require a more fine-grained authentication than can be provided with symmetric-key-based authentication techniques alone, such as with group communications (broadcast, multicast) or in scenarios that require non-repudiation.
データの真正性は、対称鍵ベースまたは公開鍵ベースの技術を使用して提供されてもよいです。対称鍵ベースの技術を用いて、データの真正のみ鍵共有グループ内のデバイスに対して提供される一方、（署名を介して）公開鍵ベースの技術を用いて、一方は、送信された情報の一意の発信に関して証拠を裏付けます。したがって、公開鍵ベースの認証は、グループ通信（ブロードキャスト、マルチキャスト）のように、または必要シナリオにおいてのみ対称鍵ベースの認証技術を提供することができるよりもきめ細かい認証を必要とするシナリオで有用であり得ます否認防止。
The RPL control message is an ICMP information message type that is to be used carry DODAG Information Objects, DODAG Information Solicitations, and Destination Advertisement Objects in support of RPL operation.
RPL制御メッセージは、RPLの動作をサポートするキャリーDODAG情報オブジェクト、DODAG情報要請、及び宛先広告オブジェクトを使用するICMP情報メッセージタイプです。
IANA has defined an ICMPv6 Type Number Registry. The type value for the RPL control message is 155.
IANAはICMPv6のタイプ番号レジストリを定義しています。 RPL制御メッセージのタイプ値は155です。
IANA has created a registry, RPL Control Codes, for the Code field of the ICMPv6 RPL control message.
IANAはICMPv6のRPL制御メッセージのCodeフィールドのレジストリ、RPL制御コードを、作成しました。
New codes may be allocated only by an IETF Review. Each code is tracked with the following qualities:
新しいコードは、IETFレビューにより割り当てることができます。それぞれのコードは、以下の品質で追跡されています。
o Code o Description
OコードO説明
o Defining RFC
Oの定義RFC
The following codes are currently defined:
以下のコードは、現在定義されています。
+------+----------------------------------------------+-------------+
| Code | Description | Reference |
+------+----------------------------------------------+-------------+
| 0x00 | DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x01 | DODAG Information Object | This |
| | | document |
| | | |
| 0x02 | Destination Advertisement Object | This |
| | | document |
| | | |
| 0x03 | Destination Advertisement Object | This |
| | Acknowledgment | document |
| | | |
| 0x80 | Secure DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x81 | Secure DODAG Information Object | This |
| | | document |
| | | |
| 0x82 | Secure Destination Advertisement Object | This |
| | | document |
| | | |
| 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document |
| | | |
| 0x8A | Consistency Check | This |
| | | document |
+------+----------------------------------------------+-------------+
RPL Control Codes
RPL制御コード
IANA has created a registry for the 3-bit Mode of Operation (MOP), which is contained in the DIO Base.
IANAは、DIOベースに含まれる動作（MOP）、の3ビットモードのレジストリを作成しました。
New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:
新しい値はIETFレビューにより割り当てることができます。各値は以下の品質で追跡されています。
o Mode of Operation Value o Capability description
機能の説明Oの動作値のOモード
o Defining RFC
Oの定義RFC
Four values are currently defined:
四つの値が現在定義されています：
+----------+------------------------------------------+-------------+
| MOP | Description | Reference |
| value | | |
+----------+------------------------------------------+-------------+
| 0 | No Downward routes maintained by RPL | This |
| | | document |
| | | |
| 1 | Non-Storing Mode of Operation | This |
| | | document |
| | | |
| 2 | Storing Mode of Operation with no | This |
| | multicast support | document |
| | | |
| 3 | Storing Mode of Operation with multicast | This |
| | support | document |
+----------+------------------------------------------+-------------+
DIO Mode of Operation
操作のDIOモード
The rest of the range, decimal 4 to 7, is currently unassigned.
範囲の残りの部分は、4~7小数、現在割り当てられていません。
IANA has created a registry for the RPL Control Message Options.
IANAは、RPL制御メッセージのオプションのレジストリを作成しました。
New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:
新しい値はIETFレビューにより割り当てることができます。各値は以下の品質で追跡されています。
o Value
O値
o Meaning
Oの意味
o Defining RFC
Oの定義RFC
+-------+-----------------------+---------------+
| Value | Meaning | Reference |
+-------+-----------------------+---------------+
| 0x00 | Pad1 | This document |
| | | |
| 0x01 | PadN | This document |
| | | |
| 0x02 | DAG Metric Container | This Document |
| | | |
| 0x03 | Routing Information | This Document |
| | | |
| 0x04 | DODAG Configuration | This Document |
| | | |
| 0x05 | RPL Target | This Document |
| | | |
| 0x06 | Transit Information | This Document |
| | | |
| 0x07 | Solicited Information | This Document |
| | | |
| 0x08 | Prefix Information | This Document |
| | | |
| 0x09 | Target Descriptor | This Document |
+-------+-----------------------+---------------+
RPL Control Message Options
RPL制御メッセージのオプション
IANA has created a registry to manage the codespace of the Objective Code Point (OCP) field.
IANAは、客観コードポイント（OCP）フィールドのコードスペースを管理するために、レジストリを作成しました。
No OCPs are defined in this specification.
何OCPsは、この仕様で定義されていません。
New codes may be allocated only by an IETF Review. Each code is tracked with the following qualities:
新しいコードは、IETFレビューにより割り当てることができます。それぞれのコードは、以下の品質で追跡されています。
o Code
お こで
o Description
O説明
o Defining RFC
Oの定義RFC
IANA has created a registry for the values of the 8-bit Algorithm field in the Security section.
IANAは、[セキュリティ]セクションで、8ビットのアルゴリズムフィールドの値のレジストリを作成しました。
New values may be allocated only by an IETF Review. Each value is tracked with the following qualities:
新しい値はIETFレビューにより割り当てることができます。各値は以下の品質で追跡されています。
o Value
O値
o Encryption/MAC
O暗号化/ MAC
o Signature
O署名
o Defining RFC
Oの定義RFC
The following value is currently defined:
次の値は、現在定義されています。
+-------+------------------+------------------+---------------+
| Value | Encryption/MAC | Signature | Reference |
+-------+------------------+------------------+---------------+
| 0 | CCM with AES-128 | RSA with SHA-256 | This document |
+-------+------------------+------------------+---------------+
Security Section Algorithm
セキュリティセクションアルゴリズム
IANA has created a registry for the 8-bit Security Section Flags field.
IANAは、8ビットのセキュリティセクションFlagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bit is currently defined for the Security Section Flags field.
何ビットは、現在のセキュリティセクションFlagsフィールド用に定義されていません。
IANA has created one registry for the 3-bit Security Level (LVL) field per allocated KIM value.
IANAは、割り当てられたKIM値ごとに3ビットのセキュリティレベル（LVL）フィールドに1つのレジストリを作成しました。
For a given KIM value, new levels may be allocated only by an IETF Review. Each level is tracked with the following qualities:
所与KIM値に対して、新しいレベルは、IETF Reviewによって割り当てられてもよいです。各レベルは以下の品質で追跡されています。
o Level
Oレベル
o KIM value o Description
O KIM値O説明
o Defining RFC
Oの定義RFC
The following levels per KIM value are currently defined:
KIM値ごとに、次のレベルは、現在定義されています。
+-------+-----------+---------------+---------------+
| Level | KIM value | Description | Reference |
+-------+-----------+---------------+---------------+
| 0 | 0 | See Figure 11 | This document |
| | | | |
| 1 | 0 | See Figure 11 | This document |
| | | | |
| 2 | 0 | See Figure 11 | This document |
| | | | |
| 3 | 0 | See Figure 11 | This document |
| | | | |
| 0 | 1 | See Figure 11 | This document |
| | | | |
| 1 | 1 | See Figure 11 | This document |
| | | | |
| 2 | 1 | See Figure 11 | This document |
| | | | |
| 3 | 1 | See Figure 11 | This document |
| | | | |
| 0 | 2 | See Figure 11 | This document |
| | | | |
| 1 | 2 | See Figure 11 | This document |
| | | | |
| 2 | 2 | See Figure 11 | This document |
| | | | |
| 3 | 2 | See Figure 11 | This document |
| | | | |
| 0 | 3 | See Figure 11 | This document |
| | | | |
| 1 | 3 | See Figure 11 | This document |
| | | | |
| 2 | 3 | See Figure 11 | This document |
| | | | |
| 3 | 3 | See Figure 11 | This document |
+-------+-----------+---------------+---------------+
Per-KIM Security Levels
パー-KIMセキュリティレベル
IANA has created a registry for the DIS (DODAG Informational Solicitation) Flags field.
IANAは、DIS（DODAG情報要請）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags field.
何ビットは、現在、DIS（DODAG情報要請）Flagsフィールド用に定義されていません。
IANA has created a registry for the 8-bit DODAG Information Object (DIO) Flags field.
IANAは、8ビットDODAG情報オブジェクト（DIO）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags.
何ビットは、現在、DIS（DODAG情報募集）フラグのために定義されていません。
20.11. New Registry for the Destination Advertisement Object (DAO) Flags
20.11. 先の広告オブジェクトのための新しいレジストリ（DAO）国旗
IANA has created a registry for the 8-bit Destination Advertisement Object (DAO) Flags field.
IANAは、8ビットのデスティネーション広告オブジェクト（DAO）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
The following bits are currently defined:
次のビットは、現在定義されています。
+------------+------------------------------+---------------+
| Bit number | Description | Reference |
+------------+------------------------------+---------------+
| 0 | DAO-ACK request (K) | This document |
| | | |
| 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
DAO Base Flags
DAOベースフラグ
20.12. New Registry for the Destination Advertisement Object (DAO) Acknowledgement Flags
20.12. 先の広告オブジェクト（DAO）謝辞フラグのための新しいレジストリ
IANA has created a registry for the 8-bit Destination Advertisement Object (DAO) Acknowledgement Flags field.
IANAは、8ビットのデスティネーション広告オブジェクト（DAO）謝辞Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
The following bit is currently defined:
以下のビットは、現在定義されています。
+------------+------------------------------+---------------+
| Bit number | Description | Reference |
+------------+------------------------------+---------------+
| 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
DAO-ACK Base Flags
DAO-ACKベースフラグ
IANA has created a registry for the 8-bit Consistency Check (CC) Flags field.
IANAは、8ビットの整合性チェック（CC）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description o Defining RFC
定義RFC O O機能の説明
The following bit is currently defined:
以下のビットは、現在定義されています。
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 0 | CC Response (R) | This document |
+------------+-----------------+---------------+
Consistency Check Base Flags
整合性チェックの基本国旗
IANA has created a registry for the 8-bit DODAG Configuration Option Flags field.
IANAは、8ビットのDODAG設定オプションフラグフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
The following bits are currently defined:
次のビットは、現在定義されています。
+------------+----------------------------+---------------+
| Bit number | Description | Reference |
+------------+----------------------------+---------------+
| 4 | Authentication Enabled (A) | This document |
| 5-7 | Path Control Size (PCS) | This document |
+------------+----------------------------+---------------+
DODAG Configuration Option Flags
DODAG構成オプションフラグ
IANA has created a registry for the 8-bit RPL Target Option Flags field.
IANAは、8ビットのRPLターゲットオプションフラグフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description o Defining RFC
定義RFC O O機能の説明
No bit is currently defined for the RPL Target Option Flags.
何ビットは、現在、RPLターゲットオプションフラグのために定義されていません。
IANA has created a registry for the 8-bit Transit Information Option (TIO) Flags field.
IANAは、8ビットのトランジット情報オプション（TIO）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
The following bits are currently defined:
次のビットは、現在定義されています。
+------------+--------------+---------------+
| Bit number | Description | Reference |
+------------+--------------+---------------+
| 0 | External (E) | This document |
+------------+--------------+---------------+
Transit Information Option Flags
交通情報オプションのフラグ
IANA has created a registry for the 8-bit Solicited Information Option (SIO) Flags field.
IANAは、8ビットの要請された情報オプション（SIO）Flagsフィールドのレジストリを作成しました。
New bit numbers may be allocated only by an IETF Review. Each bit is tracked with the following qualities:
新しいビット数はIETFレビューにより割り当てることができます。各ビットは以下の品質で追跡されています。
o Bit number (counting from bit 0 as the most significant bit)
Oビット数（最上位ビットとして、ビット0から数えて）
o Capability description
O機能の説明
o Defining RFC
Oの定義RFC
The following bits are currently defined:
次のビットは、現在定義されています。
+------------+--------------------------------+---------------+
| Bit number | Description | Reference |
+------------+--------------------------------+---------------+
| 0 | Version Predicate match (V) | This document |
| | | |
| 1 | InstanceID Predicate match (I) | This document |
| | | |
| 2 | DODAGID Predicate match (D) | This document |
+------------+--------------------------------+---------------+
Solicited Information Option Flags
要請情報オプションのフラグ
In some cases RPL will return an ICMPv6 error message when a message cannot be delivered as specified by its source routing header. This ICMPv6 error message is "Error in Source Routing Header".
ソースルーティングヘッダで指定されたメッセージを配信できない場合、いくつかのケースではRPLは、ICMPv6エラーメッセージを返します。このICMPv6エラーメッセージは、「ソースルーティングヘッダでエラーが発生しました」です。
IANA has defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message Types. ICMPv6 Message Type 1 describes "Destination Unreachable" codes. The "Error in Source Routing Header" code is has been allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, with a code value of 7.
IANAはICMPv6のメッセージタイプのICMPv6の「コード」フィールドレジストリを定義しています。 ICMPv6のメッセージタイプ1は、「宛先到達不能」のコードを記述します。 「エラーソースルーティングヘッダの」コードは、7のコード値で、ICMPv6のメッセージタイプ1のためのICMPv6コードフィールドレジストリから割り当てられているされています。
The rules for assigning new IPv6 multicast addresses are defined in [RFC3307]. This specification requires the allocation of a new permanent multicast address with a link-local scope for RPL nodes called all-RPL-nodes, with a value of ff02::1a.
新しいIPv6マルチキャストアドレスを割り当てるための規則は、[RFC3307]で定義されています。この仕様は、FF02 :: 1aの値を持つすべての-RPL-ノードと呼ばれるRPLノードのリンクローカルスコープを持つ新しい永久マルチキャストアドレスの割り当てを、必要とします。
The authors would like to acknowledge the review, feedback, and comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Tripathi, and Nicolas Tsiftes.
著者は、レビュー、フィードバック、およびエマニュエルBaccelli、ドミニク・バーセル、ユスフバシール、ヨアフベン・Yehezkel、ポイボス・チェン、クインダン、ミーシャのDohler、マチルドDurvy、ジョーキム・エリクソン、Omprakash Gnawali、Manhar Goindi、Mukulからのコメントを確認したいと思いますGoyal氏、ウルリッヒHerberg、アンダースミノテルヤークト、JeongGil（ジョン）コ、アジャイクマー、クエンティンLampin、ジェリーMartocci、マッテオ・パリ、アレクサンドル・ペトレスク、ジョセフ・レディ、マイケル・リチャードソン、ドンSturek、Joydeep Tripathi、そしてニコラスTsiftes。
The authors would like to acknowledge the guidance and input provided by the ROLL Chairs, David Culler and JP. Vasseur, and the Area Director, Adrian Farrel.
著者はROLLチェア、デイヴィッドCullerとJPが提供するガイダンスと入力を確認したいと思います。 Vasseur、および地域ディレクター、エイドリアン・ファレル。
The authors would like to acknowledge prior contributions of Robert Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim Bound, Yanick Pouffary, Henning Rogge, and Arsalan Tavakoli, who have provided useful design considerations to RPL.
著者は、ロバートAssimiti、ミーシャのDohler、ジュリアンラベイユ、隆次Wakikawa、テコブーツ、パトリックWetterwald、ブライアン・マクラフリン、カルロス・J. Bernardos、トーマスWatteyne、ザックシェルビー、キャロラインBontoux、マルコMolteni、ビリー・ムーンの前に貢献を認めるしたいと思いますジムは、Yanick Pouffary、ヘニング・ロゲ会長、およびRPLに便利な設計上の考慮事項を提供してきたArsalan Tavakoliを、バウンド。
RPL Security Design, found in Section 10, Section 19, and elsewhere throughout the document, is primarily the contribution of the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip Levis, Kris Pister, Rene Struik, and Adrian Farrel.
セクション10で見つけRPLセキュリティ設計、第19、および他の場所で文書全体では、主にセキュリティ設計チームの貢献である：Tzeta Tsaoさん、ロジャー・アレクサンダー、デイブ・ワード、フィリップ・リーバイス、クリスピスター教授、ルネStruik、およびエードリアンファレル。
Thanks also to Jari Arkko and Ralph Droms for their attentive reviews, especially with respect to interoperability considerations and integration with other IETF specifications.
特に相互運用性の考慮事項およびその他のIETF仕様との統合に関して、その丁寧なレビューのためにもヤリArkkoとラルフDromsのおかげで、。
Stephen Dawson-Haggerty UC Berkeley Soda Hall Berkeley, CA 94720 USA
スティーブン・ドーソン・ハガティUCバークレーソーダホールバークレー、CA 94720 USA
EMail: stevedh@cs.berkeley.edu
メールアドレス：stevedh@cs.berkeley.edu
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]ジョンソン、J.とB. Kaliski、 "公開鍵暗号規格（PKCS）＃1：RSA暗号仕様バージョン2.1"、RFC 3447、2003年2月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6206]リーバイス、P.、Clausenの、T.、ホイ、J.、Gnawali、O.、及びJ.コ "トリクルアルゴリズム"、RFC 6206、2011年3月。
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., 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。、エド。、キム、M.、エド。、ピスター教授、K.、Dejean、N.、およびD.バーセル、 "ルーティングメトリック低消費電力とロッシーネットワークにおける経路計算に使用"、 RFC 6551、2012年3月。
[RFC6552] Thubert, P., Ed., "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]ホイ、J.およびJP。 Vasseur、RFC 6553、2012年3月、「データプレーンデータグラムにRPL情報を伝達するための低消費電力とロッシーネットワークのルーティングプロトコル（RPL）オプション」。
[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]ホイ、J.、Vasseur、JP。、Culler、D.、およびV. Manral、 "低消費電力と非可逆ネットワークのためのルーティングプロトコルを有するソースルートのIPv6ルーティングヘッダ（RPL）"、RFC 6554、 2012年3月。
[6LOWPAN-ND] Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)", Work in Progress, October 2011.
[6LOWPAN-ND]シェルビー、Z.、エド。、Chakrabarti、S.、およびE. Nordmarkと、 "低消費電力とロッシーネットワーク（6LoWPAN）のための近隣探索の最適化"、進歩、2011年10月での作業。
[FIPS180] National Institute of Standards and Technology, "FIPS Pub 180-3, Secure Hash Standard (SHS)", US Department of Commerce , February 2008, <http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
[FIPS180]米国国立標準技術研究所、 "FIPSパブ180-3、セキュアハッシュ規格（SHS）"、米国商務省、2008年2月、<http://www.nist.gov/itl/upload/fips180- 3_final.pdf>。
[Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks, Vol.7: p. 395-405, December 1983.
[Perlman83]パールマン、R.、「ルーティング情報のフォールトトレラントブロードキャスト」、北ホラントのコンピュータネットワーク、第7弾：P。 395から405まで、1983年12月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[RFC1982]エルツ、R.とR.ブッシュ大統領、 "シリアル番号演算"、RFC 1982、1996年8月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、エド。、パーキンス、D.、編、及びJ. Schoenwaelder、編、STD 58、RFC 2578、1999年4月、 "管理情報バージョン2（SMIv2）の構造"。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[RFC3307]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535] Schoenwaelder、J.、RFC 3535、2003年5月 "2002 IABネットワーク管理ワークショップの概要" を参照してください。
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3610]ホワイティング、D.、Housley氏、R.、およびN.ファーガソン、 "CBC-MAC（CCM）とカウンター"、RFC 3610、2003年9月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
[RFC4101]レスコラ、E.およびIAB、 "ライティング・プロトコル・モデル"、RFC 4101、2005年6月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、ロイ、A.、グエン、L.、およびP. Pillay-Esnault、 "OSPFにおけるマルチトポロジー（MT）ルーティング"、RFC 4915、2007年6月。
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5120] Przygienda、T.、シェン、N.、およびN. Shethは、 "M-ISIS：中間システムへの中間システムにおけるマルチトポロジー（MT）ルーティング（IS-ISS）"、RFC 5120、2008年2月。
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K. Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5184]寺岡、F.、午後、K.、三ツ矢、K.、渋井、R.、およびK.三谷、 "レイヤ3（L3）駆動型高速ハンドオーバの統合レイヤ2（L2）抽象"、RFC 5184 、2008年5月。
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009.
[RFC5548]のDohler、M.、Watteyne、T.、冬、T.、およびD.バーセル、 "都市の低消費電力とロッシーネットワークのルーティング要件"、RFC 5548、2009年5月。
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009.
[RFC5673]ピスター教授、K.、Thubert、P.、Dwars、S.、およびT.フィニー、 "低消費電力とロッシーネットワークにおける産業ルーティング要件"、RFC 5673、2009年10月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントン、D.、RFC 5706、2009年11月「新しいプロトコルやプロトコル拡張の運用と管理を考えるためのガイドライン」。
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010.
[RFC5826]ブラント、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.、デ・ミル、P.、Riouの、N.、およびW. Vermeylen、 "低消費電力とロッシーネットワークにおけるビルオートメーションルーティング要件"、RFC 5867、2010年6月。
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.
[RFC5881]カッツ、D.およびD.区、 "IPv4およびIPv6（シングルホップ）のための双方向フォワーディング検出（BFD）"、RFC 5881、2010年6月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausenの、T.、Dearlove、C.、およびJ.ディーン、 "モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）"、RFC 6130、2011年4月。
[ROLL-TERMS] Vasseur, J., "Terminology in Low power And Lossy Networks", Work in Progress, September 2011.
[ROLL-TERMS] Vasseur、J.、 "低消費電力、ロッシーネットワークにおける用語"、進歩、2011年9月での作業。
Appendix A. Example Operation
付録A.動作例
This appendix provides some examples to illustrate the dissemination of addressing information and prefixes with RPL. The examples depict information being distributed with PIOs and RIOs and the use of DIO and DAO messages. Note that this appendix is not normative, and that the specific details of a RPL addressing plan and autoconfiguration may vary according to specific implementations. RPL merely provides a vehicle for disseminating information that may be built upon and used by other mechanisms.
この付録では、RPLとの情報とプレフィックスのアドレス指定の普及を説明するためにいくつかの例を提供します。例は、のPIOとリオスとDIOとDAOメッセージを使用して配布される情報を示しています。この付録は規範的ではなく、RPLアドレッシング計画と自動設定の具体的な詳細は、特定の実装に応じて変わり得ることことに留意されたいです。 RPLは、単に上に構築され、他の機構によって使用される情報を広めるための手段を提供します。
Note that these examples illustrate use of address autoconfiguration schemes supported by information distributed within RPL. However, if an implementation includes another address autoconfiguration scheme, RPL nodes might be configured not to set the 'A' flag in PIO options, though the PIO can still be used to distribute prefix and addressing information.
これらの例はRPL内に分散情報によってサポートされるアドレス自動設定方式の使用を示すことに留意されたいです。実装が別のアドレス自動設定方式を含む場合は、RPLノードは、PIOが依然としてプレフィックスとアドレス情報を配布するために使用することができるが、PIOオプションに「A」フラグを設定しないように構成されるかもしれません。
A.1. Example Operation in Storing Mode with Node-Owned Prefixes
A.1。ノード所有プレフィックスと保管モードの動作例
Figure 32 illustrates the logical addressing architecture of a simple RPL network operating in Storing mode. In this example, each Node, A, B, C, and D, owns its own prefix and makes that prefix available for address autoconfiguration by on-link devices. (This is conveyed by setting the 'A' flag and the 'L' flag in the PIO of the DIO messages). Node A owns the prefix A::/64, Node B owns B::/64, and so on. Node B autoconfigures an on-link address with respect to Node A, A::B. Nodes C and D similarly autoconfigure on-link addresses from Node B's prefix, B::C and B::D, respectively. Nodes have the option of setting the 'R' flag and publishing their address within the Prefix field of the PIO.
図32は、モード保存で動作する簡単なRPLネットワークの論理的アドレス指定アーキテクチャを示します。この例では、各ノードは、Aは、B、C、及びDは、独自のプレフィックスを所有し、オンリンクデバイスによるアドレス自動設定のためにそのプレフィックスが利用できるようにします。 （これは、DIOメッセージのPIOで「」フラグと「L」フラグを設定することにより搬送されます）。ノードAは、プレフィックスA :: / 64を所有して、ノードBは、その上のB :: / 64を所有している、と。ノードBはノードA :: Bに対するオンリンクアドレスを自動構成します。ノードC及びDは、同様に、それぞれ、ノードBの接頭辞、B :: C及びB :: Dからオンリンクアドレスを自動設定します。ノードは、「R」フラグを設定し、PIOのPrefixフィールド内に住所を公開するオプションがあります。
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 32: Storing Mode with Node-Owned Prefixes
図32：ノード所有接頭辞格納モード
A.1.1. DIO Messages and PIO
A.1.1。 DIOメッセージとPIO
Node A, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Set 'R' flag: Clear Prefix Length: 64 Prefix: A::
「」フラグ：セットの「L」フラグ：セットR「」フラグ：クリアプレフィックス長：64プレフィックス：Aを::次のようにノードAは、例えば、PIOでDIOメッセージを送信します
Node B, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Set 'R' flag: Set Prefix Length: 64 Prefix: B::B
「」フラグ：セット「L」フラグ：設定「R」フラグ：セットプレフィックスの長さ：64接頭辞：B :: Bを次のように、ノードBは、例えば、PIOとDIOメッセージを送信します
Node C, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Set 'R' flag: Clear Prefix Length: 64 Prefix: C::
「」フラグ：セット「L」フラグ：設定「R」フラグクリアプレフィックスの長さ：64接頭辞：次のようにノードCは、例えば、PIOとDIOメッセージを送信するCを::
Node D, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Set 'R' flag: Set Prefix Length: 64 Prefix: D::D
「」フラグ：セット「L」フラグ：設定「R」フラグ：セットプレフィックスの長さ：64接頭辞：D :: Dを次のようにノードDは、例えば、PIOとDIOメッセージを送信します
A.1.2. DAO Messages
A.1.2。 CAD投稿
Node B will send DAO messages to Node A with the following information: o Target B::/64 o Target C::/64 o Target D::/64
ノードBは、次の情報をノードAにDAOメッセージを送信する：ターゲットB :: / 64 OのターゲットC :: / 64 OのターゲットD :: / 64 oを
Node C will send DAO messages to Node B with the following information: o Target C::/64
ノードCは、以下の情報をノードBにDAOメッセージを送信します：ターゲットC oを:: / 64
Node D will send DAO messages to Node B with the following information:
ノードDは、以下の情報をノードBにDAOメッセージを送信します。
o Target D::/64
OターゲットD :: / 64
A.1.3. Routing Information Base
A.1.3。ルーティング情報ベース
Node A will conceptually collect the following information into its Routing Information Base (RIB): o A::/64 connected o B::/64 via B's link local o C::/64 via B's link local o D::/64 via B's link local
ノードAは、概念的にそのルーティング情報ベース（RIB）に以下の情報を収集します：Bのリンクローカル入出力D :: / 64を介してBのリンクローカル入出力C :: / 64を介して:: / 64接続された入出力B :: / 64 O Bのリンクを介してローカル
Node B will conceptually collect the following information into its RIB: o ::/0 via A's link local o B::/64 connected o C::/64 via C's link local o D::/64 via D's link local
ノードBは、概念的に、そのRIBに以下の情報を収集します：O :: Aのリンクローカル入出力B :: / 64 Cのリンクローカル入出力D :: / 64を介してC :: / 64 O接続されたローカルD'sのリンクビア/ 0
Node C will conceptually collect the following information into its RIB: o ::/0 via B's link local o C::/64 connected
ノードCは、概念的に、そのRIBに以下の情報を収集します：C O Bのリンクを介して:: / 0 oはローカル::接続/ 64
Node D will conceptually collect the following information into its RIB: o ::/0 via B's link local o D::/64 connected
ノードDは、概念的に、そのRIBに以下の情報を収集します：D O Bのリンクを介して:: / 0 oはローカル::接続/ 64
A.2. Example Operation in Storing Mode with Subnet-Wide Prefix
A.2。サブネットワイドプレフィックスと保管モードの動作例
Figure 33 illustrates the logical addressing architecture of a simple RPL network operating in Storing mode. In this example, the root Node A sources a prefix that is used for address autoconfiguration over the entire RPL subnet. (This is conveyed by setting the 'A' flag and clearing the 'L' flag in the PIO of the DIO messages.) Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes have the option of setting the 'R' flag and publishing their address within the Prefix field of the PIO.
図33は、モード保存で動作する簡単なRPLネットワークの論理的アドレス指定アーキテクチャを示します。この例では、ルートノードAは、全体RPLサブネット上にアドレス自動設定のために使用される接頭辞をソース。 （これは、「」フラグを設定し、DIOメッセージのPIOに「L」フラグをクリアすることによって搬送される。）のノードA、B、C、及びDプレフィックスA :: / 64へのすべての自動構成。ノードは、「R」フラグを設定し、PIOのPrefixフィールド内に住所を公開するオプションがあります。
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 33: Storing Mode with Subnet-Wide Prefix
図33：サブネットワイドプレフィックスと保存モード
A.2.1. DIO Messages and PIO
A.2.1。 DIOメッセージとPIO
Node A, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Clear Prefix Length: 64 Prefix: A::
「」フラグ：セットの「L」フラグ：クリアR「」フラグ：クリアプレフィックス長：64プレフィックス：Aを::次のようにノードAは、例えば、PIOでDIOメッセージを送信します
Node B, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::B
「」フラグ：セット「L」フラグをクリア「R」フラグ：セットプレフィックスの長さ：64プレフィックス:: Bを次のように、ノードBは、例えば、PIOとDIOメッセージを送信します
Node C, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Clear Prefix Length: 64 Prefix: A::
「」フラグ：セット「L」フラグをクリア「R」フラグクリアプレフィックスの長さ：64接頭辞：Aを::次のように、ノードCは、例えば、PIOとDIOメッセージを送信します
Node D, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::D
'' フラグ：セット 'L' フラグをクリア 'R' フラグ：セットプレフィックスの長さ：64接頭辞：A :: Dを次のようにノードDは、例えば、PIOとDIOメッセージを送信します
A.2.2. DAO Messages
A.2.2。 CAD投稿
Node B will send DAO messages to Node A with the following information: o Target A::B/128 o Target A::C/128 o Target A::D/128
ノードBは、次の情報をノードAにDAOメッセージを送信する：ターゲットO A :: B / 128 O対象A :: C / 128 OターゲットA :: D / 128
Node C will send DAO messages to Node B with the following information: o Target A::C/128
ノードCは、以下の情報をノードBにDAOメッセージを送信する：ターゲットA :: C / 128 oを
Node D will send DAO messages to Node B with the following information: o Target A::D/128
ノードDは、以下の情報をノードBにDAOメッセージを送信する：ターゲットA oを:: D / 128
A.2.3. Routing Information Base
A.2.3。ルーティング情報ベース
Node A will conceptually collect the following information into its RIB: o A::A/128 connected o A::B/128 via B's link local o A::C/128 via B's link local o A::D/128 via B's link local
ノードAは、概念的に、そのRIBに以下の情報を収集します：:: D / 128を介してOローカルBのリンクを介して:: C / 128 OローカルBのリンクを介して::のB / 128 O接続:: A / 128 oをBのリンクローカル
Node B will conceptually collect the following information into its RIB: o ::/0 via A's link local o A::B/128 connected o A::C/128 via C's link local o A::D/128 via D's link local
ノードBは、概念的に、そのRIBに以下の情報を収集します：Aのリンクを介して:: / 0 oはローカル::のB / 128に接続oを:: C / 128 oをD'sのリンクを介して:: D / 128 O Cのリンクローカル介し地元
Node C will conceptually collect the following information into its RIB: o ::/0 via B's link local o A::C/128 connected
ノードCは、概念的に、そのRIBに以下の情報を収集します：Bのリンクを介して:: / 0 oはローカル接続:: C / 128 oを
Node D will conceptually collect the following information into its RIB: o ::/0 via B's link local o A::D/128 connected
ノードDは、概念的に、そのRIBに以下の情報を収集します：O :: / 0 ::のD OローカルBのリンクを介して/ 128が接続されています
A.3. Example Operation in Non-Storing Mode with Node-Owned Prefixes
A.3。ノード所有プレフィックスと非登録モードでの動作例
Figure 34 illustrates the logical addressing architecture of a simple RPL network operating in Non-Storing mode. In this example, each Node, A, B, C, and D, owns its own prefix, and makes that prefix available for address autoconfiguration by on-link devices. (This is conveyed by setting the 'A' flag and the 'L' flag in the PIO of the DIO messages.) Node A owns the prefix A::/64, Node B owns B::/64, and so on. Node B autoconfigures an on-link address with respect to Node A, A::B. Nodes C and D similarly autoconfigure on-link addresses from Node B's prefix, B::C and B::D, respectively. Nodes have the option of setting the 'R' flag and publishing their address within the Prefix field of the PIO.
図34は、非保存モードで動作する単純なRPLネットワークの論理的アドレス指定アーキテクチャを示します。この例では、各ノードA、B、C、及びDは、独自のプレフィックスを所有し、そして上のリンク装置によってアドレス自動設定のためにそのプレフィックスが利用できるようにします。ノードAは、プレフィックスA :: / 64を所有している（これは、DIOメッセージのPIOで「」フラグと「L」フラグを設定することにより搬送される。）、ノードBは、そうでB :: / 64を所有している、と。ノードBはノードA :: Bに対するオンリンクアドレスを自動構成します。ノードC及びDは、同様に、それぞれ、ノードBの接頭辞、B :: C及びB :: Dからオンリンクアドレスを自動設定します。ノードは、「R」フラグを設定し、PIOのPrefixフィールド内に住所を公開するオプションがあります。
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 34: Non-Storing Mode with Node-Owned Prefixes
図34：ノード所有プレフィックスと非格納モード
A.3.1. DIO Messages and PIO
A.3.1。 DIOメッセージとPIO
The PIO contained in the DIO messages in the Non-Storing mode with node-owned prefixes can be considered to be identical to those in the Storing mode with node-owned prefixes case (Appendix A.1.1).
PIOは、ノードが所有するプレフィックスを有する非保存モードでDIOメッセージに含まれているノードが所有するプレフィックスの場合（付録A.1.1）と記憶モードにおけるものと同一であると考えることができます。
A.3.2. DAO Messages
A.3.2。 CAD投稿
Node B will send DAO messages to Node A with the following information:
ノードBは、以下の情報をノードAにDAOメッセージを送信します。
o Target B::/64, Transit A::B
OターゲットB :: / 64、トランジットA :: B
Node C will send DAO messages to Node A with the following information: o Target C::/64, Transit B::C
ノードCは、以下の情報をノードAにDAOメッセージを送信する：ターゲットC :: / 64、トランジットB :: C oを
Node D will send DAO messages to Node A with the following information: o Target D::/64, Transit B::D
ノードDは、以下の情報をノードAにDAOメッセージを送信する：ターゲットD ::φ/ 64、トランジットB :: D
A.3.3. Routing Information Base
A.3.3。ルーティング情報ベース
Node A will conceptually collect the following information into its RIB. Note that Node A has enough information to construct source routes by doing recursive lookups into the RIB: o A::/64 connected o B::/64 via A::B o C::/64 via B::C o D::/64 via B::D
ノードAは、概念的にはそのRIBに次の情報を収集します。ノードAはRIBに再帰的な検索を実行して、ソースルートを構築するための十分な情報があることに注意してください：B O接続:: / 64 Oで:: / 64 C O :: Bを介して:: / 64 Bを介して:: D O C Bを介して:: / 64 :: D
Node B will conceptually collect the following information into its RIB: o ::/0 via A's link local o B::/64 connected
ノードBは、概念的にはそのRIBに次の情報を収集します：O :: / 0 Aのリンクローカル入出力B ::接続/ 64を経由して
Node C will conceptually collect the following information into its RIB: o ::/0 via B's link local o C::/64 connected
ノードCは、概念的に、そのRIBに以下の情報を収集します：C O Bのリンクを介して:: / 0 oはローカル::接続/ 64
Node D will conceptually collect the following information into its RIB: o ::/0 via B's link local o D::/64 connected
ノードDは、概念的に、そのRIBに以下の情報を収集します：D O Bのリンクを介して:: / 0 oはローカル::接続/ 64
A.4. Example Operation in Non-Storing Mode with Subnet-Wide Prefix
A.4。サブネットワイドプレフィックスと非登録モードでの動作例
Figure 35 illustrates the logical addressing architecture of a simple RPL network operating in Non-Storing mode. In this example, the root Node A sources a prefix that is used for address autoconfiguration over the entire RPL subnet. (This is conveyed by setting the 'A' flag and clearing the 'L' flag in the PIO of the DIO messages.) Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes must set the 'R' flag and publish their address within the Prefix field of the PIO, in order to inform their children which address to use in the transit option.
図35は、非保存モードで動作する単純なRPLネットワークの論理的アドレス指定アーキテクチャを示します。この例では、ルートノードAは、全体RPLサブネット上にアドレス自動設定のために使用される接頭辞をソース。 （これは、「」フラグを設定し、DIOメッセージのPIOに「L」フラグをクリアすることによって搬送される。）のノードA、B、C、及びDプレフィックスA :: / 64へのすべての自動構成。ノードは、R「」フラグを設定し、トランジットオプションで使用するアドレス子どもを知らせるために、PIOのPrefixフィールド内そのアドレスを公開する必要があります。
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 35: Non-Storing Mode with Subnet-Wide Prefix
図35：サブネットワイドプレフィックスと非登録モード
A.4.1. DIO Messages and PIO
A.4.1。 DIOメッセージとPIO
Node A, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::A
'' フラグ：セットの 'L' フラグ：クリアR '' フラグ：セットのプレフィックス長：64プレフィックス：::次のようにノードAは、例えば、PIOでDIOメッセージを送信します
Node B, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::B
「」フラグ：セット「L」フラグをクリア「R」フラグ：セットプレフィックスの長さ：64プレフィックス:: Bを次のように、ノードBは、例えば、PIOとDIOメッセージを送信します
Node C, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::C
「」フラグ：セット「L」フラグをクリア「R」フラグ：セットプレフィックスの長さ：64プレフィックス:: Cを以下のように、ノードCは、例えば、PIOとDIOメッセージを送信します
Node D, for example, will send DIO messages with a PIO as follows: 'A' flag: Set 'L' flag: Clear 'R' flag: Set Prefix Length: 64 Prefix: A::D
'' フラグ：セット 'L' フラグをクリア 'R' フラグ：セットプレフィックスの長さ：64接頭辞：A :: Dを次のようにノードDは、例えば、PIOとDIOメッセージを送信します
A.4.2. DAO Messages
A.4.2。 CAD投稿
Node B will send DAO messages to Node A with the following information: o Target A::B/128, Transit A::A
ノードBは、以下の情報をノードAにDAOメッセージを送信します：ターゲットA :: B / 128、トランジットA :: A O
Node C will send DAO messages to Node A with the following information: o Target A::C/128, Transit A::B
ノードCは、以下の情報をノードAにDAOメッセージを送信する：ターゲットA oを:: C / 128、トランジットA :: B
Node D will send DAO messages to Node A with the following information: o Target A::D/128, Transit A::B
ノードDは、以下の情報をノードAにDAOメッセージを送信する：ターゲットA oを:: D / 128、トランジットA :: B
A.4.3. Routing Information Base
A.4.3。ルーティング情報ベース
Node A will conceptually collect the following information into its RIB. Note that Node A has enough information to construct source routes by doing recursive lookups into the RIB: o A::A/128 connected o A::B/128 via A::A o A::C/128 via A::B o A::D/128 via A::B
ノードAは、概念的にはそのRIBに次の情報を収集します。ノードAはRIBに再帰的な検索を実行して、ソースルートを構築するのに十分な情報を持っていることに注意：O :: A ::のB / Aを介して:: O A :: C / 128を介して128 oを接続/ 128 :: :: Bを介して::のD / 128 O B
Node B will conceptually collect the following information into its RIB: o ::/0 via A's link local o A::B/128 connected
ノードBは、概念的にはそのRIBに次の情報を収集します：Aのリンクを介して:: / 0 oはローカル接続::のB / 128 oを
Node C will conceptually collect the following information into its RIB: o ::/0 via B's link local o A::C/128 connected
ノードCは、概念的に、そのRIBに以下の情報を収集します：Bのリンクを介して:: / 0 oはローカル接続:: C / 128 oを
Node D will conceptually collect the following information into its RIB: o ::/0 via B's link local o A::D/128 connected
ノードDは、概念的に、そのRIBに以下の情報を収集します：O :: / 0 ::のD OローカルBのリンクを介して/ 128が接続されています
A.5. Example with External Prefixes
A.5。外部接頭辞を持つ例
Consider the simple network illustrated in Figure 36. In this example, there are a group of routers participating in a RPL network: a DODAG root, Nodes A, Y, and Z. The DODAG root and Node Z also have connectivity to different external network domains (i.e., external to the RPL network). Note that those external networks could be RPL networks or another type of network altogether.
また、異なる外部ネットワークへの接続を有するDODAGルート、ノードA、Y、及びZのザDODAGルート及びノードZ：RPLのネットワークに参加するルータのグループがあり、この例では、図36に示されている単純なネットワークを考えますドメイン（RPLネットワークへのすなわち、外部）。これらの外部ネットワークが完全にRPLのネットワークまたはネットワークの別のタイプの可能性があることに注意してください。
RPL Network +-------------------+
RPL::/64 | |
| External |
[RPL::Root] (Root)----------+ Prefix |
| | EXT_1::/64 |
| | |
| +-------------------+
[RPL::A] (A)
:
:
:
[RPL::Y] (Y)
| +-------------------+
| | |
| | External |
[RPL::Z] (Z)------------+ Prefix |
: | EXT_2::/64 |
: | |
: +-------------------+
Figure 36: Simple Network Example
図36：単純なネットワークの例
In this example, the DODAG root makes a prefix available to the RPL subnet for address autoconfiguration. Here, the entire RPL subnet uses that same prefix, RPL::/64, for address autoconfiguration, though in other implementations more complex/hybrid schemes could be employed.
この例では、DODAGルートは、アドレス自動設定のためのRPLサブネットに利用できるプレフィックスになります。他の実施態様では、ハイブリッド/より複雑なスキームを使用することができるけれども、ここで、全体RPLサブネットは、アドレス自動設定のために、:: / 64は、同じ接頭辞、RPLを使用します。
The DODAG root has connectivity to an external (with respect to that RPL network) prefix EXT_1::/64. The DODAG root may have learned of connectivity to this prefix, for example, via explicit configuration or IPv6 ND on a non-RPL interface. The DODAG root is configured to announce information on the connectivity to this prefix.
DODAGルートはプレフィックスEXT_1 :: / 64（つまりRPLネットワークに対して）外部への接続を有しています。 DODAGルートは非RPLインターフェイス上で明示的に設定またはIPv6 NDを経て、例えば、このプレフィックスへの接続を知っている可能性があります。 DODAGルートは、このプレフィックスへの接続に関する情報を発表するように構成されています。
Similarly, Node Z has connectivity to an external prefix EXT_2::/64. Node Z also has a sub-DODAG underneath of it.
同様に、ノードZは、外部プレフィックスEXT_2 :: / 64への接続を有しています。ノードZはまた、それの下にサブDODAGを有しています。
1. The DODAG root adds a RIO to its DIO messages. The RIO contains the external prefix EXT_1::/64. This information may be repeated in the DIO messages emitted by the other nodes within the DODAG. Thus, the reachability to the prefix EXT_1::/64 is disseminated down the DODAG.
1. DODAGルートはそのDIOメッセージにRIOを追加します。 RIOは、外部プレフィックスEXT_1 :: / 64が含まれています。この情報は、DODAG内の他のノードによって放出されたDIOメッセージに繰り返すことができます。このように、接頭辞EXT_1 :: / 64に到達可能性はDODAGを下に広めています。
2. Node Z may advertise reachability to the Target network EXT_2::/64 by sending DAO messages using EXT_2::/64 as a Target in the Target option and itself (Node Z) as a parent in the Transit Information option. (In Storing mode, that Transit Information option does not need to contain the address of Node Z). A non-storing root then becomes aware of the 1-hop link (Node Z -- EXT_2::/64) for use in constructing source routes. Node Z may additionally advertise its reachability to EXT_2::/64 to nodes in its sub-DODAG by sending DIO messages with a PIO, with the 'A' flag cleared.
2.ノードZは、交通情報オプションで親としてのターゲットオプションでターゲットと自身（ノードZ）としてEXT_2 :: / 64を使用してDAOメッセージを送信することにより、ターゲットネットワークEXT_2 :: / 64に到達可能性を宣伝することがあります。 （モードを保存するには、交通情報オプションは、ノードZのアドレスを含める必要はありません）。ソースルートを構築する際に使用するため - 非保存ルートを1ホップリンク（EXT_2 :: / 64ノードZ）の認識となります。ノードZは、さらにクリア「」フラグと、PIOとDIOメッセージを送信することによって、そのサブDODAGのノードにEXT_2 :: / 64への到達可能性を広告することができます。
Authors' Addresses
著者のアドレス
Tim Winter (editor)
ティム・冬（編集者）
EMail: wintert@acm.org
メールアドレス：wintert@acm.org
Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 France
Thubertパスカル（編集者）、シスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3ビオ - ソフィアアンティポリス、フランス06410
Phone: +33 497 23 26 34 EMail: pthubert@cisco.com
電話：+33 497 23 26 34 Eメール：pthubert@cisco.com
Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen DK-2100 Denmark
アンダースブラントシグマEmdrupvej 26A、第コペンハーゲンDK-2100デンマークデザイン
EMail: abr@sdesigns.dk
メールアドレス：abr@sdesigns.dk
Jonathan W. Hui Arch Rock Corporation 501 2nd St., Suite 410 San Francisco, CA 94107 USA
ジョナサン・W.ホイアーチロック株式会社501第二聖、スイート410サンフランシスコ、CA 94107 USA
EMail: jhui@archrock.com
メールアドレス：jhui@archrock.com
Richard Kelsey Ember Corporation Boston, MA USA
リチャード・ケルシーエンバー社、ボストン、MA USA
Phone: +1 617 951 1225 EMail: kelsey@ember.com
電話：+1 617 951 1225 Eメール：kelsey@ember.com
Philip Levis Stanford University 358 Gates Hall, Stanford University Stanford, CA 94305-9030 USA
フィリップ・リーバイススタンフォード大学358ゲイツ・ホール、スタンフォード大学のスタンフォード、カリフォルニア州94305から9030 USA
EMail: pal@cs.stanford.edu
メールアドレス：pal@cs.stanford.edu
Kris Pister Dust Networks 30695 Huntwood Ave. Hayward, CA 94544 USA
クリスピスター教授ダストネットワークス30695 Huntwoodアベニュー。ヘイワード、CA 94544 USA
EMail: kpister@dustnetworks.com
メールアドレス：kpister@dustnetworks.com
Rene Struik Struik Security Consultancy
ルネ・ブッシュブッシュセキュリティコンサルティング
EMail: rstruik.ext@gmail.com
メールアドレス：rstruik.ext@gmail.com
JP. Vasseur Cisco Systems 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France
JP。シスコシステムズVasseur 11、ルーカミーユ・デムーラン92782イシレムリノーフランス
EMail: jpv@cisco.com
メールアドレス：jpv@cisco.com
Roger K. Alexander Cooper Power Systems 20201 Century Blvd., Suite 250 Germantown, MD 20874 USA
ロジャー・K.アレクサンダー・クーパーパワーシステムズ20201センチュリーブルバード、スイート250ジャーマンタウン、MD 20874 USA
Phone: +1 240 454 9817 EMail: roger.alexander@cooperindustries.com
電話：+1 240 454 9817 Eメール：roger.alexander@cooperindustries.com