[要約] RFC 9009 - 効率的なルート無効化についての要約、目的、利用場面:要約: RFC 9009は、ネットワーク内で無効となったルートを効率的に識別し、削除する方法に関する技術仕様を定めています。目的: この文書の目的は、ネットワークのパフォーマンスを向上させ、リソースの無駄遣いを減らすために、無効なルートの迅速な識別と削除を可能にすることです。利用場面: 主に大規模ネットワークや動的に変化するネットワーク環境でのルーティング効率の向上、ネットワーク管理の自動化、およびセキュリティ強化に利用されます。
Internet Engineering Task Force (IETF) R.A. Jadhav, Ed.
Request for Comments: 9009 Huawei
Category: Standards Track P. Thubert
ISSN: 2070-1721 Cisco
R.N. Sahoo
Z. Cao
Huawei
April 2021
Efficient Route Invalidation
効率的なルート無効化
Abstract
概要
This document explains the problems associated with the use of No-Path Destination Advertisement Object (NPDAO) messaging in RFC 6550 and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging.
このドキュメントでは、RFC 6550でのNo-Path Destination Advertisement Object（NPDAO）メッセージングの使用に関連する問題について説明し、また最適化されたルート無効化メッセージング方式の要件についても説明します。さらに、このドキュメントは、最適化されたルート無効化メッセージングの要件を満たす「宛先クリーンアップオブジェクト」（DCO）と呼ばれる新しい予防的なルート無効化メッセージを指定します。
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/rfc9009.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https：//www.rfc-editor.org/info/rfc9009で入手できます。
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
1.1. Requirements Language and Terminology
1.2. RPL NPDAO Messaging
1.3. Why Is NPDAO Messaging Important?
2. Problems with the RPL NPDAO Messaging
2.1. Lost NPDAO Due to Link Break to the Previous Parent
2.2. Invalidating Routes of Dependent Nodes
2.3. Possible Route Downtime Caused by Asynchronous Operation of
the NPDAO and DAO
3. Requirements for NPDAO Optimization
3.1. Req. #1: Remove Messaging Dependency on the Link to the
Previous Parent
3.2. Req. #2: Route Invalidation for Dependent Nodes at the
Parent Switching Node
3.3. Req. #3: Route Invalidation Should Not Impact Data Traffic
4. Changes to RPL Signaling
4.1. Change in RPL Route Invalidation Semantics
4.2. Transit Information Option Changes
4.3. Destination Cleanup Object (DCO)
4.3.1. Secure DCO
4.3.2. DCO Options
4.3.3. Path Sequence in the DCO
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK)
4.3.5. Secure DCO-ACK
4.4. DCO Base Rules
4.5. Unsolicited DCO
4.6. Other Considerations
4.6.1. Invalidation of Dependent Nodes
4.6.2. NPDAO and DCO in the Same Network
4.6.3. Considerations for DCO Retries
4.6.4. DCO with Multiple Preferred Parents
5. IANA Considerations
5.1. New Registry for the Destination Cleanup Object (DCO) Flags
5.2. New Registry for the Destination Cleanup Object (DCO)
Acknowledgment Flags
5.3. RPL Rejection Status Values
6. Security Considerations
7. Normative References
Appendix A. Example Messaging
A.1. Example DCO Messaging
A.2. Example DCO Messaging with Multiple Preferred Parents
Acknowledgments
Authors' Addresses
RPL (the Routing Protocol for Low-Power and Lossy Networks) as defined in [RFC6550] specifies a proactive distance-vector-based routing scheme. RPL has optional messaging in the form of DAO (Destination Advertisement Object) messages, which the 6LBR (6LoWPAN Border Router) and 6LR (6LoWPAN Router) can use to learn a route towards the downstream nodes. ("6LoWPAN" stands for "IPv6 over Low-Power Wireless Personal Area Network".) In Storing mode, DAO messages would result in routing entries being created on all intermediate 6LRs from a node's parent all the way towards the 6LBR.
[RFC6550]で定義されているRPL（低電力および非損失ネットワークのためのルーティングプロトコル）は、予防的距離ベクトルベースのルーティング方式を指定します。RPLには、6LBR（6LOWPAN BORDER ROULTER）と6LR（6LOWPANルータ）がダウンストリームノードに向かう経路を学習するために使用できるDAO（Destination Advertisement Object）メッセージの形式でオプションのメッセージングがあります。（ "6lowpan"は "IPv6を介して低電力無線パーソナルエリアネットワーク"です。）保存モードでは、DAOメッセージはノードの親から6LBRに向かってすべての中間6LRS上にルーティングエントリを作成することになります。
RPL allows the use of No-Path DAO (NPDAO) messaging to invalidate a routing path corresponding to the given target, thus releasing resources utilized on that path. An NPDAO is a DAO message with a route lifetime of zero. It originates at the target node and always flows upstream towards the 6LBR. This document explains the problems associated with the use of NPDAO messaging in [RFC6550] and also discusses the requirements for an optimized route invalidation messaging scheme. Further, this document specifies a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which fulfills requirements for optimized route invalidation messaging.
RPLは、指定されたターゲットに対応するルーティングパスを無効にするためにNO-PATH DAO（NPDAO）メッセージングを使用することができ、したがってそのパス上で利用されるリソースを解放することができます。NPDAOは、ゼロの経路寿命を持つDAOメッセージです。ターゲットノードで発生し、常に6LBRに向かって上流に流れます。このドキュメントでは、[RFC6550]のNPDAOメッセージングの使用に関連した問題について説明します。また、最適化されたルート無効化メッセージング方式の要件についても説明します。さらに、このドキュメントは、最適化されたルート無効化メッセージングの要件を満たす「宛先クリーンアップオブジェクト」（DCO）と呼ばれる新しい予防的なルート無効化メッセージを指定します。
This document only caters to RPL's Storing Mode of Operation (MOP). The Non-Storing MOP does not require the use of an NPDAO for route invalidation, since routing entries are not maintained on 6LRs.
この文書はRPLの保存操作モード（MOP）にのみ対処します。保存されていないMOPは、ルーティングエントリが6LRで維持されていないため、ルートの無効化のためのNPDAOの使用を必要としません。
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 specification requires readers to be familiar with all the terms and concepts that are discussed in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550].
この仕様では、リーダーは「RPL：Low PowerおよびLossy Networks用のRPL：IPv6ルーティングプロトコル」で説明されているすべての条項と概念に精通しています[RFC6550]。
Low-Power and Lossy Network (LLN): A network in which both the routers and their interconnects are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability.
低電力および非損失ネットワーク（LLN）：ルータとそれらの相互接続の両方が制約されているネットワーク。LLNルータは通常、処理電力、メモリ、およびエネルギー（バッテリ電力）の処理上の制約で動作します。それらの相互接続は、高い損失率、低データレート、および不安定性によって特徴付けられます。
6LoWPAN Router (6LR): An intermediate router that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets.
6lowPan Router（6LR）：ルータアドバタイズメント（RAS）およびルータの契約（RSS）とROUTHとROUTE IPV6パケットを送受信できる中間ルータ。
Directed Acyclic Graph (DAG): A directed graph having the property that all edges are oriented in such a way that no cycles exist.
無理非環式グラフ（DAG）：すべてのエッジがサイクルが存在しないように向けられているという特性を持つ有向グラフ。
Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, i.e., at a single DAG root with no outgoing edges.
宛先指向DAG（DODAG）：単一の宛先、すなわち、発信エッジを持たない単一のDAGルートで根付いたDAG。
6LoWPAN Border Router (6LBR): A border router that is a DODAG root and is the edge node for traffic flowing in and out of the 6LoWPAN.
6lowpan Border Router（6LBR）：DoDagルートで、6LOWPANの出入りのトラフィックのエッジノードです。
Destination Advertisement Object (DAO): DAO messaging allows downstream routes to the nodes to be established.
宛先アドバタイズメントオブジェクト（DAO）：DAO Messagingでは、設定されるノードへの下流ルートを許可します。
DODAG Information Object (DIO): DIO messaging allows upstream routes to the 6LBR to be established. DIO messaging is initiated at the DAO root.
DoDag Information Object（DIO）：DIOメッセージングにより、6LBRへの上流のルートが確立されます。DIOメッセージングはDAO rootで開始されます。
Common ancestor node: A 6LR/6LBR node that is the first common node between two paths of a target node.
共通の祖先ノード：ターゲットノードの2つのパス間の最初の共通ノードである6LR / 6LBRノード。
No-Path DAO (NPDAO): A DAO message that has a target with a lifetime of 0. Used for the purpose of route invalidation.
No-Path DAO（NPDAO）：存続期間の0のターゲットを持つDAOメッセージ。ルート無効化の目的で使用されます。
Destination Cleanup Object (DCO): A new RPL control message code defined by this document. DCO messaging improves proactive route invalidation in RPL.
宛先クリーンアップオブジェクト（DCO）：この文書で定義されている新しいRPL制御メッセージコード。DCOメッセージングはRPLでの予防的なルートの無効化を改善します。
Regular DAO: A DAO message with a non-zero lifetime. Routing adjacencies are created or updated based on this message.
通常のDAO：ゼロ以外の寿命を持つDAOメッセージ。ルーティング隣接関係はこのメッセージに基づいて作成または更新されます。
Target node: The node switching its parent whose routing adjacencies are updated (created/removed).
ターゲットノード：ルーティング隣接関係が更新された親の切り替えノード（作成/削除）。
RPL uses NPDAO messaging in Storing mode so that the node changing its routing adjacencies can invalidate the previous route. This is needed so that nodes along the previous path can release any resources (such as the routing entry) they maintain on behalf of the target node.
RPLは、ルーティング隣接関係を変更するノードが前のルートを無効にすることができるように、StoringモードでNPDAOメッセージングを使用します。これは、前のパスに沿ったノードがターゲットノードに代わって保守されているリソース（ルーティングエントリなど）を解放できるように必要です。
Throughout this document, we will refer to the topology shown in Figure 1:
この文書を通して、図1に示すトポロジを参照します。
(6LBR)
|
|
|
(A)
/ \
/ \
/ \
(G) (H)
| |
| |
| |
(B) (C)
\ ;
\ ;
\ ;
(D)
/ \
/ \
/ \
(E) (F)
Figure 1: Sample Topology
図1：サンプルトポロジー
Node D is connected via preferred parent B. D has an alternate path via C towards the 6LBR. Node A is the common ancestor for D for paths through B-G and C-H. When D switches from B to C, RPL allows sending an NPDAO to B and a regular DAO to C.
ノードDは、好ましい親Bを介して接続されている.Dは、6LBRに向かってCを介して交互経路を有する。ノードAは、B-GおよびC-Hを介したパスのためのDの共通の先祖です。DからCへのDからCへの切り替えが、RPLはNPDAOをBに送信し、通常のDAOをCに送信できます。
Resources in LLN nodes are typically constrained. There is limited memory available, and routing entry records are one of the primary elements occupying dynamic memory in the nodes. Route invalidation helps 6LR nodes to decide which routing entries can be discarded for better use of the limited resources. Thus, it becomes necessary to have an efficient route invalidation mechanism. Also note that a single parent switch may result in a "subtree" switching from one parent to another. Thus, the route invalidation needs to be done on behalf of the subtree and not the switching node alone. In the above example, when Node D switches its parent, route updates need to be done for the routing table entries of C, H, A, G, and B with destinations D, E, and F. Without efficient route invalidation, a 6LR may have to hold a lot of stale route entries.
LLNノード内のリソースは通常制限されています。利用可能なメモリが限られており、ルーティングエントリレコードはノード内の動的メモリを占有する主要素の1つです。ルートの無効化は、リソースが限られているためにどのルーティングエントリを破棄できるかを決定するために6LRノードを決定します。したがって、効率的な経路無効化機構を有することが必要となる。また、単一の親スイッチは、ある親から別の親に切り替わる「サブツリー」をもたらす可能性があることにも注意してください。したがって、ルートの無効化は、スイッチングノードのみではなく、サブツリーの代わりに行う必要があります。上記の例では、ノードDがその親を切り替えると、宛先D、E、G、Bのルーティングテーブルエントリに対してルートアップデートを実行する必要があります。たくさんの古いルートエントリを保持しなければならないかもしれません。
When a node switches its parent, the NPDAO is to be sent to its previous parent and a regular DAO to its new parent. In cases where the node switches its parent because of transient or permanent parent link/node failure, the NPDAO message may not be received by the parent.
ノードがその親を切り替えると、NPDAOは以前の親とその新しい親に通常のDAOに送信されます。トランジェントまたは永続的な親リンク/ノード障害のためにノードがその親を切り替える場合、NPDAOメッセージは親によって受信されない可能性があります。
RPL does not specify how route invalidation will work for dependent nodes in the switching node subDAG, resulting in stale routing entries of the dependent nodes. The only way for a 6LR to invalidate the route entries for dependent nodes would be to use route lifetime expiry, which could be substantially high for LLNs.
RPLは、スイッチングノードサブダグ内の依存ノードに対してRoute Inernialationがどのように機能するかを指定しません。これにより、従属ノードの古いルーティングエントリが発生します。6LRが従属ノードのルートエントリを無効にする唯一の方法は、LORSライフタイムの有効期限を使用することです。これはLLNに対して実質的に高い可能性があります。
In the example topology, when Node D switches its parent, Node D generates an NPDAO on its own behalf. There is no NPDAO generated by the dependent child Nodes E and F, through the previous path via D to B and G, resulting in stale entries on Nodes B and G for Nodes E and F.
トポロジの例では、ノードDがその親を切り替えると、ノードDは自らのためにNPDAOを生成します。従属子ノードeおよびfによって、dからbおよびgを介して前の経路を通して生成されたnpdaoは、ノードeおよびfに対するノードBおよびG上のエントリを生成する。
2.3. Possible Route Downtime Caused by Asynchronous Operation of the NPDAO and DAO
2.3. NPDAOとDAOの非同期操作によって引き起こされる可能性のあるルートダウンタイム
A switching node may generate both an NPDAO and a DAO via two different paths at almost the same time. It is possible that the NPDAO may invalidate the previous route and the regular DAO sent via the new path gets lost on the way. This may result in route downtime, impacting downward traffic for the switching node.
スイッチングノードは、ほぼ同時に2つの異なる経路を介してNPDAOとDAOの両方を生成することができる。NPDAOが前のルートを無効にし、新しいパスを介して送信された通常のDAOが途中で失われる可能性があります。これにより、ルートのダウンタイムが発生し、スイッチングノードの下方トラフィックに影響を与えます。
In the example topology, say that Node D switches from parent B to C. An NPDAO sent via the previous route may invalidate the previous route, whereas there is no way to determine whether the new DAO has successfully updated the route entries on the new path.
トポロジの例では、ノードDが親BからCに切り替わります。前のルートを介して送信されたNPDAOは前のルートを無効にする可能性がありますが、新しいDAOが新しいパス上のルートエントリを正常に更新したかどうかを判断する方法はありません。。
3.1. Req. #1: Remove Messaging Dependency on the Link to the Previous Parent
3.1. req。※1：前の親へのリンクに対するメッセージング依存関係を削除する
When the switching node sends the NPDAO message to the previous parent, it is normal that the link to the previous parent is prone to failure (that's why the node decided to switch). Therefore, it is required that the route invalidation does not depend on the previous link, which is prone to failure. The previous link referred to here represents the link between the node and its previous parent (from which the node is now disassociating).
スイッチングノードが前の親にNPDAOメッセージを送信すると、前の親へのリンクが障害が発生しやすいことが通常のものです（そのノードが切り替えることにした理由です）。したがって、経路無効化が前のリンクに依存しないことが必要です。これは失敗しやすいです。ここで言及される前のリンクは、ノードとその前の親との間のリンクを表します（ノードが現在解離されている場合）。
3.2. Req. #2: Route Invalidation for Dependent Nodes at the Parent Switching Node
3.2. req。注※2親切り替えノードでの従属ノードのルート無効化
It should be possible to do route invalidation for dependent nodes rooted at the switching node.
スイッチングノードに根ざした従属ノードに対するルート無効化を行うことは可能であるべきです。
While sending the NPDAO and DAO messages, it is possible that the NPDAO successfully invalidates the previous path, while the newly sent DAO gets lost (new path not set up successfully). This will result in downstream unreachability to the node switching paths. Therefore, it is desirable that the route invalidation is synchronized with the DAO to avoid the risk of route downtime.
NPDAOメッセージとDAOメッセージの送信中に、NPDAOが前のパスを正常に無効にする可能性がありますが、新しく送信されたDAOは失われます（新しいパスは正常に設定されていません）。これにより、ノード切り替えパスへのダウンストリームの到達不能が生じる。したがって、ルートのダウンタイムのリスクを回避するために、経路無効化がDAOと同期していることが望ましい。
As described in Section 1.2, the NPDAO originates at the node changing to a new parent and traverses upstream towards the root. In order to solve the problems discussed in Section 2, this document adds a new proactive route invalidation message called the "Destination Cleanup Object" (DCO), which originates at a common ancestor node and flows downstream the old path. The common ancestor node generates a DCO when removing a next hop to a target -- for instance, as a delayed response to receiving a regular DAO from another child node with a Path Sequence for the target that is the same or newer, in which case the DCO transmission is canceled.
セクション1.2で説明されているように、NPDAOはノードで新しい親に変更され、rootに向かって上流に移動します。セクション2で説明した問題を解決するために、この文書は「宛先クリーンアップオブジェクト」（DCO）と呼ばれる新しい予防的ルート無効化メッセージを追加し、これは共通の先祖ノードで発信され、古いパスの下流に流れます。共通の先祖ノードは、同じまたは新しい場合のパスシーケンスを持つ別の子ノードから通常のDAOを受信するための遅延応答として、次のホップをターゲットに削除するときにDCOを生成します。DCO送信はキャンセルされます。
The 6LRs in the path for the DCO take such action as route invalidation based on the DCO information and subsequently send another DCO with the same information downstream to the next hop(s). This operation is similar to how the DAOs are handled on intermediate 6LRs in the Storing MOP [RFC6550]. Just like the DAO in the Storing MOP, the DCO is sent using link-local unicast source and destination IPv6 addresses. Unlike the DAO, which always travels upstream, the DCO always travels downstream.
DCOのパス内の6LRSは、DCO情報に基づいてルート無効化として行動を起こし、続いて次のホップの下流の同じ情報を使用して別のDCOを送信します。この操作は、Storing MOP [RFC6550]の中間6LRSでDAOSがどのように処理されるかと同様です。保管モップのDAOと同じように、DCOはリンクローカルユニキャストソースと宛先IPv6アドレスを使用して送信されます。常に上流に進むDAOとは異なり、DCOは常に下流に進みます。
In Figure 1, when child Node D decides to switch the path from parent B to parent C, it sends a regular DAO to Node C with reachability information containing the address of D as the target and an incremented Path Sequence. Node C will update the routing table based on the reachability information in the DAO and will in turn generate another DAO with the same reachability information and forward it to H. Node H recursively follows the same procedure as Node C and forwards it to Node A. When Node A receives the regular DAO, it finds that it already has a routing table entry on behalf of the Target Address of Node D. It finds, however, that the next-hop information for reaching Node D has changed, i.e., Node D has decided to change the paths. In this case, Node A, which is the common ancestor node for Node D along the two paths (previous and new), can generate a DCO that traverses the network downwards over the old path to the target. Node A handles normal DAO forwarding to the 6LBR as required by [RFC6550].
図1において、子ノードDが親Bから親Cへの経路を切り替えることを決定すると、ターゲットとしてDのアドレスおよびインクリメントされたパスシーケンスを含む到達可能性情報を用いて、レギュラーDAOをノードCに送信する。ノードCは、DAO内の到達可能性情報に基づいてルーティングテーブルを更新し、同じ到達可能性情報を有する別のDAOを生成し、それをHに転送する。ノードHはノードCと同じ手順に従い、それをノードAに転送する。ノードAが通常のDAOを受信すると、ノードDのターゲットアドレスに代わって既にルーティングテーブルエントリがあることがわかります。ただし、ノードDに到達するためのネクストホップ情報、つまりノードDが変化したことがわかります。パスを変更することにしました。この場合、ノードAは、2つの経路（前後）に沿ってノードDの共通の先祖ノードであるノードAは、ターゲットへの古いパスを介してネットワークを下方にトラバースするDCOを生成することができる。ノードAは、[RFC6550]で要求されるように6LBRに正常なDAOを処理します。
Every RPL message is divided into base message fields and additional options, as described in Section 6 of [RFC6550]. The base fields apply to the message as a whole, and options are appended to add message-specific / use-case-specific attributes. As an example, a DAO message may be attributed by one or more "RPL Target" options that specify that the reachability information is for the given targets. Similarly, a Transit Information option may be associated with a set of RPL Target options.
[RFC6550]のセクション6で説明されているように、すべてのRPLメッセージはベースメッセージフィールドと追加オプションに分割されています。基本フィールドは全体としてメッセージに適用され、オプションはメッセージ固有/ use-case固有の属性を追加するために追加されます。一例として、DAOメッセージは、到達可能性情報が与えられたターゲットに対するものであることを指定する1つまたは複数の「RPLターゲット」オプションによって帰属され得る。同様に、トランジット情報オプションは、一連のRPLターゲットオプションに関連付けられてもよい。
This document specifies a change in the Transit Information option to contain the "Invalidate previous route" (I) flag. This 'I' flag signals the common ancestor node to generate a DCO on behalf of the target node with a RPL Status of 195, indicating that the address has moved. The 'I' flag is carried in the Transit Information option, which augments the reachability information for a given set of one or more RPL Targets. A Transit Information option with the 'I' flag set should be carried in the DAO message when route invalidation is sought for the corresponding target or targets.
このドキュメントでは、「Invalidate Previous Route」（i）フラグを含むように、Transit Informationオプションの変更を指定します。この 'i'フラグは、195のRPLステータスを持つターゲットノードに代わってDCOを生成するために、共通の先祖ノードをシグナリングし、アドレスが移動したことを示します。「i」フラグは、輸送情報オプションで搭載されており、これは1つ以上のRPLターゲットの特定のセットの到達可能性情報を増大させる。対応するターゲットまたはターゲットに対してルートの無効化が求められている場合、 'i'フラグセットを持つTransit InformationオプションをDAOメッセージで実行する必要があります。
Value 195 represents the 'U' and 'A' bits in RPL Status, to be set as per Figure 6 of [RFC9010], with the lower 6 bits set to the 6LoWPAN Neighbor Discovery (ND) Extended Address Registration Option (EARO) Status value of 3 indicating 'Moved' as per Table 1 of [RFC8505].
値195はRPLステータスの「u」と「A」のビットを表し、[RFC9010]の図6に示すように設定され、下位6ビットが6lowpan隣接発見（ND）拡張アドレス登録オプション（EARO）ステータスに設定されています。[RFC8505]の表1に従って「移動」を示す3の値。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Option Length |E|I| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated Transit Information Option (New 'I' Flag Added)
図2：更新されたトランジット情報オプション（新しい 'i'フラグが追加されました）
I (Invalidate previous route) flag: The 'I' flag is set by the target node to indicate to the common ancestor node that it wishes to invalidate any previous route between the two paths.
I（以前のルートを無効にする）フラグ：「I」フラグは、2つのパス間の前のルートを無効にすることが望む共通の先祖ノードに示すように、ターゲットノードによって設定されます。
[RFC6550] allows the parent address to be sent in the Transit Information option, depending on the MOP. In the case of the Storing MOP, the field is usually not needed. In the case of a DCO, the Parent Address field MUST NOT be included.
[RFC6550] MOPに応じて、親アドレスをTransit Informationオプションで送信できます。記憶モップの場合、このフィールドは通常必要ではない。DCOの場合は、親アドレスフィールドを含める必要がありません。
Upon receiving a DAO message with a Transit Information option that has the 'I' flag set, and as a delayed response removing a routing adjacency to the target indicated in the Transit Information option, the common ancestor node SHOULD generate a DCO message to the next hop associated to that adjacency. The 'I' flag is intended to give the target node control over its own route invalidation, serving as a signal to request DCO generation.
「i」フラグが設定されているトランジット情報オプションを持つDAOメッセージを受信すると、[Information Information]オプションで示されているターゲットへのルーティング隣接を削除すると、共通の先祖ノードは次のDCOメッセージを生成する必要があります。その隣接に関連付けられているホップ。'i'フラグは、DCO生成を要求するための信号として機能する、それ自身のルート無効化を介してターゲットノードを制御することを目的としています。
A new ICMPv6 RPL control message code is defined by this specification and is referred to as the "Destination Cleanup Object" (DCO), which is used for proactive cleanup of state and routing information held on behalf of the target node by 6LRs. The DCO message always traverses downstream and cleans up route information and other state information associated with the given target. The format of the DCO message is shown in Figure 3.
この仕様書によって新しいICMPv6 RPL制御メッセージコードを定義し、ターゲットノードに代わって保持されている状態の予防的クリーンアップおよび6LRで保持されている「宛先クリーンアップオブジェクト」（DCO）と呼ばれます。DCOメッセージは、常に下流に進み、経路情報および与えられたターゲットに関連する他の状態情報をクリーニングする。DCOメッセージのフォーマットを図3に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | RPL Status | DCOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID (optional) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 3: DCO Base Object
図3：DCO基地オブジェクト
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.
RPLINSTANCEID：DOOから学習されたDODAGに関連付けられているトポロジインスタンスを示す8ビットフィールド。
K: The 'K' flag indicates that the recipient of a DCO message is expected to send a DCO-ACK back. If the DCO-ACK is not received even after setting the 'K' flag, an implementation may retry the DCO at a later time. The number of retries is implementation and deployment dependent and is expected to be kept similar to the number of DAO retries [RFC6550]. Section 4.6.3 specifies the considerations for DCO retries. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition. An example error condition could be that the node sending the DCO-ACK does not find the routing entry for the indicated target. When the sender does not set the 'K' flag, it is an indication that the sender does not expect a response, and the sender SHOULD NOT retry the DCO.
k： 'k'フラグは、DCOメッセージの受信者がDCO-ACKを返送すると予想されることを示します。'k'フラグを設定してもDCO-ACKが受信されない場合、実装は後でDCOを再試行することができます。再試行回数は実装および展開に依存し、DAO再試行回数と同様に保持される予定です[RFC6550]。セクション4.6.3 DCO再試行の考慮事項を指定します。「k」フラグを設定せずにDCOメッセージを受信したノードは、特にエラー状態を報告するためにDCO - ACKで応答することができる。例示的なエラー状態は、DCO-ACKを送信するノードが示されたターゲットのルーティングエントリを見つけられないことであり得る。送信者が 'k'フラグを設定していない場合は、送信者が応答を期待していないことが表示され、送信者はDCOを再試行しないでください。
D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used.
D：「D」フラグは、DoDagIDフィールドが存在することを示します。このフラグは、ローカルRPLINSTANCEIDが使用されているときに設定する必要があります。
Flags: The 6 bits remaining unused in the Flags field are reserved for future use. These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：Flagsフィールドで未使用の6ビットは将来の使用のために予約されています。これらのビットは送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
RPL Status: As defined in [RFC6550] and updated in [RFC9010]. The root or common parent that generates a DCO is authoritative for setting the status information, and the information is unchanged as propagated down the DODAG. This document does not specify a differentiated action based on the RPL Status.
RPLステータス：[RFC6550]で定義され、[RFC9010]で更新されています。DCOを生成するルートまたは共通の親は、ステータス情報を設定する権限があり、その情報はDODAGを伝播したときに変更されません。この文書では、RPLステータスに基づいて微分アクションを指定しません。
DCOSequence: 8-bit field incremented at each unique DCO message from a node and echoed in the DCO-ACK message. The initial DCOSequence can be chosen randomly by the node. Section 4.4 explains the handling of the DCOSequence.
DCOSQUENCE：ノードから各固有のDCOメッセージで8ビットフィールドは、DCO-ACKメッセージにエコーされます。初期の菱形は、ノードによってランダムに選択できます。セクション4.4は菱形の取り扱いについて説明しています。
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present if the 'D' flag is not set. The DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID.
dodagid（オプション）：DoDagルートによって設定された128ビット符号なし整数は、DoDagを一意に識別します。このフィールドは 'd'フラグが設定されているときに存在し、 'd'フラグが設定されていない場合は存在しないでください。DoDagIDは、RPLINSTANCEIDに関連付けられているDoDagIDを識別するために、ローカルRPLINSTANCEIDが使用されている場合に使用されます。
A Secure DCO message follows the format shown in [RFC6550], Figure 7, where the base message format is the DCO message shown in Figure 3 of this document.
セキュアDCOメッセージは[RFC6550]の形式に従います。図7は、基本メッセージ形式がこのドキュメントの図3に示すDCOメッセージです。
The DCO message MUST carry at least one RPL Target and the Transit Information option and MAY carry other valid options. This specification allows for the DCO message to carry the following options:
DCOメッセージは、少なくとも1つのRPLターゲットとトランジット情報オプションを持ち、他の有効なオプションを持つことがあります。この仕様では、DCOメッセージが次のオプションを実行できます。
0x00 Pad1 0x01 PadN 0x05 RPL Target 0x06 Transit Information 0x09 RPL Target Descriptor
0x00 PAD1 0x01 PADN 0x05 RPLターゲット0x06トランジット情報0x09 RPLターゲット記述子
Section 6.7 of [RFC6550] defines all the above-mentioned options. The DCO carries a RPL Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that target.
[RFC6550]の6.7項上記のオプションをすべて定義します。DCOは、RPLターゲットオプションと0x00000000の有効期間で、そのターゲットへの到達可能性の損失を示す、RPLターゲットオプションとそれに関連するトランジット情報オプションを実行します。
A DCO message includes a Transit Information option for each invalidated path. The value of the Path Sequence counter in the Transit Information option allows identification of the freshness of the DCO message versus the newest known to the 6LRs along the path being removed. If the DCO is generated by a common parent in response to a DAO message, then the Transit Information option in the DCO MUST use the value of the Path Sequence as found in the newest Transit Information option that was received for that target by the common parent. If a 6LR down the path receives a DCO with a Path Sequence that is not newer than the Path Sequence as known from a Transit Information option in a DAO message, then the 6LR MUST NOT remove its current routing state, and it MUST NOT forward the DCO down a path where it is not newer. If the DCO is newer, the 6LR may retain a temporary state to ensure that a DAO that is received later with a Transit Information option with an older sequence number is ignored. A Transit Information option in a DAO message that is as new as or newer than that in a DCO wins, meaning that the path indicated in the DAO is installed and the DAO is propagated. When the DCO is propagated upon a DCO from an upstream parent, the Path Sequence MUST be copied from the received DCO.
DCOメッセージには、無効化されたパスごとにトランジット情報オプションが含まれています。 Transit Informationオプション内のパスシーケンスカウンタの値は、削除されているパスに沿って6LRSに既知の最新のDCOメッセージの鮮度を識別できます。 DCOがDAOメッセージに応答して共通の親によって生成された場合、DCOの[Information Information]オプションは、共通の親によってそのターゲットに対して受信された最新のトランジット情報オプションにあるパスシーケンスの値を使用する必要があります。 。 PATHの6LRがPATシーケンスよりも新しいパスシーケンスを持つDCOをDAOメッセージで既知のパスシーケンスを使用してDCOを受信した場合、6LRは現在のルーティング状態を削除してはならず、それを転送しないでください。 DCO DCOはそれが新しいではないパスを下にします。 DCOが新しい場合、6LRは、古いシーケンス番号を持つトランジット情報オプションを使用して後で受信されたDAOが無視されるように、一時的な状態を保持することがあります。 DCO WINSの場合と同じまたは新しいものとして新しいメッセージ内のトランジット情報オプションは、DAOに示されているパスがインストールされ、DAOが伝播されます。 DCOがアップストリーム親からDCO上に伝播されると、パスシーケンスは受信したDCOからコピーされなければなりません。
The DCO-ACK message SHOULD be sent as a unicast packet by a DCO recipient in response to a unicast DCO message with the 'K' flag set. If the 'K' flag is not set, then the receiver of the DCO message MAY send a DCO-ACK, especially to report an error condition. The format of the DCO-ACK message is shown in Figure 4.
DCO-ACKメッセージは、Unicast DCOメッセージに応答して、 'k'フラグセットを使用してDCO受信者によってユニキャストパケットとして送信されるべきです。'k'フラグが設定されていない場合、DCOメッセージの受信機は、特にエラー状態を報告するためにDCO - ACKを送信することができる。DCO-ACKメッセージのフォーマットを図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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID (optional) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DCO-ACK Base Object
図4：DCO-ACKベースオブジェクト
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.
RPLINSTANCEID：DOOから学習されたDODAGに関連付けられているトポロジインスタンスを示す8ビットフィールド。
D: The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used.
D：「D」フラグは、DoDagIDフィールドが存在することを示します。このフラグは、ローカルRPLINSTANCEIDが使用されているときに設定する必要があります。
Flags: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
フラグ：7ビット未使用フィールド。フィールドは送信者によってゼロに初期化されなければならず、受信者によって無視される必要があります。
DCOSequence: 8-bit field. The DCOSequence in the DCO-ACK is copied from the DCOSequence received in the DCO message.
DCOSEQUENCE：8ビットフィールド。DCO-ACKの菱形は、DCOメッセージで受信されたDCROSEQUENCEからコピーされます。
DCO-ACK Status: Indicates completion status. The DCO-ACK Status field is defined based on Figure 6 of [RFC9010] defining the RPL Status Format. A StatusValue of 0 along with the 'U' bit set to 0 indicates Success / Unqualified acceptance as per Figure 6 of [RFC9010]. A StatusValue of 1 with the 'U' bit set to 1 indicates 'No routing entry' as defined in Section 5.3 of this document.
DCO-ACKステータス：完了ステータスを示します。DCO-ACKステータスフィールドは、RPLステータスフォーマットを定義する[RFC9010]の図6に基づいて定義されています。0の「u」ビットに設定されている0のステータス値は、[RFC9010]の図6に従って、成功/非修飾の受け入れを示します。'u'ビットが1に設定されている1のStatusValueは、このドキュメントのセクション5.3で定義されているように「ルーティングエントリなし」を示します。
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field MUST be present when the 'D' flag is set and MUST NOT be present when the 'D' flag is not set. The DODAGID is used when a local RPLInstanceID is in use, in order to identify the DODAGID that is associated with the RPLInstanceID.
dodagid（オプション）：DoDagルートによって設定された128ビット符号なし整数は、DoDagを一意に識別します。このフィールドは 'd'フラグが設定されているときに存在し、 'd'フラグが設定されていないときに存在しないでください。DoDagIDは、RPLINSTANCEIDに関連付けられているDoDagIDを識別するために、ローカルRPLINSTANCEIDが使用されている場合に使用されます。
A Secure DCO-ACK message follows the format shown in [RFC6550], Figure 7, where the base message format is the DCO-ACK message shown in Figure 4 of this document.
セキュアDCO-ACKメッセージは[RFC6550]、図7に示されている形式に従います。ここで、基本メッセージ形式はこのドキュメントの図4に示すDCO-ACKメッセージです。
1. If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. The DCOSequence counter follows the sequence counter operation as defined in Section 7.2 of [RFC6550].
1. ノードが以前のDCOメッセージ送信との間でDCOメッセージを新しい情報または異なる情報を送信する場合は、DCOSQUENCEフィールドを少なくとも1つずつ増やす必要があります。従来のDCOメッセージ送信と同一のDCOメッセージ送信は、DCARSQUENCEフィールドをインクリメントすることができる。DCROSQUENCEカウンタは、[RFC6550]のセクション7.2で定義されているシーケンスカウンタ動作に従います。
2. The RPLInstanceID and DODAGID fields of a DCO message MUST have the same values as those contained in the DAO message in response to which the DCO is generated on the common ancestor node.
2. DCOメッセージのRPLINSTANCEIDフィールドとDODAGIDフィールドは、COMMONESTORノードでDCOが生成されるかに応答してDAOメッセージに含まれるものと同じ値を持たなければなりません。
3. A node MAY set the 'K' flag in a unicast DCO message to solicit a unicast DCO-ACK in response, in order to confirm the attempt.
3. その試行を確認するために、ノードはユニキャストDCOメッセージに「k」フラグを設定することができる。
4. A node receiving a unicast DCO message with the 'K' flag set SHOULD respond with a DCO-ACK. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition.
4. 'k'フラグセットを使用してユニキャストDCOメッセージを受信したノードは、DCO-ACKで応答する必要があります。「k」フラグを設定せずにDCOメッセージを受信したノードは、特にエラー状態を報告するためにDCO - ACKで応答することができる。
5. A node receiving a unicast DCO message MUST verify the stored Path Sequence in context to the given target. If the stored Path Sequence is as new as or newer than the Path Sequence received in the DCO, then the DCO MUST be dropped.
5. ユニキャストDCOメッセージを受信したノードは、特定のターゲットにコンテキスト内の格納されたパスシーケンスを検証する必要があります。保存されたパスシーケンスがDCOで受信されたパスシーケンスと同じまたは新しいものである場合、DCOはドロップされなければなりません。
6. A node that sets the 'K' flag in a unicast DCO message but does not receive a DCO-ACK in response MAY reschedule the DCO message transmission for another attempt, up until an implementation-specific number of retries.
6. UniCast DCOメッセージに 'k'フラグを設定するが、応答にDCO - ACKを受信しないノードは、実装固有の再試行回数まで、DCOメッセージ送信を別の試行のために再スケジュールすることができる。
7. A node receiving a unicast DCO message with its own address in the RPL Target option MUST strip off that Target option. If this Target option is the only one in the DCO message, then the DCO message MUST be dropped.
7. RPLターゲットオプションで独自のアドレスを持つユニキャストDCOメッセージを受信したノードは、そのターゲットオプションを削除する必要があります。このターゲットオプションがDCOメッセージ内の唯一のものである場合は、DCOメッセージをドロップする必要があります。
The scope of DCOSequence values is unique to the node that generates them.
菱形値の範囲は、それらを生成するノードに固有のものです。
A 6LR may generate an unsolicited DCO to unilaterally clean up the path on behalf of the target entry. The 6LR has all the state information, namely, the Target Address and the Path Sequence, required for generating a DCO in its routing table. The conditions under which a 6LR may generate an unsolicited DCO are beyond the scope of this document, but possible reasons could be as follows:
6LRは、ターゲットエントリに代わって経路を一方的にクリーンアップするための迷惑なDCOを生成することができる。6LRは、そのルーティングテーブル内のDCOを生成するために必要なすべての状態情報、すなわちターゲットアドレスとパスシーケンスを有する。6LRが迷惑なDCOを発生させる可能性がある条件はこの文書の範囲を超えていますが、考えられる理由は次のとおりです。
1. On route expiry of an entry, a 6LR may decide to graciously clean up the entry by initiating a DCO.
1. エントリの経路満了時に、6LRはDCOを開始することによってエントリを厳しくクリーンアップすることを決定することができます。
2. A 6LR needs to entertain higher-priority entries in case the routing table is full, thus resulting in eviction of an existing routing entry. In this case, the eviction can be handled graciously by using a DCO.
2. ルーティングテーブルがいっぱいの場合には、6LRが優先度の高いエントリを楽しませ、したがって既存のルーティングエントリの立ち退きをもたらす必要があります。この場合、DCOを使用することで慎重に追い出すことができます。
A DCO that is generated asynchronously to a DAO message and is meant to discard all state along the path regardless of the Path Sequence MUST use a Path Sequence value of 240 (see Section 7.2 of [RFC6550]). This value allows the DCO to win against any established DAO path but to lose against a DAO path that is being installed. Note that if an ancestor initiates a unilateral path cleanup on an established path using a DCO with a Path Sequence value of 240, the DCO will eventually reach the target node, which will thus be informed of the path invalidation.
DAOメッセージと非同期的に生成され、パスシーケンスに関係なくパスに沿ってすべての状態を破棄することを目的としたDCOが240のパスシーケンス値を使用する必要があります（[RFC6550]のセクション7.2を参照）。この値により、DCOは確立されたDAOパスに対して勝つが、インストールされているDAOパスに対して負けます。祖先がPATHシーケンス値240のDCOを使用して確立されたパスで一方的なパスクリーンアップを開始すると、DCOは最終的にターゲットノードに到達します。これにより、パスの無効化が通知されます。
The RPL specification [RFC6550] does not provide a mechanism for route invalidation for dependent nodes. This document allows the invalidation of dependent nodes. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in a manner similar to what is described for a switching node. The dependent node may set the 'I' flag in the Transit Information option as part of a regular DAO so as to request invalidation of the previous route from the common ancestor node.
RPL仕様[RFC6550]は、従属ノードにルーティング無効化のためのメカニズムを提供しません。この文書では、従属ノードの無効化を許可します。従属ノードは、それらのパスを更新するためのそれぞれのDAOを生成し、それらのノードに対する以前のルート無効化は、スイッチングノードについて説明されているものと同様の方法で動作する必要があります。従属ノードは、共通の先祖ノードから前のルートの無効化を要求するために、通常のDAOの一部として「i」フラグを定期的なDAOの一部として設定することができます。
Dependent nodes do not have any indication regarding whether any of their parents have in turn decided to switch their parent. Thus, for route invalidation, the dependent nodes may choose to always set the 'I' flag in all their DAO messages' Transit Information options. Note that setting the 'I' flag is not counterproductive even if there is no previous route to be invalidated.
依存ノードは、両親が自分の親を切り替えることを決定したかどうかに関する指示はありません。したがって、ルートの無効化の場合、従属ノードは常に「i」フラグをすべてのDAOメッセージの通過情報オプションに設定することを選択できます。無効になる前のルートがない場合でも、 'i'フラグを設定することは逆になることに注意してください。
The NPDAO mechanism provided in [RFC6550] can still be used in the same network where a DCO is used. NPDAO messaging can be used, for example, on route lifetime expiry of the target or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown. Moreover, a deployment can have a mix of nodes supporting the DCO and the existing NPDAO mechanism. It is also possible that the same node supports both NPDAO and DCO signaling for route invalidation.
[RFC6550]で提供されているNPDAOメカニズムは、DCOが使用されているのと同じネットワークで使用できます。たとえば、NPDAOメッセージングは、たとえば、ターゲットの寿命の有効期限、またはノードが正常なノードのシャットダウンでRPLセッションを正常に終了することを単に決定するときに使用できます。さらに、展開は、DCOと既存のNPDAOメカニズムをサポートするノードの組み合わせを持つことができます。同じノードがルーティング無効化のためにNPDAOとDCOシグナリングの両方をサポートすることも可能です。
Section 9.8 of [RFC6550] states, "When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message (Section 6.4.3) to that removed DAO parent to invalidate the existing route." This document introduces an alternative and more optimized way to perform route invalidation, but it also allows existing NPDAO messaging to work. Thus, an implementation has two choices to make when a route invalidation is to be initiated:
[RFC6550]のセクション9.8は、「ノードがDAO親セットからノードを削除すると、既存のルートを無効にするためにDAO親を削除したDAO親メッセージ（6.4.3）を送信する必要があります。」このドキュメントでは、ルートの無効化を実行するための代替的かつ最適化された方法を紹介しますが、既存のNPDAOメッセージングも機能することもできます。したがって、実装にはルートの無効化が開始されるときに行うための2つの選択肢があります。
1. Use an NPDAO to invalidate the previous route, and send a regular DAO on the new path.
1. NPDAOを使用して前のルートを無効にし、新しいパスに通常のDAOを送信します。
2. Send a regular DAO on the new path with the 'I' flag set in the Transit Information option such that the common ancestor node initiates the DCO message downstream to invalidate the previous route.
2. 共通の先祖ノードがDCOメッセージをダウンストリームで無効にするためにDCOメッセージを開始するように、「i」フラグを「i」フラグに設定して、新しいパスに通常のDAOを送信します。
This document recommends using option 2, for the reasons specified in Section 3 of this document.
このドキュメントのセクション3で指定されている理由は、オプション2を使用することをお勧めします。
This document assumes that all the 6LRs in the network support this specification. If there are 6LR nodes that do not support this document that are in the path of the DCO message transmission, then the route invalidation for the corresponding targets (targets that are in the DCO message) may not work or may work partially. Alternatively, a node could generate an NPDAO if it does not receive a DCO with itself as the target within a specified time limit. The specified time limit is deployment specific and depends upon the maximum depth of the network and per-hop average latency. Note that sending an NPDAO and a DCO for the same operation would not result in unwanted side effects because the acceptability of an NPDAO or a DCO depends upon the Path Sequence freshness.
この文書では、ネットワーク内のすべての6LRがこの仕様をサポートしていると想定しています。DCOメッセージ送信のパス内にあるこの文書をサポートしていない6LRノードがある場合は、対応するターゲット（DCOメッセージ内にあるターゲット）に対するルートの無効化が機能しないか、または部分的に機能する可能性があります。あるいは、ノードは、指定された制限時間内にターゲットとしてDCOを受信しない場合、NPDAOを生成することもできます。指定された制限時間はデプロイメント固有であり、ネットワークの最大深さと1ホップ平均待ち時間に依存します。NPDAOおよびDCOを同じ操作のために送信することは、NPDAOまたはDCOの許容性が経路配列の鮮度に依存するので、不要な副作用をもたらさないであろう。
A DCO message could be retried by a sender if it sets the 'K' flag and does not receive a DCO-ACK. The DCO retry time could be dependent on the maximum depth of the network and average per-hop latency. This could range from 2 seconds to 120 seconds, depending on the deployment. If the latency limits are not known, an implementation MUST NOT retry more than once in 3 seconds and MUST NOT retry more than three times.
DCOメッセージは「k」フラグを設定し、DCO-ACKを受信しない場合は、送信者によって再試行できます。DCOの再試行時間は、ネットワークの最大深さと平均ホップの待ち時間に依存する可能性があります。展開に応じて、これは2秒から120秒の範囲です。待ち時間の制限がわからない場合、実装は3秒以内に複数回再試行してはならず、3回以上再試行しないでください。
The number of retries could also be set depending on how critical the route invalidation could be for the deployment and the link-layer retry configuration. For networks supporting only Multi-Point to Point (MP2P) and Point-to-Multipoint (P2MP) flows, such as in Advanced Metering Infrastructure (AMI) and telemetry applications, the 6LRs may not be very keen to invalidate routes, unless they are highly memory constrained. For home and building automation networks that may have substantial P2P traffic, the 6LRs might be keen to invalidate efficiently because it may additionally impact forwarding efficiency.
ルートの無効化が展開とリンクレイヤの再試行設定になることができるかに応じて、再試行回数も設定できます。高度な計量インフラストラクチャ（AMI）やテレメトリアプリケーションなどのマルチポイントツーポイント（MP2P）およびポイントツーマルチポイント（P2MP）フローのみをサポートするネットワークの場合、6LRはルートを無効にしていない可能性があります。非常にメモリが制限されていました。実質的なP2Pトラフィックを持つ可能性があるホームおよびビルディングオートメーションネットワークの場合、6LRは、さらに転送効率に影響を与える可能性があるため、効率的に無効になるように熱心になります。
[RFC6550] allows a node to select multiple preferred parents for route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs generated at the same time for the same target MUST be sent with the same Path Sequence in the Transit Information." Subsequently, when route invalidation has to be initiated, an NPDAO, which can be initiated with an updated Path Sequence to all the parent nodes through which the route is to be invalidated, can be used; see [RFC6550].
[RFC6550]は、ノードがルート設立のために複数の優先親を選択することを可能にします。[RFC6550]のセクション9.2.1は、「同じターゲットに対して同時に生成されたすべてのDAOは、トランジット情報の同じパスシーケンスで送信する必要があります」。続いて、経路無効化を開始する必要がある場合、ルートを無効にするすべての親ノードに更新されたパスシーケンスで開始することができるNPDAOを使用することができる。[RFC6550]を参照してください。
With a DCO, the target node itself does not initiate the route invalidation; this is left to the common ancestor node. A common ancestor node when it discovers an updated DAO from a new next hop, it initiates a DCO. It is recommended that an implementation initiate a DCO after a time period (DelayDCO) such that the common ancestor node may receive updated DAOs from all possible next hops. This will help to reduce DCO control overhead, i.e., the common ancestor can wait for updated DAOs from all possible directions before initiating a DCO for route invalidation. After timeout, the DCO needs to be generated for all the next hops for which the route invalidation needs to be done.
DCOを使用すると、ターゲットノード自体はルートの無効化を開始しません。これは共通の先祖ノードに残ります。共通の先祖ノードそれが新しいネクストホップから更新されたDAOを検出すると、DCOを開始します。一般的な先祖ノードがすべての可能なホップから更新されたDAOを受信できるように、実装は期間（DelayDCO）の後にDCOを開始することをお勧めします。これはDCO制御のオーバーヘッドを減らすのに役立ちます、すなわち一般的な先祖は、ルート無効化のためにDCOを開始する前に、すべての可能な方向から更新されたDAOを待つことができる。タイムアウト後、ルートの無効化を実行する必要があるすべての次のホップに対してDCOを生成する必要があります。
This document recommends using a DelayDCO timer value of 1 second. This value is inspired by the default DelayDAO timer value of 1 second [RFC6550]. Here, the hypothesis is that the DAOs from all possible parent sets would be received on the common ancestor within this time period.
この文書は、1秒のDelayDCOタイマー値を使用することをお勧めします。この値は、1秒[RFC6550]のデフォルトのDelaindDaoタイマ値にインスパイアされています。ここで、仮説は、すべての可能な親セットのDAOがこの期間内に共通の祖先で受信されることです。
It is still possible that a DCO is generated before all the updated DAOs from all the paths are received. In this case, the ancestor node would start the invalidation procedure for paths from which the updated DAO is not received. The DCO generated in this case would start invalidating the segments along these paths on which the updated DAOs are not received. But once the DAO reaches these segments, the routing state would be updated along these segments; this should not lead to any inconsistent routing states.
すべてのパスから更新されたすべてのDAOが受信される前にDCOが生成される可能性があります。この場合、先祖ノードは、更新されたDAOが受信されないパスの無効化手順を開始します。この場合に生成されたDCOは、更新されたDAOが受信されていないこれらのパスに沿ってセグメントの無効化を開始します。しかし、DAOがこれらのセグメントに達すると、ルーティング状態はこれらのセグメントに沿って更新されます。これは矛盾するルーティング状態につながるはずです。
Note that there is no requirement for synchronization between a DCO and DAOs. The DelayDCO timer simply ensures that DCO control overhead can be reduced and is only needed when the network contains nodes using multiple preferred parents.
DCOとDAOとの間の同期が要求されていないことに注意してください。DelayDCOタイマーは、DCOコントロールオーバーヘッドを削減できるようにするだけで、ネットワークに複数の優先親を使用してノードが含まれている場合にのみ必要です。
IANA has allocated codes for the DCO and DCO-ACK messages from the "RPL Control Codes" registry.
IANAは、「RPL制御コード」レジストリからDCOメッセージとDCO-ACKメッセージの割り当てコードを割り当てました。
+======+===========================================+===============+
| Code | Description | Reference |
+======+===========================================+===============+
| 0x07 | Destination Cleanup Object | This document |
+------+-------------------------------------------+---------------+
| 0x08 | Destination Cleanup Object Acknowledgment | This document |
+------+-------------------------------------------+---------------+
| 0x87 | Secure Destination Cleanup Object | This document |
+------+-------------------------------------------+---------------+
| 0x88 | Secure Destination Cleanup Object | This document |
| | Acknowledgment | |
+------+-------------------------------------------+---------------+
Table 1: New Codes for DCO and DCO-ACK Messages
表1：DCOおよびDCO-ACKメッセージの新しいコード
IANA has allocated bit 1 from the "Transit Information Option Flags" registry for the 'I' flag (Invalidate previous route; see Section 4.2).
IANAは、「i」フラグ（前のルートを無効にする; 4.2を参照）の「トランジット情報オプションフラグ」レジストリからビット1を割り当てました。
IANA has created a registry for the 8-bit Destination Cleanup Object (DCO) Flags field. The "Destination Cleanup Object (DCO) Flags" registry is located in the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
IANAは、8ビット宛先クリーンアップオブジェクト（DCO）FLAGSフィールドのレジストリを作成しました。「デスティネーションクリーンアップオブジェクト（DCO）フラグ」レジストリは、「低電力および非損失ネットワーク（RPL）」レジストリの「ルーティングプロトコル」にあります。
New bit numbers may be allocated only by IETF Review [RFC8126]. Each bit is tracked with the following qualities:
新しいビット数はIETFレビュー[RFC8126]によってのみ割り当てられます。各ビットは以下の資質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット数（最上位ビットとしてのビット0からのカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCを定義する
The following bits are currently defined:
次のビットが現在定義されています。
+============+==============================+===============+
| Bit number | Description | Reference |
+============+==============================+===============+
| 0 | DCO-ACK request (K) | This document |
+------------+------------------------------+---------------+
| 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
Table 2: DCO Base Flags
表2：DCO基本フラグ
5.2. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags
5.2. 宛先クリーンアップオブジェクト（DCO）確認フラグ用の新しいレジストリ
IANA has created a registry for the 8-bit Destination Cleanup Object (DCO) Acknowledgment Flags field. The "Destination Cleanup Object (DCO) Acknowledgment Flags" registry is located in the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry.
IANAは、8ビットの宛先クリーンアップオブジェクト（DCO）確認フラグフィールドのレジストリを作成しました。「宛先クリーンアップオブジェクト（DCO）確認応答フラグ」レジストリは、「低電力および非可逆ネットワーク（RPL）」レジストリの「ルーティングプロトコル」にあります。
New bit numbers may be allocated only by IETF Review [RFC8126]. Each bit is tracked with the following qualities:
新しいビット数はIETFレビュー[RFC8126]によってのみ割り当てられます。各ビットは以下の資質で追跡されます。
* Bit number (counting from bit 0 as the most significant bit)
* ビット数（最上位ビットとしてのビット0からのカウント）
* Capability description
* 機能の説明
* Defining RFC
* RFCを定義する
The following bit is currently defined:
次のビットが現在定義されています。
+============+==============================+===============+
| Bit number | Description | Reference |
+============+==============================+===============+
| 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
Table 3: DCO-ACK Base Flag
表3：DCO-ACKベースフラグ
This document adds a new status value to the "RPL Rejection Status" subregistry initially created per Section 12.6 of [RFC9010].
このドキュメントは、[RFC9010]のセクション12.6ごとに最初に作成された「RPL拒否ステータス」サブレクシストに新しいステータス値を追加します。
+=======+==================+===============+
| Value | Meaning | Reference |
+=======+==================+===============+
| 1 | No routing entry | This document |
+-------+------------------+---------------+
Table 4: Rejection Value of the RPL Status
表4：RPLステータスの拒否値
This document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. The common ancestor node could be directed to do so by the target node, using the 'I' flag in a DCO's Transit Information option. However, the common ancestor node is in a position to unilaterally initiate the route invalidation, since it possesses all the required state information, namely, the Target Address and the corresponding Path Sequence. Thus, a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node.
この文書では、共通の先祖ノードがターゲットノードに代わってルートを無効にする機能を紹介します。Common Ancestorノードは、DCOのTransit Informationオプションの 'i'フラグを使用して、ターゲットノードによってそうするように指示されます。しかしながら、共通の先祖ノードは、必要な状態情報、すなわちターゲットアドレスおよび対応するパスシーケンスをすべて有するので、経路無効化を一方的に開始する位置にある。したがって、不正な共通の祖先ノードはそのような無効化を開始し、トラフィックにターゲットノードへの影響を与える可能性があります。
The DCO carries a RPL Status value, which is informative. New Status values may be created over time, and a node will ignore an unknown Status value. This enables the RPL Status field to be used as a cover channel. But the channel only works once, since the message destroys its own medium, i.e., the existing route that it is removing.
DCOはRPLステータス値を運びます。これは有益です。新しいステータス値を経時的に作成することができ、ノードは未知のステータス値を無視します。これにより、RPLステータスフィールドをカバーチャネルとして使用することができます。しかし、チャネルは一度だけ機能します。
This document also introduces an 'I' flag, which is set by the target node and used by the ancestor node to initiate a DCO if the ancestor sees an update in the routing adjacency. However, this flag could be spoofed by a malicious 6LR in the path and can cause invalidation of an existing active path. Note that invalidation will work only if the Path Sequence condition is also met for the target for which the invalidation is attempted. Having said that, such a malicious 6LR may spoof a DAO on behalf of the (sub) child with the 'I' flag set and can cause route invalidation on behalf of the (sub) child node. Note that by using existing mechanisms offered by [RFC6550], a malicious 6LR might also spoof a DAO with a lifetime of zero or otherwise cause denial of service by dropping traffic entirely, so the new mechanism described in this document does not present a substantially increased risk of disruption.
この文書はまた、ターゲットノードによって設定され、先祖がルーティング隣接の更新を見ればDCOを開始するために先祖ノードによって使用される「i」フラグを紹介します。ただし、このフラグはパス内の悪意のある6LRによって偽装する可能性があり、既存のアクティブパスの無効化を引き起こす可能性があります。無効化が試行されたターゲットに対してPATHシーケンス条件も満たされている場合にのみ、無効化が機能します。そのような悪意のある6LRは、そのような悪意のある6LRが「i」の子を代表して、（サブ）子を設定し、（サブ）子ノードに代わって経路の無効化を引き起こす可能性がある。[RFC6550]で提供される既存のメカニズムを使用することで、悪意のある6LRもゼロの存続可能なDAO、またはその他の方法でトラフィックを落とすことによってサービス拒否を引き起こす可能性があるため、この文書に記載されている新しいメカニズムは実質的に増加していません。混乱の危険性。
This document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials. A non-secure RPL network needs to take into consideration the risks highlighted in this section as well as those highlighted in [RFC6550].
この文書では、[RFC6550]で定義されているセキュリティメカニズムに従うと仮定します。つまり、共通の先祖ノードとすべての6LRが必要な資格情報を持つため、RPLネットワークの一部であることを示しています。非セキュアRPLネットワークは、このセクションで強調表示されているリスクと[RFC6550]で強調表示されているリスクを考慮する必要があります。
All RPL messages support a secure version of messages; this allows integrity protection using either a Message Authentication Code (MAC) or a signature. Optionally, secured RPL messages also have encryption protection for confidentiality.
すべてのRPLメッセージは、セキュアバージョンのメッセージをサポートしています。これにより、メッセージ認証コード（MAC）または署名のいずれかを使用した整合性保護が可能です。任意選択で、保護されたRPLメッセージにも機密性のための暗号化保護があります。
This document adds new messages (DCO and DCO-ACK) that are syntactically similar to existing RPL messages such as DAO and DAO-ACK. Secure versions of DCO and DCO-ACK messages are added in a way that is similar to the technique used for other RPL messages (such as DAO and DAO-ACK).
このドキュメントは、DAOやDAO-ACKなどの既存のRPLメッセージと構文的に似ている新しいメッセージ（DCOとDCO-ACK）を追加します。安全なバージョンのDCOおよびDCO-ACKメッセージは、他のRPLメッセージ（DAOやDAO-ACKなど）に使用されるテクニックと似ている方法で追加されます。
RPL supports three security modes, as mentioned in Section 10.1 of [RFC6550]:
[RFC6550]のセクション10.1で述べたように、RPLは3つのセキュリティモードをサポートします。
Unsecured: In this mode, it is expected that the RPL control messages are secured by other security mechanisms, such as link-layer security. In this mode, the RPL control messages, including DCO and DCO-ACK messages, do not have Security sections. Also note that unsecured mode does not imply that all messages are sent without any protection.
無担保：このモードでは、RPL制御メッセージは、リンクレイヤセキュリティなどの他のセキュリティメカニズムによって保護されていると予想されます。このモードでは、DCOおよびDCO-ACKメッセージを含むRPL制御メッセージにセキュリティセクションがありません。無担保モードでは、すべてのメッセージが保護なしで送信されることを意味しないことに注意してください。
Preinstalled: In this mode, RPL uses secure messages. Thus, secure versions of DCO and DCO-ACK messages MUST be used in this mode.
プレインストール：このモードでは、RPLはセキュアメッセージを使用します。したがって、このモードでは、DCOおよびDCO-ACKメッセージの安全なバージョンを使用する必要があります。
Authenticated: In this mode, RPL uses secure messages. Thus, secure versions of DCO and DCO-ACK messages MUST be used in this mode.
認証済み：このモードでは、RPLはセキュアメッセージを使用します。したがって、このモードでは、DCOおよびDCO-ACKメッセージの安全なバージョンを使用する必要があります。
[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>。
[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>。
[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>。
[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>。
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021, <https://www.rfc-editor.org/info/rfc9010>.
[RFC9010] Thubert、P、ED。M. RiChardson「RPLのルーティング（低消費電力ネットワークのためのルーティングプロトコル）葉」、RFC 9010、DOI 10.17487 / RFC9010、2021年4月、<https://www.rfc-editor.org/info/rfc9010>。
In this example, Node D (Figure 1) switches its parent from B to C. This example assumes that Node D has already established its own route via Node B-G-A-6LBR using pathseq=x. The example uses DAO and DCO messaging conventions and specifies only the required parameters to explain the example, namely, the parameter 'tgt', which stands for "Target option"; the value of this parameter specifies the address of the target node. The parameter 'pathseq' specifies the Path Sequence value carried in the Transit Information option, and the parameter 'I_flag' specifies the 'I' flag in the Transit Information option. The sequence of actions is as follows:
この例では、ノードD（図1）は、その親をBからCに切り替えます。この例では、ノードDがPathSeq = Xを使用してノードB-G-A-6LBRを介して既に独自の経路を確立していると仮定します。この例では、DAOとDCOメッセージングの表記規則を使用し、「ターゲットオプション」を表すパラメータ 'TGT'を説明するために必要なパラメータのみを指定します。このパラメータの値は、ターゲットノードのアドレスを指定します。パラメータ 'pathseq'は、Transit Informationオプションで実行されているパスシーケンス値を指定し、パラメータ 'i_flag'はTransit Informationオプションの 'i'フラグを指定します。一連の動作は次のとおりです。
1. Node D switches its parent from Node B to Node C.
1. ノードDは、その親をノードBからノードCに切り替える。
2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated path to C.
2. dは、更新されたパスに通常のDAO（TGT = D、PATHSEQ = X 1、I_FLAG = 1）をCに送信します。
3. C checks for a routing entry on behalf of D; since it cannot find an entry on behalf of D, it creates a new routing entry and forwards the reachability information of the target D to H in a DAO(tgt=D,pathseq=x+1,I_flag=1).
3. cは、dの代わりにルーティングエントリをチェックします。Dに代わってエントリが見つからないため、新しいルーティングエントリを作成し、DAO（TGT = D、PATHSEQ = X 1、I_FLAG = 1）のターゲットDの到達可能性情報をHに転送します。
4. Similar to C, Node H checks for a routing entry on behalf of D, cannot find an entry, and hence creates a new routing entry and forwards the reachability information of the target D to A in a DAO(tgt=D,pathseq=x+1,I_flag=1).
4. Cと同様に、ノードHはDに代わってルーティングエントリをチェックし、エントリを見つけることができないため、新しいルーティングエントリを作成し、ターゲットDの到達可能性情報をDAOのaのaに転送します（tgt = d、pathseq = x1、i_flag = 1）。
5. Node A receives the DAO(tgt=D,pathseq=x+1,I_flag=1) and checks for a routing entry on behalf of D. It finds a routing entry but checks that the next hop for target D is different (i.e., Node G). Node A checks the I_flag and generates the DCO(tgt=D,pathseq=x+1) to the previous next hop for target D, which is G. Subsequently, Node A updates the routing entry and forwards the reachability information of target D upstream using the DAO(tgt=D,pathseq=x+1,I_flag=1).
5. ノードAはDAO（TGT = D、PATSSEQ = 1、I_FLAG = 1）を受信し、Dに代わってルーティングエントリをチェックします。ルーティングエントリはルーティングエントリを見つけますが、ターゲットDのネクストホップが異なることを確認します（つまり、ノードg）。ノードAは、i_flagをチェックし、GであるターゲットDの前の次のホップにDCO（TGT = D、PATHSEQ = X 1）を生成します。DAO（TGT = D、PATHSEQ = X 1、I_FLAG = 1）。
6. Node G receives the DCO(tgt=D,pathseq=x+1). It checks to see if the received Path Sequence is later than the stored Path Sequence. If it is later, Node G invalidates the routing entry of target D and forwards the (un)reachability information downstream to B in the DCO(tgt=D,pathseq=x+1).
6. ノードGはDCOを受信する（TGT = D、PATHSEQ = X 1）。受信したパスシーケンスが格納されているパスシーケンスより遅いかどうかを確認します。後で、ノードGはターゲットDのルーティングエントリを無効にし、DCO内の（UN）到達可能性情報を下流に転送する（TGT = D、PATHSEQ = X 1）。
7. Similarly, B processes the DCO(tgt=D,pathseq=x+1) by invalidating the routing entry of target D and forwards the (un)reachability information downstream to D.
7. 同様に、BはターゲットDのルーティングエントリを無効にしてDCO（TGT = D、PATHSEQ = X 1）を処理し、（UN）到達可能性情報をDに転送することによってDCOを処理します。
8. D ignores the DCO(tgt=D,pathseq=x+1), since the target is itself.
8. ターゲットはそれ自体であるため、DCO（TGT = D、PATHSEQ = X 1）を無視します。
9. The propagation of the DCO will stop at any node where the node does not have routing information associated with the target. If cached routing information is present and the cached Path Sequence is higher than the value in the DCO, then the DCO is dropped.
9. DCOの伝播は、ノードがターゲットに関連付けられているルーティング情報を持たない任意のノードで停止します。キャッシュされたルーティング情報が存在し、キャッシュされたパスシーケンスがDCO内の値より高い場合、DCOはドロップされます。
As shown in Figure 5, node (N41) selects multiple preferred parents (N32) and (N33). The sequence of actions is listed below the figure.
図5に示すように、ノード（N41）は複数の好ましい親（N32）および（N33）を選択する。一連の動作を図の下に示します。
(6LBR)
|
|
|
(N11)
/ \
/ \
/ \
(N21) (N22)
/ / \
/ / \
/ / \
(N31) (N32) (N33)
: | /
: | /
: | /
(N41)
Figure 5: Sample Topology 2
図5：サンプルトポロジ2.
1. (N41) sends a DAO(tgt=N41,PS=x,I_flag=1) to (N32) and (N33). Here, 'I_flag' refers to the Invalidation flag, and 'PS' refers to the Path Sequence in the Transit Information option.
1. （N41）DAO（TGT = N41、PS = X、I_FLAG = 1）〜（N32）および（N33）を送信する。ここで、 'i_flag'は無効化フラグを指し、 'PS'はTransit Informationオプションのパスシーケンスを指します。
2. (N32) sends the DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N33) also sends the DAO(tgt=N41,PS=x,I_flag=1) to (N22). (N22) learns multiple routes for the same destination (N41) through multiple next hops. (N22) may receive the DAOs from (N32) and (N33) in any order with the I_flag set. The implementation should use the DelayDCO timer to wait to initiate the DCO. If (N22) receives an updated DAO from all the paths, then the DCO need not be initiated in this case. Thus, the routing table at N22 should contain (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }.
2. （N32）DAO（TGT = N41、PS = X、I_FLAG = 1）〜（N22）を送信します。（N33）もDAO（TGT = N41、PS = X、I_FLAG = 1）〜（N22）を送信する。（N22）複数のネクストホップを介して同じ宛先（N41）の複数のルートを学習します。（N22）は、I_Flagセットを用いて任意の順序で（N32）および（N33）からDAOを受信することができる。実装はDCOを開始するのを待つためにDelayDCOタイマーを使用する必要があります。（N22）がすべてのパスから更新されたDAOを受信した場合、この場合、DCOを開始する必要はありません。したがって、N22のルーティングテーブルには（DST、NexThop、PS）を含める必要があります。{（N41、N32、X）、（N41、N33、X）}。
3. (N22) sends the DAO(tgt=N41,PS=x,I_flag=1) to (N11).
3. （N22）DAO（TGT = N41、PS = X、I_FLAG = 1）〜（N11）を送信します。
4. (N11) sends the DAO(tgt=N41,PS=x,I_flag=1) to (6LBR). Thus, the complete path is established.
4. （N11）DAO（TGT = N41、PS = X、I_FLAG = 1）を（6LBR）に送信します。したがって、完全な経路が確立される。
5. (N41) decides to change the preferred parent set from { N32, N33 } to { N31, N32 }.
5. （N41）{N32、N33}から{N31、N32}に設定されている優先親セットを変更することを決定します。
6. (N41) sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N32). (N41) sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N31).
6. （N41）DAO（TGT = N41、PS = X 1、I_FLAG = 1）〜（N32）を送信します。（N41）DAO（TGT = N41、PS = X 1、I_FLAG = 1）を（N31）に送信します。
7. (N32) sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N22). (N22) has multiple routes to destination (N41). It sees that a new Path Sequence for Target=N41 is received and thus waits for a predetermined time period (the DelayDCO time period) to invalidate another route { (N41),(N33),x }. After the time period, (N22) sends the DCO(tgt=N41,PS=x+1) to (N33). Also (N22) sends the regular DAO(tgt=N41,PS=x+1,I_flag=1) to (N11).
7. （N32）DAO（TGT = N41、PS = X 1、I_FLAG = 1）〜（N22）を送信します。（n22）宛先への複数のルートがあります（N41）。ターゲット= N41のための新しいパスシーケンスを受信し、したがって所定の期間（DelayDCO期間）を待つことを見て、別の経路{（N41）、（N33）、X}を無効にする。期間後（N22）はDCO（TGT = N41、PS = X 1）〜（N33）を送信する。また、（N22）通常のDAO（TGT = N41、PS = X 1、I_FLAG = 1）〜（N11）を送信する。
8. (N33) receives the DCO(tgt=N41,PS=x+1). The received Path Sequence is the latest and thus invalidates the entry associated with the target (N41). (N33) then sends the DCO(tgt=N41,PS=x+1) to (N41). (N41) sees itself as the target and drops the DCO.
8. （N33）DCOを受け取る（TGT = N41、PS = X 1）。受信したパスシーケンスは最新のものであり、したがってターゲットに関連付けられているエントリを無効にします（N41）。（N33）次にDCO（TGT = N41、PS = X 1）を（N41）に送信する。（n41）それ自体をターゲットとして見て、DCOを落とします。
9. From Step 6 above, (N31) receives the DAO(tgt=N41,PS=x+1,I_flag=1). It creates a routing entry and sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N21). Similarly, (N21) receives the DAO and subsequently sends the DAO(tgt=N41,PS=x+1,I_flag=1) to (N11).
9. 上記のステップ6から（N31）DAOを受信する（TGT = N41、PS = X 1、I_FLAG = 1）。ルーティングエントリを作成し、DAO（TGT = N41、PS = X 1、I_FLAG = 1）を（N21）に送信します。同様に、（N21）DAOを受信し、続いてDAO（TGT = N41、PS = X 1、I_FLAG = 1）を（N11）に送信する。
10. (N11) receives the DAO(tgt=N41,PS=x+1,I_flag=1) from (N21). It waits for the DelayDCO timer, since it has multiple routes to (N41). (N41) will receive the DAO(tgt=N41,PS=x+1,I_flag=1) from (N22) from Step 7 above. Thus, (N11) has received the regular DAO(tgt=N41,PS=x+1,I_flag=1) from all paths and thus does not initiate the DCO.
10. （N11）（N21）からDAO（TGT = N41、PS = X 1、I_FLAG = 1）を受信する。これは、（N41）に複数のルートがあるため、DelayDCOタイマーを待ちます。（n41）は上記のステップ7からDAO（TGT = N41、PS = X 1、I_FLAG = 1）を受信する。したがって、（N11）は、すべてのパスから通常のDAO（TGT = N41、PS = X 1、I_FLAG = 1）を受信し、したがってDCOを開始しない。
11. (N11) forwards the DAO(tgt=N41,PS=x+1,I_flag=1) to (6LBR), and the full path is established.
11. （N11）DAO（TGT = N41、PS = X 1、I_FLAG = 1）を（6LBR）に転送し、フルパスを確立します。
Acknowledgments
謝辞
Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulos, and Peter van der Stok for their review and comments. Alvaro Retana helped shape this document's final version with critical review comments.
Alvaro Retana、CeNk Gundogan、Simon Duquennoy、Georgios Papadopoulos、およびPeter Van Der Stok、レビューやコメントに感謝します。Alvaro Retanaがこのドキュメントの最終版を重大なレビューのコメントで形作るのに役立ちました。
Authors' Addresses
著者の住所
Rahul Arvind Jadhav (editor) Huawei Whitefield Kundalahalli Village Bangalore 560037 Karnataka India
Rahul Arvind Jadhav（編集）Huawei Whitefield Kundalahalli Village Bangalore 560037 Karnataka India
Phone: +91-080-49160700
Email: rahul.ietf@gmail.com
Pascal Thubert Cisco Systems, Inc. Building D 45 Allee des Ormes - BP1200 06254 MOUGINS - Sophia Antipolis France
Pascal Thubert Cisco Systems、Inc。建物D 45 Allee Des Ormes - BP1200 06254 Mougins - ソフィアアンティポリスフランス
Phone: +33-497-23-26-34
Email: pthubert@cisco.com
Rabi Narayan Sahoo Huawei Whitefield Kundalahalli Village Bangalore 560037 Karnataka India
Rabi Narayan Sahoo Huawei Whitefield Kundalahalli Villageバンガロール560037カルナタカインド
Phone: +91-080-49160700
Email: rabinarayans0828@gmail.com
Zhen Cao Huawei W Chang'an Ave Beijing China
Zhen Cao Huawei W Chang'an Ave Beijing China
Email: zhencao.ietf@gmail.com