[要約] RFC 9010は、低電力かつ損失の多いネットワーク(Low-Power and Lossy Networks, LLNs)用のルーティングプロトコルであるRPLのリーフノードのためのルーティング手法を定義します。この文書の目的は、リーフノードがインターネットと通信するための効率的な方法を提供することにあります。主にスマートシティ、産業自動化、環境モニタリングなどの分野で利用されます。
Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9010 Cisco Systems
Updates: 6550, 6775, 8505 M. Richardson
Category: Standards Track Sandelman
ISSN: 2070-1721 April 2021
Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
RPLのルーティング（低消費電力および非損失ネットワークのためのルーティングプロトコル）
Abstract
概要
This specification provides a mechanism for a host that implements a routing-agnostic interface based on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery to obtain reachability services across a network that leverages RFC 6550 for its routing operations. It updates RFCs 6550, 6775, and 8505.
この仕様は、RFC 6550を活用したネットワーク全体でRFC 6550を活用したネットワーク全体で到達可能性サービスを得るためのIPv6に基づくルーティングアンジノスティックインタフェースを実装するホストのメカニズムを提供します。RFCS 6550,6775、および8505を更新します。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9010.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9010で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Terminology
2.1. Requirements Language
2.2. Glossary
2.3. Related Documents
3. RPL External Routes and Data-Plane Artifacts
4. 6LoWPAN Neighbor Discovery
4.1. Address Registration per RFC 6775
4.2. Extended Address Registration per RFC 8505
4.2.1. R Flag
4.2.2. TID, "I" Field, and Opaque Field
4.2.3. Route Ownership Verifier
4.3. EDAR/EDAC per RFC 8505
4.3.1. Capability Indication Option per RFC 7400
5. Requirements for the RPL-Unaware Leaf
5.1. Support of 6LoWPAN ND
5.2. Support of IPv6 Encapsulation
5.3. Support of the Hop-by-Hop Header
5.4. Support of the Routing Header
6. Enhancements to RFC 6550
6.1. Updated RPL Target Option
6.2. Additional Flag in the RPL DODAG Configuration Option
6.3. Updated RPL Status
7. Enhancements to RFC 9009
8. Enhancements to RFCs 6775 and 8505
9. Protocol Operations for Unicast Addresses
9.1. General Flow
9.2. Detailed Operation
9.2.1. Perspective of the 6LN Acting as a RUL
9.2.2. Perspective of the 6LR Acting as a Border Router
9.2.3. Perspective of the RPL DODAG Root
9.2.4. Perspective of the 6LBR
10. Protocol Operations for Multicast Addresses
11. Security Considerations
12. IANA Considerations
12.1. Fixing the Address Registration Option Flags
12.2. Resizing the ARO Status Values
12.3. New RPL DODAG Configuration Option Flag
12.4. RPL Target Option Flags Registry
12.5. New Subregistry for RPL Non-Rejection Status Values
12.6. New Subregistry for RPL Rejection Status Values
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Example Compression
Acknowledgments
Authors' Addresses
The design of Low-Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. Other design constraints, such as a limited memory capacity, duty cycling of the LLN devices, and low-power lossy transmissions, derive from that primary concern.
低消費電力および非損失ネットワーク（LLN）の設計は一般にエネルギーを節約することに焦点を当てており、これは全部の最も拘束されたリソースです。その主な関心から派生した、LLNデバイスの制限されたメモリ容量、デューティサイクル、および低電力の損失のある送信などの他の設計上の制約。
The IETF produced "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] to provide routing services for IPv6 [RFC8200] within such constraints. RPL belongs to the class of distance-vector protocols -- which, compared to link-state protocols, limit the amount of topological knowledge that needs to be installed and maintained in each node -- and does not require convergence to avoid micro-loops.
IETFは、そのような制約内のIPv6 [RFC8200]のルーティングサービスを提供するための「RPL：LOSPYネットワークのためのRPL：IPv6ルーティングプロトコル」を作成しました。RPLは距離 - ベクトルプロトコルのクラスに属しています - リンクステートプロトコルと比較して、各ノードにインストールおよび維持される必要があるトポロジの知識の量を制限し、マイクロループを回避するための収束を必要としません。
To save signaling and routing state in constrained networks, RPL allows a path stretch (see [RFC6687]), whereby routing is only performed along a Destination-Oriented Directed Acyclic Graph (DODAG) that is optimized to reach a root node, as opposed to along the shortest path between two peers, whatever that would mean in a given LLN. This trades the quality of peer-to-peer (P2P) paths for a vastly reduced amount of control traffic and routing state that would be required to operate an any-to-any shortest-path protocol. Additionally, broken routes may be fixed lazily and on demand, based on data-plane inconsistency discovery, which avoids wasting energy in the proactive repair of unused paths.
制約付きネットワークでシグナリングとルーティング状態を保存するために、RPLはパスストレートを許可します（[RFC6687]を参照）、それによってルーティングはルートノードに到達するように最適化された宛先指向の無指向性グラフ（DODAG）に沿って行われます。2つのピア間の最短経路に沿って、与えられたLLNで意味するものは何でも。これにより、任意の最短経路プロトコルを操作するために必要となるであろう制御トラフィックとルーティング状態のために、絶対的にピアツーピア（P2P）経路の品質を取得します。さらに、壊れた経路は、未使用経路の積極的な修理におけるエネルギーを無駄にすることを回避するデータプレーンの不整合発見に基づいて、壊れた経路が遅延およびオンデマンドに固定され得る。
For many of the nodes, though not all, the DODAG provides multiple forwarding solutions towards the root of the topology via so-called parents. RPL installs the routes proactively, but to adapt to fuzzy connectivity -- whereby the physical topology cannot be expected to reach a stable state -- it uses a lazy route maintenance operation that may only fix them reactively, upon actual traffic. The result is that RPL provides reachability for most of the LLN nodes, most of the time, but may not converge in the classical sense.
すべてのノードにとって、すべてのノードの場合、DoDagは、いわゆる親を介してトポロジの根元に向けて複数の転送ソリューションを提供します。RPLはルートを積極的にインストールしますが、ファジィ接続に適応します。その結果、RPLはほとんどのLLNノードの到達可能性を提供しますが、ほとんどの場合、古典的な意味で収束することはできません。
RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND) [RFC4861] [RFC4862] and IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ND [RFC6775] [RFC8505] to maintain reachability within a Non-Broadcast Multi-Access (NBMA) multi-link subnet.
RPLは、非放送マルチアクセス内の到達可能性を維持するために、RFC4861 [RFC4862] [RFC4862] [RFC4862] [RFC4862] [RFC4862] [RFC4862] [RFC4862]とIPv6 [RFC6775] [RFC8505]を展開できます。（NBMA）マルチリンクサブネット。
In that mode, IPv6 addresses are advertised individually as host routes. Some nodes may act as routers and participate in the forwarding operations, whereas others will only receive/originate packets, acting as hosts in the data plane. Per the terminology of [RFC6550], an IPv6 host [RFC8504] that is reachable over the RPL network is called a "leaf".
そのモードでは、IPv6アドレスはホストルートとして個別にアドバタイズされます。一部のノードはルーターとして機能し、転送操作に参加し、他のユーザーはデータプレーン内のホストとして機能します。[RFC6550]の用語では、RPLネットワーク上で到達可能なIPv6ホスト[RFC8504]を「リーフ」と呼びます。
Section 2 of [RFC9008] defines the terms "RPL leaf", "RPL-Aware Leaf" (RAL), and "RPL-Unaware Leaf" (RUL). A RPL leaf is a host attached to one or more RPL routers; as such, it relies on the RPL router(s) to forward its traffic across the RPL domain but does not forward traffic from another node. As opposed to the RAL, the RUL does not participate in RPL and relies on its RPL router(s) to also inject the routes to its IPv6 addresses in the RPL domain.
[RFC9008]のセクション2の「RPLリーフ」、「RPL対応葉」（RAL）、および「RPL-NAAWARE LEAF」（RUR）を定義します。RPLリーフは、1つ以上のRPLルータに接続されているホストです。そのため、RPLルータに依存してRPLドメイン間でトラフィックを転送するが、他のノードからトラフィックを転送しません。RALとは対照的に、RULはRPLに参加しておらず、RPLドメイン内のIPv6アドレスにルートを注入するためにRPLルータに依存しています。
A RUL may be unable to participate because it is very energy constrained or code-space constrained, or because it would be unsafe to let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as the host-to-router interface limits the surface of the possible attacks by the RUL against the RPL domain. If all RULs and RPL-Aware Nodes (RANs) use 6LoWPAN ND for the neighbor discovery process, it is also possible to protect the address ownership of all nodes, including the RULs.
それは非常にエネルギー拘束またはコードスペースに制約された、またはRPLでルートを挿入できるようにするため、ルールが参加できない場合があります。ホストからルータへのインターフェイスがRPLドメインに対するルールによって可能な攻撃の表面を制限すると、RPLとは対照的に6LOWPAN NDを使用する。すべてのRUSとRPLとRPLのノード（RAN）が近隣探索プロセスに6LOWPAN NDを使用する場合は、RULSを含むすべてのノードのアドレスの所有権を保護することも可能です。
This document specifies how the router injects the host routes in the RPL domain on behalf of the RUL. Section 5 details how the RUL can leverage 6LoWPAN ND to obtain the routing services from the router. In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-aware router is also a 6LoWPAN Router (6LR). Using the 6LoWPAN ND Address Registration mechanism, the RUL signals that the router must inject a host route for the Registered Address.
このドキュメントは、ルータがRPLドメイン内のホストルートにルーの代わりにどのように挿入されるかを指定します。セクション5は、ルーパンNDをレバレッジできるように、ルータからルーティングサービスを取得する方法を示します。そのモデルでは、RURは6LOWPANノード（6LN）でもあり、RPL対応ルータも6LOWPANルータ（6LR）である。6LOWPAN NDアドレス登録メカニズムを使用して、ルータが登録アドレスのホストルートを注入しなければならないRUR信号。
------+---------
| Internet
|
+-----+
| | <------------- 6LBR / RPL DODAG Root
+-----+ ^
| |
o o o o | RPL
o o o o o o o o |
o o o o o o o o o o | +
o o o o o o o |
o o o o o o o o o | 6LoWPAN ND
o o o o o o |
o o o o v
o o o <------------- 6LR / RPL Border Router
^
| 6LoWPAN ND only
v
u <------------- 6LN / RPL-Unaware Leaf
Figure 1: Injecting Routes on Behalf of RULs
図1：ルールに代わってルートを注入する
The RPL Non-Storing mode mechanism is used to extend the routing state with connectivity to the RULs even when the DODAG is operated in Storing mode. The unicast packet-forwarding operation by the 6LR serving a RUL is described in Section 4.1.1 of [RFC9008].
RPL非記憶モード機構は、ドダグが記憶モードで動作している場合でも、ルーティング状態をRULSに接続するために使用される。RFC9008のセクション4.1.1では、6LRを処理する6LRによるユニキャストパケット転送操作について説明します。
Examples of possible RULs include severely energy-constrained sensors such as window smash sensors (alarm system) and kinetically powered light switches. Other applications of this specification may include a smart grid network that controls appliances -- such as washing machines or the heating system -- in the home. Appliances may not participate in the RPL protocol operated in the smart grid network but can still interact with the smart grid for control and/or metering.
可能性のあるrULSの例には、ウィンドウスマッシュセンサ（警報システム）などの厳しくエネルギー拘束されたセンサおよび動きの光スイッチが含まれる。本明細書の他のアプリケーションは、洗濯機や暖房システムなど、家具や暖房システムなどのスマートグリッドネットワークを含み得る。アプライアンスは、スマートグリッドネットワークで動作しているRPLプロトコルに参加できませんが、コントロールやメータリングのためにスマートグリッドと対話することはできません。
This specification can be deployed incrementally in a network that implements [RFC9008]. Only the root and the 6LRs that connect the RULs need to be upgraded. The RPL routers on the path will only see unicast IPv6 traffic between the root and the 6LR.
この仕様は、[RFC9008]を実装するネットワークで段階的に展開できます。rulsを接続するrootと6lrsのみをアップグレードする必要があります。パス上のRPLルータは、rootと6lrの間のユニキャストIPv6トラフィックのみを見るだけです。
This document is organized as follows:
この文書は次のように編成されています。
* Sections 3 and 4 present in a non-normative fashion the salient aspects of RPL and 6LoWPAN ND, respectively, that are leveraged in this specification to provide connectivity to a 6LN acting as a RUL across a RPL network.
* セクション3および4は、RPLネットワークを横切るルーブルとして機能する6LNへの接続性を提供するために、それぞれRPLおよび6LOWPAN NDの顕著な側面に存在する。
* Section 5 lists the requirements that a RUL needs to match in order to be served by a RPL router that complies with this specification.
* セクション5に、この仕様書に準拠したRPLルーターが提供するために、規則が一致する必要がある要件を示します。
* Section 6 presents the changes made to [RFC6550]; a new behavior is introduced whereby the 6LR advertises the 6LN's addresses in a RPL Destination Advertisement Object (DAO) message based on the ND registration by the 6LN, and the RPL DODAG root performs the Extended Duplicate Address Request / Extended Duplicate Address Confirmation (EDAR/EDAC) exchange with the 6LoWPAN Border Router (6LBR) on behalf of the 6LR; modifications are introduced to some RPL options and to the RPL Status to facilitate the integration of the protocols.
* セクション6は[RFC6550]に加えられた変更を示しています。6LRが6LRのND登録に基づいて6LRがRPL宛先アドレス（DAO）メッセージで6LRをアドレス指定し、RPDAGルートは拡張された重複アドレス要求/拡張された重複アドレス確認を実行します（EDAR /6LRに代わって6LOWPAN BORTHORルータ（6LBR）との交換。変更は、プロトコルの統合を容易にするために、いくつかのRPLオプションとRPLステータスに導入されます。
* Section 7 presents the changes made to [RFC9009]; the use of the Destination Cleanup Object (DCO) message is extended to the Non-Storing RPL Mode of Operation (MOP) to report asynchronous issues from the root to the 6LR.
* セクション7は[RFC9009]に加えられた変更を示しています。宛先クリーンアップオブジェクト（DCO）メッセージの使用は、ルートから6LRへの非同期の問題を報告するために、保存されていないRPLモード（MOP）に拡張されます。
* Section 8 presents the changes made to [RFC6775] and [RFC8505]; the range of the Address Registration Option / Extended Address Registration Option (ARO/EARO) Status values is reduced to 64 values, and the remaining bits in the original status field are now reserved.
* セクション8は[RFC6775]と[RFC8505]に加えられた変更を示しています。アドレス登録オプション/拡張アドレス登録オプション（ARO / EARO）ステータス値の範囲が64の値に縮小され、元のステータスフィールドの残りのビットは予約されています。
* Sections 9 and 10 present the operation of this specification for unicast and multicast flows, respectively, and Section 11 presents associated security considerations.
* セクション9および10は、それぞれユニキャストフローおよびマルチキャストフローに対するこの仕様の動作を示し、セクション11は関連するセキュリティ上の考慮事項を提示する。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the following abbreviations:
この文書は次の略語を使用します。
6BBR: 6LoWPAN Backbone Router 6CIO: 6LoWPAN Capability Indication Option 6LBR: 6LoWPAN Border Router 6LN: 6LoWPAN Node (a low-power host or router) 6LoRH: 6LoWPAN Routing Header 6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network 6LR: 6LoWPAN Router AP-ND: Address-Protected Neighbor Discovery ARO: Address Registration Option DAC: Duplicate Address Confirmation DAD: Duplicate Address Detection DAO: Destination Advertisement Object (a RPL message) DAR: Duplicate Address Request DCO: Destination Cleanup Object (a RPL message) DIO: DODAG Information Object (a RPL message) DODAG: Destination-Oriented Directed Acyclic Graph EARO: Extended Address Registration Option EDAC: Extended Duplicate Address Confirmation EDAR: Extended Duplicate Address Request EUI: Extended Unique Identifier LLN: Low-Power and Lossy Network MLD: Multicast Listener Discovery MOP: RPL Mode of Operation NA: Neighbor Advertisement NBMA: Non-Broadcast Multi-Access NCE: Neighbor Cache Entry ND: Neighbor Discovery NS: Neighbor Solicitation PIO: Prefix Information Option RA: Router Advertisement RAL: RPL-Aware Leaf RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) RH3: Routing Header for IPv6 (type 3) ROVR: Registration Ownership Verifier RPI: RPL Packet Information RPL: Routing Protocol for Low-Power and Lossy Networks RUL: RPL-Unaware Leaf SAVI: Source Address Validation Improvement SLAAC: Stateless Address Autoconfiguration SRH: Source Routing Header TID: Transaction ID (a sequence counter in the EARO) TIO: Transit Information Option
6BBR：6lowpanバックボーンルーター6CIO：6ローパン機能指示オプション6LBR：6ローパンボーダールーター6LN：6 LowPANノード（低電力ホストまたはルータ）6LLOWPAN：6LOWPANルーティングヘッダ6LOWPAN：低電力無線パーソナルエリアネットワーク6LR：6LOWPANルータAP -nd：アドレス保護隣接ディスカバリARO：アドレス登録オプションDAC：重複アドレス確認DAD：重複アドレス検出DAO：宛先アドバタイズメントオブジェクト（RPLメッセージ）DAR：重複アドレス要求DCO：宛先クリーンアップオブジェクト（RPLメッセージ）DIO： DODAG情報オブジェクト（A RPLメッセージ）DODAG：宛先指向特異的非晶系グラフEDAC：拡張されたアドレス登録オプションEDAC：拡張された重複アドレス確認EDAR：拡張された重複アドレス要求EUI：拡張固有識別子LLN：低消費電力および非損失ネットワークMLD：マルチキャストリスナー発見モップ：RPLオペレーションモードNA：ネイバーアドバタイズメントNBMA：非ブロードキャストマルチアクセスNCE：ネイバーキャッシュエントリND：ネイバーディスカバリN S：隣接勧誘PIO：プレフィックス情報オプションRA：ルータ広告RAL：RPL対応リーフRAN：RPL対応ノード（RPLルータまたはRPL認識リーフ）RH3：IPv6のルーティングヘッダー（タイプ3）ROVR：登録所有権検証者RPI：RPLパケット情報RPL：低消費電力および非損失ネットワークのルーティングプロトコル：RPL - アンウェアリーフSAVI：送信元アドレス検証改善SLAAC：ステートレスアドレス自動設定SRH：ソースルーティングヘッダTID：トランザクションID（シーケンスカウンタ）イヤー）Tio：トランジット情報オプション
The terminology used in this document is consistent with, and incorporates the terms provided in, "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]. A glossary of classical 6LoWPAN abbreviations is given in Section 2.2. Other terms in use in LLNs are found in "Terminology for Constrained-Node Networks" [RFC7228]. This specification uses the terms "6LN" and "6LR" to refer specifically to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does not expect other functionality such as 6LoWPAN Header Compression [RFC6282] from those nodes.
この文書で使用されている用語は、「低電力および非損失ネットワークのためのルーティングで使用される用語」[RFC7102]に記載されている用語を組み込んでいます。クラシック6ローパンの略語の用語集はセクション2.2に示されています。LLNで使用されている他の用語は、「制約ノードネットワークの用語」[RFC7228]にあります。この仕様書「6LN」および「6LR」という用語は、6LOWPAN NDで6LNおよび6LRロールを実装するノードを参照し、それらのノードから6LOWPANヘッダ圧縮[RFC6282]などの他の機能を期待していない。
"RPL", "RPI", "RPL Instance" (indexed by a RPLInstanceID), "up", and "down" are defined in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract information that RPL defines to be placed in data packets, e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By extension, the term "RPI" is often used to refer to the RPL Option itself. The DAO and DIO messages are also specified in [RFC6550]. The DCO message is defined in [RFC9009].
"RPL"、 "RPI"、 "RPLインスタンス"（RplinStanceIDによってインデックスされています）、 "up"、および "down"は "RPL：Low-Power Networksのルーティングプロトコル" [RFC6550]で定義されています。RPIは、RPLがIPv6ホップバイホップヘッダー内のRPLオプション[RFC6553]として、RPLがデータパケットに配置されることを定義する抽象情報です。拡張によって、「RPI」という用語は、RPLオプション自体を指すためによく使用されます。DAOメッセージとDIOメッセージも[RFC6550]に指定します。DCOメッセージは[RFC9009]で定義されています。
This document uses the terms "RUL", "RAN", and "RAL" consistently with [RFC9008]. A RAN is either a RAL or a RPL router. As opposed to a RUL, a RAN manages the reachability of its addresses and prefixes by injecting them in RPL by itself.
この文書では、「RUR」、「RAN」、および「RAL」という用語を[RFC9008]と一貫して使用します。RANはRALまたはRPLルータのいずれかです。規則とは対照的に、RANはそれ自体でRPLで注入することによってそのアドレスとプレフィックスの到達可能性を管理します。
In this document, readers will encounter terms and concepts that are discussed in the following documents:
このドキュメントでは、読者は以下の文書で説明されている用語と概念に遭遇します。
Classical IPv6 ND: "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862],
Classical IPv6 ND：「IPバージョン6（IPv6）のネイバー・ディスカバリー（IPv6）」と「IPv6ステートレスアドレス自動設定」[RFC4862]
6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], and
6LOWPAN：「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティング「【RFC6606」および「低電力無線パーソナルエリアネットワーク（6LOWPAN）（6LOWPAN）を経由して、IPv6（6LOWPAN）：概要、仮定、問題文、および目標[RFC4919]
6LoWPAN ND: "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775], "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928], and "IPv6 Backbone Router" [RFC8929].
6LOWPAN ND：「低電力無線パーソナルエリアネットワーク（6LOWPANS）「IPv6の近隣探索最適化」[RFC6775]、「低電力無線パーソナルエリアネットワークにおけるIPv6の登録拡張（6LOWPAN）近隣探索」[RFC8505]、「アドレス」 - 低電力および非損失ネットワークのための保護されたネイバーディスカバリ「[RFC8928]、および「IPv6バックボーンルータ」[RFC8929]。
RPL was initially designed to build stub networks whereby the only border router would be the RPL DODAG root (typically co-located with the 6LBR) and all the nodes in the stub would be RPL aware. But [RFC6550] was also prepared to be extended for external routes ("targets" in RPL parlance), via the External ('E') flag in the Transit Information Option (TIO). External targets provide the ability to reach destinations that are outside the RPL domain and connected to the RPL domain via RPL border routers that are not the root. Section 4.1 of [RFC9008] provides a set of rules (summarized below) that must be followed for routing packets to and from an external destination. A RUL is a special case of an external target that is also a host directly connected to the RPL domain.
RPLは、最初の境界ルータがRPDAGルート（通常は6LBRと同じ場所に配置されている）になり、スタブ内のすべてのノードがRPL認識になるようにします。しかし、[RFC6550]はまた、輸送情報オプション（TIO）の外部（ 'E'）フラグを介して外部ルート（RPLパラランスの「ターゲット」）のために拡張されるように準備されていました。外部ターゲットは、RPLドメインの外側にある送信先に到達し、ルートではないRPL境界ルータを介してRPLドメインに接続されます。[RFC9008]のセクション4.1は、外部の宛先との間のルーティングパケットをルーティングする必要がある一連の規則（以下に要約されています）を提供します。RURは、RPLドメインに直接接続されているホストである外部ターゲットの特別な場合です。
A 6LR that acts as a border router for external routes advertises them using Non-Storing mode DAO messages that are unicast directly to the root, even if the DODAG is operated in Storing mode. Non-Storing mode routes are not visible inside the RPL domain, and all packets are routed via the root. The RPL DODAG root tunnels the data packets directly to the 6LR that advertised the external route, which decapsulates and forwards the original (inner) packets.
外部ルート用のボーダールータとして機能する6LRは、ドダグが格納モードで操作されていても、ルートに直接ユニキャストされている非格納モードDAOメッセージを使用してアドバタイズします。保存されていないモードのルートはRPLドメイン内では表示されず、すべてのパケットはルートを介してルーティングされます。RPDAGルートは、外部ルートをアドバタイズした6LRに直接データパケットをトンネリングし、元の（内部）パケットをカプセル化して転送します。
The RPL Non-Storing MOP signaling and the associated IPv6-in-IPv6 encapsulated packets appear as normal traffic to the intermediate routers. Support of external routes only impacts the root and the 6LR. It can be operated with legacy intermediate routers and does not add to the amount of state that must be maintained in those routers. A RUL is an example of a destination that is reachable via an external route that happens to also be a host route.
RPL非格納MOPシグナリングと関連するIPv6-In-IPv6カプセル化パケットは、中間ルータへの通常のトラフィックとして表示されます。外部ルートのサポートはルートと6LRにのみ影響します。それはレガシ中間ルータで操作することができ、それらのルーターで維持されなければならない状態の量には追加されません。ルールは、ホストルートでも発生する外部ルートを介して到達可能な宛先の例です。
The RPL data packets typically carry a Hop-by-Hop Header with a RPL Option [RFC6553] that contains the RPI (the RPL Packet Information, as defined in Section 11.2 of [RFC6550]). Unless the RUL already placed a RPL Option in the outer header chain, the packets from and to the RUL are encapsulated using an IPv6-in-IPv6 tunnel between the root and the 6LR that serves the RUL (see Sections 7 and 8 of [RFC9008] for details). If the packet from the RUL has an RPI, the 6LR acting as a RPL border router rewrites the RPI to indicate the selected RPL Instance and set the flags, but it does not need to encapsulate the packet (see Section 9.2.2).
RPLデータパケットは通常、RPIを含むRPLオプション[RFC6553]を含むホップバイホップヘッダを搭載しています（RFC6550のセクション11.2で定義されているように、RPLパケット情報）。RURが外側のヘッダーチェーンにRPLオプションをすでに配置していない限り、ルートの間のIPv6-IN-IPv6トンネルを使用して、ルートと6LRの間のIPv6-in-IPv6トンネルを使用してカプセル化されます（RFC9008のセクション7と8を参照）。] 詳細については）。ルーからのパケットにRPIがある場合、RPLボーダールータとして機能する6LRは、選択されたRPLインスタンスを示すためにRPIを書き換えてフラグを設定しますが、パケットをカプセル化する必要はありません（セクション9.2.2を参照）。
In Non-Storing mode, packets going down the DODAG carry a Source Routing Header (SRH). The IPv6-in-IPv6 encapsulation, the RPI, and the SRH are collectively called the "RPL artifacts" and can be compressed using the method defined in [RFC8138]. Appendix A presents an example compressed format for a packet forwarded by the root to a RUL in a Storing mode DODAG.
保存されていないモードでは、パケットがDoDagをダウンロードすると、ソースルーティングヘッダ（SRH）が搭載されています。IPv6-in-IPv6カプセル化、RPI、およびSRHをまとめて「RPLアーチファクト」と呼び、[RFC8138]で定義されている方法で圧縮することができます。付録Aは、保存モードDoDag内のルートによって転送されたパケットのための圧縮フォーマットの例を示しています。
The inner packet that is forwarded to the RUL may carry some RPL artifacts, e.g., an RPI if the original packet was generated with it, and an SRH in a Non-Storing mode DODAG. [RFC9008] expects the RUL to support the basic IPv6 node requirements per [RFC8504] and, in particular, the mandates in Sections 4.2 and 4.4 of [RFC8200]. As such, the RUL is expected to ignore the RPL artifacts that may be left over -- either an SRH whose Segments Left is zero or a RPL Option in the Hop-by-Hop Header (which can be skipped when not recognized; see Section 5.3 for details).
規則に転送される内側パケットは、元のパケットがそれを用いて生成された場合、例えばRPI、および非記憶モードDoDAG内のSRHを搬送することができる。[RFC9008] RFC8504の基本的なIPv6ノード要件をサポートし、特に[RFC8200]のセクション4.2と4.4の命令をサポートすることを求めています。このように、ルーは、残っているSRHが残っているSRHまたはホップバイホップヘッダーのRPLオプション（認識されていないときにスキップすることができる）のいずれかのRPLアーチファクトを無視すると予想されます。詳細は5.3）。
A RUL is not expected to support the compression method defined in [RFC8138]. For that reason, the border router (the 6LR here) uncompresses the packet before forwarding it over an external route to a RUL [RFC9008].
[RFC8138]で定義されている圧縮方法をサポートする必要がない。そのため、境界ルータ（ここでは6LR）は、外部ルートを介してRUR [RFC9008]に転送する前にパケットを解凍します。
This section goes through the 6LoWPAN ND mechanisms that this specification leverages, as a non-normative reference to the reader. The full normative text is to be found in [RFC6775], [RFC8505], and [RFC8928].
このセクションは、この仕様が読者への非規範的な参照として、6LOWPAN NDメカニズムを通過します。完全な規範的なテキストは[RFC6775]、[RFC8505]、[RFC8928]にあります。
The classical IPv6 Neighbor Discovery (IPv6 ND) protocol [RFC4861] [RFC4862] was defined for serial links and transit media such as Ethernet. It is a reactive protocol that relies heavily on multicast operations for Address Discovery (aka address lookup) and Duplicate Address Detection (DAD).
Classical IPv6ネイバーディスカバリ（IPv6 ND）プロトコル[RFC4861] [RFC4862]は、シリアルリンクとイーサネットなどのトランジットメディアに対して定義されていました。これは、アドレス検出（AKAアドレス検索）および重複アドレス検出（DAD）のマルチキャスト操作に大きく依存する反応性プロトコルです。
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] adapts IPv6 ND for operations over energy-constrained LLNs. The main functions of [RFC6775] are to proactively establish the Neighbor Cache Entry (NCE) in the 6LR and to prevent address duplication. To that effect, [RFC6775] introduces a unicast Address Registration mechanism that contributes to reducing the use of multicast messages compared to the classical IPv6 ND protocol.
「低電力無線パーソナルエリアネットワーク（6lowpans）上のIPv6の近隣探索最適化（6lowpans）」[RFC6775]エネルギー制約LLNを介した操作のためにIPv6 NDを適応させる。[RFC6775]の主な機能は、6LRの隣接キャッシュエントリ（NCE）を積極的に確立し、アドレスの重複を防ぐことです。その効果に、[RFC6775]は、クラシックIPv6 NDプロトコルと比較してマルチキャストメッセージの使用を抑えることに貢献するユニキャストアドレス登録メカニズムを紹介します。
[RFC6775] also introduces the Address Registration Option (ARO), which is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR). It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR). In an LLN, the 6LBR is the central repository of all the Registered Addresses in its domain and the source of truth for uniqueness and ownership.
[RFC6775] 6LOWPANノード（6LN）と6LOWPANルータ（6LR）間のユニキャストネイバー勧誘（NS）およびネイバー広告（NA）メッセージで運ばれるアドレス登録オプション（ARO）を紹介します。また、6LRと6LBRの間の重複アドレス要求（DAR）と重複アドレス確認（DAC）メッセージを定義します。LLNでは、6LBRはそのドメイン内のすべての登録アドレスの中央リポジトリと、独自性と所有権のための真実の源です。
"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505] updates RFC 6775 with a generic Address Registration mechanism that can be used to access services such as routing and ND proxy functions. To that effect, [RFC8505] defines the Extended Address Registration Option (EARO), as shown in Figure 2:
「低電力無線パーソナルエリアネットワーク（6LOWPAN）近隣探索の登録拡張[RFC8505]ルーティングやNDプロキシ関数などのサービスにアクセスするために使用できる一般的なアドレス登録メカニズムでRFC 6775を更新します。その効果に、[RFC8505]は、図2に示すように、拡張アドレス登録オプション（EARO）を定義します。
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 | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO Format
図2：Earoフォーマット
[RFC8505] introduces the R flag in the EARO. The Registering Node sets the R flag to indicate whether the 6LR should ensure reachability for the Registered Address. If the R flag is set to 0, then the Registering Node handles the reachability of the Registered Address by other means. In a RPL network, this means that either it is a RAN that injects the route by itself or it uses another RPL router for reachability services.
[RFC8505] EaroにRフラグを紹介します。登録ノードは、6LRが登録アドレスの到達可能性を確保するかどうかを示すためにRフラグを設定します。Rフラグが0に設定されている場合、登録ノードは登録アドレスの到達可能性を他の手段で処理します。RPLネットワークでは、これはそれ自体でルートを挿入する、または到達可能性サービスのために別のRPLルーターを使用するRANであることを意味します。
This document specifies how the R flag is used in the context of RPL. A RPL leaf that implements the 6LN functionality from [RFC8505] requires reachability services for an IPv6 address if and only if it sets the R flag in the NS(EARO) used to register the address to a 6LR acting as a RPL border router. Upon receiving the NS(EARO), the RPL router generates a DAO message for the Registered Address if and only if the R flag is set to 1.
このドキュメントはRPLのコンテキストでRフラグがどのように使用されるかを指定します。[RFC8505]から6LN機能を実装するRPLリーフには、アドレスをRPLボーダールータとして機能する6LRに登録するために使用されるNS（EARO）にRフラグが設定されている場合に限り、IPv6アドレスの到達可能性サービスが必要です。NS（EARO）を受信すると、RPLルータは、Rフラグが1に設定されている場合に限り、登録アドレスのDAOメッセージを生成する。
Section 9.2 specifies additional operations when the R flag is set to 1 in an EARO that is placed in either an NS message or an NA message.
セクション9.2は、RフラグがNSメッセージまたはNAメッセージのいずれかに配置されているEAROの1に設定されている場合の追加操作を指定します。
When the T flag is set to 1, the EARO includes a sequence counter called the "Transaction ID" (TID), which is needed to fill the Path Sequence field in the RPL Transit Information Option (TIO). For this reason, support of [RFC8505] by the RUL, as opposed to only [RFC6775], is a prerequisite for this specification; this requirement is fully explained in Section 5.1. The EARO also transports an Opaque field and an associated "I" field that describes what the Opaque field transports and how to use it.
Tフラグが1に設定されている場合、EAROには「トランザクションID」（TID）と呼ばれるシーケンスカウンタが含まれています。これは、RPLトランジット情報オプション（TIO）のパスシーケンスフィールドを埋めるために必要です。このため、[RFC6775]のみではなく、RFC8505のサポートは、この仕様の前提条件です。この要件はセクション5.1で完全に説明されています。イヤーはまた、不透明なフィールドとそれを使う方法を説明する不透明なフィールドと関連する「i」フィールドを輸送します。
Section 9.2.1 specifies the use of the "I" field and the Opaque field by a RUL.
セクション9.2.1は、「i」フィールドと不透明フィールドのルーシングを指定します。
Section 5.3 of [RFC8505] introduces the Registration Ownership Verifier (ROVR) field, which has a variable length of 64 to 256 bits. The ROVR replaces the 64-bit Extended Unique Identifier (EUI-64) in the ARO [RFC6775], which was used to uniquely identify an Address Registration with the link-layer address of the owner but provided no protection against spoofing.
[RFC8505]のセクション5.3では、登録所有権検証者（ROVR）フィールドを紹介します。これは、1が64から256ビットの可変長です。ROVRは、ARO [RFC6775]の64ビット拡張固有ID（EUI-64）をARO [RFC6775]に置き換えます。これは、所有者のリンクレイヤアドレスに対応したものを一意に識別しますが、スプーフィングに対する保護を提供しません。
"Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928] leverages the ROVR field as a cryptographic proof of ownership to prevent a rogue third party from registering an address that is already owned. The use of the ROVR field enables the 6LR to block traffic that is not sourced at an owned address.
「低電力および非損失ネットワークのためのアドレス保護されたネイバーディスカバリ」[RFC8928] ROVRフィールドは、ローグの第三者がすでに所有されているアドレスを登録するのを防ぐために、ROVRフィールドを所有権の証明を活用します。ROVRフィールドを使用すると、6LRが所有されているアドレスで供給されていないトラフィックをブロックできます。
This specification does not address how the protection offered by [RFC8928] could be extended for use in RPL. On the other hand, it adds the ROVR to the DAO to build the proxied EDAR at the root (see Section 6.1), which means that nodes that are aware of the host route are also aware of the ROVR associated to the Target Address.
この仕様は、[RFC8928]によって提供された保護がRPLで使用するためにどのように拡張できるかには対処しません。一方、ROVRをDAOに追加して、ルートでプロキシしたEDARを構築します（セクション6.1を参照）。これは、ホストルートを認識しているノードもターゲットアドレスに関連付けられているROVRを認識していることを意味します。
[RFC8505] updates the DAR/DAC messages to EDAR/EDAC messages to carry the ROVR field. The EDAR/EDAC exchange takes place between the 6LR and the 6LBR. It is triggered by an NS(EARO) message from a 6LN to create, refresh, and delete the corresponding state in the 6LBR. The exchange is protected by the retry mechanism specified in Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1 second may be necessary to cover the round-trip delay between the 6LR and the 6LBR.
[RFC8505] DAR / DACメッセージをEDAR / EDACメッセージに更新してROVRフィールドを運びます。EDAR / EDAC交換は6LRと6LBRの間で行われます。6LNからのNS（EARO）メッセージによってトリガされ、6LBRの対応する状態を作成、更新、および削除します。Exchangeは[RFC6775]のセクション8.2.6で指定された再試行メカニズムによって保護されていますが、LLNでは、1秒のRetranStimer（RETRANS_TIMER）[RFC4861]のデフォルト値より長い期間がラウンドをカバーする必要がある場合があります。6LRと6LBRの間のストリップ遅延。
RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to the root that maintains the routing state in the RPL network for the lifetime indicated by the source of the DAO. This means that for each address, there are two keep-alive messages that traverse the whole network: one to the root and one to the 6LBR.
RPL [RFC6550] DAOのソースによって示される有効期間について、RPLネットワーク内のルーティング状態を維持するルートまで、6LNのすべての方法から定期的なDAOを指定します。つまり、各アドレスについて、ネットワーク全体をトラバースする2つのキープアライブメッセージがあります。
This specification avoids the periodic EDAR/EDAC exchange across the LLN. The 6LR turns the periodic NS(EARO) from the RUL into a DAO message to the root on every refresh, but it only generates the EDAR upon the first registration, for the purpose of DAD, which must be verified before the address is injected in RPL. Upon the DAO message, the root proxies the EDAR exchange to refresh the state at the 6LBR on behalf of the 6LR, as illustrated in Figure 8 in Section 9.1.
この仕様は、LLN全体の周期的なEDAR / EDAC交換を回避します。6LRは、RURからの定期的なNS（EARO）をREXからREFRESHのDAOメッセージに変わりますが、DADの目的で最初の登録時にEDARを生成します。これは、アドレスが注入される前に検証されなければなりません。RPL。DAOメッセージの上に、rootは、セクション9.1の図8に示すように、6LRの代わりに6LRの状態を6LRに更新するためにEDAR Exchangeをプロキシします。
"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 6LoWPAN Capability Indication Option (6CIO), which enables a node to expose its capabilities in Router Advertisement (RA) messages.
"6lowpan-GHC：低電力無線パーソナルエリアネットワーク（6lowpans）" [RFC7400] [RFC7400] [RFC7400] [RFC7400]は、ノードがルータ広告（RA）メッセージでその機能を公開できるようになります。。
[RFC8505] defines a number of bits in the 6CIO; in particular:
[RFC8505] 6CIOのビット数を定義します。特に：
L: The node is a 6LR. E: The node is an IPv6 ND Registrar -- i.e., it supports registrations based on EARO. P: The node is a Routing Registrar -- i.e., an IPv6 ND Registrar that also provides reachability services for the Registered Address.
l：ノードは6lrです。E：ノードはIPv6 NDレジストラである - すなわち、それはEAROに基づく登録をサポートする。P：ノードは、登録アドレスの到達可能性サービスも提供する、Routing Registrar - すなわちIPv6 NDレジストラである。
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 | Length = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: 6CIO Flags
図3：6 CIOフラグ
A 6LR that provides reachability services for a RUL in a RPL network as specified in this document includes a 6CIO in its RA messages and set the L, P, and E flags to 1 as prescribed by [RFC8505]; this is fully explained in Section 9.2.
この文書で指定されているRPLネットワーク内のRECの到達可能性サービスを提供する6LRは、RAメッセージ内の6CIOを含み、[RFC8505]によって規定されているように1、P、およびEのフラグを1に設定します。これはセクション9.2で詳しく説明されています。
This document describes how RPL routing can be extended to reach a RUL. This section specifies the minimal RPL-independent functionality that the RUL needs to implement in order to obtain routing services for its addresses.
この文書では、RPLルーティングを規則に到達させる方法を説明します。このセクションでは、そのアドレスのルーティングサービスを取得するためにRULが実装する必要がある最小限のRPL非依存型機能を指定します。
To obtain routing services from a router that implements this specification, a RUL needs to implement [RFC8505] and sets the "R" and "T" flags in the EARO to 1 as discussed in Sections 4.2.1 and 4.2.2, respectively. Section 9.2.1 specifies new behaviors for the RUL, e.g., when the R flag set to 1 in an NS(EARO) is not echoed in the NA(EARO), which indicates that the route injection failed.
この仕様を実装するルータからルーティングサービスを取得するには、RFC8505を実装する必要があり、それぞれセクション4.2.1および4.2.2で説明したように、EAROに "R"および "T"フラグを設定する必要があります。セクション9.2.1は、NS（EARO）の1に設定されているRフラグがNA（EARO）に設定されていない場合に、RUN（EARO）に設定されていない場合、ルーティング噴射が失敗したことを示します。
The RUL is expected to request routing services from a router only if that router originates RA messages with a 6CIO that has the L, P, and E flags all set to 1 as discussed in Section 4.3.1, unless configured to do so. It is suggested that the RUL also implement [RFC8928] to protect the ownership of its addresses.
そのルータがL、P、およびEフラグを持つ6CIOを使用してRAメッセージを開始する場合にのみ、ルーラーからルーティングサービスを要求すると予想されます。そのアドレスの所有権を保護するために、RURはまたRFC8928を実装することが示唆されています。
A RUL that may attach to multiple 6LRs is expected to prefer those that provide routing services. The RUL needs to register with all the 6LRs from which it desires routing services.
複数の6LRに添付される可能性がある規則は、ルーティングサービスを提供するものを好むことが期待されています。規則は、それがルーティングサービスを望むすべての6LRを登録する必要があります。
Parallel Address Registrations to several 6LRs should be performed in a rapid sequence, using the same EARO for the same address. Gaps between the Address Registrations will invalidate some of the routes until the Address Registration finally shows on those routes.
同じアドレスに同じELOを使用して、数6LRSへの並列アドレス登録を迅速なシーケンスで実行する必要があります。アドレス登録の間のギャップは、アドレス登録が最終的にそれらのルートに表示されるまでルートのいくつかを無効にします。
[RFC8505] introduces error Status values in the NA(EARO) that can be received synchronously upon an NS(EARO) or asynchronously. The RUL needs to support both cases and refrain from using the address when the Status value indicates a rejection (see Section 6.3).
[RFC8505] NS（EARO）または非同期的に同期して受信できるNA（EARO）にエラーステータス値を紹介します。規則は両方のケースをサポートし、ステータス値が拒否を示すときにアドレスの使用を控えてください（セクション6.3を参照）。
Section 4.1.1 of [RFC9008] defines the rules for signaling an external destination (e.g., a RUL) and tunneling to its attachment router (designated as a 6LR). In order to terminate the IPv6-in-IPv6 tunnel, the RUL, as an IPv6 host, would have to be capable of decapsulating the tunneled packet and either drop the encapsulated packet if it is not the final destination or pass it to the upper layer for further processing. As indicated in Section 4.1 of [RFC9008], this is not mandated by [RFC8504], and the IPv6-in-IPv6 tunnel from the root is terminated at the parent 6LR. It is thus not necessary for a RUL to support IPv6-in-IPv6 decapsulation.
[RFC9008]のセクション4.1.1は、外部の目的地（例えば、RUR）をシグナリングし、その添付ファイルルータ（6LRと呼ばれる）をシグナリングするための規則を定義します。IPv6-in-IPv6トンネルを終了するには、IPv6ホストとしてのルーはトンネリングパケットをカプセル化でき、カプセル化されたパケットをドロップする必要があるか、最終的な宛先ではなく上位レイヤに渡す必要があります。さらなる処理のために。[RFC9008]のセクション4.1に示されているように、これは[RFC8504]では必須ではなく、ルートからのIPv6-in-IPv6トンネルは親6LRで終了します。したがって、RULがIPv6-IN-IPv6カプセル化をサポートする必要はありません。
A RUL is expected to process an Option Type in a Hop-by-Hop Header as prescribed by Section 4.2 of [RFC8200]. An RPI with an Option Type of 0x23 [RFC9008] is thus skipped when not recognized.
[RFC8200]のセクション4.2で規定されているように、ホップごとのヘッダのオプションタイプを処理することが規定されています。したがって、オプションタイプのオプションタイプのRFC9008を持つRPIは、認識されていないときにスキップされます。
A RUL is expected to process an unknown Routing Header Type as prescribed by Section 4.4 of [RFC8200]. This implies that the SRH, which has a Routing Type of 3 [RFC6554], is ignored when Segments Left is zero. When Segments Left is non-zero, the RUL discards the packet and sends an ICMP Parameter Problem message with Code 0 to the packet's source address, pointing to the unrecognized Routing Type.
[RFC8200]のセクション4.4で規定されている未知のルーティングヘッダータイプを処理することが規定されています。これは、SRHが3 [RFC6554]のルーティングタイプを持つSRHは、セグメントがゼロのときに無視されます。セグメントがゼロ以外の場合、レーブはパケットを破棄し、認識されていないルーティングタイプを指すパケットの送信元アドレスにコード0を持つICMPパラメータ問題メッセージを送信します。
This document specifies a new behavior whereby a 6LR injects DAO messages for unicast addresses (see Section 9) and multicast addresses (see Section 10) on behalf of leaves that are not aware of RPL. The RUL addresses are exposed as external targets [RFC6550]. Conforming to [RFC9008], IPv6-in-IPv6 encapsulation between the 6LR and the RPL DODAG root is used to carry the RPL artifacts and remove them when forwarding outside the RPL domain, e.g., to a RUL.
このドキュメントは、RPLを認識していない葉を代わって、6LRがユニキャストアドレス（セクション9）およびマルチキャストアドレス（セクション9）およびマルチキャストアドレス（セクション10を参照）にDAOメッセージを挿入する（セクション10を参照）。ルグアドレスは外部ターゲット[RFC6550]として公開されています。[RFC9008]に準拠して、6LRとRPDAGルートとの間のIPv6-in-IPv6カプセル化は、RPLアーチファクトを運ぶために使用され、例えばRPLドメインの外側、例えばRULに転送するときにそれらを除去するために使用されます。
This document also synchronizes the liveness monitoring at the root and the 6LBR. The same lifetime value is used for both, and a single keep-alive message, the RPL DAO, traverses the RPL network. Another new behavior is introduced whereby the RPL DODAG root proxies the EDAR message to the 6LBR on behalf of the 6LR (see Section 8), for any leaf node that implements the 6LN functionality described in [RFC8505].
この文書はまた、ルートと6LBRの活性監視を同期します。同じ有効期間の値が両方に使用され、単一のキープアライブメッセージ、RPL DAOはRPLネットワークを通過します。[RFC8505]で説明されている6LN機能を実装する任意のリーフノードについて、RPDAGルートが6LR（8LR）に代わってEDARメッセージを6LBにプロキシします。
Section 6.7.7 of [RFC6550] introduces the RPL Target option, which can be used in RPL control messages such as the DAO message to signal a destination prefix. This document adds capabilities for transporting the ROVR field (see Section 4.2.3) and the IPv6 address of the prefix advertiser when the Target is a shorter prefix. Their use is signaled by a new ROVR Size field being non-zero and a new "Advertiser address in Full (F)" flag set to 1, respectively; see Section 6.1.
[RFC6550]のセクション6.7.7では、DAOメッセージなどのRPL制御メッセージで使用できるRPLターゲットオプションを紹介します。このドキュメントでは、ターゲットが短いプレフィックスの場合、ROVRフィールド（4.2.3項を参照）とプレフィックスアドバタイザのIPv6アドレスを転送する機能が追加されています。それらの使用は、それぞれ1に設定されている新しいROVRサイズフィールドと、それぞれ1に設定されている新しい "広告主アドレス"フラグがそれぞれシグナリングされます。セクション6.1を参照してください。
This specification defines a new flag, "Root Proxies EDAR/EDAC (P)", in the RPL DODAG Configuration option; see Section 6.2.
この仕様では、RPL DoDag設定オプションで、新しいフラグ「rootプロキシEDAR / EDAC（P）」を定義します。6.2項を参照してください。
Furthermore, this specification provides the ability to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO messages, embedded in a RPL Status; see Section 6.3.
さらに、この仕様は、RPLステータスに埋め込まれたRPL DAOメッセージおよびDCOメッセージで6LOWPAN NDに定義されたEAROステータスを持ち運ぶ機能を提供します。6.3を参照してください。
Section 12 of [RFC6550] details RPL support for multicast flows when the RPL Instance is operated with a MOP setting of 3 ("Storing Mode of Operation with multicast support"). This specification extends the RPL DODAG root operation to proxy-relay the MLDv2 operation [RFC3810] between the RUL and the 6LR; see Section 10.
[RFC6550]の第12章RPLインスタンスがMOP設定で動作しているときのマルチキャストフローのRPLサポートは、3（ "マルチキャストサポートによる動作モード"）を使用しています。この仕様は、RPDAGルート操作をRURと6LRの間のMLDV2操作[RFC3810]をプロキシリアレイに拡張します。10を参照してください。
This specification updates the RPL Target option to transport the ROVR that was also defined for 6LoWPAN ND messages. This enables the RPL DODAG root to generate the proxied EDAR message to the 6LBR.
この仕様は、6LOWPAN NDメッセージに対しても定義されたROVRを転送するためのRPLターゲットオプションを更新します。これにより、RPDAGルートはプロキシされたEDARメッセージを6LBRに生成することができます。
The Target Prefix of the RPL Target option is left (high bit) justified and contains the advertised prefix; its size may be smaller than 128 when it indicates a prefix route. The Prefix Length field signals the number of bits that correspond to the advertised prefix; it is 128 for a host route or less in the case of a prefix route. This remains unchanged.
RPLターゲットオプションのターゲットプレフィックスが残っている（ハイビット）正当化され、アドバタイズされたプレフィックスを含みます。そのサイズは、プレフィックスルートを示すときに128より小さくなる可能性があります。プレフィックス長フィールドは、アドバタイズされた接頭辞に対応するビット数です。プレフィックスルートの場合はホストルートの場合は128です。これは変わりません。
This specification defines the new 'F' flag. When it is set to 1, the size of the Target Prefix field MUST be 128 bits and it MUST contain an IPv6 address of the advertising node taken from the advertised prefix. In that case, the Target Prefix field carries two distinct pieces of information: a route that can be a host route or a prefix route, depending on the Prefix Length; and an IPv6 address that can be used to reach the advertising node and validate the route.
この仕様は新しい 'f'フラグを定義します。1に設定されている場合、ターゲットプレフィックスフィールドのサイズは128ビットでなければならず、アドバタイズされたプレフィックスから取得した広告ノードのIPv6アドレスを含める必要があります。その場合、ターゲットプレフィックスフィールドは2つの異なる情報を搬送します。プレフィックスの長さに応じて、ホストルートまたはプレフィックスルートになることができるルートです。広告ノードに到達してルートを検証するために使用できるIPv6アドレス。
If the 'F' flag is set to 0, the Target Prefix field can be shorter than 128 bits, and it MUST be aligned to the next byte boundary after the end of the prefix. Any additional bits in the rightmost octet are filled with padding bits. Padding bits are reserved and set to 0 as specified in Section 6.7.7 of [RFC6550].
'f'フラグが0に設定されている場合、ターゲットプレフィックスフィールドは128ビットより短くなる可能性があり、プレフィックスの終了後に次のバイト境界に整列している必要があります。一番右のオクテットの追加のビットはパディングビットでいっぱいです。[RFC6550]の6.7.7項で指定されているように、パディングビットは予約されて0に設定されます。
With this specification, the ROVR is the remainder of the RPL Target option. The size of the ROVR is indicated in a new ROVR Size field that is encoded to map one to one with the Code Suffix in the EDAR message (see Table 4 of [RFC8505]). The ROVR Size field is taken from the Flags field, which is an update to the "RPL Target Option Flags" IANA registry.
この仕様では、ROVRはRPLターゲットオプションの残りの部分です。ROVRのサイズは、EDARメッセージ内のコードサフィックスを使用して1に1つをマッピングするようにエンコードされた新しいROVRサイズフィールドに示されています（[RFC8505]の表4参照）。ROVRサイズフィールドはFlagsフィールドから取得されます。これは、「RPLターゲットオプションフラグ」の更新であるIANAレジストリを更新します。
The updated format is illustrated in Figure 4. It is backward compatible with the Target option defined in [RFC6550]. It is recommended that the updated format be used as a replacement in new implementations in all MOPs in preparation for upcoming route ownership validation mechanisms based on the ROVR, unless the device or the network is so constrained that this is not feasible.
更新されたフォーマットは図4に示されています。[RFC6550]で定義されているターゲットオプションと下位互換性があります。更新されたフォーマットは、ROVRに基づく次のルート所有権検証メカニズムに準拠しているすべてのMOPSの新しい実装での置き換えとして使用されることをお勧めします。
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 |F|X|Flg|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Prefix (Variable Length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Updated Target Option
図4：更新されたターゲットオプション
New fields:
新しいフィールド：
F: 1-bit flag. Set to 1 to indicate that the Target Prefix field contains the complete (128-bit) IPv6 address of the advertising node.
F：1ビットフラグ。ターゲットプレフィックスフィールドに広告ノードの完全な（128ビット）IPv6アドレスが含まれていることを示すには、1に設定します。
X: 1-bit flag. Set to 1 to request that the root perform a proxy EDAR/EDAC exchange.
x：1ビットのフラグ。ルートがプロキシEDAR / EDAC Exchangeを実行するように要求するには、1に設定します。
The 'X' flag can only be set to 1 if the DODAG is operating in Non-Storing mode and if the root sets the "Root Proxies EDAR/EDAC (P)" flag to 1 in the DODAG Configuration option; see Section 6.2.
DODAGが保存されていないモードで動作している場合は、 'x'フラグは1に設定でき、ルートがDoDag設定オプションで "rootプロキシEDAR / EDAC（P）"フラグを1に設定します。6.2項を参照してください。
The 'X' flag can be set for host routes to RULs and RANs; it can also be set for internal prefix routes if the 'F' flag is set, using the node's address in the Target Prefix field to form the EDAR, but it cannot be used otherwise.
'x'フラグは、rulsおよびransへのホストルートに設定できます。「F」フラグが設定されている場合は、「F」フラグが設定されている場合は、EDARを形成するのではなく、それ以外の場合は使用できません。
Flg (Flags): The 2 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to 0 by the sender and MUST be ignored by the receiver.
FLG（フラグ）：Flagsフィールドで未使用の2ビットはフラグ用に予約されています。フィールドは送信者によって0に初期化されなければならず、受信者によって無視される必要があります。
ROVRsz (ROVR Size): Indicates the size of the ROVR. It MUST be set to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, respectively.
ROVRSZ（ROVRサイズ）：ROVRのサイズを示します。それはそれぞれ64,128,192、または256ビットのROVRサイズを示す1,2,3、または4に設定する必要があります。
If a legacy Target option is used, then the value must remain 0, as specified in [RFC6550].
レガシターゲットオプションが使用されている場合、[RFC6550]で指定されているように、値は0のままになります。
In the case of a value above 4, the size of the ROVR is undetermined and this node cannot validate the ROVR; an implementation SHOULD propagate the whole Target option upwards as received to enable the verification by an ancestor that would support the upgraded ROVR.
4を超える値の場合、ROVRのサイズは未確定であり、このノードはROVRを検証できません。実装は、アップグレードされたROVRをサポートする祖先による検証を可能にするように受信したように、ターゲットオプション全体を上に伝播する必要があります。
Registration Ownership Verifier (ROVR): This is the same field as in the EARO; see [RFC8505].
登録所有権検証者（ROVR）：これはEaroと同じ分野です。[RFC8505]を参照してください。
The DODAG Configuration option is defined in Section 6.7.6 of [RFC6550]. Its purpose is extended to distribute configuration information affecting the construction and maintenance of the DODAG, as well as operational parameters for RPL on the DODAG, through the DODAG. This option was originally designed with four bit positions reserved for future use as flags.
DODAG設定オプションは[RFC6550]の6.7.6項で定義されています。その目的は、DODAGを介してDODAGの構造と保守に影響を与える構成情報を配布するために拡張されています。このオプションは、Flagsとして将来の使用のために予約されている4つのビット位置で最初に設計されていました。
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| |P| | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |
Figure 5: DODAG Configuration Option (Partial View)
図5：DODAG構成オプション（部分表示）
This specification defines a new flag, "Root Proxies EDAR/EDAC (P)". The 'P' flag is encoded in bit position 1 of the reserved flags in the DODAG Configuration option (counting from bit 0 as the most significant bit), and it is set to 0 in legacy implementations as specified in Sections 20.14 and 6.7.6 of [RFC6550], respectively.
この仕様では、「root Proxies Edar / EDAC（P）」という新しいフラグを定義します。'p'フラグは、DoDag設定オプション（最上位ビットとしてビット0からカウントする）の予約フラグのビット位置1でエンコードされ、セクション20.14および6.7.6で指定されているレガシー実装では0に設定されています。[RFC6550]のそれぞれ。
The 'P' flag is set to 1 to indicate that the root performs the proxy operation, which implies that it supports this specification and the updated RPL Target option (see Section 6.1).
ルートがプロキシ操作を実行することを示すために、 'p'フラグは1に設定され、この仕様と更新されたRPLターゲットオプションをサポートすることを意味します（セクション6.1を参照）。
Section 4.1.3 of [RFC9008] updates [RFC6550] to indicate that the definition of the flags applies to MOP values from zero (0) to six (6) only. For a MOP value of 7, the implementation MUST assume that the root performs the proxy operation.
[RFC9008]のセクション4.1.3 [RFC6550] [RFC6550]は、フラグの定義がゼロ（0）から6（6）のみのMOP値に適用されることを示すために。7のMOP値の場合、実装はルートがプロキシ操作を実行すると仮定する必要があります。
The RPL DODAG Configuration option is typically placed in a DODAG Information Object (DIO) message. The DIO message propagates down the DODAG to form and then maintain its structure. The DODAG Configuration option is copied unmodified from parents to children. [RFC6550] states that "Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option." Therefore, a legacy parent propagates the 'P' flag as set by the root, and when the 'P' flag is set to 1, it is transparently flooded to all the nodes in the DODAG.
RPDAG設定オプションは通常、DoDag Information Object（DIO）メッセージに配置されています。DIOメッセージはDODAGを下に伝播してその構造を維持します。DoDag設定オプションは、両親から子供に変更されずにコピーされます。[RFC6550]「DoDag構成オプションを伝播するときにDoDagルート以外のノードはこの情報を変更してはいけません」と述べています。したがって、従来の親はルートによって設定されているように「P」フラグを伝播し、「P」フラグが1に設定されていると、DODAG内のすべてのノードに透過的にフラッディングされます。
The RPL Status is defined in Section 6.5.1 of [RFC6550] for use in the DAO-ACK message. Values are assigned as follows:
RPLステータスは、DAO-ACKメッセージで使用するための[RFC6550]のセクション6.5.1で定義されています。値は次のように割り当てられます。
+---------+----------------------------------+
| Range | Meaning |
+---------+----------------------------------+
| 0 | Success / Unqualified acceptance |
+---------+----------------------------------+
| 1-127 | Not an outright rejection |
+---------+----------------------------------+
| 128-255 | Rejection |
+---------+----------------------------------+
Table 1: RPL Status per RFC 6550
表1：RFC 6550あたりのRPLステータス
The 6LoWPAN ND Status was defined for use in the EARO; see Section 4.1 of [RFC8505]. This specification adds the ability to allow the carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages, embedded in the RPL Status field.
6LOWPAN NDステータスは、ETOでの使用に定義されていました。[RFC8505]のセクション4.1を参照してください。この仕様は、RPL DAOおよびDCOメッセージで6LOWPAN NDステータス値のキャリッジを許可する機能を追加します。これはRPLステータスフィールドに埋め込まれています。
To achieve this, the range of the ARO/EARO Status values is reduced to 0-63, which updates the IANA registry created for [RFC6775]. This reduction ensures that the values fit within a RPL Status as shown in Figure 6. See Sections 12.2, 12.5, and 12.6 for the respective IANA declarations. These updates are reasonable because the associated registry relies on the Standards Action policy [RFC8126] for registration and only values up to 10 are currently allocated.
これを実現するために、ARO / EAROステータス値の範囲は0から63に減らされ、[RFC6775]で作成されたIANAレジストリが更新されます。この減少により、図6に示すように値がRPLステータスに収まるようになります。各IANA宣言については、セクション12.2,12.5、および12.6を参照してください。関連付けられているレジストリは、登録のために標準アクションポリシー[RFC8126]に依存しているため、これらの更新は合理的です。これは現在最大10の値だけです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|A|StatusValue|
+-+-+-+-+-+-+-+-+
Figure 6: RPL Status Format
図6：RPLステータスフォーマット
This specification updates the RPL Status with the following subfields:
この仕様は、次のサブフィールドでRPLステータスを更新します。
U: 1-bit flag. Set to 1 to indicate a rejection. When set to 0, a Status value of 0 indicates Success / Unqualified acceptance and other values indicate "Not an outright rejection" as per RFC 6550.
U：1ビットフラグ。拒否を示すために1に設定してください。0に設定すると、0のステータス値は成功/非修飾の受け入れを示し、他の値はRFC 6550に従って「完全な拒否ではない」と示しています。
A: 1-bit flag. Indicates the type of the RPL Status value.
A：1ビットのフラグ。RPLステータス値のタイプを示します。
Status Value: 6-bit unsigned integer.
ステータス値：6ビット符号なし整数。
If the 'A' flag is set to 1, this field transports a value defined for the 6LoWPAN ND EARO Status.
'a'フラグが1に設定されている場合、このフィールドは6lowpan ND Earoステータスに定義されている値を転送します。
When the 'A' flag is set to 0, this field transports a Status value defined for RPL.
'A'フラグが0に設定されていると、このフィールドはRPLに定義されているステータス値を転送します。
When building a DCO or a DAO-ACK message upon an IPv6 ND NA or an EDAC message, the RPL DODAG root MUST copy the 6LoWPAN ND status code unchanged in the RPL Status Value field and set the 'A' flag to 1. The RPL DODAG root MUST set the 'U' flag to 1 for all rejection and unknown status codes. The status codes in the 1-10 range [RFC8505] are all considered rejections.
DCOまたはDAO-ACKメッセージをIPv6 ND NAまたはEDACメッセージに構築するとき、RPDAGルートはRPLステータス値フィールドで変更されずに6LOWPAN NDステータスコードをコピーし、 'A'フラグを1に設定する必要があります。DoDagルートは、すべての拒否コードと不明なステータスコードについて、 'u'フラグを1に設定する必要があります。1-10範囲[RFC8505]のステータスコードはすべて拒否と見なされます。
Reciprocally, upon a DCO or a DAO-ACK message from the RPL DODAG root with a RPL Status that has the 'A' flag set, the 6LR MUST copy the RPL Status value unchanged in the Status field of the EARO when generating an NA to the RUL.
相互に、「A」フラグセットを持つRPLステータスを持つRPCODAGルートからのDCOまたはDAO-ACKメッセージの上に、6LRは、NAを生成するときにEAROのステータスフィールドでRPLステータス値をコピーする必要があります。ルーズ。
[RFC9009] defines the DCO message for RPL Storing mode only, with a link-local scope. All nodes in the RPL network are expected to support the specification, since the message is processed hop by hop along the path that is being cleaned up.
[RFC9009] LINGローカルスコープを使用して、RPL格納モードのDCOメッセージを定義します。メッセージはクリーンアップされているパスに沿ってホップでホップされるので、RPLネットワーク内のすべてのノードは仕様をサポートすることが予想されます。
This specification extends the use of the DCO message to the Non-Storing MOP, whereby the DCO is sent end to end by the root directly to the RAN that injected the DAO message for the considered target. In that case, intermediate nodes do not need to support [RFC9009]; they forward the DCO message as a plain IPv6 packet between the root and the RAN.
この仕様は、DCOメッセージの使用を非格納モップへの使用を拡張することで、DCOは、検討されたターゲットのDAOメッセージを注入するRANに直接終了して送信されます。その場合、中間ノードは[RFC9009]をサポートする必要はありません。DCOメッセージをルートとRAN間の普通のIPv6パケットとして転送します。
In the case of a RUL, the 6LR that serves the RUL acts as the RAN that receives the Non-Storing DCO. This specification leverages the Non-Storing DCO between the root and the 6LR that serves as the attachment router for a RUL. A 6LR and a root that support this specification MUST implement the Non-Storing DCO.
規則の場合、規則を処理する6LRは、保存されていないDCOを受信するRANとして機能します。この仕様は、ルートと6LRとの間の非格納DCOを、添付ファイルルータとして機能する。この仕様をサポートする6LRとルートは、保存されていないDCOを実装する必要があります。
This document updates [RFC6775] and [RFC8505] to reduce the range of the ARO/EARO Status values to 64 values. The two most significant (leftmost) bits of the original ND Status field are now reserved; they MUST be set to 0 by the sender and ignored by the receiver.
この文書は[RFC6775]と[RFC8505]を更新して、ARO / EAROステータス値の範囲を64の値に縮小します。元のNDステータスフィールドの2つの最上位（左端）ビットが予約されています。それらは送信者によって0に設定され、受信者によって無視されなければなりません。
This document also updates the behavior of a 6LR acting as a RPL router and of a 6LN acting as a RUL in the 6LoWPAN ND Address Registration as follows:
この文書はまた、RPLルータとして機能する6LRの動作を更新し、6lowpan NDアドレス登録のルーとして機能する6LNの動作を次のように更新します。
* If the RPL DODAG root advertises the ability to proxy the EDAR/ EDAC exchange to the 6LBR, the 6LR refrains from sending the keep-alive EDAR message. If it is separated from the 6LBR, the root regenerates the EDAR message to the 6LBR periodically, upon a DAO message that signals the liveliness of the address.
* RPDAGルートがEDAR / EDAC交換を6LBRにプロキシする機能をアドバタイズした場合、6LRはキープアライブEDARメッセージの送信を控えます。それが6LBRから分離されている場合、ルートはアドレスの活動性を知らせるDAOメッセージの上に、EDARメッセージを定期的に再生する。
* The use of the R flag is extended to the NA(EARO) to confirm whether the route was installed.
* Rフラグを使用すると、ルートがインストールされているかどうかを確認するためにNA（EURO）に拡張されます。
The description below assumes that the root sets the 'P' flag in the DODAG Configuration option and performs the EDAR proxy operation presented in Section 4.3.
以下の説明では、ルートはDoDag構成オプションで 'P'フラグを設定し、セクション4.3に示されているEDARプロキシ操作を実行します。
If the 'P' flag is set to 0, the 6LR MUST generate the periodic EDAR messages and process the returned status as specified in [RFC8505]. If the EDAC indicates success, the rest of the flow takes place as presented but without the proxied EDAR/EDAC exchange.
'p'フラグが0に設定されている場合、6LRは定期的なEDARメッセージを生成し、[RFC8505]で指定された状態に戻った状態を処理する必要があります。EDACが成功を示す場合、フローの残りのフローは提示されたがプロキシを付けられたEDAR / EDAC Exchangeがありません。
Section 9.1 provides an overview of the route injection in RPL, whereas Section 9.2 offers more details from the perspective of the different nodes involved in the flow.
セクション9.1はRPLでのルートインジェクションの概要を示しているが、セクション9.2はフローに含まれるさまざまなノードの観点からより多くの詳細を提供します。
This specification eliminates the need to exchange keep-alive EDAR and EDAC messages all the way from a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange with the 6LBR is proxied by the RPL DODAG root upon the DAO message that refreshes the RPL routing state. The first EDAR upon a new Address Registration cannot be proxied, though, as it is generated for the purpose of DAD, which must be verified before the address is injected in RPL.
この仕様では、RPLメッシュ全体で6LNから6LBRへのキープアライブEDARおよびEDACメッセージをすべて交換する必要がなくなります。代わりに、6LBRとのEDAR / EDAC Exchangeは、RPLルーティング状態を更新するDAOメッセージにRPDAGルートによってプロキシされています。新しいアドレス登録時の最初のEDARは、DADの目的のために生成されるため、RPLでアドレスが注入される前に検証されなければならないので、プロキシを処理することはできません。
In a RPL network where the function is enabled, refreshing the state in the 6LBR is the responsibility of the root. Consequently, only addresses that are injected in RPL will be kept alive at the 6LBR by the RPL DODAG root. Since RULs are advertised using Non-Storing mode, the DAO message flow and the keep-alive EDAR/EDAC can be nested within the Address (re)Registration flow. Figure 7 illustrates that, for the first Address Registration, both the DAD and the keep-alive EDAR/EDAC exchanges happen in the same sequence.
機能が有効になっているRPLネットワークでは、6LBRの状態をリフレッシュすることは、ルートの責任です。その結果、RPLで注入されているアドレスのみが、RPL DODAGルートによって6LBRで生存しています。RULSは非記憶モードを使用してアドバタイズされているので、DAOメッセージフローとキープアライブEDAR / EDACをアドレス（RE）登録フロー内にネストすることができます。図7は、第1のアドレス登録について、DADとキープアライブEDAR / EDAC交換の両方が同じシーケンスで発生することを示している。
6LN/RUL 6LR <6LR*> Root 6LBR
|<---Using ND--->|<--Using RPL->|<-----Using ND---->|
| |<-----------Using ND------------->|
| | | |
| NS(EARO) | | |
|--------------->| |
| | EDAR |
| |--------------------------------->|
| | |
| | EDAC |
| |<---------------------------------|
| | |
| | DAO(X=0) | |
| |------------->| |
| | |
| | DAO-ACK | |
| |<-------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 7: First RUL Registration Flow
図7：最初のrug登録フロー
This flow requires that the lifetimes and sequence counters in 6LoWPAN ND and RPL be aligned.
このフローでは、6LOWPAN NDとRPL内の寿命およびシーケンスカウンタを整列させる必要があります。
To achieve this, the Path Sequence and the Path Lifetime in the DAO message are taken from the Transaction ID and the Address Registration lifetime in the NS(EARO) message from the 6LN.
これを達成するために、DAOメッセージ内のパスシーケンスとパス寿命は、6LNからのNS（EARO）メッセージのトランザクションIDおよびアドレス登録寿命から取得される。
On the first Address Registration, illustrated in Figure 7 for RPL Non-Storing mode, the EDAR/EDAC exchange takes place as prescribed by [RFC8505]. If the exchange fails, the 6LR returns an NA message with a non-zero status to the 6LN, the NCE is not created, and the address is not injected in RPL. Otherwise, the 6LR creates an NCE and injects the Registered Address in the RPL routing using a DAO/DAO-ACK exchange with the RPL DODAG root.
RPL以外の記憶モードの図7に示す第1のアドレス登録では、EDAR / EDAC交換は[RFC8505]で規定されているように行われる。Exchangeが失敗した場合、6LRはゼロ以外のステータスを6LNに返し、NCEは作成されず、アドレスはRPLに注入されません。それ以外の場合、6LRはNCEを作成し、RPDAGルートとDAO / DAO-ACK交換を使用してRPLルーティング内の登録アドレスを挿入します。
An Address Registration refresh is performed by the 6LN to keep the NCE in the 6LR alive before the lifetime expires. Upon the refresh of a registration, the 6LR reinjects the corresponding route in RPL before it expires, as illustrated in Figure 8.
有効期限が切れる前に、6LRのNCEを6LRに保つために、アドレス登録リフレッシュが6LNによって実行されます。登録が更新されると、6LRは、図8に示すように、期限切れになる前にRPL内の対応する経路を再確認します。
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | DAO(X=1) | |
| |------------->| |
| | | EDAR |
| | |------------------>|
| | | EDAC |
| | |<------------------|
| | DAO-ACK | |
| |<-------------| |
| NA(EARO) | | |
|<---------------| | |
Figure 8: Next RUL Registration Flow
図8：次の規則登録フロー
This is what causes the RPL DODAG root to refresh the state in the 6LBR, using an EDAC message. In the case of an error in the proxied EDAR flow, the error is returned in the DAO-ACK using a RPL Status with the 'A' flag set to 1, which embeds a 6LoWPAN Status value as discussed in Section 6.3.
これが、edacメッセージを使用して、RPDAG Rootを6LBRの状態を更新する原因となるものです。プロキシされたEDARフローのエラーの場合、 'A'フラグが1に設定されたRPLステータスを使用してDAO-ACKにエラーが返され、6LOWPANステータス値を埋め込み、6Lowpanステータス値が埋め込まれます。
The 6LR may receive a requested DAO-ACK after it received an asynchronous Non-Storing DCO, but the non-zero status in the DCO supersedes a positive status in the DAO-ACK, regardless of the order in which they are received. Upon the DAO-ACK -- or the DCO, if one arrives first -- the 6LR responds to the RUL with an NA(EARO).
6LRは、非同期非記憶DCOを受信した後に要求されたDAO - ACKを受信することができるが、DCO内のゼロ以外のステータスは、それらが受信される順序にかかわらず、DAO - ACK内の正のステータスに優先される。DAO-ACK - またはDCOの上に、最初に到着した場合、6LRはNA（EARO）を持つルーブルに応答します。
An issue may be detected later, e.g., the address moves to a different DODAG with the 6LBR attached to a different 6LoWPAN Backbone Router (6BBR); see Figure 5 in Section 3.3 of [RFC8929]. The 6BBR may send a negative ND Status, e.g., in an asynchronous NA(EARO) to the 6LBR.
問題は、後で検出されてもよく、例えば、アドレスは異なる6LOWPANバックボーンルータ（6BBR）に接続された6LBRを有する異なるDODAGに移動する。[RFC8929]の3.3項の図5を参照してください。6BBRは、否定的なNDステータスを、例えば非同期NA（EARO）に6LBRに送信することができる。
[RFC8929] expects that the 6LBR is co-located with the RPL DODAG root, but if not, the 6LBR MUST forward the status code to the originator of the EDAR -- either the 6LR or the RPL DODAG root that proxies for it. The ND status code is mapped in a RPL Status value by the RPL DODAG root, and then back to an ND Status by the 6LR to the 6LN. Note that a legacy RAN that receives a Non-Storing DCO that it does not support will ignore it silently, as specified in Section 6 of [RFC6550]. The result is that it will remain unaware that it is no longer reachable until its next RPL exchange happens. This situation will be cleared upon the next Non-Storing DAO exchange if the error is returned in a DAO-ACK.
[RFC8929] 6LBRがRPL DODAGルートと同じ場所にあることを期待していますが、そうでない場合、6LBはステータスコードをEDARのオリジネータに転送しなければなりません - 6LRまたはそれのプロキシのRPL DODAGルートのいずれかです。NDステータスコードは、RPDAGルートによってRPLステータス値でマッピングされ、次に6LRで6LRまでのNDステータスに戻ります。[RFC6550]のセクション6では、サポートされていない非保存DCOを受信するレガシRANは静かに無視されます。その結果、その次のRPL交換が行われるまで、それがもはや到達できないことに気付かないということです。DAO-ACKにエラーが返されると、この状況は次の非保存DAO交換時にクリアされます。
Figure 9 illustrates this in the case where the 6LBR and the root are not co-located, and the root proxies the EDAR/EDAC flow.
図9は、6LBRとルートが同じ場所に配置されておらず、rootがEDAR / EDACフローをプロキシした場合の図である。
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR
| | | | |
| | | | NA(EARO) |
| | | |<------------|
| | | EDAC | |
| | |<-------------| |
| | DCO | | |
| |<------------| | |
| NA(EARO) | | | |
|<-------------| | | |
| | | | |
Figure 9: Asynchronous Issue
図9：非同期の問題
If the root does not proxy, then the EDAC with a non-zero status reaches the 6LR directly. In that case, the 6LR MUST clean up the route using a DAO with a Lifetime of 0, and it MUST propagate the status back to the RUL in an NA(EARO) with the R flag set to 0.
ルートがプロキシしない場合、ゼロ以外のステータスのEDACは直接6LRに達します。その場合、6LRは存続時間0のDAOを使用してルートをクリーンアップする必要があり、Rフラグが0に設定されている状態でNA（EARO）の規則に戻る必要があります。
The RUL may terminate the registration at any time by using a Registration Lifetime of 0. This specification requires that the RPL Target option transport the ROVR. This way, the same flow as the heartbeat flow is sufficient to inform the 6LBR using the root as a proxy, as illustrated in Figure 8.
RUGは、登録寿命を使用して常に登録を終了させることができます。この仕様では、RPLターゲットオプションがROVRを輸送する必要があります。このようにして、図8に示すように、6LBRをプロキシとして使用して6LBRに通知するのに十分である。
All or any combination of the 6LR, the root, and the 6LBR might be collapsed in a single node.
6LR、ルート、および6LBRの全部または任意の組み合わせは、単一のノードで折りたたまれる可能性があります。
The following sections specify the behavior of (1) the 6LN acting as a RUL, (2) the 6LR acting as a border router and serving the 6LN, (3) the RPL DODAG root, and (4) the 6LBR in the control flows that enable RPL routing back to the RUL, respectively.
以下のセクションでは、（1）6LNがルーとして機能し、（2）ボーダールータとして機能し、6LR、（3）RPL DODAGルート、および（4）コントロールフローの6LBを処理します。それはそれぞれRPLルーティングをそれぞれルーティングします。
This specification builds on the operation of a 6LoWPAN ND-compliant 6LN/RUL, which is expected to operate as follows:
この仕様は、6LOWPAN ND準拠の6LN / RURの動作について説明します。これは次のように動作する予定です。
1. The 6LN selects a 6LR that provides reachability services for a RUL. This is signaled by a 6CIO in the RA messages with the L, P, and E flags set to 1 as prescribed by [RFC8505].
1. 6LNは、reachの到達可能性サービスを提供する6LRを選択します。これは、RA、P、およびEフラグが1に設定されているRAメッセージ内の6CIOによって、[RFC8505]によって指定されています。
2. The 6LN obtains an IPv6 global address, via either (1) Stateless Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix Information Option (PIO) [RFC4861] found in an RA message or (2) some other means, such as DHCPv6 [RFC8415].
2. 6LNは、RAメッセージで見つかったプレフィックス情報オプション（PIO）[RFC4861]に基づいて（1）ステートレスアドレス自動設定（SLAAC）[RFC4862]を経由して、（1）ステートレスアドレス自動アドレス（SLAAC）[RFC4862]を介して、DHCPv6などの他の手段[RFC8415]。
3. Once it has formed an address, the 6LN registers its address and refreshes its registration periodically, early enough within the lifetime of the previous Address Registration, as prescribed by [RFC6775], to refresh the NCE before the lifetime indicated in the EARO expires. It sets the T flag to 1 as prescribed in [RFC8505]. The TID is incremented each time and wraps in a lollipop fashion (see Section 5.2.1 of [RFC8505], which is fully compatible with Section 7.2 of [RFC6550]).
3. アドレスを作成すると、6LNはそのアドレスを登録し、[RFC6775]で規定されているように、[RFC6775]によって規定されているように、前回のアドレス登録の有効期間内に十分に登録を更新して、EAROに示されている寿命が切れる前にNCEをリフレッシュします。Tフラグを[RFC8505]に規定されているように1に設定します。TIDは毎回増分され、LollIPOPファッションでラップされます（[RFC6550]のセクション7.2と完全に互換性がある[RFC8505]のセクション5.2.1を参照）。
4. As stated in Section 5.2 of [RFC8505], the 6LN can register with more than one 6LR at the same time. In that case, all the fields in the EARO are set to the same value for all of the parallel Address Registrations, with the exception of the Registration Lifetime field and the R flag, which may be set to different values. The 6LN may cancel a subset of its registrations or may transfer a registration from one or more old 6LRs to one or more new 6LRs. To do so, the 6LN sends a series of NS(EARO) messages, all with the same TID, with a zero Registration Lifetime to the old 6LR(s) and with a non-zero Registration Lifetime to the new 6LR(s). In that process, the 6LN SHOULD send the NS(EARO) with a non-zero Registration Lifetime and ensure that at least one succeeds before it sends an NS(EARO) that terminates another registration. This avoids the churn related to transient route invalidation in the RPL network above the common parent of the involved 6LRs.
4. [RFC8505]のセクション5.2に記載されているように、6LNは同時に1つ以上の6LRに登録できます。その場合、登録寿命フィールドとRフラグを除いて、EARO内のすべてのフィールドはすべてのパラレルアドレス登録に対して同じ値に設定されます。これは異なる値に設定されます。6LNはその登録のサブセットをキャンセルすることができ、あるいは1つ以上の古い6LRから1つまたは複数の新しい6LRSへの登録を転送することができる。そうするために、6LNは、同じTIDを持つ一連のNS（EARO）メッセージを、ゼロ登録寿命をゼロにゼロ6LR（S）に送信し、NEW 6LRにゼロ以外の登録寿命を送信します。そのプロセスでは、6LNはNS（EARO）をゼロ以外の登録寿命で送信し、もう1つの登録を終了するNS（EARO）を送信する前に少なくとも1つ成功するようにしてください。これにより、関与した6LRの共通の親の上のRPLネットワークにおける一時的なルート無効化に関連するクチャンが回避されます。
5. Following Section 5.1 of [RFC8505], a 6LN acting as a RUL sets the R flag in the EARO of its registration(s) for which it requires routing services. If the R flag is not echoed in the NA, the RUL MUST assume that establishing the routing services via this 6LR failed, and it SHOULD attempt to use another 6LR. The RUL SHOULD ensure that one registration succeeds before setting the R flag to 0. In the case of a conflict with the preceding rule regarding the lifetime, the rule regarding the lifetime has precedence.
5. [RFC8505]のセクション5.1では、ルーティングサービスが必要な登録のEaroにRフラグを設定します。RフラグがNAでエコーされていない場合、ルールはこの6LRを介してルーティングサービスを確立したと仮定しなければならず、さらに6LRを使用しようとしなければなりません。REURは、RFフラグを0に設定する前に1つの登録が成功することを確実にしておくべきです。
6. The 6LN may use any of the 6LRs to which it registered as the default gateway. Using a 6LR to which the 6LN is not registered may result in packets dropped at the 6LR by a Source Address Validation Improvement (SAVI) function [RFC7039] and thus is not recommended.
6. 6LNは、デフォルトゲートウェイとして登録されている6LRのいずれかを使用できます。6LNが登録されていない6LRを使用すると、送信元アドレス検証改善（SAVI）機能[RFC7039]によって6LRでパケットが削除される可能性があります。
Even without support for RPL, the RUL may be configured with an opaque value to be provided to the routing protocol. If the RUL has knowledge of the RPL Instance into which the packet should be injected, then it SHOULD set the Opaque field in the EARO to the RPLInstanceID; otherwise, it MUST leave the Opaque field as 0.
RPLをサポートしなくても、ルーティングプロトコルに提供される不透明な値で規則を構成することができる。規則がパケットが注入されるべきRPLインスタンスに関する知識を持っている場合、それはEaro内の不透明フィールドをRPLINSTANCEIDに設定する必要があります。それ以外の場合は、不透明フィールドを0として残す必要があります。
Regardless of the setting of the Opaque field, the 6LN MUST set the "I" field to 0 to signal "topological information to be passed to a routing process", as specified in Section 5.1 of [RFC8505].
不透明フィールドの設定にかかわらず、[RFC8505]のセクション5.1のセクション5.1で指定されているように、6LNは「i」フィールドを0に設定する必要があります。
A RUL is not expected to produce RPL artifacts in the data packets, but it may do so. For instance, if the RUL has minimal awareness of the RPL Instance, then it can build an RPI. A RUL that places an RPI in a data packet SHOULD indicate the RPLInstanceID of the RPL Instance where the packet should be forwarded. It is up to the 6LR (e.g., by policy) to use the RPLInstanceID information provided by the RUL or rewrite it to the selected RPLInstanceID for forwarding inside the RPL domain. All the flags and the SenderRank field are set to 0 as specified by Section 11.2 of [RFC6550].
データパケットにRPLアーティファクトを生成することは規則は見られないが、そうすることができる。たとえば、RULがRPLインスタンスの認識が最小限に抑えられている場合は、RPIを構築できます。データパケットにRPIを配置するRURは、パケットを転送する必要があるRPLインスタンスのRPLINSTANCEIDを指定する必要があります。RURによって提供されたRPLINSTANCEID情報を使用するか、RPLドメイン内で転送するために選択されたRPLINSTANCEIDに書き換えることは、6LR（例えばポリシー別）次第です。[RFC6550]のセクション11.2で指定されているように、すべてのフラグとSenderRankフィールドが0に設定されています。
A 6LR that provides reachability services for a RUL in a RPL network as specified in this document MUST include a 6CIO in its RA messages and set the L, P, and E flags to 1 as prescribed by [RFC8505].
この文書で指定されているRPネットワーク内のRURの到達可能性サービスを提供する6LRは、RAメッセージに6CIOを含め、[RFC8505]によって規定されているように1、P、およびEのフラグを1に設定する必要があります。
As prescribed by [RFC8505], the 6LR generates an EDAR message upon reception of a valid NS(EARO) message for the registration of a new IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds, then the 6LR installs an NCE for the Registration Lifetime.
[RFC8505]に規定されているように、6LRは、6LNで新しいIPv6アドレスを登録するために有効なNS（EARO）メッセージを受信したときにEDARメッセージを生成します。最初のEDAR / EDAC Exchangeが成功した場合、6LRは登録寿命にNCEをインストールします。
If the R flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the host route in RPL, unless this is barred for other reasons, such as the saturation of the RPL parents. The 6LR MUST use RPL Non-Storing mode signaling and the updated Target option (see Section 6.1). To avoid a redundant EDAR/EDAC flow to the 6LBR, the 6LR SHOULD refrain from setting the 'X' flag. The 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO message. Successfully injecting the route to the RUL's address will be indicated via the 'U' flag set to 0 in the RPL Status of the DAO-ACK message.
RフラグがNS（EARO）で1に設定されている場合、RPL親の飽和などの他の理由で禁止されていない限り、6LRはRPLのホストルートを注入する必要があります。6LRはRPL非記憶モードシグナリングと更新されたターゲットオプションを使用する必要があります（セクション6.1を参照）。6LBRへの冗長なEDAR / EDACの流れを回避するために、6LRは 'x'フラグの設定を控えるべきです。6LRはDAOメッセージに 'k'フラグを設定することによってDAO-ACKを要求する必要があります。RURのアドレスへのルートを正常に注入することは、DAO-ACKメッセージのRPLステータスで0に設定された 'u'フラグを介して表示されます。
For the registration refreshes, if the RPL DODAG root sets the 'P' flag in the DODAG Configuration option to 1, then the 6LR MUST refrain from sending the keep-alive EDAR; instead, it MUST set the 'X' flag to 1 in the Target option of the DAO messages, to request that the root proxy the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6); if the 'P' flag is set to 0, then the 6LR MUST set the 'X' flag to 0 and handle the EDAR/EDAC flow itself.
登録の更新の場合、RPDAGのルートがDoDag構成オプションで 'P'フラグを1に設定した場合、6LRはキープアライブEDARの送信を控えなければなりません。代わりに、DAOメッセージのターゲットオプションで 'X'フラグを1に設定し、6LBRとのキープアライブEDAR / EDAC交換を要求する必要があります（セクション6を参照）。'p'フラグが0に設定されている場合、6LRは 'x'フラグを0に設定し、EDAR / EDACフロー自体を処理する必要があります。
The Opaque field in the EARO provides a means to signal which RPL Instance is to be used for the DAO advertisements and the forwarding of packets sourced at the Registered Address when there is no RPI in the packet.
イヤーの不透明フィールドは、パケットにRPIがないときに、どのRPLインスタンスをDAOアドバタイズメントと登録アドレスに供給されたパケットの転送とのかをシグナルにするための手段を提供する。
As described in [RFC8505], if the "I" field is 0, then the Opaque field is expected to carry the RPLInstanceID suggested by the 6LN; otherwise, there is no suggested RPL Instance. If the 6LR participates in the suggested RPL Instance, then the 6LR MUST use that RPL Instance for the Registered Address.
[RFC8505]に記載されているように、「I」フィールドが0の場合、不透明フィールドは6LNによって示唆されたRPLINSTANCEIDを運ぶことが予想される。それ以外の場合は、推奨されるRPLインスタンスはありません。6LRが推奨されたRPLインスタンスに参加した場合、6LRは登録アドレスにそのRPLインスタンスを使用する必要があります。
If there is no suggested RPL Instance or if the 6LR does not participate in the suggested RPL Instance, it is expected that the packets coming from the 6LN "can unambiguously be associated to at least one RPL Instance" [RFC6550] by the 6LR, e.g., using a policy that maps the 6-tuple to a RPL Instance.
推奨されたRPLインスタンスがない場合、または6LRが推奨されたRPLインスタンスに参加していない場合、6LRからのパケットは6LRによって少なくとも1つのRPLインスタンスに著しく関連付けられていることができることが予想されます。、6タプルをRPLインスタンスにマッピングするポリシーを使用します。
The DAO message advertising the Registered Address MUST be constructed as follows:
登録アドレスを広告するDAOメッセージは次のように構成する必要があります。
1. The Registered Address is signaled as the Target Prefix in the updated Target option in the DAO message; the Prefix Length is set to 128 but the 'F' flag is set to 0, since the advertiser is not the RUL. The ROVR field is copied unchanged from the EARO (see Section 6.1).
1. 登録されたアドレスは、DAOメッセージの更新されたターゲットオプションのターゲットプレフィックスとしてシグナリングされます。プレフィックス長は128に設定されていますが、広告主はRUREではないため、 'F'フラグは0に設定されています。ROVRフィールドはEAROから変更されずにコピーされます（6.1節を参照）。
2. The 6LR indicates one of its global or unique-local IPv6 unicast addresses as the Parent Address in the TIO associated with the Target option.
2. 6LRは、ターゲットオプションに関連付けられているTIOの親アドレスとして、グローバルまたは一意のローカルIPv6ユニキャストアドレスの1つを示します。
3. The 6LR sets the External ('E') flag in the TIO to indicate that it is redistributing an external target into the RPL network.
3. 6LRは、LPLネットワークに外部ターゲットを再配布することを示すために、TIO内の外部（ 'E'）フラグを設定します。
4. The Path Lifetime in the TIO is computed from the Registration Lifetime in the EARO. This operation converts seconds to the Lifetime Units used in the RPL operation. This creates the deployment constraint that the Lifetime Unit is reasonably compatible with the expression of the Registration Lifetime; e.g., a Lifetime Unit of 0x4000 maps the most significant byte of the Registration Lifetime to the Path Lifetime.
4. TIO内の経路寿命は、イヤーの登録寿命から計算されます。この操作は、RPL操作で使用されている有効期間単位に秒数を変換します。これにより、ライフタイムユニットが登録有効期間の式とかなり互換性があるという展開制約が作成されます。例えば、0x4000の寿命単位は、登録寿命の最上位バイトを経路寿命にマッピングする。
In that operation, the Path Lifetime must be set to ensure that the path has a longer lifetime than the registration and also covers the round-trip time to the root.
その操作では、パスの有効期間を設定するように設定する必要があります。これは、パスが登録よりも寿命が長く、rootへの往復時間をカバーするように設定する必要があります。
Note that if the Registration Lifetime is 0, then the Path Lifetime is also 0 and the DAO message becomes a No-Path DAO, which cleans up the routes down to the RUL's address; this also causes the root as a proxy to send an EDAR message to the 6LBR with a Lifetime of 0.
登録寿命が0の場合、パスの有効期間も0で、DAOメッセージはNo-Path DAOになります。これはまた、reseを6LBRに送信して存続期間0の0を送信します。
5. The Path Sequence in the TIO is set to the TID value found in the EARO.
5. TIO内のパスシーケンスは、イヤーにあるTID値に設定されています。
Upon receiving or timing out the DAO-ACK after an implementation-specific number of retries, the 6LR MUST send the corresponding NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, it MUST send an asynchronous NA(EARO) to the RUL immediately but still be capable of processing the DAO-ACK if one is pending.
実装固有の再試行回数の後にDAO-ACKを受信またはタイムアウトすると、6LRは対応するNA（EARO）をルーに送信しなければなりません。非同期DCOメッセージを受信すると、それはすぐに非同期NA（EARO）を直ちに保留中の場合はDAO-ACKを処理することができます。
The 6LR MUST set the R flag to 1 in the NA(EARO) that it sends back to the 6LN if and only if the 'U' flag in the RPL Status is set to 0, indicating that the 6LR injected the Registered Address in the RPL routing successfully and that the EDAR proxy operation succeeded.
6LRは、6LRの場合にのみ、RPLステータスの「u」フラグが0に設定されている場合に限らず、6LRが0に設定されている場合に限り、NA（Earo）にRフラグを1に設定する必要があります。RPLルーティングは正常に、そしてEDARプロキシ操作が成功したこと。
If the 'A' flag in the RPL Status is set to 1, the embedded Status value is passed back to the RUL in the EARO Status. If the 'U' flag is also set to 1, the registration failed for 6LoWPAN-ND-related reasons, and the NCE is removed.
RPLステータスの「a」フラグが1に設定されている場合、埋め込みステータス値はEAROステータスのRURに返されます。'u'フラグも1に設定されている場合、登録は6lowpan-nd関連の理由で失敗し、NCEが削除されます。
An error injecting the route causes the 'U' flag to be set to 1. If the error is not related to ND, the 'A' flag is set to 0. In that case, the registration succeeds, but the RPL route is not installed. So, the NA(EARO) is returned with a status indicating success but the R flag set to 0, which means that the 6LN obtained a binding but no route.
ルートを注入するエラーが発生すると、「u」のフラグが1に設定されます。エラーがNDと関連しない場合、 'A'フラグは0に設定されます。その場合、登録は成功しますが、RPLルートは成功しませんが、RPLルートは成功しません。取り付けられています。したがって、NA（EARO）は成功を示すステータスで返されますが、Rフラグは0に設定されています。これは、6LNがバインディングを取得したがルートがないことを意味します。
If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success) MUST be returned to the 6LN. The EARO Status of 0 MUST also be used if the 6LR did not attempt to inject the route but could create the binding after a successful EDAR/EDAC exchange or refresh it.
DAO-ACKのRPLステータスで 'a'フラグが0に設定されている場合、6LOWPAN ND操作は成功し、6LNにイヤーステータス0（成功）を返す必要があります。6LRがその経路を挿入しようとしていないが、EDAR / EDAC Exchangeの再生後にバインディングを作成することはできない場合は、0のELOステータスを使用する必要があります。
If the 'U' flag is set to 1 in the RPL Status of the DAO-ACK, then the route was not installed, and the R flag MUST be set to 0 in the NA(EARO). The R flag MUST be set to 0 if the 6LR did not attempt to inject the route.
DAO-ACKのRPLステータスで 'u'フラグが1に設定されている場合、ルートはインストールされず、RA（Earo）でRフラグを0に設定する必要があります。6LRがルートを挿入しようとしなかった場合は、Rフラグを0に設定する必要があります。
In a network where Address-Protected Neighbor Discovery (AP-ND) is enabled, in the case of a DAO-ACK or a DCO transporting an EARO Status value of 5 (Validation Requested), the 6LR MUST challenge the 6LN for ownership of the address, as described in Section 6.1 of [RFC8928], before the registration is complete. This flow, illustrated in Figure 10, ensures that the address is validated before it is injected in the RPL routing.
アドレス保護されたネイバーディスカバリ（AP-ND）が有効になっているネットワークでは、DAO-ACKまたはDCOの場合は、5（検証要求）のELOステータス値を輸送する（検証要求）、6LRは6LNに挑戦しなければなりません。登録が完了する前に、[RFC8928]のセクション6.1に記載されているように、アドレス。図10に示すこのフローでは、RPLルーティングに注入される前にアドレスが検証されるようになります。
6LN 6LR Root 6LBR
| | | |
|<--------------- RA ---------------------| | |
| | | |
|------ NS(EARO) (ROVR=Crypto-ID) ------->| | |
| | | |
|<-NA(EARO) (Status=Validation Requested)-| | |
| | | |
|---- NS(EARO) and proof of ownership --->| | |
| | | |
| <validate the proof> | |
| | |
|<------- NA(EARO) (Status=10) -----<if failed> | |
| | |
| <else> | |
| | | |
| |--------- EDAR ------->|
| | |
| |<-------- EDAC --------|
| | |
| | | |
| |-DAO(X=0)->| |
| | | |
| |<- DAO-ACK-| |
| | | |
|<---------- NA(EARO) (Status=0) ---------| | |
| | | |
...
| | | |
|------ NS(EARO) (ROVR=Crypto-ID) ------->| | |
| |-DAO(X=1)->| |
| | |-- EDAR -->|
| | | |
| | |<-- EDAC --|
| |<- DAO-ACK-| |
|<---------- NA(EARO) (Status=0) ---------| | |
| | | |
...
Figure 10: Address Protection
図10：アドレス保護
If the challenge succeeded, then the operations continue as normal. In particular, a DAO message is generated upon the NS(EARO) that proves the ownership of the address. If the challenge failed, the 6LR rejects the registration as prescribed by AP-ND and may take actions to protect itself against Denial-Of-Service (DoS) attacks by a rogue 6LN; see Section 11.
チャレンジが成功した場合、その操作は通常どおり続きます。特に、DAOメッセージは、アドレスの所有権を証明するNS（EARO）に生成されます。チャレンジが失敗した場合、6LRはAP-NDによって規定されているように登録を拒否し、不正6LNによるサービス拒否（DOS）攻撃に対して自分自身を保護するための行動を起こす可能性があります。11を参照してください。
The 6LR may, at any time, send a unicast asynchronous NA(EARO) with the R flag set to 0 to signal that it has stopped providing routing services, and/or with an EARO Status of 2 (Neighbor Cache Full) to signal that it removed the NCE. It may also send a final RA -- unicast or multicast -- with a router Lifetime field of 0, to signal that it will cease to serve as the router, as specified in Section 6.2.5 of [RFC4861]. This may happen upon a DCO or a DAO-ACK message indicating that the path is already removed; otherwise, the 6LR MUST remove the host route to the 6LN using a DAO message with a Path Lifetime of 0.
6LRは、いつでも、Rルーティングサービスの提供を停止していること、および/または2（近隣キャッシュフル）のELOステータスを停止した状態で、RAXを0に設定してユニキャスト非同期NA（EARO）を送信してもよい。それはNCEを削除しました。[RFC4861]のセクション6.2.5で指定されているように、ルータの有効期間フィールドを使用して、最後のRA-UnicastまたはMulticastを送信することもできます。これは、パスがすでに削除されていることを示すDCOまたはDAO-ACKメッセージで発生する可能性があります。それ以外の場合、6LRは、PAT LIFETIME 0のDAOメッセージを使用してホストルートを6LNに削除する必要があります。
A valid NS(EARO) message with the R flag set to 0 and a Registration Lifetime that is not zero signals that the 6LN wishes to maintain the binding but does not require (i.e., no longer requires) the routing services from the 6LR. Upon this message, if, due to a previous NS(EARO) with the R flag set to 1 the 6LR was injecting the host route to the Registered Address in RPL using DAO messages, then the 6LR MUST invalidate the host route in RPL using a DAO with a Path Lifetime of 0. It is up to the registering 6LN to maintain the corresponding route from then on, by either (1) keeping it active via a different 6LR or (2) acting as a RAN and managing its own reachability.
Rフラグが0に設定された有効なNS（EARO）メッセージ、6LNがバインディングを維持したいが、6LRからのルーティングサービスを必要としない（すなわち、はもはや必要としない）信号が0に設定されている（登録寿命）。このメッセージの上に、Rフラグが1に設定されている前のNS（EARO）のために、6LRがDAOメッセージを使用してRPLの登録アドレスにホストルートを挿入している場合、6LRはRPLのホストルートを無効にする必要があります。パスの寿命を持つDAO 0の存続時間は、次に、対応するルートを維持するための6LN次第です。（1）異なる6LRまたは（2）を介してアクティブに保ち、RANとして機能し、独自の到達可能性を管理します。
When forwarding a packet from the RUL into the RPL domain, if the packet does not have an RPI, the 6LR MUST encapsulate the packet to the root and add an RPI. If there is an RPI in the packet, the 6LR MUST rewrite the RPI, but it does not need to encapsulate.
パケットをRULドメインに転送するときに、パケットにRPIがない場合、6LRはパケットをルートにカプセル化してRPIを追加する必要があります。パケットにRPIがある場合、6LRはRPIを書き換える必要がありますが、カプセル化する必要はありません。
A RPL DODAG root MUST set the 'P' flag to 1 in the RPL DODAG Configuration option of the DIO messages that it generates (see Section 6) to signal that it proxies the EDAR/EDAC exchange and supports the updated RPL Target option.
RPDAGルートは、生成したDIOメッセージのRPDAG設定オプション（セクション6を参照）の「P」フラグを1に設定する必要があります（セクション6を参照）、EDAR / EDAC Exchangeをプロキシし、更新されたRPLターゲットオプションをサポートしています。
Upon reception of a DAO message, for each updated RPL Target option (see Section 6.1) with the 'X' flag set to 1, the root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange; if the RPL DODAG root and the 6LBR are integrated, an internal API can be used instead.
DAOメッセージを受信すると、更新されたRPLターゲットオプション（セクション6.1を参照）1に設定されている「x」フラグが1に設定されている場合、プロキシされたEDAR / EDAC Exchangeを使用して6LBRに通知する必要があります。RPDAGルートと6LBRが統合されている場合は、代わりに内部APIを使用できます。
The EDAR message MUST be constructed as follows:
EDARメッセージは次のように構築する必要があります。
1. The target IPv6 address from the RPL Target option is placed in the Registered Address field of the EDAR message;
1. RPLターゲットオプションからのターゲットIPv6アドレスは、EDARメッセージの登録済みアドレスフィールドに配置されます。
2. The Registration Lifetime is adapted from the Path Lifetime in the TIO by converting the Lifetime Units used in RPL into units of 60 seconds used in the 6LoWPAN ND messages;
2. 登録寿命は、RPLで使用されている寿命単位を6lowpan NDメッセージで使用されている60秒単位に変換することによって、TIOの経路寿命から適応されます。
3. The TID value is set to the Path Sequence in the TIO and indicated with an ICMP code of 1 in the EDAR message;
3. TID値はTIO内のパスシーケンスに設定され、EDARメッセージ内のICMPコード1で示されます。
4. The ROVR in the RPL Target option is copied as is in the EDAR, and the ICMP Code Suffix is set to the appropriate value as shown in Table 4 of [RFC8505], depending on the size of the ROVR field.
4. RPRターゲットオプションのROVRはEDARのようにコピーされ、ROVRフィールドのサイズに応じて[RFC8505]の表4に示すように、[RFC8505]の表4に示すように適切な値に設定されます。
Upon receiving an EDAC message from the 6LBR, if a DAO is pending, then the root MUST send a DAO-ACK back to the 6LR. Otherwise, if the status in the EDAC message is not "Success", then it MUST send an asynchronous DCO to the 6LR.
6LBRからのEDACメッセージを受信すると、DAOが保留中の場合、ルートはDAO-ACKを6LRに戻す必要があります。それ以外の場合、EDACメッセージ内のステータスが「成功」でない場合は、非同期DCOを6LRに送信する必要があります。
In either case, the EDAC Status is embedded in the RPL Status with the 'A' flag set to 1.
いずれの場合も、EDACステータスは「a」フラグが1に設定された状態でRPLステータスに埋め込まれています。
The proxied EDAR/EDAC exchange MUST be protected with a timer whose appropriate duration and number of retries (1) are implementation dependent and (2) SHOULD be configurable, since the root and the 6LBR are typically nodes with a higher capacity and manageability than 6LRs. Upon timing out, the root MUST send an error back to the 6LR as above, using either a DAO-ACK or a DCO, as appropriate, with the 'A' and 'U' flags set to 1 in the RPL Status, and a RPL Status value of "6LBR Registry Saturated" [RFC8505].
プロキシされたEDAR / EDAC Exchangeは、適切な期間および再試行回数（1）の数が実装に依存し、（2）が設定可能であるタイマーで保護する必要があります。ルートと6LBRは通常6LRよりも高い容量と管理性を持つノードです。。タイムアウトすると、ルートは上記のように6LRにエラーを返信しなければなりません。RPLステータス値「6LBRレジストリ飽和」[RFC8505]。
The 6LBR is unaware that the RPL DODAG root is not the new attachment 6LR of the RUL, so it is not impacted by this specification.
6LBRは、RPL DODAGルートがRURの新しい添付ファイル6LRではないことに気付いているので、この仕様の影響は影響しません。
Upon reception of an EDAR message, the 6LBR behaves as prescribed by [RFC8505] and returns an EDAC message to the sender.
EDARメッセージを受信すると、6LBRは[RFC8505]で規定されているとおりに動作し、送信者にEDACメッセージを返します。
Section 12 of [RFC6550] details RPL support for multicast flows. This support is activated by setting the MOP value to 3 ("Storing Mode of Operation with multicast support") in the DIO messages that form the DODAG. This section also applies if and only if the MOP of the RPL Instance is 3.
[RFC6550]のセクション12マルチキャストフローのRPLサポートの詳細。このサポートは、DODAGを形成するDIOメッセージ内のMOP値を3に設定することによって起動されます（マルチキャストサポートによる操作モードの操作モード）。このセクションでは、RPLインスタンスのMOPが3の場合に限ります。
RPL support for multicast is not source specific and only operates as an extension to the Storing mode of operation for unicast packets. Note that it is the RPL model that the multicast packet is copied and transmitted as a Layer 2 unicast to each of the interested children. This remains true when forwarding between the 6LR and the listener 6LN.
マルチキャストのRPLサポートはソース固有ではなく、ユニキャストパケットの保存動作モードへの拡張としてのみ動作します。マルチキャストパケットがコピーされ、それぞれの興味のある子どもの間のレイヤ2ユニキャストとして送信されるRPLモデルです。これは、6LRとリスナー6LNを転送するときに存在します。
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] provides an interface for a listener to register with multicast flows. In the MLD model, the router is a "querier", and the host is a multicast listener that registers with the querier to obtain copies of the particular flows it is interested in.
"IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）" [RFC3810]は、リスナーがマルチキャストフローに登録するためのインタフェースを提供します。MLDモデルでは、ルータは「クエリア」で、ホストはクエリアに登録して興味のあるフローのコピーを取得するマルチキャストリスナーです。
The equivalent of the first Address Registration happens as illustrated in Figure 11. The 6LN, as an MLD listener, sends an unsolicited Report to the 6LR. This enables it to start receiving the flow immediately and causes the 6LR to inject the multicast route in RPL.
図11に示すように、最初のアドレス登録と同等のものが発生します.6LNは、MLDリスナーとして、未承諾のレポートを6LRに送信します。これにより、直ちにフローの受信を開始し、6LRがRPL内のマルチキャストルートを注入させます。
6LN/RUL 6LR Root 6LBR
| | | |
| unsolicited Report | | |
|------------------->| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | <if not done already> |
| | | unsolicited Report |
| | |---------------------->|
| | | |
Figure 11: First Multicast Registration Flow
図11：最初のマルチキャスト登録フロー
This specification does not change MLD but will operate more efficiently if the asynchronous messages for unsolicited Report and Done are sent by the 6LN as Layer 2 unicast to the 6LR, particularly on wireless.
この仕様はMLDを変更しませんが、迷惑な報告書の非同期メッセージが6LNによって6LLとして6LR、特にワイヤレス上の6LRに送信される場合は、より効率的に動作します。
The 6LR acts as a generic MLD querier and generates a DAO with the multicast address as the Target Prefix as described in Section 12 of [RFC6550]. As for the unicast host routes, the Path Lifetime associated to the Target is mapped from the Query Interval and is set to be larger, to account for variable propagation delays to the root. The root proxies the MLD exchange as a listener with the 6LBR acting as the querier, so as to get packets from a source external to the RPL domain.
6LRは汎用MLDクエリアとして機能し、[RFC6550]のセクション12で説明されているように、ターゲットプレフィックスとしてマルチキャストアドレスを持つDAOを生成します。ユニキャストホストルートに関しては、ターゲットに関連付けられているパスライフタイムはクエリ間隔からマッピングされ、rootの可変伝播遅延を考慮して大きくなるように設定されます。ルートは、RPLドメインの外部からのソースからパケットを取得するために、クエリアとして機能する6LBRを使用してMLD Exchangeをリスナとしてプロキシします。
Upon a DAO with a Target option for a multicast address, the RPL DODAG root checks to see if it is already registered as a listener for that address, and if not, it performs its own unsolicited Report for the multicast address as described in Section 6.1 of [RFC3810]. The Report is source independent, so there is no source address listed.
マルチキャストアドレスのターゲットオプションを持つDAOに、RPDAGルートは、そのアドレスのリスナーとしてすでに登録されているかどうかを確認します。[RFC3810]の。レポートはソースに依存しないため、ソースアドレスがリストされていません。
The equivalent of the registration refresh is pulled periodically by the 6LR acting as the querier. Upon the timing out of the Query Interval, the 6LR sends a Multicast Address Specific Query to each of its listeners, for each multicast address. The listeners respond with a Report. Based on the Reports, the 6LR maintains the aggregated list of all the multicast addresses for which there is a listener and advertises them using DAO messages as specified in Section 12 of [RFC6550]. Optionally, the 6LR MAY send a General Query, where the Multicast Address field is set to 0. In that case, the multicast packet is passed as a Layer 2 unicast to each of the interested children.
登録リフレッシュと同等のものは、クエリアとして機能する6LRによって定期的に引っ張られます。クエリ間隔からタイミングが切り離されると、6LRは、マルチキャストアドレスごとに、各リスナーにマルチキャストアドレス固有のクエリを送信します。リスナーはレポートで応答します。レポートに基づいて、6LRはリスナーがあるすべてのマルチキャストアドレスの集約リストを管理し、[RFC6550]のセクション12で指定されているDAOメッセージを使用してアドバタイズします。任意選択で、6LRは一般的なクエリを送信することができ、マルチキャストアドレスフィールドは0に設定されることがあるので、マルチキャストパケットは、興味のある子どもの各々にレイヤ2ユニキャストとして渡される。
Upon a Report, the 6LR generates a DAO with as many Target options as there are Multicast Address Records in the Report message, copying the Multicast Address field in the Target Prefix of the RPL Target option. The DAO message is a Storing mode DAO, passed to a selection of the 6LR's parents.
レポートになると、6LRはレポートメッセージにマルチキャストアドレスレコードがあるため、多くのターゲットオプションを持つDAOを生成し、RPLターゲットオプションのターゲットプレフィックスにマルチキャストアドレスフィールドをコピーします。DAOメッセージは、6LRの両親の選択に渡された格納モードDAOです。
Asynchronously to this, a similar procedure happens between the root and a router, such as the 6LBR, that serves multicast flows on the link where the root is located. Again, the Query and Report messages are source independent. The root lists exactly once each multicast address for which it has at least one active multicast DAO state, copying the multicast address in the DAO state in the Multicast Address field of the Multicast Address Records in the Report message.
これに非同期的には、ルートと6LBRなどのルータとの間で同様の手順が発生します。これは、ルートが配置されているリンク上のマルチキャストフローを提供します。繰り返しますが、クエリメッセージとレポートメッセージはソースに依存しません。ルートは、それが少なくとも1つのアクティブなマルチキャストDAO状態を持ち、Reportメッセージ内のマルチキャストアドレスレコードのマルチキャストアドレスフィールドにマルチキャストアドレスをコピーする各マルチキャストアドレスを正確にリストします。
This is illustrated in Figure 12:
これは図12に示されています。
6LN/RUL 6LR Root 6LBR
| | | |
| Query | | |
|<-------------------| | |
| Report | | |
|------------------->| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | Query |
| | |<-------------------|
| | | Report |
| | |------------------->|
| | | |
Figure 12: Next Registration Flow
図12：次の登録フロー
Note that all or any combination of the 6LR, the root, and the 6LBR might be collapsed in a single node, in which case the flow above happens internally, and possibly through internal API calls as opposed to messaging.
6LR、ルート、および6LBRのすべてまたは任意の組み合わせが単一のノードで折りたたまれる可能性があるため、上記のフローは内部的に、場合によってはメッセージングとは対照的に内部API呼び出しを介して行われます。
It is worth noting that with [RFC6550], every node in the LLN is RPL aware and can inject any RPL-based attack in the network. This specification improves this situation by isolating edge nodes that can only interact with the RPL routers using 6LoWPAN ND, meaning that they cannot perform RPL insider attacks.
[RFC6550]では、LLN内のすべてのノードがRPL認識であり、ネットワーク内でRPLベースの攻撃を注入できることは注目に値します。この仕様は、6LOWPAN NDを使用してRPLルータと対話できるエッジノードを分離することで、この状況を改善します。つまり、RPLインサイダー攻撃を実行できません。
The LLN nodes depend on the 6LBR and the RPL participants for their operation. A trust model must be put in place to ensure that the right devices are acting in these roles, so as to avoid such threats as black-holing (see Section 7 of [RFC7416]), DoS attacks whereby a rogue 6LR creates a high churn in the RPL network by advertising and removing many forged addresses, or a bombing attack whereby an impersonated 6LBR would destroy state in the network by using a status code of 4 ("Removed") [RFC8505].
LLNノードは、6LBRおよびRPL参加者に依存している。ブラックホールとのような脅威を回避するために、このような脅威を回避するために、信頼モデルを設置する必要があります（[RFC7416]のセクション7を参照）、Rogue 6LRが高いチャーンを作成するDOS攻撃RPLネットワークでは、多くの偽アドレスを広告して削除することによって、または偽装された6LBRは、ステータスコード4（「削除」）[RFC8505]を使用してネットワーク内の状態を破壊することになります。
This trust model could be, at a minimum, based on Layer 2 secure joining and link-layer security. This is a generic 6LoWPAN requirement; see Req-5.1 in Appendix B.5 of [RFC8505].
この信頼モデルは、レイヤ2のセキュアソリュー化とリンク層のセキュリティに基づいて、最低でもよい。これは一般的な6lowpan要件です。[RFC8505]の付録B.5のREQ-5.1を参照してください。
In a general manner, the Security Considerations sections of [RFC6550], [RFC7416], [RFC6775], and [RFC8505] apply to this specification as well.
一般的な方法では、[RFC6550]、[RFC7416]、[RFC6775]、[RFC8505]のセキュリティ上の考察セクションもこの仕様にも適用されます。
In particular, link-layer security is needed to prevent DoS attacks whereby a rogue 6LN creates a high churn in the RPL network by constantly registering and deregistering addresses with the R flag set to 1 in the EARO.
特に、DOS攻撃を防ぐためには、RPLネットワークでRPLネットワークで高チャーンを作成するために、RPLネットワークで高チャーンを作成するのを防ぐために必要なセキュリティが必要です。
[RFC8928] updated 6LoWPAN ND with AP-ND. AP-ND protects the owner of an address against address theft and impersonation attacks in an LLN. Nodes supporting the extension compute a cryptographic identifier (Crypto-ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing SAVI. [RFC8928] reduces even further the attack perimeter that is available to the edge nodes, and its use is suggested in this specification.
[RFC8928] AP-NDで6LOWPAN NDを更新しました。AP-NDは、アドレスの盗難および導入攻撃に対してアドレスの所有者をLLNに保護します。拡張子をサポートするノードは暗号識別子（暗号ID）を計算し、1つ以上の登録アドレスを使用して使用します。暗号IDは登録アドレスの所有者を識別し、登録アドレスの所有権の証明を提供するために使用できます。アドレスが暗号IDと所有権の証明に登録されると、そのアドレスの所有者だけが登録情報を変更することができ、それによってSAVIを強制することができます。[RFC8928]エッジノードが利用できる攻撃周囲をさらに縮小し、その使用がこの仕様で提案されています。
Additionally, the trust model could include role validation (e.g., using role-based authorization) to ensure that the node that claims to be a 6LBR or a RPL DODAG root is entitled to do so.
さらに、信頼モデルには、6LBRまたはRPL DODAGルートであると主張するノードがそうする権利があることを確認するために、ロール検証（例えば、役割ベースの承認を使用）を含めることができます。
The Opaque field in the EARO enables the RUL to suggest a RPLInstanceID where its traffic is placed. It is also possible for an attacker RUL to include an RPI in the packet. This opens the door to attacks where a RPL Instance would be reserved for critical traffic, e.g., with a specific bandwidth reservation, that the additional traffic generated by a rogue may disrupt. The attack may be alleviated by traditional access control and traffic-shaping mechanisms where the 6LR controls the incoming traffic from the 6LN. More importantly, the 6LR is the node that injects the traffic in the RPL domain, so it has the final word on which RPL Instance is to be used for the traffic coming from the RUL, per its own policy. In particular, a policy can override the formal language that forces the use of the Opaque field or the rewriting of the RPI provided by the RUL, in a situation where the network administrator finds it relevant.
EAROの不透明フィールドは、そのトラフィックが配置されているRPLINSTANCEIDIDを示唆することができます。攻撃者の規則がパケット内にRPIを含めることも可能である。これにより、RPLインスタンスが重要なトラフィックのために、例えば、不正に生成された追加のトラフィックが破壊される可能性があるという攻撃の扉を開きます。攻撃は、6LRが6LNから入ってくるトラフィックを制御する従来のアクセス制御およびトラフィックシェーピングメカニズムによって軽減され得る。さらに重要なことに、6LRはRPLドメイン内のトラフィックを注入するノードであるため、RPLインスタンスを自分のポリシーごとにルーブルから使用するトラフィックに使用する最後のワードがあります。特に、ネットワーク管理者が関連性があると判断した状況で、不透明フィールドの使用またはRPIの書き換えを強制する正式な言語を上書きすることができます。
At the time of this writing, RPL does not have a route ownership validation model whereby it is possible to validate the origin of an address that is injected in a DAO. This specification makes a first step in that direction by allowing the root to challenge the RUL via the 6LR that serves it.
この書き込み時に、RPLにはルート所有権検証モデルがありません。これにより、DAOに注入されたアドレスの原点を検証することが可能です。この仕様は、それを提供する6LRを介してルートがルートに挑戦することを可能にすることによってその方向に最初のステップを作ります。
Section 6.1 indicates that when the length of the ROVR field is unknown, the RPL Target option must be passed on as received in RPL Storing mode. This creates a possible opening for using DAO messages as a covert channel. Note that DAO messages are rare, and overusing that channel could be detected. An implementation SHOULD notify the network management system when a RPL Target option is received with an unknown ROVR field size, to ensure that the network administrator is aware of the situation.
セクション6.1は、ROVRフィールドの長さが不明な場合、RPL格納モードで受信したようにRPLターゲットオプションを渡す必要があることを示します。これにより、CovertチャネルとしてDAOメッセージを使用するための可能な開口部が作成されます。DAOメッセージはまれであり、そのチャネルが検出されたことを非常に使いやすくすることに注意してください。ネットワーク管理者が状況を認識していることを確認するために、RPLターゲットオプションが不明なROVRフィールドサイズで受信されたときに実装がネットワーク管理システムに通知する必要があります。
[RFC9009] introduces the ability for a rogue common ancestor node to invalidate a route on behalf of the target node. In this case, the RPL Status in the DCO has the 'A' flag set to 0, and an NA(EARO) is returned to the 6LN with the R flag set to 0. This encourages the 6LN to try another 6LR. If a 6LR exists that does not use the rogue common ancestor, then the 6LN will eventually succeed gaining reachability over the RPL network in spite of the rogue node.
[RFC9009]は、不正な共通の先祖ノードがターゲットノードに代わってルートを無効にする機能を紹介します。この場合、DCO内のRPLステータスは0に設定されていて、RA（EARO）が0に設定されている6LNに戻されます。これにより、6LNがさらに6LRを試すように促進されます。不正な共通の祖先を使用しない6LRが存在する場合、6LNは最終的には不正ノードにもかかわらずRPLネットワーク上で到達可能性を得ることに成功するでしょう。
Section 9.1 of [RFC8505] created a registry for the 8-bit Address Registration Option Flags field. IANA has renamed the first column of the table from "ARO Status" to "Bit Number".
[RFC8505]のセクション9.1は、8ビットアドレス登録オプションフラグフィールドのレジストリを作成しました。IANAは、テーブルの最初の列を「ARO STATUS」から「ビット数」に変更しました。
Section 12 of [RFC6775] created the "Address Registration Option Status Values" registry with a range of 0-255.
[RFC6775]のセクション12は、0~255の範囲の「アドレス登録オプションステータス値」レジストリを作成しました。
This specification reduces that range to 0-63; see Section 6.3.
この仕様はその範囲を0から63に減らします。6.3を参照してください。
IANA has modified the "Address Registration Option Status Values" registry so that the upper bound of the unassigned values is 63. This document has been added as a reference. The registration procedure has not changed.
IANAは、未割り当て値の上限が63であるように、「アドレス登録オプションステータス値」レジストリを変更しました。この文書は参照として追加されました。登録手順は変更されていません。
IANA has assigned the following flag in the "DODAG Configuration Option Flags for MOP 0..6" registry [RFC9008]:
IANAは「MOP 0..6」レジストリ[RFC9008]の「DODAG構成オプションフラグ」に次のフラグを割り当てました。
+------------+----------------------------+-----------+
| Bit Number | Capability Description | Reference |
+------------+----------------------------+-----------+
| 1 | Root Proxies EDAR/EDAC (P) | RFC 9010 |
+------------+----------------------------+-----------+
Table 2: New DODAG Configuration Option Flag
表2：新しいDoDag設定オプションのフラグ
IANA has added this document as a reference for MOP 7 in the RPL "Mode of Operation" registry.
IANAはこの文書をRPLの「操作モード」レジストリのMOP 7の参照として追加しました。
This document modifies the "RPL Target Option Flags" registry initially created per Section 20.15 of [RFC6550]. The registry now includes only 4 bits (Section 6.1) and lists this document as an additional reference. The registration procedure has not changed.
この文書は、[RFC6550]のセクション20.15ごとに最初に作成された「RPLターゲットオプションフラグ」レジストリを変更します。レジストリには4ビットしか含まれていません（セクション6.1）、この文書を追加の参照としてリストします。登録手順は変更されていません。
Section 6.1 also defines two new entries in the registry, as follows:
セクション6.1は、次のように、レジストリ内の2つの新しいエントリも定義されています。
+------------+--------------------------------+-----------+
| Bit Number | Capability Description | Reference |
+------------+--------------------------------+-----------+
| 0 | Advertiser address in Full (F) | RFC 9010 |
+------------+--------------------------------+-----------+
| 1 | Proxy EDAR Requested (X) | RFC 9010 |
+------------+--------------------------------+-----------+
Table 3: RPL Target Option Flags Registry
表3：RPLターゲットオプションフラグレジストリ
IANA has created a new subregistry for the RPL Non-Rejection Status values for use in the RPL DAO-ACK, DCO, and DCO-ACK messages with the 'A' flag set to 0 and the 'U' flag set to 1, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
IANAは、RPL DAO-ACK、DCO、およびDCO-ACKメッセージで使用するためのRPL非拒否ステータス値のための新しいサブレジストを作成しました。「低電力および非損失ネットワーク（RPL）」レジストリの「ルーティングプロトコル」。
* Possible values are 6-bit unsigned integers (0..63).
* 可能な値は6ビットの符号なし整数（0..63）です。
* The registration procedure is IETF Review [RFC8126].
* 登録手順はIETFレビュー[RFC8126]です。
* The initial allocation is as indicated in Table 4:
* 初期割り当ては表4に示されているとおりです。
+-------+----------------------------------+---------------------+
| Value | Meaning | Reference |
+-------+----------------------------------+---------------------+
| 0 | Success / Unqualified acceptance | RFC 6550 / RFC 9010 |
+-------+----------------------------------+---------------------+
| 1..63 | Unassigned | |
+-------+----------------------------------+---------------------+
Table 4: Acceptance Values of the RPL Status
表4：RPLステータスの受け入れ値
IANA has created a new subregistry for the RPL Rejection Status values for use in the RPL DAO-ACK and DCO messages with the 'A' flag set to 0 and the 'U' flag set to 1, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
IANAはRPL DAO-ACKおよびDCOメッセージで使用するためのRPL拒否ステータス値のための新しいサブレジストを作成しました。そして、非損失ネットワーク（RPL） "レジストリ。
* Possible values are 6-bit unsigned integers (0..63).
* 可能な値は6ビットの符号なし整数（0..63）です。
* The registration procedure is IETF Review [RFC8126].
* 登録手順はIETFレビュー[RFC8126]です。
* The initial allocation is as indicated in Table 5:
* 初期割り当ては表5に示されているとおりです。
+-------+-----------------------+-----------+
| Value | Meaning | Reference |
+-------+-----------------------+-----------+
| 0 | Unqualified rejection | RFC 9010 |
+-------+-----------------------+-----------+
| 1 | No routing entry | RFC 9009 |
+-------+-----------------------+-----------+
| 2..63 | Unassigned | |
+-------+-----------------------+-----------+
Table 5: Rejection Values of the RPL Status
表5：RPLステータスの拒否値
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.
[RFC3810] VIDA、R.、ED。L. Costa、Ed。、「IPv6のマルチキャストリスナー発見バージョン2（MLDV2）、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<https：//www.rfc-editor.org/info/rfc3810>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、ED。、Thubert、P.、Ed。、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR.RPL：低消費電力ネットワークの「RPL：IPv6ルーティングプロトコル」、RFC 6550、DOI 10.17487 / RFC6550、2012年3月、<https：//www.rfc-editor.org/info/RFC6550>。
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.
[RFC6775] Shelby、Z.、ED。、Chakrabarti、S.、Nordmark、E.、およびC. Bormann、「低電力無線パーソナルエリアネットワークにおけるIPv6の近隣探索最適化（6lowpans）」、RFC 6775、DOI 10.17487/ RFC6775、2012年11月、<https://www.rfc-editor.org/info/rfc6775>。
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7102] Vasseur、JP。、「低電力および非損失ネットワークのためのルーティングで使用される用語」、RFC 7102、DOI 10.17487 / RFC7102、2014年1月、<https：//www.rfc-editor.org/info/rfc7102>。
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC7400] Bormann、C、 "6lowpan-GHC：低電力無線パーソナルエリアネットワーク（6lowpans）"、RFC 7400、DOI 10.17487 / RFC7400、2014年11月、<https：//www.rfc-editor.org/info/rfc7400>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] The'th、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https：//www.rfc-editor.org/ info / rfc8200>。
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8504] Chown、T.、Loughney、J.、およびT.Winters、「IPv6ノード要件」、BCP 220、RFC 8504、DOI 10.17487 / RFC8504、2019年1月、<https：//www.rfc-editor.org/ info / rfc8504>。
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.
[RFC8505] Thubert、P.、Ed。、Nordmark、E.、Chakrabarti、S.およびPerkins、「低電力無線パーソナルエリアネットワーク（6lowpan）隣接ディスカバリーに関するIPv6の登録拡張」、RFC 8505、DOI10.17487 / RFC8505、2018年11月、<https：//www.rfc-editor.org/info/rfc8505>。
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8928] Thubert、P.、Ed。、Sarikaya、B.、Sethi、M.、R. Struik、「低消費電力損失ネットワークのためのアドレス保護隣接発見」、RFC 8928、DOI 10.17487 / RFC8928、11月2020、<https://www.rfc-editor.org/info/rfc8928>。
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI Option Type, Routing Header for Source Routes, and IPv6- in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008, DOI 10.17487/RFC9008, April 2021, <https://www.rfc-editor.org/info/rfc9008>.
[RFC9008] ROBLES、MI、Richardson、M.、およびP.Thubert、「RPIオプションタイプの使用、ソースルートのルーティングヘッダー、RPLデータプレーンにおけるIPv6-in-IPv6カプセル化」、RFC 9008、DOI 10.17487 / RFC9008、2021年4月、<https：//www.rfc-editor.org/info/rfc9008>。
[RFC9009] Jadhav, R.A., Ed., Thubert, P., Sahoo, R.N., and Z. Cao, "Efficient Route Invalidation", RFC 9009, DOI 10.17487/RFC9009, April 2021, <https://www.rfc-editor.org/info/rfc9009>.
[RFC9009] Jadhav、RA、ED。、Thubert、P.、Sahoo、RN、Z. Cao、「効率的なルート無効化」、RFC 9009、DOI 10.17487 / RFC9009、2021年4月、<https：///www.rfc-editor.org/info/rfc9009>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N.、Montenegro、G.、Schumacher、C. Schumacher、「低電力無線パーソナルエリアネットワーク（6lowpans）：概要、仮定、問題ステートメント、および目標、RFC 4919、DOI 10.17487 / RFC49192007年8月、<https：//www.rfc-editor.org/info/rfc4919>。
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6282] HUI、J.、ED。2011年9月、2011年9月、2011年9月、<https：//www.rfc-editor.org/info/rfc6282、<https：//www.rfc-editor.org/info/rfc6282>。
[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, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>.
[RFC6553] HUI、J.およびJP。「データプレーンデータグラム」、RFC 6553、DOI 10.17487 / RFC6553、2012年3月、<https：///www.rfc-editorのvasseur、 "RPL情報のためのルーティングプロトコル）。ORG / INFO / RFC6553>。
[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, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.
[RFC6554] HUI、J.、Vasseur、JP、Culler、D.、およびV. Manral、「低電力および非損失ネットワーク（RPL）」（RPL） "、RFC 6554を備えたソースルート用のIPv6ルーティングヘッダー。DOI 10.17487 / RFC6554、2012年3月、<https：//www.rfc-editor.org/info/rfc6554>。
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.
[RFC6606] KIM、E.、KASPAR、D.、Gomez、C、およびC. Bormann、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングにおけるIPv6の要件」、RFC 6606、DOI 10.17487 /rfc6606、2012年5月、<https://www.rfc-editor.org/info/rfc6606>。
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, Ed., "Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6687, DOI 10.17487/RFC6687, October 2012, <https://www.rfc-editor.org/info/rfc6687>.
[RFC6687] Tripathi、J.、Ed。、De Oliveira、J.、Ed。、およびJP。Vasseur、Ed。、「低消費電力および非損失ネットワーク（RPL）」、RFC 6687、DOI 10.17487 / RFC6687、2012年10月、<https://ww.rfc-editor.org/info/RFC6687>。
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., "Source Address Validation Improvement (SAVI) Framework", RFC 7039, DOI 10.17487/RFC7039, October 2013, <https://www.rfc-editor.org/info/rfc7039>.
[RFC7039] Wu、J.、Bi、J.、Bagnulo、M.、Baker、F.、およびC. Vogt、Ed。、「Source Address検証改善（SAVI）フレームワーク」、RFC 7039、DOI 10.17487 / RFC7039、2013年10月、<https://www.rfc-editor.org/info/rfc7039>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., "A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, <https://www.rfc-editor.org/info/rfc7416>.
[RFC7416] TSAO、T.、Alexander、R.、Dohler、M.、Daza、V.、Lozano、A.、およびM. Richardson、「低電力のためのルーティングプロトコルのセキュリティ脅威分析」2015年1月、<https：//www.rfc-editor.org/info/rfc7416>。<https：//ww.rfc-editor.org/info/rfc7416>。
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch", RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>.
[RFC8025] Thubert、P.、ED。そしてR. Cragie、「低電力無線パーソナルエリアネットワーク（6lowpan）ページングディスパッチ」、RFC 8025、DOI 10.17487 / RFC8025、2016年11月、<https：//www.rfc-editor.org/info/rfc8025>。
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, "IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8138] Thubert、P.、ED。、Bormann、C、Toutain、L.、R. Cragie、R.Cragie、「低電力無線パーソナルエリアネットワーク（6LOWPAN）ルーティングヘッダ」、RFC 8138、DOI 10.17487 / RFC8138、2017年4月、<https://www.rfc-editor.org/info/rfc8138>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC8929] Thubert、P.、Ed。、Perkins、CE、E. Levy-Abngingoli、「IPv6 Backbone Router」、RFC 8929、DOI 10.17487 / RFC8929、2020年11月、<https：//www.rfc-編集者。ORG / INFO / RFC8929>。
Figure 13 illustrates the case in Storing mode where the packet is received from the Internet, then the root encapsulates the packet to insert the RPI and deliver it to the 6LR that is the parent and last hop to the final destination, which is not known to support [RFC8138].
図13は、パケットがインターネットから受信された状態で、ルートをカプセル化してRPIをカプセル化し、それを最終宛先への最後のホップである6LRに配信する。サポート[RFC8138]。
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... <-4 bytes-> <- RFC 6282 -> <- No RPL artifact ...
- ... - - ... - ... - - ... - ... - ... - ... --... 11110001 | SRH-6LLOH |RPI- | IP-IN-IP |NH = 1 | 11110CPP |UDP |UDPページ1 | TIDE1 S = 0 |6llhh |6lllh | LowPan_IPHC |UDP |HDR | payld - ... - - ... - - ... - - ... - - ... - ... - ... --... <-4バイト - > < - rfc6282 - > < - RPLアーチファクトなし...
Figure 13: Encapsulation to Parent 6LR in Storing Mode
図13：保存モードにおける親6LRへのカプセル化
The difference from the example presented in Figure 19 of [RFC8138] is the addition of an SRH-6LoRH before the RPI-6LoRH to transport the compressed address of the 6LR as the destination address of the outer IPv6 header. In Figure 19 of [RFC8138], the destination IP of the outer header was elided and was implicitly the same address as the destination of the inner header. Type 1 was arbitrarily chosen, and the size of 0 denotes a single address in the SRH.
[RFC8138]の図19に示した例との違いは、RPI-6LLORHの前のSRH-6LLORの追加であり、6LRの圧縮アドレスを外部IPv6ヘッダーの宛先アドレスとして輸送します。[RFC8138]の図19では、外側のヘッダーの宛先IPが照らされ、内側ヘッダーの宛先と暗黙的に同じアドレスでした。タイプ1は任意に選択され、0のサイズはSRH内の単一のアドレスを表します。
In Figure 13, the source of the IPv6-in-IPv6 encapsulation is the root, so it is elided in the IPv6-in-IPv6 6LoRH. The destination is the parent 6LR of the destination of the encapsulated packet, so it cannot be elided. If the DODAG is operated in Storing mode, it is the single entry in the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH is the first 6LoRH in the chain. In this particular example, the 6LR address can be compressed to 2 bytes, so a Type of 1 is used. The result is that the total length of the SRH-6LoRH is 4 bytes.
図13では、IPv6-In-IPv6のカプセル化の原因がルートであるため、IPv6-in-IPv6 6lllhに区画されています。宛先はカプセル化パケットの宛先の親6LRであるため、存在できません。ドダグが貯蔵モードで操作される場合、それはSrH-6llorhの単一の入口であり、そしてSrH - 6lllhサイズは0としてコードされている.SRH - 6llhは鎖中の最初の6llhである。この特定の例では、6LRアドレスを2バイトに圧縮することができるので、1種類が使用される。その結果、SRH-6LLORの全長は4バイトであることです。
In Non-Storing mode, the encapsulation from the root would be similar to that represented in Figure 13 with possibly more hops in the SRH-6LoRH and possibly multiple SRH-6LoRHs if the various addresses in the routing header are not compressed to the same format. Note that on the last hop to the parent 6LR, the RH3 is consumed and removed from the compressed form, so the use of Non-Storing mode vs. Storing mode is indistinguishable from the packet format.
非記憶モードでは、ルートからのカプセル化は、図13に示されているものと類似しています。。なお、親6LRに対する最後のホップでは、RH3が消費されて圧縮された形から削除されるので、保存モードと記憶モードとの使用はパケット形式と区別がつかない。
The SRH-6LoRHs are followed by the RPI-6LoRH and then the IPv6-in-IPv6 6LoRH. When the IPv6-in-IPv6 6LoRH is removed, all the 6LoRH Headers that precede it are also removed. The Paging Dispatch [RFC8025] may also be removed if there was no previous Page change to a Page other than 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and in Page 1. The resulting packet to the destination is the encapsulated packet compressed per [RFC6282].
SRH-6LLORの後にRPI-6LLOR、次いでIPV6-in-IPV6 6LLORHが続く。IPv6-in-IPv6 6lllorhが削除されると、その前にあるすべての6llhヘッダーも削除されます。LowPan_iphcは、デフォルトのページ0および1ページの場合と同じ方法でエンコードされているため、Paging Dispatch [RFC8025]も0または1以外のページへの前のページ変更がなかった場合には削除されることがあります。宛先は、[RFC6282]ごとに圧縮されたカプセル化パケットです。
Acknowledgments
謝辞
The authors wish to thank Ines Robles, Georgios Papadopoulos, and especially Rahul Jadhav and Alvaro Retana for their reviews and contributions to this document. Also many thanks to Éric Vyncke, Erik Kline, Murray Kucherawy, Peter van der Stok, Carl Wallace, Barry Leiba, Julien Meuric, and especially Benjamin Kaduk and Elwyn Davies, for their reviews and useful comments during the IETF Last Call and the IESG review sessions.
著者らは、Robours、Georgios Papadopoulos、特にRahul JadhavとAlvaro Retanaに、レビューと貢献に感謝します。また、Eric Vyncke、Erik Kline、Murray Kucherawy、Peter Van Der Stok、Carl Wallace、Barry Leiba、Julien Meuriic、特にBenjamin KadukとElwyn Daviesのおかげで、Reviewsのレビューと便利なコメントとIESGレビューセッション。
Authors' Addresses
著者の住所
Pascal Thubert (editor) Cisco Systems, Inc. Building D 45 Allee des Ormes - BP1200 06254 MOUGINS - Sophia Antipolis France
Pascal Thubert（編集）Cisco Systems、Inc。Cisco Systems、Inc。建物D 45 Allee Des Ormes - BP1200 06254 Mougins - Sophia Antipolis France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Michael C. Richardson Sandelman Software Works
Michael C. Richardson Sandelman Software Works.
Email: mcr+ietf@sandelman.ca
URI: https://www.sandelman.ca/