[要約] RFC 6971は、信頼性の低いネットワークでの深さ優先転送（DFF）に関する情報を提供する。DFFは、ネットワークの信頼性を向上させるための手法であり、このRFCはその目的と実装の詳細を説明している。
Internet Engineering Task Force (IETF) U. Herberg, Ed.
Request for Comments: 6971 Fujitsu
Category: Experimental A. Cardenas
ISSN: 2070-1721 University of Texas at Dallas
T. Iwao
Fujitsu
M. Dow
Freescale
S. Cespedes
Icesi University
June 2013
Depth-First Forwarding (DFF) in Unreliable Networks
信頼性の低いネットワークでの深度優先転送（DFF）
Abstract
概要
This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, a data-forwarding mechanism that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. The protocol operates entirely on the forwarding plane but may interact with the routing plane. DFF forwards data packets using a mechanism similar to a "depth-first search" for the destination of a packet. The routing plane may be informed of failures to deliver a packet or loops. This document specifies the DFF mechanism both for IPv6 networks (as specified in RFC 2460) and for "mesh-under" Low-Power Wireless Personal Area Networks (LoWPANs), as specified in RFC 4944. The design of DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not. It is applicable for networks with little traffic and is used for unicast transmissions only.
このドキュメントでは、IPv6ネットワーク用の深さ優先転送（DFF）プロトコルを指定します。これは、動的トポロジや損失の多いリンクを持つネットワークでのデータ配信の信頼性を高めることができるデータ転送メカニズムです。プロトコルは完全に転送プレーンで動作しますが、ルーティングプレーンと相互作用する場合があります。 DFFは、パケットの宛先の「深さ優先検索」と同様のメカニズムを使用してデータパケットを転送します。ルーティングプレーンには、パケットまたはループの配信の失敗が通知される場合があります。このドキュメントでは、RFC 4944で指定されているように、IPv6ネットワーク（RFC 2460で指定されている）と「メッシュアンダー」低電力ワイヤレスパーソナルエリアネットワーク（LoWPAN）の両方のDFFメカニズムを指定しています。DFFの設計では、基になるリンクがレイヤは、パケットがネクストホップに正常に配信されたかどうかを検出する手段を提供します。トラフィックの少ないネットワークに適用でき、ユニキャスト送信にのみ使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6971.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6971で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Experiments to Be Conducted . . . . . . . . . . . . . . . 5
2. Notation and Terminology . . . . . . . . . . . . . . . . . . . 6
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
3. Applicability Statement . . . . . . . . . . . . . . . . . . . 9
4. Protocol Overview and Functioning . . . . . . . . . . . . . . 10
4.1. Overview of Information Sets . . . . . . . . . . . . . . . 11
4.2. Signaling Overview . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Dependencies . . . . . . . . . . . . . . . . . . . . 13
6. Information Sets . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Symmetric Neighbor List . . . . . . . . . . . . . . . . . 13
6.2. Processed Set . . . . . . . . . . . . . . . . . . . . . . 13
7. Packet Header Fields . . . . . . . . . . . . . . . . . . . . . 14
8. Protocol Parameters . . . . . . . . . . . . . . . . . . . . . 15
9. Data Packet Generation and Processing . . . . . . . . . . . . 15
9.1. Data Packets Entering the DFF Routing Domain . . . . . . . 16
9.2. Data Packet Processing . . . . . . . . . . . . . . . . . . 17
10. Unsuccessful Packet Transmission . . . . . . . . . . . . . . . 19
11. Determining the Next Hop for a Packet . . . . . . . . . . . . 20
12. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 21
13. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Route-Over . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1.1. Mapping of DFF Terminology to IPv6 Terminology . . . 22
13.1.2. Packet Format . . . . . . . . . . . . . . . . . . . . 22
13.2. Mesh-Under . . . . . . . . . . . . . . . . . . . . . . . . 24
13.2.1. Mapping of DFF Terminology to LoWPAN Terminology . . 24
13.2.2. Packet Format . . . . . . . . . . . . . . . . . . . . 25
14. Scope Limitation of DFF . . . . . . . . . . . . . . . . . . . 26
14.1. Route-Over MoP . . . . . . . . . . . . . . . . . . . . . . 28
14.2. Mesh-Under MoP . . . . . . . . . . . . . . . . . . . . . . 29
15. MTU Exceedance . . . . . . . . . . . . . . . . . . . . . . . . 30
16. Security Considerations . . . . . . . . . . . . . . . . . . . 31
16.1. Attacks That Are Out of Scope . . . . . . . . . . . . . . 31
16.2. Protection Mechanisms of DFF . . . . . . . . . . . . . . . 31
16.3. Attacks That Are in Scope . . . . . . . . . . . . . . . . 32
16.3.1. Denial of Service . . . . . . . . . . . . . . . . . . 32
16.3.2. Packet Header Modification . . . . . . . . . . . . . 32
16.3.2.1. Return Flag Tampering . . . . . . . . . . . . . . 32
16.3.2.2. Duplicate Flag Tampering . . . . . . . . . . . . 33
16.3.2.3. Sequence Number Tampering . . . . . . . . . . . . 33
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
19.1. Normative References . . . . . . . . . . . . . . . . . . . 34
19.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 36
A.1. Example 1: Normal Delivery . . . . . . . . . . . . . . . . 36
A.2. Example 2: Forwarding with Link Failure . . . . . . . . . 37
A.3. Example 3: Forwarding with Missed Link-Layer
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 38
A.4. Example 4: Forwarding with a Loop . . . . . . . . . . . . 39
Appendix B. Deployment Experience . . . . . . . . . . . . . . . . 40
B.1. Deployments in Japan . . . . . . . . . . . . . . . . . . . 40
B.2. Kit Carson Electric Cooperative . . . . . . . . . . . . . 40
B.3. Simulations . . . . . . . . . . . . . . . . . . . . . . . 40
B.4. Open-Source Implementation . . . . . . . . . . . . . . . . 40
This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, both for IPv6 forwarding [RFC2460] (henceforth denoted "route-over"), and also for "mesh-under" forwarding using the LoWPAN adaptation layer [RFC4944]. The protocol operates entirely on the forwarding plane but may interact with the routing plane. The purpose of DFF is to increase reliability of data delivery in networks with dynamic topologies and/or lossy links.
このドキュメントは、IPv6フォワーディング[RFC2460]（以降「ルートオーバー」と表記）、およびLoWPANアダプテーションレイヤー[RFC4944]を使用した「メッシュアンダー」フォワーディングの両方について、IPv6ネットワークの深度優先転送（DFF）プロトコルを指定します。プロトコルは完全に転送プレーンで動作しますが、ルーティングプレーンと相互作用する場合があります。 DFFの目的は、動的トポロジーや損失の多いリンクを持つネットワークでのデータ配信の信頼性を高めることです。
DFF forwards data packets using a "depth-first search" for the destination of the packets. DFF relies on an external neighborhood discovery mechanism that lists a router's neighbors that may be attempted as Next Hops for a data packet. In addition, DFF may use information from the Routing Information Base (RIB) for deciding in which order to try to send the packet to the neighboring routers.
DFFは、パケットの宛先の「深さ優先検索」を使用してデータパケットを転送します。 DFFは、データパケットのネクストホップとして試行される可能性のあるルーターのネイバーをリストする外部ネイバーディスカバリーメカニズムに依存しています。さらに、DFFはルーティング情報ベース（RIB）からの情報を使用して、隣接するルーターにパケットを送信しようとする順序を決定できます。
If the packet makes no forward progress using the first selected Next Hop, DFF will successively try all neighbors of the router. If none of the Next Hops successfully receives or forwards the packet, DFF returns the packet to the Previous Hop, which in turn tries to send it to alternate neighbors.
最初に選択されたネクストホップを使用してパケットが前進しない場合、DFFはルータのすべてのネイバーを連続して試行します。ネクストホップのいずれも正常にパケットを受信または転送しない場合、DFFはパケットを前のホップに戻し、次に前のホップが代替ネイバーへの送信を試みます。
As network topologies do not necessarily form trees, loops can occur. Therefore, DFF contains a loop detection and avoidance mechanism.
ネットワークトポロジは必ずしもツリーを形成しないため、ループが発生する可能性があります。したがって、DFFにはループ検出および回避メカニズムが含まれています。
DFF may provide information that may -- by a mechanism outside of this specification -- be used for updating the cost of routes in the RIB based on failed or successful delivery of packets through alternative Next Hops. Such information may also be used by a routing protocol.
DFFは、この仕様外のメカニズムにより、代替ネクストホップを介したパケットの配信の失敗または成功に基づいてRIBのルートのコストを更新するために使用できる情報を提供する場合があります。このような情報は、ルーティングプロトコルでも使用できます。
DFF assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not, is designed for networks with little traffic, and is used for unicast transmissions only.
DFFは、基礎となるリンク層がパケットがネクストホップに正常に配信されたかどうかを検出する手段を提供し、トラフィックの少ないネットワーク用に設計され、ユニキャスト送信にのみ使用されると想定しています。
In networks with dynamic topologies and/or lossy links, even frequent exchanges of control messages between routers for updating the routing tables cannot guarantee that the routes correspond to the effective topology of the network at all times. Packets may not be delivered to their destination because the topology has changed since the last routing protocol update.
動的なトポロジーや損失の多いリンクを持つネットワークでは、ルーティングテーブルを更新するためにルーター間で頻繁に制御メッセージを交換しても、ルートが常にネットワークの有効なトポロジーに対応しているとは限りません。前回のルーティングプロトコルの更新以降にトポロジが変更されたため、パケットが宛先に配信されない可能性があります。
More frequent routing protocol updates can mitigate that problem to a certain extent; however, this requires additional signaling, consuming channel and router resources (e.g., when flooding control messages through the network). This is problematic in networks with lossy links, where further control traffic exchange can worsen the network stability because of collisions. Moreover, additional control traffic exchange may drain energy from battery-driven routers.
ルーティングプロトコルの更新を頻繁に行うと、その問題をある程度緩和できます。ただし、これには追加のシグナリングが必要であり、チャネルとルーターのリソースを消費します（ネットワークを介して制御メッセージをフラッディングする場合など）。これは、不可逆リンクのあるネットワークでは問題があり、さらに制御トラフィックを交換すると、衝突が原因でネットワークの安定性が低下する可能性があります。さらに、追加の制御トラフィック交換により、バッテリー駆動のルーターからエネルギーが排出される場合があります。
The data-forwarding mechanism specified in this document allows for forwarding data packets along alternate paths for increasing reliability of data delivery, using a depth-first search. The objective is to decrease the necessary control traffic overhead in the network and, at the same time, to increase delivery success rates.
このドキュメントで指定されているデータ転送メカニズムでは、深さ優先検索を使用して、データ配信の信頼性を高めるために代替パスに沿ってデータパケットを転送できます。その目的は、ネットワークで必要な制御トラフィックのオーバーヘッドを減らすと同時に、配信成功率を高めることです。
As this specification is intended for experimentation, the mechanism is also specified for forwarding on the LoWPAN adaption layer (according to Section 11 of [RFC4944]), in addition to IPv6 forwarding as specified in [RFC2460]. Other than different header formats, the DFF mechanism for route-over and mesh-under is similar, and is therefore first defined in general and then more specifically for both IPv6 route-over forwarding (as specified in Section 13.1) and LoWPAN adaptation layer mesh-under (as specified in Section 13.2).
この仕様は実験を目的としているため、[RFC2460]で指定されているIPv6転送に加えて、LoWPANアダプテーション層での転送のメカニズムも指定されています（[RFC4944]のセクション11による）。異なるヘッダー形式を除いて、route-overとmesh-underのDFFメカニズムは類似しているため、最初に一般的に定義され、次にIPv6 route-over転送（セクション13.1で指定）とLoWPANアダプテーションレイヤーメッシュの両方に対してより具体的に定義されます。 -under（セクション13.2で指定）。
This document is presented as an Experimental specification that can increase reliability of data delivery in networks with dynamic topology and/or lossy links. It is anticipated that, once sufficient operational experience has been gained, this specification will be revised to progress it on to the Standards Track. This experiment is intended to be tried in networks that meet the applicability described in Section 3, and with the scope limitations set out in Section 14. While experimentation is encouraged in such networks, operators should exercise caution before attempting this experiment in other types of networks as the stability of interaction between DFF and routing in those networks has not been established.
このドキュメントは、動的トポロジーや損失の多いリンクを持つネットワークでのデータ配信の信頼性を向上させることができる実験的仕様として提示されています。十分な運用経験が得られたら、この仕様が改訂されて標準トラックに進むことが予想されます。この実験は、セクション3で説明されている適用範囲を満たし、範囲の制限がセクション14で設定されているネットワークで試行することを目的としています。このようなネットワークでは実験が推奨されますが、オペレーターは他のタイプのネットワークでこの実験を試行する前に注意する必要がありますこれらのネットワークでのDFFとルーティング間の相互作用の安定性が確立されていないためです。
Experience reports regarding DFF implementation and deployment are encouraged, particularly with respect to:
DFFの実装と展開に関する経験報告は、特に以下に関して推奨されます。
o Optimal values for the parameter P_HOLD_TIME, depending on the size of the network, the topology, and the amount of traffic originated per router. The longer a Processed Tuple is held, the more memory is consumed on a router. Moreover, if a tuple is held too long, a sequence number wrap-around may occur, and a new packet may have the same sequence number as one indicated in an old Processed Tuple. However, if the tuple is expired too soon (before the packet has completed its path to the destination), it may be mistakenly detected as a new packet instead of one already seen.
oパラメーターP_HOLD_TIMEの最適値。ネットワークのサイズ、トポロジー、およびルーターごとに発信されるトラフィックの量によって異なります。処理されたタプルが長く保持されるほど、ルーターで消費されるメモリが多くなります。さらに、タプルの保持時間が長すぎると、シーケンス番号の折り返しが発生し、新しいパケットのシーケンス番号が古い処理済みタプルで示されたものと同じになる場合があります。ただし、タプルの有効期限が早すぎると（パケットが宛先へのパスを完了する前に）、すでに検出されたタプルではなく、誤って新しいパケットとして検出される可能性があります。
o Optimal values for the parameter MAX_HOP_LIMIT, depending on the size of the network, the topology, and how lossy the link layer is. MAX_HOP_LIMIT makes sure that packets do not unnecessarily traverse in the network; it may be used to limit the "detour" of packets that is acceptable. The value may also be issued on a per-packet basis if hop-count information is available from the RIB or routing protocol. In such a case, the Hop Limit for the packet may be a percentage (e.g., 200%) of the hop-count value indicated in the routing table.
o ネットワークのサイズ、トポロジ、およびリンク層の損失の程度に応じて、パラメータMAX_HOP_LIMITの最適値。 MAX_HOP_LIMITは、パケットがネットワーク内を不必要に通過しないようにします。許容できるパケットの「迂回」を制限するために使用できます。この値は、ホップ数情報がRIBまたはルーティングプロトコルから入手できる場合は、パケットごとに発行することもできます。そのような場合、パケットのホップ制限は、ルーティングテーブルに示されているホップカウント値のパーセンテージ（200％など）である場合があります。
o Optimal methods to increase the cost of a route when a loop or lost Layer 2 (L2) ACK is detected by DFF. While this is not specified as a normative part of this document, it may be of interest in an experiment to find good values of how much to increase link cost in the RIB or routing protocol.
o ループまたは失われたレイヤー2（L2）ACKがDFFによって検出されたときにルートのコストを増やすための最適な方法。これはこのドキュメントの標準的な部分として指定されていませんが、RIBまたはルーティングプロトコルでリンクコストをどれだけ増加させるかについての適切な値を見つけることは、実験で興味深いかもしれません。
o Performance of using DFF in combination with different routing protocols, such as reactive and proactive protocols. This also implies how routes are updated by the RIB or routing protocol when informed by DFF about loops or broken links.
o DFFを、リアクティブプロトコルやプロアクティブプロトコルなどのさまざまなルーティングプロトコルと組み合わせて使用した場合のパフォーマンス。これは、ループまたはリンク切れについてDFFから通知されたときに、RIBまたはルーティングプロトコルによってルートが更新される方法も意味します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、[RFC2119]で説明されているように解釈されます。
Additionally, this document uses the notation in Section 2.1 and the terminology in Section 2.2.
さらに、このドキュメントでは、セクション2.1の表記とセクション2.2の用語を使用しています。
The following notations are used in this document:
このドキュメントでは、次の表記法を使用しています。
List: A list of elements is defined as [] for an empty list, [element] for a list with one element, and [element1, element2, ...] for a list with multiple elements.
リスト：要素のリストは、空のリストの場合は[]、要素が1つのリストの場合は[element]、複数の要素が含まれるリストの場合は[element1、element2、...]として定義されます。
Concatenation of Lists: If List1 and List2 are lists, then List1@ List2 is a new list with all elements of List1 first, followed by all elements of List2.
リストの連結：List1とList2がリストの場合、List1 @ List2は、最初にList1のすべての要素、次にList2のすべての要素が続く新しいリストです。
Byte Order: All packet formats in this specification use network byte order (most significant octet first) for all fields. The most significant bit in an octet is numbered bit 0, and the least significant bit of an octet is numbered bit 7.
バイト順：この仕様のすべてのパケット形式は、すべてのフィールドにネットワークバイト順（最上位オクテットが最初）を使用します。オクテットの最上位ビットの番号はビット0で、オクテットの最下位ビットの番号はビット7です。
Assignment: a := b An assignment operator, whereby the left side (a) is assigned the value of the right side (b).
代入：a：= b代入演算子。左側（a）には右側（b）の値が代入されます。
Comparison: c = d A comparison operator, returning true if the value of the left side (c) is equal to the value of the right side (d).
比較：c = d左側（c）の値が右側（d）の値と等しい場合にtrueを返す比較演算子。
Flags: This specification uses multiple 1-bit flags. A value of '0' of a flag means 'false'; a value of '1' means 'true'.
フラグ：この仕様では、複数の1ビットフラグを使用します。フラグの「0」の値は「false」を意味します。値「1」は「true」を意味します。
The terms "route-over" and "mesh-under", introduced in [RFC6775], are used in this document, where "route-over" is not only limited to IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) but also applies to general IPv6 networks.
[RFC6775]で導入された「ルートオーバー」および「メッシュアンダー」という用語は、このドキュメントで使用されています。「ルートオーバー」は、低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）上のIPv6に限定されるだけでなく、一般的なIPv6ネットワークにも適用されます。
Mesh-under: A topology where nodes are connected to a 6LoWPAN Border Router (6LBR) through a mesh using link-layer forwarding. Thus, in a mesh-under configuration, all IPv6 hosts in a LoWPAN are only one IP hop away from the 6LBR. This topology simulates the typical IP-subnet topology with one router with multiple nodes in the same subnet.
Mesh-under：ノードがリンク層転送を使用するメッシュを介して6LoWPANボーダールーター（6LBR）に接続されているトポロジ。したがって、メッシュアンダー構成では、LoWPAN内のすべてのIPv6ホストは6LBRから1 IPホップだけ離れています。このトポロジは、同じサブネット内に複数のノードを持つ1つのルーターを使用した一般的なIPサブネットトポロジをシミュレートします。
Route-over: A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. Here, hosts are typically multiple IP hops away from a 6LBR. The route-over topology typically consists of a 6LBR, a set of 6LoWPAN Routers (6LRs), and hosts.
ルートオーバー：ホストが中間レイヤー3（IP）ルーティングを使用して6LBRに接続されるトポロジ。ここで、ホストは通常、6LBRから離れた複数のIPホップです。ルートオーバートポロジは、通常、6LBR、一連の6LoWPANルーター（6LR）、およびホストで構成されます。
The following terms are used in this document. As the DFF mechanism is specified both for route-over IPv6 and for the mesh-under LoWPAN adaptation layer, the terms are generally defined in this section, and then specifically mapped for each of the different modes of operation in Section 13.
このドキュメントでは、次の用語が使用されています。 DFFメカニズムはIPv6ルートオーバーとメッシュアンダーLoWPANアダプテーションレイヤーの両方に指定されているため、用語はこのセクションで一般的に定義され、セクション13でさまざまな動作モードごとに具体的にマッピングされます。
Depth-First Search: "Depth-first search (DFS) is an algorithm for traversing or searching tree or graph data structures. One starts at the root (selecting some node as the root in the graph case) and explores as far as possible along each branch before backtracking" [DFS_wikipedia]. In this document, the algorithm
深さ優先検索：「深さ優先検索（DFS）は、ツリーまたはグラフのデータ構造をトラバースまたは検索するためのアルゴリズムです。1つはルートから開始し（グラフの場合は、ノードをルートとして選択）、可能な限り探索します。バックトラック前の各ブランチ」[DFS_wikipedia]。このドキュメントでは、アルゴリズム
for traversing a graph is applied to forwarding packets in a computer network, with nodes being routers.
グラフをトラバースするには、ノードがルーターであるコンピュータネットワークでパケットを転送するために適用されます。
Routing Information Base (RIB): A table stored in the user space of an operating system of a router or host. The table lists routes to network destinations, as well as associated metrics with these routes.
ルーティング情報ベース（RIB）：ルーターまたはホストのオペレーティングシステムのユーザースペースに格納されているテーブル。この表には、ネットワーク宛先へのルートと、これらのルートに関連付けられているメトリックがリストされています。
Mode of Operation (MoP): The DFF mechanism specified in this document can either be used as the "route-over" IPv6-forwarding mechanism (Mode of Operation: "route-over") or as the "mesh-under" LoWPAN adaptation layer (Mode of Operation: "mesh-under").
動作モード（MoP）：このドキュメントで指定されているDFFメカニズムは、「ルートオーバー」IPv6転送メカニズム（動作モード：「ルートオーバー」）または「メッシュアンダー」LoWPAN適応として使用できます。レイヤー（操作モード：「メッシュアンダー」）。
Packet: An IPv6 packet (for "route-over" MoP) or a "LoWPAN-encapsulated packet" (for "mesh-under" MoP), containing an IPv6 packet as payload.
パケット：ペイロードとしてIPv6パケットを含むIPv6パケット（「ルートオーバー」MoPの場合）または「LoWPANカプセル化パケット」（「メッシュアンダー」MoPの場合）。
Packet Header: An IPv6 extension header (for "route-over" MoP) or a LoWPAN header (for "mesh-under" MoP).
パケットヘッダー：IPv6拡張ヘッダー（「ルートオーバー」MoPの場合）またはLoWPANヘッダー（「メッシュアンダー」MoPの場合）。
Address: An IPv6 address (for "route-over" MoP), or a 16-bit short or 64-bit Extended Unique Identifier (EUI-64) link-layer address (for "mesh-under" MoP).
アドレス：IPv6アドレス（「ルートオーバー」MoPの場合）、または16ビットのショートまたは64ビットの拡張一意識別子（EUI-64）リンク層アドレス（「メッシュアンダー」MoPの場合）。
Originator: The router that added the DFF header (specified in Section 7) to a packet.
発信者：DFFヘッダー（セクション7で指定）をパケットに追加したルーター。
Originator Address: An address of the Originator. According to [RFC6724], this address SHOULD be selected from the addresses that are configured on the interface that transmits the packet.
発信者アドレス：発信者のアドレス。 [RFC6724]によると、このアドレスは、パケットを送信するインターフェイスで構成されているアドレスから選択する必要があります（SHOULD）。
Destination: The router or host to which a packet is finally destined. In case this router or host is outside of the routing domain in which DFF is used, the destination is the router that removes the DFF header (specified in Section 7) from the packet. This case is described in Section 14.1.
宛先：パケットの最終的な宛先となるルーターまたはホスト。このルーターまたはホストがDFFが使用されているルーティングドメインの外にある場合、宛先はパケットからDFFヘッダー（セクション7で指定）を削除するルーターです。このケースについては、セクション14.1で説明します。
Destination Address: An address to which the packet is sent.
宛先アドレス：パケットの送信先アドレス。
Next Hop: An address of the Next Hop to which the packet is sent along the path to the destination.
ネクストホップ：宛先へのパスに沿ってパケットが送信されるネクストホップのアドレス。
Previous Hop: The address of the previous-hop router from which a packet has been received. In case the packet has been received by a router from outside of the routing domain where DFF is used (i.e., no DFF header is contained in the packet), the Originator Address of the router adding the DFF header to the packet is used as the Previous Hop.
前のホップ：パケットが受信された前のホップのルーターのアドレス。 DFFが使用されているルーティングドメインの外部からルーターによってパケットが受信された場合（つまり、DFFヘッダーがパケットに含まれていない場合）、DFFヘッダーをパケットに追加するルーターの発信元アドレスが前のホップ。
Hop Limit: An upper bound denoting how many times the packet may be forwarded.
ホップ制限：パケットが転送される回数を示す上限。
This document specifies DFF, a packet-forwarding mechanism intended for use in networks with dynamic topology and/or lossy links with the purpose of increasing reliability of data delivery. The protocol's applicability is determined by its characteristics, which are that this protocol:
このドキュメントでは、DFFを指定します。これは、データ転送の信頼性を向上させる目的で、動的トポロジーや損失の多いリンクを持つネットワークでの使用を目的としたパケット転送メカニズムです。プロトコルの適用性は、このプロトコルであるという特性によって決定されます。
o Is applicable for use in IPv6 networks, either as a "route-over" forwarding mechanism using IPv6 [RFC2460], or as a "mesh-under" forwarding mechanism using the frame format for transmission of IPv6 packets, as defined in [RFC4944].
o [RFC4944]で定義されているように、IPv6 [RFC2460]を使用する「ルートオーバー」転送メカニズムとして、またはIPv6パケットの送信用のフレーム形式を使用する「メッシュアンダー」転送メカニズムとして、IPv6ネットワークでの使用に適用可能。
o Assumes addresses used in the network are either IPv6 addresses (if the protocol is used as "route-over"), or 16-bit short or EUI-64 link-layer addresses, as specified in [RFC4944], if the protocol is used as "mesh-under". In "mesh-under" mode, mixed 16-bit and EUI-64 addresses within one DFF routing domain are allowed (if they conform with [RFC4944]), as long as DFF is limited to use within one PAN (Personal Area Network). It is assumed that the "route-over" mode and "mesh-under" mode are mutually exclusive in the same routing domain.
o ネットワークで使用されるアドレスは、IPv6アドレス（プロトコルが「ルートオーバー」として使用される場合）、または[RFC4944]で指定されている16ビットのショートまたはEUI-64リンク層アドレス（プロトコルが使用される場合）のいずれかであると想定します。 「メッシュアンダー」として。 「メッシュアンダー」モードでは、DFFが1つのPAN（パーソナルエリアネットワーク）内での使用に制限されている限り、1つのDFFルーティングドメイン内で16ビットとEUI-64の混合アドレスが許可されます（[RFC4944]に準拠している場合）。 。 「route-over」モードと「mesh-under」モードは、同じルーティングドメイン内で相互に排他的であると想定されています。
o Assumes that the underlying link layer provides means to detect if a packet has been successfully delivered to the Next Hop or not (e.g., by L2 ACK messages). Examples for such underlying link layers are specified in IEEE 802.15.4 and IEEE 802.11.
o 基礎となるリンク層が、パケットが（たとえば、L2 ACKメッセージによって）ネクストホップに正常に配信されたかどうかを検出する手段を提供すると仮定します。そのような基礎となるリンク層の例は、IEEE 802.15.4およびIEEE 802.11で指定されています。
o Is applicable in networks with lossy links and/or with a dynamic topology. In networks with very stable links and fixed topology, DFF will not bring any benefit (but also will not be harmful, other than the additional overhead for the packet header).
o 非可逆リンクや動的トポロジーを持つネットワークに適用できます。非常に安定したリンクと固定トポロジのネットワークでは、DFFは何のメリットもありません（ただし、パケットヘッダーの追加のオーバーヘッド以外に害はありません）。
o Works in a completely distributed manner and does not depend on any central entity.
o 完全に分散した方法で機能し、中心的なエンティティに依存しません。
o Is applicable for networks with little traffic in terms of numbers of packets per second, since each recently forwarded packet increases the state on a router. The amount of traffic per time that is supported by DFF depends on the memory resources of the router running DFF, the density of the network, the loss rate of the channel, and the maximum Hop Limit for each packet: for each recently seen packet, a list of Next Hops that the packet has been sent to is stored in memory. The stored entries can be deleted after an expiration time, so that only recently received packets require storage on the router. Implementations are advised to measure and report rates of packets in the network, and also to report memory usage. Thus, operators can determine memory exhaustion because of growing information sets or problems because of too rapid sequence-number wrap-around.
o最近転送された各パケットはルーターの状態を増加させるため、1秒あたりのパケット数の点でトラフィックが少ないネットワークに適用できます。 DFFでサポートされる時間あたりのトラフィック量は、DFFを実行しているルーターのメモリリソース、ネットワークの密度、チャネルの損失率、および各パケットの最大ホップリミットによって異なります。パケットが送信されたネクストホップのリストはメモリに保存されます。保存されたエントリは有効期限が切れた後に削除できるため、最近受信したパケットのみがルーターに保存する必要があります。実装では、ネットワーク内のパケットの速度を測定して報告し、メモリ使用量を報告することをお勧めします。したがって、オペレーターは、シーケンス番号の折り返しが速すぎるために、情報セットの増加や問題が原因で、メモリーの枯渇を判別できます。
o Is applicable for dense topologies with multiple paths between each source and each destination. Certain topologies are less suitable for DFF: topologies that can be partitioned by the removal of a single router or link, topologies with multiple stub routers that each have a single link to the network, topologies with only a single path to a destination, or topologies where the "detour" that a packet makes during the depth-first search in order to reach the destination would be too long. Note that the number of retransmissions of a packet that stipulate a "too long" path depends on the underlying link layer (capacity and probability of packet loss), as well as how much bandwidth is required for data traffic by applications running in the network. In such topologies, the packet may never reach the destination; therefore, unnecessary transmissions of data packets may occur until the Hop Limit of the packet reaches zero, and the packet is dropped. This may consume channel and router resources.
o 各送信元と各宛先の間に複数のパスがある高密度トポロジに適用できます。特定のトポロジーはDFFにはあまり適していません。単一のルーターまたはリンクを削除することで分割できるトポロジー、それぞれがネットワークへの単一のリンクを持つ複数のスタブルーターを持つトポロジー、宛先への単一のパスのみを持つトポロジー、またはトポロジーここで、宛先に到達するためにパケットが縦型検索の最中に行う「迂回」は長すぎます。 「長すぎる」パスを規定するパケットの再送信の数は、基盤となるリンク層（容量とパケット損失の確率）、およびネットワークで実行されているアプリケーションがデータトラフィックに必要な帯域幅に依存することに注意してください。このようなトポロジでは、パケットが宛先に到達することはありません。したがって、パケットのホップ制限がゼロになり、パケットがドロップされるまで、データパケットの不要な送信が発生する可能性があります。これにより、チャネルとルーターのリソースが消費される可能性があります。
o Is used for unicast transmissions only (not for anycast or multicast).
o ユニキャスト送信にのみ使用されます（エニーキャストまたはマルチキャストには使用されません）。
o Is for use within stub networks and for traffic between a router inside the routing domain in which DFF is used and a known border router. Examples of such networks are LoWPANs. Scope limitations are described in Section 14.
o スタブネットワーク内、およびDFFが使用されるルーティングドメイン内のルーターと既知の境界ルーター間のトラフィック用です。このようなネットワークの例は、LoWPANです。スコープの制限については、セクション14で説明します。
When a packet is to be forwarded by a router using DFF, the router creates a list of candidate Next Hops for that packet. This list (created per packet) is ordered, and Section 11 provides recommendations on how to order the list, e.g., first listing Next Hops listed in the RIB, if available, ordered in increasing cost, followed by other neighbors provided by an external neighborhood discovery. DFF proceeds to forward the packet to the first Next Hop in the list. If the transmission was not successful (as determined by the underlying link layer) or if the packet was "returned" by a Next Hop to which it had been sent before, the router will try to forward the packet to the subsequent Next Hop on the list. A router "returns" a packet to the router from which it was originally received once it has unsuccessfully tried to forward the packet to all elements in the candidate Next Hop list. If the packet is eventually returned to the Originator of the packet, and after the Originator has exhausted all of its Next Hops for the packet, the packet is dropped.
パケットがDFFを使用してルーターによって転送される場合、ルーターはそのパケットの候補ネクストホップのリストを作成します。このリスト（パケットごとに作成される）は順序付けされており、セクション11はリストの順序付けに関する推奨事項を提供します。たとえば、RIBにリストされている次のホップを最初にリストし、可能な場合はコストが高くなるように順序付けし、その後に外部の近隣によって提供される他の近隣をリストします。発見。 DFFはパケットをリストの最初のネクストホップに転送します。送信が成功しなかった場合（基礎となるリンク層によって決定された場合）、またはパケットが以前に送信されたネクストホップによって「返された」場合、ルーターはパケットを次のネクストホップに転送しようとします。リスト。ルーターは、ネクストホップ候補リストのすべての要素にパケットを転送しようとして失敗した場合、パケットを最初に受信したルーターに「戻し」ます。パケットが最終的にパケットの発信者に返され、発信者がパケットのすべてのネクストホップを使い果たした後、パケットはドロップされます。
For each recently forwarded packet, a router running DFF stores information about the packet as an entry in an information set, denoted "Processed Set". Each entry in the Processed Set contains a sequence number, included in the packet header, identifying the packet. (Refer to Section 12 for further details on the sequence number.) Furthermore, the entry contains a list of Next Hops to which the packet has been sent. This list of recently forwarded packets also allows for avoiding loops when forwarding a packet. Entries in the Processed Set expire after a given expiration timeout and are removed.
最近転送された各パケットについて、DFFを実行しているルーターは、パケットに関する情報を「処理済みセット」と表示された情報セットのエントリとして格納します。処理済みセットの各エントリには、パケットを識別するシーケンス番号が含まれ、パケットを識別します。 （シーケンス番号の詳細については、セクション12を参照してください。）さらに、エントリには、パケットが送信されたネクストホップのリストが含まれています。最近転送されたパケットのこのリストにより、パケット転送時のループを回避することもできます。処理済みセットのエントリは、指定された期限切れタイムアウト後に期限切れになり、削除されます。
This specification requires a single set on each router, the Processed Set. The Processed Set stores the sequence number, the Originator Address, the Previous Hop, and a list of Next Hops to which the packet has been sent, for each recently seen packet. Entries in the set are removed after a predefined timeout. Each time a packet is forwarded to a Next Hop, that Next Hop is added to the list of Next Hops of the entry for the packet.
この仕様では、各ルーターに1つのセットである処理済みセットが必要です。処理されたセットは、最近見られた各パケットについて、シーケンス番号、発信元アドレス、前のホップ、およびパケットが送信された次のホップのリストを格納します。セット内のエントリは、事前定義されたタイムアウト後に削除されます。パケットがネクストホップに転送されるたびに、そのネクストホップは、パケットのエントリのネクストホップのリストに追加されます。
Note that an implementation of this protocol may maintain the information of the Processed Set in the indicated form, or in any other organization that offers access to this information. In particular, it is not necessary to remove tuples from a set at the exact time indicated, only to behave as if the tuples were removed at that time.
このプロトコルの実装は、指定された形式で、またはこの情報へのアクセスを提供する他の組織で、処理済みセットの情報を維持する場合があることに注意してください。特に、示された正確な時刻にセットからタプルを削除する必要はありません。その時点でタプルが削除されたかのように動作するだけです。
In addition to the Processed Set, a list of symmetric neighbors must be provided by an external neighborhood discovery mechanism, or may be determined from the RIB (e.g., if the RIB provides routes to adjacent routers, and if these one-hop routes are verified to be symmetric).
プロセスセットに加えて、対称ネイバーのリストは、外部ネイバー探索メカニズムによって提供される必要があります。または、RIBから決定される場合があります（たとえば、RIBが隣接ルーターへのルートを提供する場合、およびこれらの1ホップルートが検証される場合）対称になる）。
Information is needed on a per-packet basis by a router that is running DFF and receives a packet. This information is encoded in the packet header that is specified in this document as the IPv6 Hop-by-Hop Options header and LoWPAN header, respectively, for the intended "route-over" and "mesh-under" Modes of Operation. This DFF header contains a sequence number used for uniquely identifying a packet and two flags, RET (for "return") and DUP (for "duplicate").
DFFを実行してパケットを受信するルーターは、パケットごとに情報が必要です。この情報は、このドキュメントでIPv6ホップバイホップオプションヘッダーおよびLoWPANヘッダーとしてそれぞれ指定されているパケットヘッダーにエンコードされており、意図した「ルートオーバー」および「メッシュアンダー」動作モードに対応しています。このDFFヘッダーには、パケットを一意に識別するために使用されるシーケンス番号と、RET（「戻り」の場合）とDUP（「複製」の場合）の2つのフラグが含まれています。
While a router successively tries sending a data packet to one or more of its neighbors, RET = 0. If none of the transmissions of the packet to the neighbors of a router have succeeded, the packet is returned to the router from which the packet was first received, indicated by setting the return flag (RET := 1). The RET flag is required to discern between a deliberately returned packet and a looping packet: if a router receives a packet with RET = 1 (and DUP = 0 or DUP = 1) that it has already forwarded, the packet was deliberately returned, and the router will continue to successively send the packet to routers from the candidate Next Hop list. If that packet has RET = 0, the router assumes that the packet is looping and returns it to the router from which it was last received. An external mechanism may use this information for increasing the route cost of the route to the destination using the Next Hop that resulted in the loop in the RIB or the routing protocol. It is out of scope of this document to specify such a mechanism. Note that once DUP is set to 1, loop detection is not possible any more as the flag is not reset any more. Therefore, a packet may loop if the RIBs of routers in the domain are inconsistent, until the Hop Limit has reached 0.
ルータが連続して1つ以上のネイバーにデータパケットを送信しようとしている間、RET =0。ルータのネイバーへのパケットの送信がどれも成功しなかった場合、パケットはパケットの送信元のルータに返されます最初に受信され、戻りフラグを設定することによって示されます（RET：= 1）。故意に返されたパケットとループパケットを区別するには、RETフラグが必要です。ルーターがRET = 1（およびDUP = 0またはDUP = 1）ですでに転送したパケットを受信した場合、そのパケットは故意に返され、ルーターは引き続き、次ホップ候補のリストからルーターにパケットを送信し続けます。そのパケットのRET = 0の場合、ルーターはパケットがループしていると想定し、最後に受信したルーターにそれを返します。外部メカニズムはこの情報を使用して、RIBまたはルーティングプロトコルでループが発生したネクストホップを使用して、宛先へのルートのルートコストを増加させることができます。このようなメカニズムを指定することは、このドキュメントの範囲外です。 DUPが1に設定されると、フラグがリセットされなくなるため、ループ検出はできなくなります。したがって、ホップ制限が0に達するまで、ドメイン内のルーターのRIBに一貫性がない場合、パケットがループすることがあります。
Whenever a packet transmission to a neighbor has failed (as determined by the underlying link layer, e.g., using L2 ACKs), the DUP flag is set in the packet header for the following transmissions. The rationale is that the packet may have been successfully received by the neighbor and only the L2 ACK has been lost, resulting in possible duplicates of the packet in the network. The DUP flag tags such a possible duplicate. The DUP flag is required to discern between a duplicated packet and a looping packet: if a router receives a packet with DUP = 1 (and RET = 0) that it has already forwarded, the packet is not considered looping and is successively forwarded to the next router from the candidate Next Hop list. If the received packet has DUP = 0 (and RET = 0), the router assumes that the packet is looping, sets RET := 1, and returns it to the Previous Hop. Again, an external mechanism may use this information for increasing route costs and/or informing the routing protocol.
ネイバーへのパケット送信が失敗したときはいつでも（たとえば、L2 ACKを使用して、基礎となるリンク層によって決定されます）、DUPフラグが次の送信のパケットヘッダーに設定されます。理論的根拠は、パケットがネイバーによって正常に受信された可能性があり、L2 ACKのみが失われたため、ネットワーク内でパケットが重複する可能性があることです。 DUPフラグは、このような重複の可能性をタグ付けします。 DUPフラグは、重複パケットとループパケットを区別するために必要です。ルーターがDUP = 1（およびRET = 0）ですでに転送済みのパケットを受信した場合、そのパケットはループとは見なされず、連続して転送されます。ネクストホップリストの候補からの次のルーター。受信したパケットにDUP = 0（およびRET = 0）がある場合、ルーターはパケットがループしていると想定し、RET：= 1を設定して、前のホップに戻します。この場合も、外部メカニズムはこの情報を使用して、ルートコストの増加やルーティングプロトコルへの通知を行います。
The reason for not dropping received duplicated packets (with DUP = 1) is that a duplicated packet may be duplicated again during its path if another L2 ACK is lost. However, when DUP is already set to 1, it is not possible to discern the duplicate from the duplicate of the duplicate. As a consequence, loop detection is not possible after the second lost L2 ACK on the path of a packet. However, if duplicates are simply dropped, it is possible that the packet was actually a looping packet (and not a duplicate), and so the depth-first search would be interrupted.
受信した重複パケット（DUP = 1の場合）をドロップしない理由は、別のL2 ACKが失われた場合、パスの間に重複パケットが再度重複する可能性があるためです。ただし、DUPがすでに1に設定されている場合、複製を複製の複製と区別することはできません。その結果、パケットのパス上で2番目に失われたL2 ACKの後、ループ検出は不可能です。ただし、重複が単純に削除された場合、パケットが実際には（重複ではなく）ループしているパケットである可能性があるため、深さ優先検索が中断されます。
DFF MAY use information from the Routing Information Base (RIB), specifically for determining an order of preference for which Next Hops a packet should be forwarded to (e.g., the packet may be forwarded first to neighbors that are listed in the RIB as Next Hops to the destination, preferring those with the lowest route cost). Section 11 provides recommendations about the order of preference for the Next Hops of a packet.
DFFは、ルーティング情報ベース（RIB）からの情報を使用できます。具体的には、パケットを転送するネクストホップの優先順位を決定するためです（たとえば、パケットは、RIBにネクストホップとしてリストされているネイバーに最初に転送される場合があります）ルートコストが最も低いものを優先します）。セクション11では、パケットのネクストホップの優先順位に関する推奨事項を示します。
DFF MUST have access to a list of symmetric neighbors for each router; this list is provided by a neighborhood discovery protocol, such as the one defined in [RFC6130]. A neighborhood discovery protocol is not specified in this document.
DFFは、各ルーターの対称ネイバーのリストにアクセスできる必要があります。このリストは、[RFC6130]で定義されているような近隣探索プロトコルによって提供されます。このドキュメントでは、近隣探索プロトコルは指定されていません。
This section specifies the information sets used by DFF.
このセクションでは、DFFが使用する情報セットを指定します。
DFF MUST have access to a list of addresses of symmetric neighbors of the router. This list can be provided by an external neighborhood discovery mechanism or, alternatively, may be determined from the RIB (e.g., if the RIB provides routes to adjacent routers, and if these one-hop routes are verified to be symmetric). The list of addresses of symmetric neighbors is not specified within this document. The addresses in the list are used to construct a list of candidate Next Hops for a packet, as specified in Section 11.
DFFは、ルーターの対称ネイバーのアドレスのリストにアクセスできる必要があります。このリストは、外部の近隣探索メカニズムによって提供することも、RIBから決定することもできます（たとえば、RIBが隣接するルーターへのルートを提供し、これらの1ホップルートが対称であることが確認されている場合）。対称ネイバーのアドレスのリストは、このドキュメントでは指定されていません。リストのアドレスは、セクション11で指定されているように、パケットの次ホップ候補のリストを作成するために使用されます。
Each router maintains a Processed Set in order to support the loop detection functionality. The Processed Set lists sequence numbers of previously received packets, as well as a list of Next Hops to which the packet has been sent successively as part of the depth-first forwarding mechanism. To protect against this situation, it is recommended that an implementation retains the Processed Set in non-volatile storage if such is provided by the router.
各ルーターは、ループ検出機能をサポートするために、プロセスセットを維持します。 Processed Setには、以前に受信したパケットのシーケンス番号と、パケットが深度優先転送メカニズムの一部として連続して送信されたNext Hopのリストが表示されます。この状況から保護するために、ルーターが提供する場合は、実装が処理済みセットを不揮発性ストレージに保持することをお勧めします。
The set consists of Processed Tuples
セットは処理済みタプルで構成されています
(P_orig_address, P_seq_number, P_prev_hop, P_next_hop_neighbor_list, P_time)
（P_orig_address、P_seq_number、P_prev_hop、P_next_hop_neighbor_list、P_time）
where
ただし
P_orig_address is the Originator Address of the received packet;
P_orig_addressは、受信したパケットの発信元アドレスです。
P_seq_number is the sequence number of the received packet;
P_seq_numberは、受信したパケットのシーケンス番号です。
P_prev_hop is the address of the Previous Hop of the packet;
P_prev_hopは、パケットの前のホップのアドレスです。
P_next_hop_neighbor_list is a list of addresses of Next Hops to which the packet has been sent previously, as part of the depth-first forwarding mechanism, as specified in Section 9.2;
P_next_hop_neighbor_listは、セクション9.2で指定されているように、深さ優先転送メカニズムの一部として、以前にパケットが送信されたネクストホップのアドレスのリストです。
P_time specifies when this tuple expires and MUST be removed.
P_timeは、このタプルの有効期限を指定し、削除する必要があります。
The consequences when no, or not enough, non-volatile storage is available on a router (e.g., because of limited resources) or when an implementation chooses not to make the Processed Set persistent are that packets that are already in a loop caused by the routing protocol may continue to loop until the Hop Limit is exhausted. Non-looping packets may be sent to Next Hops that have already received the packet previously and will return the packet, leading to some unnecessary retransmissions. This effect is only temporary and applies only for packets already traversing the network.
（たとえば、リソースが限られているため）ルーターで不揮発性ストレージが利用できない、または十分でない場合、または実装が処理済みセットを永続化しないことを選択した場合の結果は、ルーティングプロトコルは、ホップ制限がなくなるまでループし続ける場合があります。非ループパケットは、以前にパケットを受信して次のホップに送信され、そのパケットを返すため、不要な再送信が発生する可能性があります。この影響は一時的なものであり、すでにネットワークを通過するパケットにのみ適用されます。
This section specifies the information required by DFF in the packet header. Note that, depending on whether DFF is used in the "route-over" MoP or in the "mesh-under" MoP, the DFF header is either an IPv6 Hop-by-Hop Options header (as specified in Section 13.1.2) or a LoWPAN header (as specified in Section 13.2.2). Sections 13.1.2 and 13.2.2 specify the precise order, format, and encoding of the fields that are listed in this section.
このセクションでは、パケットヘッダーのDFFに必要な情報を指定します。 DFFが「route-over」MoPで使用されているか、「mesh-under」MoPで使用されているかに応じて、DFFヘッダーはIPv6ホップバイホップオプションヘッダーになります（セクション13.1.2で指定）。またはLoWPANヘッダー（13.2.2項で指定）。セクション13.1.2および13.2.2は、このセクションにリストされているフィールドの正確な順序、フォーマット、およびエンコードを指定します。
Version (VER) - This 2-bit value indicates the version of DFF that is used. This specification defines value '00'. Packets with other values of the version MUST be forwarded using the route-over MoP and mesh-under MoP as defined in [RFC2460] and [RFC4944], respectively.
バージョン（VER）-この2ビットの値は、使用されるDFFのバージョンを示します。この仕様は値「00」を定義します。バージョンの他の値を持つパケットは、[RFC2460]と[RFC4944]でそれぞれ定義されているroute-over MoPとmesh-under MoPを使用して転送する必要があります。
Duplicate (DUP) Packet Flag - This 1-bit flag is set in the DFF header of a packet when that packet is being retransmitted due to a signal from the link layer that the original transmission failed, as specified in Section 9.2. Once the flag is set to 1, it MUST NOT be modified by routers forwarding the packet.
複製（DUP）パケットフラグ-この1ビットのフラグは、セクション9.2で指定されているように、元の送信が失敗したリンク層からの信号が原因でパケットが再送信されるときに、パケットのDFFヘッダーに設定されます。フラグが1に設定されると、パケットを転送するルーターによって変更されてはなりません（MUST NOT）。
Return (RET) Packet Flag - This 1-bit flag MUST be set to 1 prior to sending the packet back to the Previous Hop. Upon receiving a packet with RET = 1, and before sending it to a new candidate Next Hop, that flag MUST be set to 0, as specified in Section 9.2.
リターン（RET）パケットフラグ-パケットを前のホップに送り返す前に、この1ビットフラグを1に設定する必要があります。 RET = 1のパケットを受信し、それを新しい候補Next Hopに送信する前に、セクション9.2で指定されているように、そのフラグを0に設定する必要があります。
Sequence Number - A 16-bit field, containing an unsigned integer sequence number generated by the Originator, unique to each router for each packet to which the DFF has been added, as specified in Section 12. The Originator Address concatenated with the sequence number represents an identifier of previously seen data packets. Refer to Section 12 for further information about sequence numbers.
シーケンス番号-セクション12で指定されているように、DFFが追加された各パケットの各ルーターに固有の、発信元によって生成された符号なし整数のシーケンス番号を含む16ビットのフィールド。シーケンス番号と連結された発信元アドレスは、以前に見られたデータパケットの識別子。シーケンス番号の詳細については、セクション12を参照してください。
The parameters used in this specification are listed in this section. These parameters are configurable, do not need to be stored in non-volatile storage, and can be varied by implementations at run-time. Default values for the parameters depend on the network size, topology, link layer, and traffic patterns. Part of the experimentation described in Section 1.2 is to determine suitable default values.
この仕様で使用されるパラメータは、このセクションにリストされています。これらのパラメーターは構成可能で、不揮発性ストレージに保存する必要はなく、実行時に実装によって変更できます。パラメータのデフォルト値は、ネットワークサイズ、トポロジ、リンク層、およびトラフィックパターンによって異なります。セクション1.2で説明した実験の一部は、適切なデフォルト値を決定することです。
P_HOLD_TIME - Is the time period after which a newly created or modified Processed Tuple expires and MUST be deleted. An implementation SHOULD use a value for P_HOLD_TIME that is high enough that the Processed Tuple for a packet is still in memory on all forwarding routers while the packet is transiting the routing domain. The value SHOULD at least be MAX_HOP_LIMIT times the expected time to send a packet to a router on the same link. The value MUST be lower than the time it takes until the same sequence number is reached again after a wrap-around on the router identified by P_orig_address of the Processed Tuple.
P_HOLD_TIME-新しく作成または変更された処理済みタプルが期限切れになり、削除する必要がある期間です。実装は、パケットがルーティングドメインを通過している間、パケットの処理済みタプルがすべての転送ルーターのメモリに残っているほど十分に高いP_HOLD_TIMEの値を使用する必要があります（SHOULD）。値は、同じリンク上のルーターにパケットを送信するために予想される時間の少なくともMAX_HOP_LIMIT倍にする必要があります（SHOULD）。値は、Processed TupleのP_orig_addressで識別されるルーターでのラップアラウンド後、同じシーケンス番号に再度到達するまでにかかる時間よりも低くなければなりません（MUST）。
MAX_HOP_LIMIT - Is the initial value of Hop Limit, and therefore the maximum number of times that a packet is forwarded in the routing domain. When choosing the value of MAX_HOP_LIMIT, the size of the network, the distance between source and destination in number of hops, and the maximum possible "detour" of a packet SHOULD be considered (compared to the shortest path). Such information MAY be used from the RIB, if provided.
MAX_HOP_LIMIT-ホップリミットの初期値であり、ルーティングドメインでパケットが転送される最大回数です。 MAX_HOP_LIMITの値、ネットワークのサイズ、ソースと宛先の間のホップ数での距離、およびパケットの可能な最大の「迂回」を考慮する必要があります（最短パスと比較して）。そのような情報が提供されている場合は、RIBから使用できます。
The following sections specify the process of handling a packet entering the DFF routing domain, i.e., without a DFF header (Section 9.1), as well as forwarding a data packet from another router running DFF (Section 9.2).
次のセクションでは、DFFルーティングドメインに入る、つまりDFFヘッダーなしでパケットを処理するプロセス（セクション9.1）、およびDFFを実行している別のルーターからデータパケットを転送するプロセス（セクション9.2）を指定します。
This section applies for any data packets upon their first entry into a routing domain in which DFF is used. This occurs when a new data packet is generated on this router, or when a data packet is forwarded from outside the routing domain (i.e., from a host attached to this router or from a router outside the routing domain in which DFF is used). Before such a data packet (henceforth denoted "current packet") is transmitted, the following steps MUST be executed:
このセクションは、DFFが使用されているルーティングドメインへの最初のエントリのデータパケットに適用されます。これは、このルーターで新しいデータパケットが生成されたとき、またはデータパケットがルーティングドメインの外部（このルーターに接続されているホストから、またはDFFが使用されているルーティングドメインの外部のルーターから）から転送されたときに発生します。このようなデータパケット（以下「現在のパケット」と表記）を送信する前に、次の手順を実行する必要があります。
1. If required, encapsulate the packet, as specified in Section 14.
1. 必要に応じて、セクション14で指定されているように、パケットをカプセル化します。
2. Add the DFF header to the current packet (to the outer header if the packet has been encapsulated) with:
2. DFFヘッダーを現在のパケットに（パケットがカプセル化されている場合は外部ヘッダーに）追加します。
* DUP := 0;
* DUP：= 0;
* RET := 0;
* RET：= 0;
* Sequence Number := a new sequence number of the packet (as specified in Section 12).
* シーケンス番号：=パケットの新しいシーケンス番号（セクション12で指定）。
3. Check that the packet does not exceed the MTU, as specified in Section 15. In case it does, execute the procedures listed in Section 15 and do not further process the packet.
3. セクション15で指定されているように、パケットがMTUを超えていないことを確認します。超えている場合は、セクション15にリストされている手順を実行し、それ以上パケットを処理しないでください。
4. Select the Next Hop (henceforth denoted "next_hop") for the current packet, as specified in Section 11.
4. セクション11で指定されているように、現在のパケットの次のホップ（以降、「next_hop」と表記）を選択します。
5. Add a Processed Tuple to the Processed Set with:
5. 以下を使用して、処理済みタプルを処理済みセットに追加します。
* P_orig_address := the Originator Address of the current packet;
* P_orig_address：=現在のパケットの発信元アドレス。
* P_seq_number := the sequence number of the current packet;
* P_seq_number：=現在のパケットのシーケンス番号。
* P_prev_hop := the Originator Address of the current packet;
* P_prev_hop：=現在のパケットの発信元アドレス。
* P_next_hop_neighbor_list := [next_hop];
* P_next_hop_neighbor_list：= [next_hop];
* P_time := current time + P_HOLD_TIME.
* P_time：=現在の時刻+ P_HOLD_TIME。
6. Pass the current packet to the underlying link layer for transmission to next_hop. If the transmission fails (as determined by the link layer), the procedures in Section 10 MUST be executed.
6. 現在のパケットを基になるリンク層に渡して、next_hopに送信します。送信が失敗した場合（リンク層により決定）、セクション10の手順を実行する必要があります。
When a packet (henceforth denoted the "current packet") is received by a router, the following tasks MUST be performed:
パケット（以降、「現在のパケット」と表記）がルーターによって受信された場合、次のタスクを実行する必要があります。
1. If the packet header is malformed (i.e., the header format is not as expected by this specification), drop the packet.
1. パケットヘッダーの形式が正しくない場合（つまり、ヘッダーの形式がこの仕様で想定されていない場合）、パケットをドロップします。
2. Otherwise, if the Destination Address of the packet matches an address of an interface of this router, deliver the packet to upper layers and do not further process the packet, as specified below.
2. それ以外の場合、パケットの宛先アドレスがこのルーターのインターフェースのアドレスと一致する場合は、パケットを上位層に配信し、以下に指定されているようにパケットをさらに処理しないでください。
3. Decrement the value of the Hop Limit field by one (1).
3. ホップ制限フィールドの値を1減らします。
4. Drop the packet if Hop Limit is decremented to zero and do not further process the packet, as specified below.
4. ホップ制限がゼロにデクリメントされている場合はパケットをドロップし、以下に指定されているようにパケットをさらに処理しません。
5. If no Processed Tuple (henceforth denoted the "current tuple") exists in the Processed Set, where both of the following conditions are true:
5. 処理されたタプル（以降、「現在のタプル」と呼ばれます）が処理されたセットに存在しない場合、以下の条件の両方が当てはまります。
+ P_orig_address = the Originator Address of the current packet, AND;
+ P_orig_address =現在のパケットの発信者アドレス、および;
+ P_seq_number = the sequence number of the current packet.
+ P_seq_number =現在のパケットのシーケンス番号。
Then:
次に：
1. Add a Processed Tuple (henceforth denoted the "current tuple") with:
1. 処理されたタプル（以下、「現在のタプル」と呼ばれます）を追加します。
+ P_orig_address := the Originator Address of the current packet;
+ P_orig_address：=現在のパケットの発信元アドレス。
+ P_seq_number := the sequence number of the current packet;
+ P_seq_number：=現在のパケットのシーケンス番号。
+ P_prev_hop := the Previous Hop Address of the current packet;
+ P_prev_hop：=現在のパケットの前のホップアドレス。
+ P_next_hop_neighbor_list := [];
+ P_next_hop_neighbor_list：= [];
+ P_time := current time + P_HOLD_TIME.
+ P_time：=現在の時刻+ P_HOLD_TIME。
2. Set RET to 0 in the DFF header.
2. DFFヘッダーでRETを0に設定します。
3. Select the Next Hop (henceforth denoted "next_hop") for the current packet, as specified in Section 11.
3. セクション11で指定されているように、現在のパケットの次のホップ（以降、「next_hop」と表記）を選択します。
4. P_next_hop_neighbor_list := P_next_hop_neighbor_list@ [next_hop].
4. P_next_hop_neighbor_list：= P_next_hop_neighbor_list @ [next_hop]。
5. Pass the current packet to the underlying link layer for transmission to next_hop. If the transmission fails (as determined by the link layer), the procedures in Section 10 MUST be executed.
5. 現在のパケットを基になるリンク層に渡して、next_hopに送信します。送信が失敗した場合（リンク層により決定）、セクション10の手順を実行する必要があります。
6. Otherwise, if a tuple exists:
6. それ以外で、タプルが存在する場合：
1. If the return flag of the current packet is not set (RET = 0) (i.e., a loop has been detected):
1. 現在のパケットのリターンフラグが設定されていない場合（RET = 0）（つまり、ループが検出された場合）：
1. Set RET := 1.
1. RETを設定：= 1。
2. Pass the current packet to the underlying link layer for transmission to the Previous Hop.
2. 現在のパケットを下のリンク層に渡して、前のホップに送信します。
2. Otherwise, if the return flag of the current packet is set (RET = 1):
2. それ以外の場合で、現在のパケットの戻りフラグが設定されている場合（RET = 1）：
1. If the Previous Hop of the packet is not contained in P_next_hop_neighbor_list of the current tuple, drop the packet.
1. パケットの前のホップが現在のタプルのP_next_hop_neighbor_listに含まれていない場合は、パケットをドロップします。
2. If the Previous Hop of the packet (i.e., the address of the router from which the current packet has just been received) is equal to P_prev_hop of the current tuple (i.e., the address of the router from which the current packet has been first received), drop the packet.
2. パケットの前のホップ（つまり、現在のパケットを受信したルーターのアドレス）が現在のタプルのP_prev_hop（つまり、現在のパケットを最初に受信したルーターのアドレス）と等しい場合）、パケットをドロップします。
3. Set RET := 0.
3. RET：= 0を設定します。
4. Select the Next Hop (henceforth denoted "next_hop") for the current packet, as specified in Section 11.
4. セクション11で指定されているように、現在のパケットの次のホップ（以降、「next_hop」と表記）を選択します。
5. Modify the current tuple:
5. 現在のタプルを変更します。
- P_next_hop_neighbor_list := P_next_hop_neighbor_list@ [next_hop];
- P_next_hop_neighbor_list：= P_next_hop_neighbor_list @ [next_hop];
- P_time := current time + P_HOLD_TIME.
- P_time：=現在の時間+ P_HOLD_TIME。
6. If the selected Next Hop is equal to P_prev_hop of the current tuple, as specified in Section 11 (i.e., all candidate Next Hops have been unsuccessfully tried), set RET := 1. If this router (i.e., the router receiving the current packet) has the same address as the Originator Address of the current packet, drop the packet.
6. 選択されたネクストホップがセクション11で指定された現在のタプルのP_prev_hopと等しい場合（つまり、すべての候補ネクストホップの試行に失敗した場合）、RET：= 1を設定します。このルーター（つまり、現在のパケットを受信するルーター） ）は、現在のパケットの発信元アドレスと同じアドレスを持っているため、パケットをドロップします。
7. Pass the current packet to the underlying link layer for transmission to next_hop. If transmission fails (as determined by the link layer), the procedures in Section 10 MUST be executed.
7. 現在のパケットを基になるリンク層に渡して、next_hopに送信します。送信が失敗した場合（リンク層により決定）、セクション10の手順を実行する必要があります。
DFF requires that the underlying link layer provides information as to whether a packet is successfully received by the Next Hop. Absence of such a signal is interpreted as a delivery failure of the packet (henceforth denoted the "current packet"). Note that the underlying link layer MAY retry sending the packet multiple times (e.g., using exponential back-off) before determining that the packet has not been successfully received by the Next Hop. The following steps are executed when a delivery failure occurs and Section 9 requests that they be executed.
DFFでは、基礎となるリンク層が、パケットがネクストホップによって正常に受信されたかどうかに関する情報を提供する必要があります。このような信号がないと、パケットの配信が失敗したと解釈されます（以降、「現在のパケット」と表示されます）。基礎となるリンク層は、パケットがネクストホップで正常に受信されなかったと判断する前に、（たとえば、指数バックオフを使用して）パケットの送信を複数回再試行してもよいことに注意してください。以下のステップは、配信エラーが発生し、セクション9がそれらの実行を要求したときに実行されます。
1. Set the DUP flag of the DFF header of the current packet to 1.
1. 現在のパケットのDFFヘッダーのDUPフラグを1に設定します。
2. Select the Next Hop (henceforth denoted "next_hop") for the current packet, as specified in Section 11.
2. セクション11で指定されているように、現在のパケットの次のホップ（以降、「next_hop」と表記）を選択します。
3. Find the Processed Tuple (the "current tuple") in the Processed Set with:
3. 処理されたタプル（「現在のタプル」）を処理されたセットで検索します。
+ P_orig_address = the Originator Address of the current packet, AND;
+ P_orig_address =現在のパケットの発信元アドレス、および;
+ P_seq_number = the sequence number of the current packet.
+ P_seq_number =現在のパケットのシーケンス番号。
4. If no current tuple is found, drop the packet.
4. 現在のタプルが見つからない場合は、パケットをドロップします。
5. Otherwise, modify the current tuple:
5. それ以外の場合は、現在のタプルを変更します。
* P_next_hop_neighbor_list := P_next_hop_neighbor_list@ [next_hop];
* P_next_hop_neighbor_list：= P_next_hop_neighbor_list @ [next_hop];
* P_time := current time + P_HOLD_TIME.
* P_time：=現在の時間+ P_HOLD_TIME。
6. If the selected next_hop is equal to P_prev_hop of the current tuple, as specified in Section 11 (i.e., all neighbors have been unsuccessfully tried), then:
6. 選択されたnext_hopが、セクション11で指定されているように、現在のタプルのP_prev_hopと等しい場合（つまり、すべてのネイバーの試行が失敗した場合）：
* RET := 1
* RET：= 1
* Decrement the value of the Hop Limit field by one (1). Drop the packet if the Hop Limit is decremented to zero.
* ホップ制限フィールドの値を1減らします。ホップ制限がゼロにデクリメントされる場合、パケットをドロップします。
7. Otherwise
7. さもないと
* RET := 0
* RET：= 0
8. Transmit the current packet to next_hop. If transmission fails (as determined by the link layer), and if the next_hop does not equal P_prev_hop from the current tuple, the procedures in Section 10 MUST be executed.
8. 現在のパケットをnext_hopに送信します。送信が失敗した場合（リンク層で決定）、next_hopが現在のタプルのP_prev_hopと等しくない場合は、セクション10の手順を実行する必要があります。
When forwarding a packet, a router determines a valid Next Hop for that packet, as specified in this section. As a Processed Tuple either existed when receiving the packet (henceforth denoted the "current packet") or was created, it can be assumed that the Processed Tuple for that packet (henceforth denoted the "current tuple") is available.
パケットを転送するとき、ルーターは、このセクションで指定されているように、そのパケットの有効なネクストホップを決定します。処理されたタプルは、パケットの受信時に存在していた（以降、「現在のパケット」と表示されます）か、または作成されたため、そのパケットの処理されたタプル（以下、「現在のタプル」と表示されます）が使用可能であると想定できます。
The Next Hop is chosen from a list of candidate Next Hops in order of decreasing priority. This list is created per packet. The maximum candidate Next Hop list for a packet contains all the neighbors of the router (as determined from an external neighborhood discovery process), except for the Previous Hop of the current packet. A smaller list MAY be used, if desired, and the exact selection of the size of the candidate Next Hop list is a local decision that is made in each router and does not affect interoperability. Selecting a smaller list may reduce the path length of a packet traversing the network and reduce the required state in the Processed Set, but it may result in valid paths that are not explored. If information from the RIB is used, then the candidate Next Hop list MUST contain at least the Next Hop indicated in the RIB as the Next Hop on the shortest path to the destination, and it SHOULD contain all Next Hops indicated to the RIB as Next Hops on paths to the destination. If a Next Hop from the RIB equals the Previous Hop of the current packet, it MUST NOT be added to the candidate Next Hop list.
ネクストホップは、優先度の高い順に、候補ネクストホップのリストから選択されます。このリストはパケットごとに作成されます。パケットの最大候補ネクストホップリストには、現在のパケットの前ホップを除く、ルーターのすべてのネイバー（外部の近隣探索プロセスから決定）が含まれます。必要に応じて、より小さなリストを使用することができます。候補のNext Hopリストのサイズの正確な選択は、各ルーターで行われるローカルな決定であり、相互運用性に影響しません。小さいリストを選択すると、ネットワークを通過するパケットのパス長が短くなり、処理済みセットで必要な状態が少なくなりますが、探索されない有効なパスになる可能性があります。 RIBからの情報が使用される場合、候補ネクストホップリストには、宛先への最短パス上のネクストホップとしてRIBに示されているネクストホップが少なくとも含まれている必要があり、RIBに次として示されているすべてのネクストホップを含む必要があります（SHOULD）。宛先へのパスにホップします。 RIBからのネクストホップが現在のパケットの前のホップに等しい場合、それは候補ネクストホップリストに追加してはなりません（MUST NOT）。
The list MUST NOT contain addresses that are listed in P_next_hop_neighbor_list of the current tuple, in order to avoid sending the packet to the same neighbor multiple times. Moreover, an address MUST NOT appear more than once in the list, for the same reason. Also, addresses of an interface of this router MUST NOT be added to the list.
同じネイバーへのパケットの複数回の送信を回避するために、リストには、現在のタプルのP_next_hop_neighbor_listにリストされているアドレスを含めてはなりません（MUST NOT）。さらに、同じ理由で、1つのアドレスがリストに複数回出現してはなりません（MUST NOT）。また、このルーターのインターフェースのアドレスをリストに追加してはなりません（MUST NOT）。
The list has an order of preference, where packets are first sent to the Next Hops at the top of the list during depth-first processing as specified in Sections 9.1 and 9.2. The following order is RECOMMENDED, with the elements listed on top having the highest preference:
リストには優先順位があり、セクション9.1および9.2で指定されているように、深さ優先の処理中に、リストの先頭にある次のホップに最初にパケットが送信されます。次の順序が推奨され、一番上にリストされている要素が最も優先されます。
1. The neighbor that is indicated in the RIB as the Next Hop on the shortest path to the destination of the current packet;
1. 現在のパケットの宛先への最短パス上のネクストホップとしてRIBで示されるネイバー。
2. Other neighbors indicated in the RIB as Next Hops on the path to the destination of the current packet;
2. 現在のパケットの宛先へのパス上のネクストホップとしてRIBに示されている他のネイバー。
3. All other symmetric neighbors (except the Previous Hop of the current packet).
3. 他のすべての対称ネイバー（現在のパケットの前のホップを除く）。
Additional information from the RIB or the list of symmetric neighbors (such as route cost or link quality) MAY be used for determining the order.
順序を決定するために、RIBからの追加情報または対称ネイバーのリスト（ルートコストやリンク品質など）を使用できます。
If the candidate Next Hop list created as specified in this section is empty, the selected Next Hop MUST be P_prev_hop of the current tuple; this case applies when returning the packet to the Previous Hop.
このセクションで指定されたように作成された次ホップ候補のリストが空の場合、選択された次ホップは現在のタプルのP_prev_hopでなければなりません。このケースは、パケットを前のホップに戻すときに適用されます。
Whenever a router generates a packet or forwards a packet on behalf of a host or a router outside the routing domain where DFF is used, a sequence number MUST be created and included in the DFF header. This sequence number MUST be unique locally on each router where it is created. A sequence number MUST start at 0 for the first packet to which the DFF header is added, and then increment by 1 for each new packet. The sequence number MUST NOT be greater than 65535 and MUST wrap around to 0.
ルーターがパケットを生成するか、DFFが使用されているルーティングドメイン外のホストまたはルーターに代わってパケットを転送する場合は常に、シーケンス番号を作成してDFFヘッダーに含める必要があります。このシーケンス番号は、それが作成された各ルーターでローカルに一意である必要があります。シーケンス番号は、DFFヘッダーが追加される最初のパケットの0から始まり、新しいパケットごとに1ずつ増加する必要があります。シーケンス番号は65535を超えてはならず（MUST NOT）、0に折り返す必要があります。
DFF can be used either as the "route-over" IPv6-forwarding protocol, or alternatively as the "mesh-under" data-forwarding protocol for the LoWPAN adaptation layer [RFC4944]. Previous sections have specified the DFF mechanism in general; specific differences for each MoP are specified in this section.
DFFは、「ルートオーバー」IPv6転送プロトコルとして、またはLoWPANアダプテーションレイヤーの「メッシュアンダー」データ転送プロトコルとして使用できます[RFC4944]。前のセクションでは、一般的にDFFメカニズムを指定しました。このセクションでは、各MoPの具体的な違いについて説明します。
This section maps the general terminology from Section 2.2 to the specific terminology when using the "route-over" MoP.
このセクションでは、「ルートオーバー」MoPを使用する場合に、セクション2.2の一般的な用語を特定の用語にマッピングします。
The following terms are those listed in Section 2.2, and their meaning is explicitly defined when DFF is used in the "route-over" MoP:
次の用語は、セクション2.2に記載されている用語であり、その意味は、「ルートオーバー」MoPでDFFが使用される場合に明示的に定義されます。
Packet - An IPv6 packet, as specified in [RFC2460].
パケット-[RFC2460]で指定されているIPv6パケット。
Packet Header - An IPv6 extension header, as specified in [RFC2460].
パケットヘッダー-[RFC2460]で指定されているIPv6拡張ヘッダー。
Address - An IPv6 address, as specified in [RFC4291].
アドレス-[RFC4291]で指定されているIPv6アドレス。
Originator Address - The Originator Address corresponds to the Source Address field of the IPv6 header, as specified in [RFC2460].
発信者アドレス-[RFC2460]で指定されているように、発信者アドレスはIPv6ヘッダーの送信元アドレスフィールドに対応します。
Destination Address - The Destination Address corresponds to the destination field of the IPv6 header, as specified in [RFC2460].
宛先アドレス-[RFC2460]で指定されているように、宛先アドレスはIPv6ヘッダーの宛先フィールドに対応します。
Next Hop - The Next Hop is the IPv6 address of the node to which the packet is sent; the link-layer address from that IP address is resolved by a mechanism such as Neighbor Discovery (ND) [RFC4861]. The link-layer address is then used by L2 as the destination.
ネクストホップ-ネクストホップは、パケットの送信先のノードのIPv6アドレスです。そのIPアドレスからのリンク層アドレスは、近隣探索（ND）[RFC4861]などのメカニズムによって解決されます。リンク層アドレスは、L2によって宛先として使用されます。
Previous Hop - The Previous Hop is the IPv6 address from the interface of the node from which the packet has been received.
前のホップ-前のホップは、パケットが受信されたノードのインターフェースからのIPv6アドレスです。
Hop Limit - The Hop Limit corresponds to the Hop Limit field in the IPv6 header, as specified in [RFC2460].
ホップ制限-[RFC2460]で指定されているように、ホップ制限はIPv6ヘッダーのホップ制限フィールドに対応します。
In the "route-over" MoP, all IPv6 packets MUST conform with the format specified in [RFC2460].
「ルートオーバー」MoPでは、すべてのIPv6パケットは[RFC2460]で指定されたフォーマットに準拠する必要があります。
The DFF header, as specified below, is an IPv6 Hop-by-Hop Options header, and is depicted in Figure 1 (where DUP is abbreviated to D, and RET is abbreviated to R because of the limited space in the figure). This document specifies a new option to be used inside the Hop-by-Hop Options header, which contains the DFF fields (DUP and RET flags and sequence number, as specified in Section 7).
以下で指定するDFFヘッダーは、IPv6ホップバイホップオプションヘッダーであり、図1に示されています（図ではスペースが限られているため、DUPはDと省略され、RETはRと省略されています）。このドキュメントでは、DFFフィールド（セクション7で指定されているDUPおよびRETフラグとシーケンス番号）を含むホップバイホップオプションヘッダー内で使用される新しいオプションを指定します。
[RFC6564] specifies:
[RFC6564]は以下を指定します：
New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible. Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential in the document proposing the new option with hop-by-hop behavior.
既存のホップバイホップヘッダーの新しいオプションは、代替ソリューションが実行可能でない限り、作成または指定しないでください。既存のホップバイホップヘッダーの新しいオプションを作成する提案には、ホップバイホップ動作の新しいオプションを提案するドキュメントで、ホップバイホップ動作が絶対に不可欠である理由の詳細な説明を含める必要があります。
[RFC6564] recommends to use destination headers instead of Hop-by-Hop Options headers. Destination headers are only read by the destination of an IPv6 packet, not by intermediate routers. However, the mechanism specified in this document relies on intermediate routers reading and editing the header. Specifically, the sequence number and the DUP and RET flags are read by each router running the DFF protocol. Modifying the DUP and RET flags is essential for this protocol to tag duplicate or returned packets. Without the DUP flag, a duplicate packet cannot be discerned from a looping packet, and without the RET flag, a returned packet cannot be discerned from a looping packet.
[RFC6564]はホップバイホップオプションヘッダーの代わりに宛先ヘッダーを使用することを推奨しています。宛先ヘッダーは、中間ルーターではなく、IPv6パケットの宛先によってのみ読み取られます。ただし、このドキュメントで指定されているメカニズムは、ヘッダーの読み取りと編集を行う中間ルーターに依存しています。具体的には、シーケンス番号とDUPおよびRETフラグは、DFFプロトコルを実行している各ルーターによって読み取られます。 DUPおよびRETフラグの変更は、このプロトコルが重複または返されたパケットにタグを付けるために不可欠です。 DUPフラグがないと、重複パケットをループパケットと区別できません。また、RETフラグがないと、返されたパケットとループパケットを区別できません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | OptTypeDFF | OptDataLenDFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER|D|R|0|0|0|0| Sequence Number | Pad1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 DFF Header
図1：IPv6 DFFヘッダー
Field definitions of the DFF header are as follows:
DFFヘッダーのフィールド定義は次のとおりです。
Next Header - 8-bit selector. Identifies the type of header immediately following the Hop-by-Hop Options header, as specified in [RFC2460].
次のヘッダー-8ビットのセレクター。 [RFC2460]で指定されているように、ホップバイホップオプションヘッダーの直後にあるヘッダーのタイプを識別します。
Hdr Ext Len - 8-bit unsigned integer. Length of the Hop-by-Hop Options header in 8-octet units, not including the first 8 octets, as specified in [RFC2460]. This value is set to 0 (zero).
Hdr Ext Len-8ビットの符号なし整数。 [RFC2460]で指定されている、最初の8オクテットを含まない、8オクテット単位のホップバイホップオプションヘッダーの長さ。この値は0（ゼロ）に設定されます。
OptTypeDFF - 8-bit identifier of the type of option, as specified in [RFC2460]. This value is set to IP_DFF. The two high-order bits of the option type MUST be set to '11', and the third bit is equal to '1'. With these bits, according to [RFC2460], routers that do not understand this option on a received packet discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem (Code 2) message to the packet's Source Address, pointing to the unrecognized option type. Also, according to [RFC2460], the values within the option are expected to change en route.
OptTypeDFF-[RFC2460]で指定されているオプションのタイプの8ビット識別子。この値はIP_DFFに設定されます。オプションタイプの上位2ビットは「11」に設定する必要があり、3番目のビットは「1」に等しくなります。 [RFC2460]によると、これらのビットを使用して、受信パケットのこのオプションを理解しないルーターはパケットを破棄し、パケットの宛先アドレスがマルチキャストアドレスでない場合にのみ、ICMPパラメータ問題（コード2）メッセージを認識されないオプションタイプを指すパケットの送信元アドレス。また、[RFC2460]によれば、オプション内の値は途中で変更されることが予想されます。
OptDataLenDFF - 8-bit unsigned integer. Length of the option data field of this option, in octets, as specified in [RFC2460]. This value is set to 2 (two).
OptDataLenDFF-8ビットの符号なし整数。 [RFC2460]で指定されている、このオプションのオプションデータフィールドの長さ（オクテット単位）。この値は2（2）に設定されています。
DFF fields - A 2-bit version field (abbreviated as VER); the DUP (abbreviated as D) and RET (abbreviated as R) flags follow after Mesh Forw, as specified in Section 13.2.2. The version specified in this document is '00'. All other bits (besides VER, DUP, and RET) of this octet are reserved and MUST be set to 0.
DFFフィールド-2ビットバージョンフィールド（省略形はVER）。セクション13.2.2で指定されているように、DUP（略してD）およびRET（略してR）フラグはMesh Forwの後に続きます。このドキュメントで指定されているバージョンは「00」です。このオクテットの他のすべてのビット（VER、DUP、およびRETを除く）は予約されており、0に設定する必要があります。
Sequence Number - A 16-bit field, containing an unsigned integer sequence number, as specified in Section 7.
シーケンス番号-セクション7で指定されている、符号なし整数のシーケンス番号を含む16ビットのフィールド。
Pad1 - Since the Hop-by-Hop Options header must have a length that is a multiple of 8 octets, a Pad1 option is used, as specified in [RFC2460]. All bits of this octet are 0.
Pad1-ホップバイホップオプションヘッダーは8オクテットの倍数である必要があるため、[RFC2460]で指定されているように、Pad1オプションが使用されます。このオクテットのすべてのビットは0です。
This section maps the general terminology from Section 2.2 to the specific terminology when using the "mesh-under" MoP.
このセクションでは、「メッシュアンダー」MoPを使用するときに、セクション2.2の一般的な用語を特定の用語にマッピングします。
The following terms are those listed in Section 2.2 (besides "Mode of Operation"), and their meaning is explicitly defined when DFF is used in the "mesh-under" MoP.
以下の用語は、セクション2.2（「動作モード」以外）にリストされている用語であり、その意味は、「メッシュアンダー」MoPでDFFが使用される場合に明示的に定義されます。
Packet - A "LoWPAN-encapsulated packet" (as specified in [RFC4944]), which contains an IPv6 packet as payload.
パケット-「LoWPANカプセル化パケット」（[RFC4944]で指定）には、IPv6パケットがペイロードとして含まれています。
Packet Header - A LoWPAN header, as specified in [RFC4944].
パケットヘッダー-[RFC4944]で指定されているLoWPANヘッダー。
Address - A 16-bit short or EUI-64 link-layer address, as specified in [RFC4944].
アドレス-[RFC4944]で指定されている、16ビットのショートまたはEUI-64リンク層アドレス。
Originator Address - The Originator Address corresponds to the Originator Address field of the Mesh Addressing header, as specified in [RFC4944].
発信者アドレス-[RFC4944]で指定されているように、発信者アドレスはメッシュアドレッシングヘッダーの発信者アドレスフィールドに対応します。
Destination Address - The Destination Address corresponds to the Final Destination field of the Mesh Addressing header, as specified in [RFC4944].
宛先アドレス-[RFC4944]で指定されているように、宛先アドレスはメッシュアドレッシングヘッダーの最終宛先フィールドに対応します。
Next Hop - The Next Hop is the Destination Address of a frame containing a LoWPAN-encapsulated packet, as specified in [RFC4944].
ネクストホップ-ネクストホップは、[RFC4944]で指定されている、LoWPANカプセル化パケットを含むフレームの宛先アドレスです。
Previous Hop - The Previous Hop is the Source Address of the frame containing a LoWPAN-encapsulated packet, as specified in [RFC4944].
前のホップ-前のホップは、[RFC4944]で指定されている、LoWPANカプセル化パケットを含むフレームのソースアドレスです。
Hop Limit - The Hop Limit corresponds to the Deep Hops Left field in the Mesh Addressing header, as specified in [RFC4944].
ホップ制限-[RFC4944]で指定されているように、ホップ制限はメッシュアドレッシングヘッダーの[Deep Hops Left]フィールドに対応します。
In the "mesh-under" MoP, all IPv6 packets MUST conform with the format specified in [RFC4944]. All data packets exchanged by routers using this specification MUST contain the Mesh Addressing header as part of the LoWPAN encapsulation, as specified in [RFC4944].
「メッシュアンダー」MoPでは、すべてのIPv6パケットは[RFC4944]で指定されたフォーマットに準拠する必要があります。 [RFC4944]で指定されているように、この仕様を使用してルーターによって交換されるすべてのデータパケットには、LoWPANカプセル化の一部としてメッシュアドレッシングヘッダーが含まれている必要があります。
The DFF header, as specified below, MUST follow the Mesh Addressing header. After these two headers, any other LoWPAN header, e.g., header compression or fragmentation headers, MAY also be added before the actual payload. Figure 2 depicts the Mesh Addressing header defined in [RFC4944], and Figure 3 depicts the DFF header.
以下で指定するDFFヘッダーは、メッシュアドレッシングヘッダーに続く必要があります。これらの2つのヘッダーの後に、他のLoWPANヘッダー（ヘッダー圧縮ヘッダーやフラグメンテーションヘッダーなど）も、実際のペイロードの前に追加できます（MAY）。図2は[RFC4944]で定義されたメッシュアドレス指定ヘッダーを示し、図3はDFFヘッダーを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| DeepHopsLeft |orig. address, final address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Mesh Addressing Header
図2：メッシュアドレス指定ヘッダー
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| Mesh Forw |VER|D|R|0|0|0|0| sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Header for DFF Data Packets
図3：DFFデータパケットのヘッダー
Field definitions of the Mesh Addressing header are as specified in [RFC4944]. When adding that header to the LoWPAN encapsulation on the Originator, the fields of the Mesh Addressing header MUST be set to the following values: o V := 0 if the Originator Address is an IEEE extended 64-bit address (EUI-64); otherwise, V := 1 if it is a short 16-bit address.
Mesh Addressingヘッダーのフィールド定義は、[RFC4944]で指定されています。そのヘッダーを発信元のLoWPANカプセル化に追加する場合、メッシュアドレス指定ヘッダーのフィールドを次の値に設定する必要があります。o V：= 0発信元アドレスがIEEE拡張64ビットアドレス（EUI-64）の場合。それ以外の場合、短い16ビットアドレスの場合はV：= 1。
o F := 0 if the Final Destination Address is an IEEE extended 64-bit address (EUI-64); otherwise, F := 1 if it is a short 16-bit address.
o F：=最終宛先アドレスがIEEE拡張64ビットアドレス（EUI-64）の場合は0。それ以外の場合、それが短い16ビットアドレスの場合、F：= 1です。
o Hops Left := 0xF (i.e., reserved value indicating that the Deep Hops Left field follows);
o 左ホップ：= 0xF（つまり、[左のディープホップ]フィールドが続くことを示す予約値）;
o Deep Hops Left := MAX_HOP_LIMIT.
o ディープホップ残り：= MAX_HOP_LIMIT。
Field definitions of the DFF header are as follows:
DFFヘッダーのフィールド定義は次のとおりです。
Mesh Forw - A 6-bit identifier that allows for the use of different mesh-forwarding mechanisms. As specified in [RFC4944], additional mesh-forwarding mechanisms should use the reserved dispatch byte values following LOWPAN_BC0; therefore, '0 1' MUST precede Mesh Forw. The value of Mesh Forw is LOWPAN_DFF.
Mesh Forw-さまざまなメッシュ転送メカニズムの使用を可能にする6ビットの識別子。 [RFC4944]で指定されているように、追加のメッシュ転送メカニズムは、LOWPAN_BC0に続く予約済みディスパッチバイト値を使用する必要があります。したがって、「0 1」はMesh Forwの前になければなりません。 Mesh Forwの値はLOWPAN_DFFです。
DFF fields - A 2-bit version (abbreviated as VER) field; the DUP (abbreviated as D) and RET (abbreviated as R) flags follow after Mesh Forw, as specified in Section 13.2.2. The version specified in this document is '00'. All other bits (besides VER, DUP, and RET) of this octet are reserved and MUST be set to 0.
DFFフィールド-2ビットバージョン（略称VER）フィールド。セクション13.2.2で指定されているように、DUP（略してD）およびRET（略してR）フラグはMesh Forwの後に続きます。このドキュメントで指定されているバージョンは「00」です。このオクテットの他のすべてのビット（VER、DUP、およびRETを除く）は予約されており、0に設定する必要があります。
Sequence Number - A 16-bit field, containing an unsigned integer sequence number, as specified in Section 7.
シーケンス番号-セクション7で指定されている、符号なし整数のシーケンス番号を含む16ビットのフィールド。
The forwarding mechanism specified in this document MUST be limited in scope to the routing domain in which DFF is used. That also implies that any headers specific to DFF do not traverse the boundaries of the routing domain. This section specifies, both for the "route-over" MoP and the "mesh-under" MoP, how to limit the scope of DFF to the routing domain in which it is used.
このドキュメントで指定されている転送メカニズムは、DFFが使用されているルーティングドメインにスコープを限定する必要があります。これは、DFFに固有のヘッダーがルーティングドメインの境界を通過しないことも意味します。このセクションでは、「route-over」MoPと「mesh-under」MoPの両方について、DFFのスコープを、それが使用されるルーティングドメインに制限する方法を指定します。
Figures 4 to 7 depict four different cases for source and destination of traffic with regards to the scope of the routing domain in which DFF is used. Sections 14.1 and 14.2 specify how routers limit the scope of DFF for the "route-over" MoP and the "mesh-under" MoP, respectively, for these cases. In these sections, all nodes "inside the routing domain" are routers and use DFF, and may also be sources or destinations. Sources or destinations "outside the routing domain" do not run DFF; either they are hosts attached to a router in the routing domain that is running DFF, or they are themselves routers but outside the routing domain and not running DFF.
図4〜7は、DFFが使用されるルーティングドメインのスコープに関して、トラフィックの送信元と宛先の4つの異なるケースを示しています。セクション14.1および14.2は、これらの場合に、ルーターが「ルートオーバー」MoPおよび「メッシュアンダー」MoPのDFFのスコープをそれぞれ制限する方法を指定します。これらのセクションでは、「ルーティングドメイン内」のすべてのノードがルーターであり、DFFを使用しており、送信元または宛先である場合もあります。 「ルーティングドメイン外」の送信元または宛先はDFFを実行しません。それらは、DFFを実行しているルーティングドメイン内のルーターに接続されているホストであるか、またはそれら自体がルーターであるがルーティングドメイン外にあり、DFFを実行していないかのいずれかです。
+-----------------+
| |
| (S) ----> (D) |
| |
+-----------------+
Routing Domain
Figure 4: Traffic within the Routing Domain (from S to D)
図4：ルーティングドメイン内のトラフィック（SからDへ）
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
Routing Domain
Figure 5: Traffic from Within the Routing Domain to Outside of the Domain (from S to D)
図5：ルーティングドメイン内からドメイン外へのトラフィック（SからD）
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
Routing Domain
Figure 6: Traffic from Outside the Routing Domain to Inside the Domain (from S to D)
図6：ルーティングドメインの外側からドメインの内側へのトラフィック（SからDへ）
+-----------------+
| |
(S) --------> (R1) -----------> (R2) --------> (D)
| |
+-----------------+
Routing Domain
Figure 7: Traffic from Outside the Routing Domain, Traversing the Domain and Then to the Outside of the Domain (from S to D)
図7：ルーティングドメインの外側からドメインを通過し、次にドメインの外側へのトラフィック（SからD）
Key: (S) = source router (D) = destination router (R), (R1), (R2) = other routers
キー：（S）=送信元ルーター（D）=宛先ルーター（R）、（R1）、（R2）=その他のルーター
In Figure 4, both the source and destination of the traffic are routers within the routing domain. If traffic is originated at S, the DFF header is added to the IPv6 header (as specified in Section 13.1.2). The Originator Address is set to S and the Destination Address is set to D. The packet is forwarded to D using this specification. When router D receives the packet, it processes the payload of the IPv6 packet in upper layers. This case assumes that S has knowledge that D is in the routing domain, e.g., because of the administrative setting based on the IP address of the destination. If S has no knowledge about whether D is in the routing domain, IPv6-in-IPv6 tunnels as specified in [RFC2473] MUST be used. These cases are described in the following paragraphs.
図4では、トラフィックの送信元と宛先の両方がルーティングドメイン内のルーターです。トラフィックがSで発信された場合、DFFヘッダーがIPv6ヘッダーに追加されます（セクション13.1.2で指定）。発信元アドレスはSに設定され、宛先アドレスはDに設定されます。パケットは、この仕様を使用してDに転送されます。ルーターDはパケットを受信すると、IPv6パケットのペイロードを上位層で処理します。このケースでは、宛先のIPアドレスに基づく管理設定などにより、DがルーティングドメインにあることをSが知っていると想定しています。 DがルーティングドメインにあるかどうかについてSが認識していない場合、[RFC2473]で指定されているIPv6-in-IPv6トンネルを使用する必要があります。これらのケースについては、次の段落で説明します。
In Figure 5, the source of the traffic (S) is within the routing domain, and the destination (D) is outside of the routing domain. The IPv6 packet, originated at S, MUST be encapsulated according to [RFC2473] (IPv6-in-IPv6 tunnels) and the DFF header MUST be added to the outer IPv6 header. S chooses the next router that should process the packet as the tunnel exit-point (R). Administrative settings, as well as information from a routing protocol, may be used to determine the tunnel exit-point. If no information is available for which router to choose as the tunnel exit-point, the Next Hop MUST be used as the tunnel exit-point. In some cases, the tunnel exit-point will be the final router along a path towards the packet's destination, and the packet will only traverse a single tunnel (e.g., if R is a known border router then S can choose R as the tunnel exit-point). In other cases, the tunnel exit-point will not be the final router along the path to D, and the packet may traverse multiple tunnels to reach the destination; note that in this case, the DFF mechanism is only used inside each IPv6-in-IPv6 tunnel. The Originator Address of the packet is set to S and the Destination Address is set to the tunnel exit-point (in the outer IPv6 header). The packet is forwarded to the tunnel exit-point using this specification (potentially using multiple consecutive IPv6-in-IPv6 tunnels). When router R receives the packet, it decapsulates the IPv6 packet and forwards the inner IPv6 packet to D, using normal IPv6 forwarding as specified in [RFC2460].
図5では、トラフィックのソース（S）はルーティングドメイン内にあり、宛先（D）はルーティングドメイン外にあります。 Sで生成されたIPv6パケットは、[RFC2473]（IPv6-in-IPv6トンネル）に従ってカプセル化されなければならず、DFFヘッダーは外部IPv6ヘッダーに追加されなければなりません（MUST）。 Sは、パケットを処理する次のルーターをトンネル出口点（R）として選択します。管理設定とルーティングプロトコルからの情報を使用して、トンネルの出口点を決定できます。トンネルの出口点として選択するルーターに関する情報がない場合は、ネクストホップをトンネルの出口点として使用する必要があります。場合によっては、トンネルの出口点は、パケットの宛先に向かうパスに沿った最後のルーターとなり、パケットは単一のトンネルのみを通過します（たとえば、Rが既知の境界ルーターである場合、Sはトンネルの出口としてRを選択できます） -ポイント）。他の場合では、トンネルの出口点はDへのパスに沿った最後のルーターではなく、パケットは複数のトンネルを通過して宛先に到達することがあります。この場合、DFFメカニズムは各IPv6-in-IPv6トンネル内でのみ使用されることに注意してください。パケットの発信元アドレスはSに設定され、宛先アドレスは（外部IPv6ヘッダー内の）トンネル出口ポイントに設定されます。パケットは、この仕様を使用して（場合によっては、複数の連続するIPv6-in-IPv6トンネルを使用して）トンネル出口ポイントに転送されます。ルータRはパケットを受信すると、IPv6パケットのカプセル化を解除し、内部のIPv6パケットをDに転送します。これには、[RFC2460]で指定されている通常のIPv6転送を使用します。
In Figure 6, the source of the traffic (S) is outside of the routing domain, and the destination (D) is inside of the routing domain. The IPv6 packet, originated at S, is forwarded to R using normal IPv6 forwarding as specified in [RFC2460]. Router R MUST encapsulate the IPv6 packet according to [RFC2473] and add the DFF header (as specified in Section 13.1.2) to the outer IPv6 header. Like in the previous case, R has to select a tunnel exit-point; if it knows that D is in the routing domain (e.g., based on administrative settings), it SHOULD select D as the tunnel exit-point. In case it does not have any information as to which exit-point to select, it MUST use the Next Hop as the tunnel exit-point, limiting the effectiveness of DFF to inside each IPv6-in-IPv6 tunnel. The Originator Address of the packet is set to R, the Destination Address to the tunnel exit-point (both in the outer IPv6 header), and the sequence number in the DFF header is generated locally on R. The packet is forwarded to D using this specification. When router D receives the packet, it decapsulates the inner IPv6 packet and processes the payload of the inner IPv6 packet in upper layers.
図6では、トラフィックのソース（S）はルーティングドメインの外側にあり、宛先（D）はルーティングドメインの内側にあります。 Sで発信されたIPv6パケットは、[RFC2460]で指定されている通常のIPv6転送を使用してRに転送されます。ルータRは[RFC2473]に従ってIPv6パケットをカプセル化し、DFFヘッダー（セクション13.1.2で指定）を外部IPv6ヘッダーに追加する必要があります。前のケースと同様に、Rはトンネルの出口点を選択する必要があります。 Dがルーティングドメインにあることがわかっている場合（たとえば、管理設定に基づいて）、Dをトンネル出口ポイントとして選択する必要があります（SHOULD）。選択する出口点に関する情報がない場合は、ネクストホップをトンネル出口点として使用し、DFFの有効性を各IPv6-in-IPv6トンネル内に制限する必要があります。パケットの発信元アドレスはR、トンネル出口ポイントへの宛先アドレス（両方とも外部IPv6ヘッダー内）に設定され、DFFヘッダー内のシーケンス番号はRでローカルに生成されます。パケットはDに転送されますこの仕様。ルーターDはパケットを受信すると、内部IPv6パケットのカプセル化を解除し、内部IPv6パケットのペイロードを上位層で処理します。
This mechanism is typically not used in transit networks; therefore, this case is discouraged, but described nevertheless for completeness. In Figure 7, both the source of the traffic (S) and the destination (D) are outside of the routing domain. The IPv6 packet, originated at S, is forwarded to R1 using normal IPv6 forwarding, as specified in [RFC2460]. Router R1 MUST encapsulate the IPv6 packet according to [RFC2473] and add the DFF header (as specified in Section 13.1.2). R1 selects a tunnel exit-point like in the previous cases; if R2 is, e.g., a known border router, then R1 can select R2 as the tunnel exit-point. The Originator Address is set to R1, the Destination Address is set to the tunnel exit-point (both in the outer IPv6 header), and the sequence number in the DFF header is generated locally on R1. The packet is forwarded to the tunnel exit-point using this specification (potentially traversing multiple consecutive IPv6-in-IPv6 tunnels). When router R2 receives the packet, it decapsulates the inner IPv6 packet and forwards the inner IPv6 packet to D, using normal IPv6 forwarding as specified in [RFC2460].
このメカニズムは通常、トランジットネットワークでは使用されません。したがって、このケースは推奨されませんが、完全を期すために説明されています。図7では、トラフィックの送信元（S）と宛先（D）の両方がルーティングドメインの外にあります。 Sで発信されたIPv6パケットは、[RFC2460]で指定されている通常のIPv6転送を使用してR1に転送されます。ルータR1は、[RFC2473]に従ってIPv6パケットをカプセル化し、DFFヘッダーを追加する必要があります（セクション13.1.2で指定）。 R1は、前のケースと同様にトンネル出口ポイントを選択します。 R2が、たとえば既知の境界ルーターである場合、R1はトンネル出口ポイントとしてR2を選択できます。発信元アドレスはR1に設定され、宛先アドレスはトンネル出口ポイント（両方とも外部IPv6ヘッダー内）に設定され、DFFヘッダー内のシーケンス番号はR1でローカルに生成されます。パケットは、この仕様を使用してトンネル出口ポイントに転送されます（複数の連続するIPv6-in-IPv6トンネルを通過する可能性があります）。ルータR2は、パケットを受信すると、内部IPv6パケットのカプセル化を解除し、[RFC2460]で指定されている通常のIPv6転送を使用して、内部IPv6パケットをDに転送します。
In Figure 4, both the source and destination of the traffic are routers within the routing domain. If traffic is originated at router S, the LoWPAN-encapsulated packet is created from the IPv6 packet, as specified in [RFC4944]. Then, the Mesh Addressing header and the DFF header (as specified in Section 13.2.2) are added to the LoWPAN encapsulation on router S. The Originator Address is set to S and the Destination Address is set to D. The packet is then forwarded using this specification. When router D receives the packet, it processes the payload of the packet in upper layers.
図4では、トラフィックの送信元と宛先の両方がルーティングドメイン内のルーターです。トラフィックがルータSで発信された場合、LoWPANカプセル化パケットは、[RFC4944]で指定されているように、IPv6パケットから作成されます。次に、メッシュアドレス指定ヘッダーとDFFヘッダー（セクション13.2.2で指定）がルーターSのLoWPANカプセル化に追加されます。発信者アドレスはSに設定され、宛先アドレスはDに設定されます。次に、パケットが転送されます。この仕様を使用します。ルータDはパケットを受信すると、パケットのペイロードを上位層で処理します。
In Figure 5, the source of the traffic (S) is within the routing domain, and the destination (D) is outside of the routing domain (which is known by S to be outside the routing domain because D uses a different IP prefix from the PAN). The LoWPAN-encapsulated packet, originated at router S, is created from the IPv6 packet as specified in [RFC4944]. Then, the Mesh Addressing header and the DFF header (as specified in Section 13.2.2) are added to the LoWPAN encapsulation on router S. The Originator Address is set to S and the Destination Address is set to R, which is a known border router of the PAN. The packet is then forwarded using this specification. When router R receives the packet, it restores the IPv6 packet from the LoWPAN-encapsulated packet and forwards it to D, using normal IPv6 forwarding, as specified in [RFC2460].
図5では、トラフィックの送信元（S）はルーティングドメイン内にあり、宛先（D）はルーティングドメイン外にあります（Dは、 PAN）。ルータSで発信されたLoWPANカプセル化パケットは、[RFC4944]で指定されているIPv6パケットから作成されます。次に、メッシュアドレス指定ヘッダーとDFFヘッダー（セクション13.2.2で指定）がルーターSのLoWPANカプセル化に追加されます。発信元アドレスはSに設定され、宛先アドレスは既知の境界であるRに設定されます。 PANのルーター。次に、この仕様を使用してパケットが転送されます。ルータRがパケットを受信すると、LoWPANカプセル化パケットからIPv6パケットを復元し、[RFC2460]で指定されている通常のIPv6転送を使用してDに転送します。
In Figure 6, the source of the traffic (S) is outside of the routing domain, and the destination (D) is inside of the routing domain. The IPv6 packet, originated at S, is forwarded to R using normal IPv6 forwarding, as specified in [RFC2460]. Router R (which is a known border router to the PAN) creates the LoWPAN-encapsulated packet from the IPv6 packet, as specified in [RFC4944]. Then, R adds the Mesh Addressing header and the DFF header (as specified in Section 13.2.2). The Originator Address is set to R, the Destination Address to D, and the sequence number in the DFF header is generated locally on R. The packet is forwarded to D using this specification. When router D receives the packet, it restores the IPv6 packet from the LoWPAN-encapsulated packet and processes the payload in upper layers.
図6では、トラフィックのソース（S）はルーティングドメインの外側にあり、宛先（D）はルーティングドメインの内側にあります。 Sで発信されたIPv6パケットは、[RFC2460]で指定されているように、通常のIPv6転送を使用してRに転送されます。ルータR（PANへの既知の境界ルータ）は、[RFC4944]で指定されているように、IPv6パケットからLoWPANカプセル化パケットを作成します。次に、Rは、メッシュアドレス指定ヘッダーとDFFヘッダーを追加します（セクション13.2.2で指定）。発信元アドレスはRに、宛先アドレスはDに設定され、DFFヘッダーのシーケンス番号はRでローカルに生成されます。パケットは、この仕様を使用してDに転送されます。ルーターDは、パケットを受信すると、LoWPANでカプセル化されたパケットからIPv6パケットを復元し、ペイロードを上位層で処理します。
As LoWPANs are typically not transit networks, the following case is discouraged, but described nevertheless for completeness: In Figure 7, both the source of the traffic (S) and the destination (D) are outside of the routing domain. The IPv6 packet, originated at S, is forwarded to R1 using normal IPv6 forwarding, as specified in [RFC2460]. Router R1 (which is a known border router of the PAN) creates the LoWPAN-encapsulated packet from the IPv6 packet, as specified in [RFC4944]. Then, it adds the Mesh Addressing header and the DFF header (as specified in Section 13.2.2). The Originator Address is set to R1, the Destination Address is set to R2 (which is another border router towards the destination), and the sequence number in the DFF header is generated locally on R1. The packet is forwarded to R2 using this specification. When router R2 receives the packet, it restores the IPv6 packet from the LoWPAN-encapsulated packet and forwards the IPv6 packet to D, using normal IPv6 forwarding, as specified in [RFC2460].
LoWPANは通常トランジットネットワークではないため、次のケースはお勧めしませんが、完全を期して説明します。図7では、トラフィックの送信元（S）と宛先（D）の両方がルーティングドメインの外側にあります。 Sで発信されたIPv6パケットは、[RFC2460]で指定されている通常のIPv6転送を使用してR1に転送されます。 [RFC4944]で指定されているように、ルーターR1（PANの既知の境界ルーター）は、IPv6パケットからLoWPANカプセル化パケットを作成します。次に、メッシュアドレッシングヘッダーとDFFヘッダーを追加します（セクション13.2.2で指定）。発信元アドレスはR1に設定され、宛先アドレスはR2（宛先への別の境界ルーター）に設定され、DFFヘッダーのシーケンス番号はR1でローカルに生成されます。パケットは、この仕様を使用してR2に転送されます。ルータR2がパケットを受信すると、LoWPANカプセル化パケットからIPv6パケットを復元し、[RFC2460]で指定されているように、通常のIPv6転送を使用してIPv6パケットをDに転送します。
When adding the DFF header, as specified in Section 9.1, or when encapsulating the packet, as specified in Section 14, the packet size may exceed the MTU. This is described in Section 5 of [RFC2460]. When the packet size of a packet to be forwarded by DFF exceeds the MTU, the following steps apply.
セクション9.1で指定されているようにDFFヘッダーを追加するとき、またはセクション14で指定されているようにパケットをカプセル化するときに、パケットサイズがMTUを超える場合があります。これは[RFC2460]のセクション5で説明されています。 DFFによって転送されるパケットのパケットサイズがMTUを超える場合、次の手順が適用されます。
1. The router MUST discard the packet.
1. ルーターはパケットを破棄しなければなりません（MUST）。
2. The router MAY log the event locally (depending on the storage capabilities of the router).
2. ルーターはローカルでイベントをログに記録できます（ルーターのストレージ機能によって異なります）。
3. The router MUST send back an ICMP "Packet Too Big" message to the source of the packet and report back the Next Hop MTU, which includes the overhead of adding the headers.
3. ルーターはICMP "Packet Too Big"メッセージをパケットの送信元に送り返し、ヘッダーを追加するオーバーヘッドを含むNext Hop MTUを報告しなければなりません（MUST）。
Based on the recommendations in [RFC3552], this section describes security threats to DFF and lists which attacks are out of scope, which attacks DFF is susceptible to, and which attacks DFF protects against.
[RFC3552]の推奨事項に基づいて、このセクションではDFFに対するセキュリティの脅威について説明し、どの攻撃が範囲外であるか、どの攻撃がDFFの影響を受けやすく、どの攻撃がDFFから保護されるかを示します。
As DFF is a data-forwarding protocol, any security issues concerning the payload of the packets are not considered in this section.
DFFはデータ転送プロトコルであるため、パケットのペイロードに関するセキュリティの問題は、このセクションでは考慮されません。
It is the responsibility of upper layers to use appropriate security mechanisms (IPsec, Transport Layer Security (TLS), etc.) according to application requirements. As DFF does not modify the contents of IP datagrams, other than the DFF header (which is a Hop-by-Hop Options extension header in the "route-over" MoP, and therefore not protected by IPsec), no special considerations for IPsec have to be addressed.
アプリケーションの要件に応じて適切なセキュリティメカニズム（IPsec、トランスポート層セキュリティ（TLS）など）を使用するのは、上位層の責任です。 DFFはDFFヘッダー（「route-over」MoPのホップバイホップオプション拡張ヘッダーであり、したがってIPsecによって保護されない）以外のIPデータグラムの内容を変更しないため、IPsecに関する特別な考慮事項はありません対処する必要があります。
Any attack that is not specific to DFF but that applies in general to the link layer (e.g., wireless, Power Line Communication (PLC)) is out of scope. In particular, these attacks are: eavesdropping, packet insertion, packet replay, packet deletion, and man-in-the-middle attacks. Appropriate link-layer encryption can mitigate part of these attacks and is therefore RECOMMENDED.
DFFに固有ではないが、一般にリンク層（ワイヤレス、電力線通信（PLC）など）に適用される攻撃は、範囲外です。特に、これらの攻撃は、盗聴、パケット挿入、パケット再生、パケット削除、および中間者攻撃です。適切なリンク層暗号化は、これらの攻撃の一部を軽減できるため、推奨されます。
DFF itself does not provide any additional integrity, confidentiality, or authentication. Therefore, the level of protection of DFF depends on the underlying link-layer security, as well as protection of the payload by upper-layer security (e.g., IPsec).
DFF自体は、追加の整合性、機密性、または認証を提供しません。したがって、DFFの保護レベルは、基盤となるリンク層のセキュリティと、上位層のセキュリティ（IPsecなど）によるペイロードの保護に依存します。
In the following sections, whenever encrypting or digitally signing packets is suggested for protecting DFF, it is assumed that routers are not compromised.
次のセクションでは、DFFを保護するためにパケットの暗号化またはデジタル署名が提案されている場合は常に、ルーターが危険にさらされていないことを前提としています。
This section discusses security threats to DFF, and for each, describes whether (and how) DFF is affected by the threat. DFF is designed to be used in lossy and unreliable networks. Predominant examples of lossy networks are wireless networks, where routers send packets via broadcast. The attacks listed below are easier to exploit in wireless media but can also be observed in wired networks.
このセクションでは、DFFに対するセキュリティの脅威について説明し、それぞれについて、DFFが脅威の影響を受けるかどうか（およびその方法）について説明します。 DFFは、損失が多く信頼性の低いネットワークで使用するように設計されています。損失の多いネットワークの主な例は、ルーターがブロードキャストを介してパケットを送信するワイヤレスネットワークです。以下にリストされている攻撃は、ワイヤレスメディアで悪用するのが簡単ですが、有線ネットワークでも確認できます。
Denial-of-service (DoS) attacks are possible when using DFF by either exceeding the storage on a router or exceeding the available bandwidth of the channel. As DFF does not contain any algorithms with high complexity, it is unlikely that the processing power of the router could be exhausted by an attack on DFF.
ルータのストレージを超えるか、チャネルの利用可能な帯域幅を超えることによってDFFを使用する場合、サービス拒否（DoS）攻撃が可能です。 DFFには複雑度の高いアルゴリズムが含まれていないため、DFFへの攻撃によってルータの処理能力が使い果たされる可能性はほとんどありません。
The storage of a router can be exhausted by increasing the size of the Processed Set, i.e., by adding new tuples, or by increasing the size of each tuple. New tuples can be added by injecting new packets in the network or by forwarding overheard packets.
ルーターのストレージは、処理済みセットのサイズを増やす、つまり新しいタプルを追加するか、各タプルのサイズを増やすことによって使い果たすことができます。新しいタプルを追加するには、ネットワークに新しいパケットを注入するか、傍受されたパケットを転送します。
Another possible DoS attack is to send packets to a non-existing address in the network. DFF would perform a depth-first search until the Hop Limit has reached zero. It is therefore RECOMMENDED to set the Hop Limit to a value that limits the path length.
もう1つの可能なDoS攻撃は、ネットワーク内に存在しないアドレスにパケットを送信することです。 DFFは、ホップ制限がゼロに達するまで、深さ優先検索を実行します。したがって、ホップ制限をパス長を制限する値に設定することをお勧めします。
If security provided by the link layer is used, this attack can be mitigated if the malicious router does not possess valid credentials, since other routers would not forward data through the malicious router.
リンク層によって提供されるセキュリティが使用されている場合、悪意のあるルーターが有効な資格情報を持っていない場合、他のルーターが悪意のあるルーターを介してデータを転送しないため、この攻撃を緩和できます。
The following attacks can be exploited by modifying the packet header information, unless additional security (such as link-layer security) is used.
次の攻撃は、追加のセキュリティ（リンク層セキュリティなど）が使用されていない限り、パケットヘッダー情報を変更することで悪用される可能性があります。
A malicious router may tamper with the "return" flag of a DFF packet and send it back to the Previous Hop, but only if the malicious router has been selected as the Next Hop by the receiving router (as specified in Section 9.2). If the malicious router had not been selected as the Next Hop, then a returned packet is dropped by the receiving router. Otherwise (i.e., the malicious router had been selected as the Next Hop by the receiving router, and the malicious router has set the return flag), the receiving router then tries alternative neighbors. This may lead to packets never reaching their destination, as well as an unnecessary depth-first search in the network (bandwidth exhaustion / energy drain).
悪意のあるルーターは、DFFパケットの「リターン」フラグを改ざんして前のホップに送り返す場合がありますが、悪意のあるルーターが受信ルーターによって次のホップとして選択されている場合に限ります（セクション9.2で指定）。悪意のあるルーターがネクストホップとして選択されていなかった場合、返されたパケットは受信ルーターによってドロップされます。それ以外の場合（つまり、悪意のあるルーターが受信ルーターによってネクストホップとして選択されており、悪意のあるルーターがリターンフラグを設定している場合）、受信ルーターは代替ネイバーを試行します。これにより、パケットが宛先に到達しないだけでなく、ネットワークで不要な縦型検索が行われる可能性があります（帯域幅の枯渇/エネルギー消費）。
This attack can be mitigated by using appropriate security of the underlying link layer.
この攻撃は、基盤となるリンク層の適切なセキュリティを使用することで軽減できます。
A malicious router may modify the Duplicate Flag of a packet that it forwards.
悪意のあるルーターは、転送するパケットの重複フラグを変更する可能性があります。
If it changes the flag from 0 to 1, the packet would be detected as a duplicate by other routers in the network and not as a looping packet.
フラグを0から1に変更すると、パケットはループパケットとしてではなく、ネットワーク内の他のルーターによって重複として検出されます。
If the Duplicate Flag is changed from 1 to 0, and a router receives that packet for the second time (i.e., it has already received a packet with the same Originator Address and sequence number before), it will wrongly detect a loop.
重複フラグが1から0に変更され、ルーターが2回目にそのパケットを受信した場合（つまり、以前に同じ発信元アドレスとシーケンス番号のパケットを既に受信している場合）、ループが誤って検出されます。
This attack can be mitigated by using appropriate security of the underlying link layer.
この攻撃は、基盤となるリンク層の適切なセキュリティを使用することで軽減できます。
A malicious router may modify the sequence number of a packet that it forwards.
悪意のあるルーターは、転送するパケットのシーケンス番号を変更する可能性があります。
In particular, if the sequence number is modified to a number of another, previously sent packet of the same Originator, this packet may be wrongly perceived as a looping packet.
特に、シーケンス番号が同じ送信元の以前に送信された別のパケットの番号に変更された場合、このパケットはループパケットとして誤って認識される可能性があります。
This attack can be mitigated by using appropriate security of the underlying link layer.
この攻撃は、基盤となるリンク層の適切なセキュリティを使用することで軽減できます。
IANA has allocated the value 01 000011 for LOWPAN_DFF from the Dispatch Type Field registry.
IANAは、Dispatch Type FieldレジストリからLOWPAN_DFFに値01 000011を割り当てました。
IANA has allocated the value 0xEE for IP_DFF from the Destination Options and Hop-by-Hop Options registry. The first 3 bits of that value are 111.
IANAは、宛先オプションおよびホップバイホップオプションレジストリからIP_DFFに値0xEEを割り当てました。その値の最初の3ビットは111です。
Jari Arkko (Ericsson), Abdussalam Baryun (University of Glamorgan), Antonin Bas (Ecole Polytechnique), Thomas Clausen (Ecole Polytechnifque), Yuichi Igarashi (Hitachi), Kazuya Monden (Hitachi), Geoff Mulligan (Proto6), Hiroki Satoh (Hitachi), Ganesh Venkatesh (Mobelitix), and Jiazi Yi (Ecole Polytechnique) provided useful reviews of the draft and discussions, which helped to improve this document.
Jari Arkko（エリクソン）、Abdussalam Baryun（グラモーガン大学）、Antonin Bas（Ecole Polytechnique）、Thomas Clausen（Ecole Polytechnifque）、五十嵐雄一（Hitachi）、Kazuya Monden（Hitachi）、Geoff Mulligan（Proto6）、Hitachi Satoh（Hita） ）、Ganesh Venkatesh（Mobelitix）、およびJiazi Yi（Ecole Polytechnique）がドラフトの有用なレビューとディスカッションを提供し、このドキュメントの改善に役立ちました。
The authors also would like to thank Ralph Droms, Adrian Farrel, Stephen Farrell, Ted Lemon, Alvaro Retana, Dan Romascanu, and Martin Stiemerling for their reviews during IETF LC and IESG evaluation.
著者はまた、IETF LCとIESGの評価中のレビューについて、Ralph Droms、Adrian Farrel、Stephen Farrell、Ted Lemon、Alvaro Retana、Dan Romascanu、およびMartin Stiemerlingに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、1998年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、2007年9月。
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, April 2011.
[RFC6130] Clausen、T.、Dearlove、C。、およびJ. Dean、「モバイルアドホックネットワーク（MANET）近隣探索プロトコル（NHDP）」、RFC 6130、2011年4月。
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012.
[RFC6564]クリシュナン、S。、ウッディアット、J。、クライン、E。、ホアグランド、J。、およびM.バティア、「IPv6拡張ヘッダーの統一フォーマット」、RFC 6564、2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[DFF_paper1] Cespedes, S., Cardenas, A., and T. Iwao, "Comparison of Data Forwarding Mechanisms for AMI Networks", 2012 IEEE Innovative Smart Grid Technologies Conference (ISGT), January 2012.
[DFF_paper1] Cespedes、S.、Cardenas、A。、およびT. Iwao、「Comparison of Data Forwarding Mechanisms for AMI Networks」、2012 IEEE Innovative Smart Grid Technologies Conference（ISGT）、2012年1月。
[DFF_paper2] Iwao, T., Iwao, T., Yura, M., Nakaya, Y., Cardenas, A., Lee, S., and R. Masuoka, "Dynamic Data Forwarding in Wireless Mesh Networks", First IEEE International Conference on Smart Grid Communications (SmartGridComm), October 2010.
[DFF_paper2]岩尾敏夫、岩尾敏夫、由良正夫、中谷由紀夫、カルデナス、A。、リー、S。、およびR.マスオカ、「ワイヤレスメッシュネットワークにおける動的データ転送」、最初のIEEEスマートグリッド通信に関する国際会議（SmartGridComm）、2010年10月。
[DFS_wikipedia] Wikipedia, "Depth-first search", May 2013, <http://en.wikipedia.org/w/ index.php?title=Depth-first_search&oldid=555203731>.
[DFS_wikipedia]ウィキペディア、「深さ優先検索」、2013年5月、<http://en.wikipedia.org/w/ index.php？title = Depth-first_search＆oldid = 555203731>。
[KCEC_press_release] Kit Carson Electric Cooperative (KCEC), "DFF deployed by KCEC", Press Release, 2011, <http://www.kitcarson.com/ index.php?option=com_content&view=article&id=45&Itemid=1>.
[KCEC_press_release]キットカーソンエレクトリックコーポラティブ（KCEC）、「KFFによって展開されたDFF」、プレスリリース、2011年、<http://www.kitcarson.com/ index.php？option = com_content＆view = article＆id = 45＆Itemid = 1>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012.
[RFC6775] Shelby、Z.、Chakrabarti、S.、Nordmark、E。、およびC. Bormann、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）のネイバー探索最適化」、RFC 6775、2012年11月。
In this section, some example network topologies are depicted, using the DFF mechanism for data forwarding. In these examples, it is assumed there is a routing protocol running that adds or inserts entries into the RIB.
このセクションでは、データ転送にDFFメカニズムを使用して、いくつかのネットワークトポロジの例を示します。これらの例では、RIBにエントリを追加または挿入するルーティングプロトコルが実行されていると想定しています。
Example 1 depicts a network topology with seven routers, A to G, with links between them as indicated by lines. It is assumed that router A sends a packet to G, through B and D, according to the routing protocol.
例1は、AからGまでの7つのルーターがあり、それらの間のリンクが線で示されているネットワークトポロジを示しています。ルータAがルーティングプロトコルに従って、BおよびDを介してパケットをGに送信するとします。
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
Example 1: Normal Delivery
例1：通常配達
If no link fails in this topology, and no loop occurs, then DFF forwards the packet along the Next Hops listed in the RIB of each of the routers along the path towards the destination. Each router adds a Processed Tuple for the incoming packet and selects the Next Hop, as specified in Section 11, i.e., it will first select the Next Hop for router G, as determined by the routing protocol.
このトポロジでリンクに障害が発生しておらず、ループが発生していない場合、DFFは、宛先に向かうパスに沿った各ルーターのRIBにリストされているネクストホップに沿ってパケットを転送します。各ルーターは、着信パケットの処理済みタプルを追加し、セクション11で指定されているようにネクストホップを選択します。つまり、ルーティングプロトコルによって決定されるように、最初にルーターGのネクストホップを選択します。
Example 2 depicts the same topology as Example 1, but both links between B and D and between B and E are unavailable (e.g., because of wireless link characteristics).
例2は例1と同じトポロジを示していますが、BとDの間、およびBとEの間のリンクは両方とも使用できません（たとえば、ワイヤレスリンクの特性のため）。
+---+
XXXX+ D +-----+
X +---+ |
+---+ X |
+---+ B +---+ |
| +---+ X |
+-+-+ X +---+ +-+-+
| A | XXXX+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
Example 2: Link Failure
例2：リンク障害
When B receives the packet from router A, it adds a Processed Tuple and then tries to forward the packet to D. Once B detects that the packet cannot be successfully delivered to D because it does not receive link-layer ACKs, it will follow the procedures listed in Section 10 by setting the DUP flag to 1, selecting E as the new Next Hop, adding E to the list of Next Hops in the Processed Tuple, and then forwarding the packet to E.
BはルーターAからパケットを受信すると、処理されたタプルを追加してから、Dにパケットを転送しようとします。リンク層のACKを受信しないため、BがパケットをDに正常に配信できないことを検出すると、BはDUPフラグを1に設定し、Eを新しいネクストホップとして選択し、Eを処理済みタプルのネクストホップのリストに追加して、パケットをEに転送することにより、セクション10にリストされている手順。
As the link to E also fails, B will again follow the procedure in Section 10. As all possible Next Hops (D and E) are listed in the Processed Tuple, B will set the RET flag in the packet and return it to A.
Eへのリンクも失敗するので、Bは再びセクション10の手順に従います。すべての可能なネクストホップ（DおよびE）が処理済みタプルにリストされると、BはパケットにRETフラグを設定し、それをAに返します。
A determines that it already has a Processed Tuple for the returned packet, resets the RET flag of the packet, and selects a new Next Hop for the packet. As B is already in the list of Next Hops in the Processed Tuple, it will select C as the Next Hop and forward the packet to it. C will then forward the packet to F, and F delivers the packet to its destination G.
は、返されたパケットの処理済みタプルがすでにあると判断し、パケットのRETフラグをリセットして、パケットの新しいネクストホップを選択します。 Bはすでに処理済みタプルのネクストホップのリストにあるため、ネクストホップとしてCを選択し、パケットを転送します。 CはパケットをFに転送し、Fはパケットを宛先Gに配信します。
Example 3 depicts the same topology as Example 1, but the link-layer acknowledgments from C to A are lost (e.g., because the link is unidirectional). It is assumed that A prefers a path to G through C and F.
例3は例1と同じトポロジを示していますが、CからAへのリンク層の確認応答が失われています（リンクが単方向であるためなど）。 AはCとFを介してGへのパスを優先するものと想定されます。
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
. +---+ |
+...+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
Example 3: Missed Link-Layer Acknowledgment
例3：欠落したリンク層の確認応答
While C successfully receives the packet from A, A does not receive the L2 ACK and assumes the packet has not been delivered to C. Therefore, it sets the DUP flag of the packet to 1, in order to indicate that this packet may be a duplicate. Then, it forwards the packet to B.
CはAからパケットを正常に受信しますが、AはL2 ACKを受信せず、パケットがCに配信されなかったと想定します。したがって、このパケットがAであることを示すために、パケットのDUPフラグを1に設定します。複製。次に、パケットをBに転送します。
Example 4 depicts the same topology as Example 1, but there is a loop from D to A, and A sends the packet to G through B and D.
例4は例1と同じトポロジを示していますが、DからAへのループがあり、AはBとDを介してGにパケットを送信します。
+-----------------+
| |
| +-+-+
| +---+ D +
| | +---+
\|/ +---+ |
+---+ B +---+
| +---+ |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
Example 4: Loop
例4：ループ
When A receives the packet through the loop from D, it will find a Processed Tuple for the packet. Router A will set the RET flag and return the packet to D, which in turn will return it to B. B will then select E as the Next Hop, which will then forward it to G.
AはDからループを介してパケットを受信すると、そのパケットの処理済みタプルを見つけます。ルータAはRETフラグを設定し、パケットをDに返します。DはパケットをBに返します。次に、BはEをネクストホップとして選択し、次にそれをGに転送します。
DFF has been deployed and experimented with both in real deployments and in network simulations, as described below.
DFFは、以下で説明するように、実際の展開とネットワークシミュレーションの両方で展開および実験されています。
The majority of the large Advanced Metering Infrastructure (AMI) deployments using DFF are located in Japan, but the data of these networks is the property of Japanese utilities and cannot be disclosed.
DFFを使用した大規模なAdvanced Metering Infrastructure（AMI）展開の大部分は日本にありますが、これらのネットワークのデータは日本の公益事業者の資産であり、開示することはできません。
DFF has been deployed at Kit Carson Electric Cooperative (KCEC), a non-profit organization distributing electricity to about 30,000 customers in New Mexico. As described in a press release [KCEC_press_release], DFF is running on currently about 2000 electric meters. All meters are connected through a mesh network using an unreliable, wireless medium. DFF is used together with a distance-vector routing protocol. Metering data from each meter is sent towards a gateway periodically (every 15 minutes). The data delivery reliability is over 99%.
DFFは、ニューメキシコの約30,000人の顧客に配電する非営利団体であるキットカーソン電気協同組合（KCEC）に配備されています。プレスリリース[KCEC_press_release]で説明されているように、DFFは現在約2000の電気メーターで稼働しています。すべてのメーターは、信頼性の低いワイヤレスメディアを使用したメッシュネットワークを介して接続されています。 DFFは、距離ベクトルルーティングプロトコルと一緒に使用されます。各メーターからの測定データは、定期的に（15分ごとに）ゲートウェイに送信されます。データ配信の信頼性は99％以上です。
DFF has been evaluated in Ns2 (http://nsnam.isi.edu/nsnam) and OMNEST (http://www.omnest.com) simulations, in conjuction with a distance-vector routing protocol. The performance of DFF has been compared to using only the routing protocol without DFF. The results published in peer-reviewed academic papers [DFF_paper1] [DFF_paper2] show significant improvements of the packet delivery ratio compared to using only the distance-vector protocol.
DFFは、距離ベクトルルーティングプロトコルと組み合わせて、Ns2（http://nsnam.isi.edu/nsnam）およびOMNEST（http://www.omnest.com）シミュレーションで評価されています。 DFFのパフォーマンスは、DFFなしでルーティングプロトコルのみを使用する場合と比較されています。査読付き学術論文[DFF_paper1] [DFF_paper2]で公開された結果は、距離ベクトルプロトコルのみを使用した場合と比較して、パケット配信率の大幅な改善を示しています。
Fujitsu Laboratories of America is currently working on an open-source implementation of DFF, which will be released in 2013 and will allow for interoperability testings of different DFF implementations. The implementation is written in Java and can be used both on real machines and in the Ns2 simulator.
Fujitsu Laboratories of Americaは現在、DFFのオープンソース実装に取り組んでいます。これは、2013年にリリースされ、さまざまなDFF実装の相互運用性テストを可能にします。実装はJavaで記述されており、実際のマシンとNs2シミュレータの両方で使用できます。
Authors' Addresses
著者のアドレス
Ulrich Herberg (editor) Fujitsu 1240 E. Arques Avenue, M/S 345 Sunnyvale, CA 94085 USA Phone: +1 408 530 4528 EMail: ulrich.herberg@us.fujitsu.com
うｌりｃｈ へｒべｒｇ （えぢとｒ） ふじつ １２４０ え。 あｒくえｓ あゔぇぬえ、 Ｍ／Ｓ ３４５ すんｙゔぁぇ、 か ９４０８５ うさ Ｐほね： ＋１ ４０８ ５３０ ４５２８ えまいｌ： うｌりｃｈ。へｒべｒｇ＠うｓ。ふじつ。こｍ
Alvaro A. Cardenas University of Texas at Dallas School of Computer Science, 800 West Campbell Rd, EC 31 Richardson, TX 75080-3021 USA EMail: alvaro.cardenas@me.com
アルバロA.カルデナステキサス大学ダラス校コンピュータサイエンス校、800 West Campbell Rd、EC 31 Richardson、TX 75080-3021 USA Eメール：alvaro.cardenas@me.com
Tadashige Iwao Fujitsu Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku Tokyo, JP Phone: +81-44-754-3343 EMail: smartnetpro-iwao_std@ml.css.fujitsu.com
Tadashige Iwao Fujitsu Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku Tokyo, JP Phone: +81-44-754-3343 EMail: smartnetpro-iwao_std@ml.css.fujitsu.com
Michael L. Dow Freescale 6501 William Cannon Drive West Austin, TX 78735 USA Phone: +1 512 895 4944 EMail: m.dow@freescale.com
マイケルL.ダウフリースケール6501ウィリアムキャノンドライブウェストオースティン、テキサス州78735アメリカ電話：+1 512 895 4944メール：m.dow@freescale.com
Sandra L. Cespedes Icesi University Calle 18 #122-135, Pance Cali, Colombia Phone: +57 (2) 5552334 EMail: scespedes@icesi.edu.co
サンドラL.セスペデスIcesi大学Calle 18＃122-135、パンチェカリ、コロンビア電話：+57（2）5552334メール：scespedes@icesi.edu.co