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
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使用类似于对数据包目的地进行“深度优先搜索”的机制转发数据包。路由平面可被告知传送分组或环路的失败。本文件规定了IPv6网络（如RFC 2460中规定）和RFC 4944中规定的低功率无线个人区域网络（LoWPANs）下的“网格”的DFF机制。DFF的设计假设底层链路层提供了检测数据包是否已成功传送到下一跳的方法。它适用于流量较小的网络，仅用于单播传输。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
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）的产品。它代表了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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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网络的深度优先转发（DFF）协议，既适用于IPv6转发[RFC2460]（以下称为“路由覆盖”），也适用于使用低泛适配层[RFC4944]的“网格下”转发。该协议完全在转发平面上运行，但可能与路由平面交互。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转发外，还规定了在低泛自适应层上进行转发的机制（根据[RFC4944]第11节）。除了不同的报头格式之外，路由上和网状网下的DFF机制是类似的，因此首先一般定义，然后更具体地定义IPv6路由上转发（如第13.1节所规定）和低泛适配层网状网下（如第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
o 参数P_HOLD_TIME的最佳值，取决于网络的大小、拓扑结构和每个路由器产生的通信量。处理后的元组保存的时间越长，路由器上消耗的内存就越多。此外，如果元组保存时间过长，则可能会出现序列号环绕，并出现新的错误
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 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的最佳值，取决于网络的大小、拓扑以及链路层的损耗程度。最大跳数限制确保数据包不会不必要地在网络中移动；它可用于限制可接受的数据包的“迂回”。如果可以从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 当DFF检测到环路或丢失的第2层（L2）ACK时，增加路由成本的最佳方法。虽然这不是本文件的规范性部分，但在实验中，找到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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[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.
列表：元素列表定义为[]表示空列表，[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”表示“假”；值“1”表示“真”。
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]中介绍的术语“路由覆盖”和“网格覆盖”，其中“路由覆盖”不仅限于通过低功率无线个人区域网络（6LoWPANs）的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.
下网格：一种拓扑结构，其中节点通过网格使用链路层转发连接到6LoWPAN边界路由器（6LBR）。因此，在配置下的网状网中，低范围内的所有IPv6主机距离6LBR只有一个IP跃点。此拓扑模拟典型的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.
Route over：主机通过使用中间层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适配层下的mesh指定的，因此本节中通常定义了这些术语，然后在第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）是一种遍历或搜索树或图形数据结构的算法。它从根开始（在图形案例中选择某个节点作为根），并在回溯之前尽可能沿着每个分支进行探索”[DFS\u 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转发机制（操作模式：“路由覆盖”），也可以用作“低泛自适应层下的网格”（操作模式：“网格覆盖”）。
Packet: An IPv6 packet (for "route-over" MoP) or a "LoWPAN-encapsulated packet" (for "mesh-under" MoP), containing an IPv6 packet as payload.
数据包：一个IPv6数据包（用于“MoP上的路由”）或一个“低泛封装数据包”（用于“MoP”下的“网格”），包含一个IPv6数据包作为有效负载。
Packet Header: An IPv6 extension header (for "route-over" MoP) or a LoWPAN header (for "mesh-under" MoP).
数据包头：IPv6扩展头（用于“通过”MoP的路由）或低泛头（用于“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]，该地址应从传输数据包的接口上配置的地址中选择。
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 适用于IPv6网络中，作为使用IPv6[RFC2460]的“路由上”转发机制，或作为使用帧格式传输IPv6数据包的“网下”转发机制，如[RFC4944]中所定义。
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地址（如果协议用作“路由覆盖”），或16位短地址或EUI-64链路层地址，如[RFC4944]中所述，如果协议用作“网格覆盖”。在“mesh-under”模式下，允许在一个DFF路由域内混合16位和EUI-64地址（如果它们符合[RFC4944]），只要DFF仅限于在一个PAN（个人局域网）内使用。假设“路由覆盖”模式和“网格覆盖”模式在同一路由域中相互排斥。
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
o 适用于每秒数据包数量较少的网络，因为每个最近转发的数据包都会增加路由器上的状态。DFF支持的每次通信量取决于运行DFF的路由器的内存资源、网络密度、信道丢失率和每个数据包的最大跳数限制：对于每个最近看到的数据包，数据包发送到的下一跳的列表存储在内存中。存储的条目可以在过期时间后删除，以便只删除最近收到的数据包
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 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的路由域内的路由器与已知边界路由器之间的通信。这类网络的例子是LoWPANs。第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
当路由器使用DFF转发数据包时，路由器为该数据包创建候选下一跳的列表。该列表（每个数据包创建）是有序的，第11节提供了关于如何对列表进行排序的建议，例如，首先列出RIB中列出的下一个跃点，如果可用，按增加的成本排序，然后是外部邻居发现提供的其他邻居。DFF继续将数据包转发到列表中的第一个下一跳。如果传输不成功（由底层链路层确定），或者如果数据包被之前发送到的下一跳“返回”，路由器将尝试将数据包转发到列表上的下一跳。一旦路由器尝试将数据包转发给候选下一跳列表中的所有元素失败，它就会将数据包“返回”给最初从中接收数据包的路由器。如果数据包最终返回给数据包的发起人，则
Originator has exhausted all of its Next Hops for the packet, the packet is dropped.
发起者耗尽了数据包的所有下一个跃点，数据包被丢弃。
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.
本规范要求每个路由器上有一个单独的集，即处理集。处理集存储每个最近看到的数据包的序列号、发起者地址、前一跳和数据包已发送到的下一跳的列表。在预定义的超时后，将删除集合中的条目。每次将数据包转发到下一个跃点时，该下一个跃点被添加到该数据包条目的下一个跃点列表中。
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提供到相邻路由器的路由，并且如果这些单跳路由被验证为对称的）。
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（表示“重复”）。
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.
当路由器连续尝试向其一个或多个邻居发送数据包时，RET=0。如果分组到路由器的邻居的传输均未成功，则分组返回到第一次从其接收分组的路由器，通过设置返回标志（RET:=1）指示。需要RET标志来区分故意返回的数据包和循环数据包：如果路由器接收到一个RET=1（DUP=0或DUP=1）且已转发的数据包，则该数据包是故意返回的，并且路由器将继续从候选下一跳列表将数据包连续发送到路由器。如果该数据包的RET=0，则路由器将假定该数据包正在循环，并将其返回到上次接收该数据包的路由器。外部机制可使用该信息来增加使用导致RIB或路由协议中的循环的下一跳到目的地的路由的路由成本。指定这种机制超出了本文件的范围。注意，一旦DUP设置为1，循环检测就不再可能，因为标志不再重置。因此，如果域中路由器的肋骨不一致，则数据包可能会循环，直到跳数限制达到0。
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时，无法区分副本和副本的副本。因此，在分组路径上的第二个丢失的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提供到相邻路由器的路由，并且如果验证这些单跳路由是对称的）。本文档中未指定对称邻居的地址列表。该列表中的地址用于构建分组的候选下一跳的列表，如第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.
每个路由器维护一个处理集，以支持环路检测功能。处理集列出先前接收的分组的序列号，以及作为深度优先转发机制的一部分，分组已被连续发送到的下一跳的列表。为了防止这种情况，建议实现将处理集保留在非易失性存储器中（如果路由器提供）。
The set consists of Processed Tuples
该集合由经过处理的元组组成
(P_orig_address, P_seq_number, P_prev_hop, P_next_hop_neighbor_list, P_time)
（P_原始地址、P_序列号、P_上一跳、P_下一跳、邻居列表、P_时间）
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是在“路由覆盖”MoP中使用还是在“网格覆盖”MoP中使用，DFF报头是IPv6逐跳选项报头（如第13.1.2节所规定）还是低泛报头（如第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]中定义的MoP上的路由和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）数据包标志-如第9.2节所述，当数据包由于链路层发出的原始传输失败的信号而被重新传输时，在数据包的DFF报头中设置该1位标志。标志设置为1后，转发数据包的路由器不得修改该标志。
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的数据包时，在将其发送到新的候选下一跳之前，该标志必须设置为0，如第9.2节所述。
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.
序列号-一个16位字段，包含发起者生成的无符号整数序列号，对于添加了DFF的每个数据包，每个路由器都是唯一的，如第12节所述。与序列号连接的发起者地址表示先前看到的数据包的标识符。有关序列号的更多信息，请参阅第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的值，该值足够高，以便在数据包通过路由域时，数据包的已处理元组仍在所有转发路由器上的内存中。该值应至少为MAX_HOP_LIMIT乘以向同一链路上的路由器发送数据包的预期时间。该值必须小于经过处理的元组的P_orig_地址标识的路由器上的环绕后再次达到相同序列号所需的时间。
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-是HOP LIMIT的初始值，因此是数据包在路由域中转发的最大次数。选择最大跳数限制值时，应考虑网络大小、源和目的地之间的距离（以跳数表示）以及数据包的最大可能“迂回”（与最短路径相比）。如有提供，可从肋骨使用此类信息。
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节的规定，为当前数据包选择下一跳（此后称为“下一跳”）。
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_时间：=当前时间+P_保持时间。
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. 将当前数据包传递到底层链路层，以便传输到下一跳。如果传输失败（由链路层确定），则必须执行第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_时间：=当前时间+P_保持时间。
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节的规定，为当前数据包选择下一跳（此后称为“下一跳”）。
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. 将当前数据包传递到底层链路层，以便传输到下一跳。如果传输失败（由链路层确定），则必须执行第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_列表中，则丢弃该数据包。
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节的规定，为当前数据包选择下一跳（此后称为“下一跳”）。
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_时间：=当前时间+P_保持时间。
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. 如果所选下一跳等于当前元组的P_prev_Hop，如第11节所述（即，所有候选下一跳都已尝试失败），则将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. 将当前数据包传递到底层链路层，以便传输到下一跳。如果传输失败（由链路层确定），则必须执行第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节的规定，为当前数据包选择下一跳（此后称为“下一跳”）。
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_时间：=当前时间+P_保持时间。
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. 如第11节所述，如果选定的下一跳等于当前元组的上一跳（即，所有邻居均未成功尝试），则：
* 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. 将当前数据包传输到下一跳。如果传输失败（由链路层确定），并且如果下一跳不等于当前元组的上一跳，则必须执行第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.
下一跳按优先级降低的顺序从候选下一跳列表中选择。此列表是按数据包创建的。数据包的最大候选下一跳列表包含路由器的所有邻居（由外部邻居发现过程确定），但当前数据包的前一跳除外。如果需要，可以使用较小的列表，并且候选下一跳列表的大小的精确选择是在每个路由器中作出的本地决定，并且不影响互操作性。选择较小的列表可能会减少通过网络的数据包的路径长度，并减少处理集中所需的状态，但可能会导致未探索的有效路径。如果使用来自RIB的信息，则候选下一跳列表必须至少包含RIB中指示的下一跳，作为到目的地的最短路径上的下一跳，并且它应该包含所有指示给RIB的下一跳，作为到目的地的路径上的下一跳。如果RIB的下一跳等于当前数据包的上一跳，则不得将其添加到候选下一跳列表中。
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
该列表不得包含当前元组的P_next_hop_neighbor_列表中列出的地址，以避免多次将数据包发送到同一个邻居。此外,
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.
出于同样的原因，地址在列表中不得出现多次。此外，不得将此路由器的接口地址添加到列表中。
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，且必须环绕为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转发协议的“路由”，也可以用作低泛适配层的“网下”数据转发协议[RFC4944]。前面的章节已经详细说明了DFF机制；本节规定了各MoP的具体差异。
This section maps the general terminology from Section 2.2 to the specific terminology when using the "route-over" MoP.
本节将第2.2节中的通用术语映射到使用“路线上方”MoP时的特定术语。
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节中列出的术语，当DFF用于“飞越路线”MoP时，其含义已明确定义：
Packet - An IPv6 packet, as specified in [RFC2460].
数据包-IPv6数据包，如[RFC2460]所述。
Packet Header - An IPv6 extension header, as specified in [RFC2460].
数据包标头-IPv6扩展标头，如[RFC2460]中所述。
Address - An IPv6 address, as specified in [RFC4291].
地址-IPv6地址，如[RFC4291]中所述。
Originator Address - The Originator Address corresponds to the Source Address field of the IPv6 header, as specified in [RFC2460].
发起者地址-发起者地址对应于IPv6标头的源地址字段，如[RFC2460]中所述。
Destination Address - The Destination Address corresponds to the destination field of the IPv6 header, as specified in [RFC2460].
目标地址-目标地址对应于IPv6标头的目标字段，如[RFC2460]中所述。
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.
Previous Hop—Previous Hop是来自接收数据包的节点接口的IPv6地址。
Hop Limit - The Hop Limit corresponds to the Hop Limit field in the IPv6 header, as specified in [RFC2460].
跃点限制-跃点限制对应于IPv6标头中的跃点限制字段，如[RFC2460]中所述。
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缩写为，RET缩写为R，因为图中空间有限）。本文档指定了在逐跳选项标题中使用的新选项，该标题包含DFF字段（DUP和RET标志以及序列号，如第7节所述）。
[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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
OptTypeDFF—选项类型的8位标识符，如[RFC2460]中所述。此值设置为IP_DFF。选项类型的两个高位必须设置为“11”，第三位等于“1”。根据[RFC2460]，对于这些位，不理解接收到的数据包上的该选项的路由器丢弃该数据包，并且仅当该数据包的目的地地址不是多播地址时，才将ICMP参数问题（代码2）消息发送到路由器
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.
数据包的源地址，指向无法识别的选项类型。此外，根据[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（两个）。
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节的规定，网格Forw之后是DUP（缩写为D）和RET（缩写为R）标志。本文档中指定的版本为“00”。此八位字节的所有其他位（除VER、DUP和RET外）都是保留的，必须设置为0。
Sequence Number - A 16-bit field, containing an unsigned integer sequence number, as specified in Section 7.
序列号-一个16位字段，包含第7节中指定的无符号整数序列号。
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个八位字节的倍数，因此使用Pad1选项，如[RFC2460]中所述。这个八位组的所有位都是0。
This section maps the general terminology from Section 2.2 to the specific terminology when using the "mesh-under" MoP.
本节将第2.2节中的通用术语映射到使用MoP下的“网格”时的特定术语。
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节所列术语（除“运行模式”外），当DFF用于MoP下的“网格”时，其含义明确定义。
Packet - A "LoWPAN-encapsulated packet" (as specified in [RFC4944]), which contains an IPv6 packet as payload.
数据包-一种“低泛封装数据包”（如[RFC4944]中所述），其中包含一个IPv6数据包作为有效负载。
Packet Header - A LoWPAN header, as specified in [RFC4944].
数据包报头-如[RFC4944]中规定的低泛报头。
Address - A 16-bit short or EUI-64 link-layer address, as specified in [RFC4944].
地址-16位短或EUI-64链路层地址，如[RFC4944]中所述。
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]中所述。
Previous Hop - The Previous Hop is the Source Address of the frame containing a LoWPAN-encapsulated packet, as specified in [RFC4944].
前一跳-前一跳是包含低泛封装数据包的帧的源地址，如[RFC4944]中所述。
Hop Limit - The Hop Limit corresponds to the Deep Hops Left field in the Mesh Addressing header, as specified in [RFC4944].
跃点限制-跃点限制对应于[RFC4944]中指定的网状寻址报头中的左深跃点字段。
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描述了[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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:Mesh寻址头
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
网状寻址报头的字段定义如[RFC4944]所述。将该标头添加到发起人上的LoWPAN封装时，网格寻址标头的字段必须设置为以下值：
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.
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:=0，如果最终目标地址是IEEE扩展64位地址（EUI-64）；否则，如果是短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 左深跳数：=最大跳数限制。
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位标识符，允许使用不同的Mesh转发机制。如[RFC4944]所述，额外的网状转发机制应使用LOWPAN_BC0之后的保留调度字节值；因此，“0 1”必须位于网格Forw之前。网格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节的规定，网格Forw之后是DUP（缩写为D）和RET（缩写为R）标志。本文档中指定的版本为“00”。此八位字节的所有其他位（除VER、DUP和RET外）都是保留的，必须设置为0。
Sequence Number - A 16-bit field, containing an unsigned integer sequence number, as specified in Section 7.
序列号-一个16位字段，包含第7节中指定的无符号整数序列号。
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的头都不会穿过路由域的边界。本节规定，对于“路由覆盖”MoP和“网格覆盖”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
图4至图7描述了与使用DFF的路由域范围有关的流量源和目的地的四种不同情况。第14.1节和第14.2节分别规定了在这些情况下，路由器如何限制“路由覆盖”MoP和“网格覆盖”MoP的DFF范围。在这些部分中，“路由域内”的所有节点都是路由器，使用DFF，也可以是源或目的地。路由之外的“源或目的地”
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.
域“不运行DFF；或者它们是连接到运行DFF的路由域中的路由器的主机，或者它们本身是路由器，但在路由域之外，不运行DFF。
+-----------------+
| |
| (S) ----> (D) |
| |
+-----------------+
Routing Domain
+-----------------+
| |
| (S) ----> (D) |
| |
+-----------------+
Routing Domain
Figure 4: Traffic within the Routing Domain (from S to D)
图4：路由域内的流量（从S到D）
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
Routing Domain
+-----------------+
| |
| (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
+-----------------+
| |
(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
+-----------------+
| |
(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分组的有效载荷。这种情况假设S知道D在路由域中，例如，由于基于目的地的IP地址的管理设置。如果S不知道D是否在路由域中，则必须使用[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中，流量的来源在路由域内，而目的地（D）在路由域外。起源于的IPv6数据包必须根据[RFC2473]（IPv6-in-IPv6隧道）进行封装，并且DFF报头必须添加到外部IPv6报头。S选择下一个应该处理数据包的路由器作为隧道出口点（R）。管理设置以及来自路由协议的信息可用于确定隧道出口点。如果没有关于选择哪个路由器作为隧道出口点的信息，则必须使用下一跳作为隧道出口点。在某些情况下，隧道出口点将是沿着朝向分组目的地的路径的最终路由器，并且分组将仅穿过单个隧道（例如，如果R是已知边界路由器，则s可以选择R作为隧道出口点）。在其他情况下，隧道出口点将不是沿到D的路径的最终路由器，并且分组可以穿过多个隧道到达目的地；请注意，在这种情况下，DFF机制仅在每个IPv6-in-IPv6隧道中使用。数据包的发起方地址设置为S，目标地址设置为隧道出口点（在外部IPv6报头中）。使用此规范（可能使用多个连续的IPv6-in-IPv6隧道）将数据包转发到隧道出口点。当路由器R接收到数据包时，它将解除对IPv6数据包的封装，并使用[RFC2460]中规定的正常IPv6转发将内部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 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),
在图6中，流量的来源在路由域之外，而目的地（D）在路由域之内。起源于S的IPv6数据包使用[RFC2460]中规定的正常IPv6转发转发到R。路由器R必须根据[RFC2473]封装IPv6数据包，并将DFF报头（如第13.1.2节所述）添加到外部IPv6报头。与前一种情况一样，R必须选择隧道出口点；如果它知道D在路由域中（例如，基于管理设置），
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.
应选择D作为隧道出口点。如果它没有关于选择哪个出口点的任何信息，它必须使用下一个跃点作为隧道出口点，从而将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中，通信量的来源和目的地都在路由域之外。根据[RFC2460]中的规定，起源于S的IPv6数据包通过正常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中，流量的来源和目的地都是路由域中的路由器。如[RFC4944]所述，如果流量源自路由器S，则根据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
在图5中，流量的来源在路由域内，而目的地（D）在路由域外（S知道该目的地在路由域外，因为D使用与PAN不同的IP前缀）。根据[RFC4944]中的规定，从IPv6数据包创建源自路由器S的LoWPAN封装数据包。然后是Mesh寻址报头和DFF报头
(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].
（如第13.2.2节所述）添加到路由器S上的LoWPAN封装中。发起者地址设置为S，目的地地址设置为R，这是PAN的已知边界路由器。然后使用该规范转发该数据包。当路由器R接收到数据包时，它从低泛封装的数据包恢复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中，流量的来源在路由域之外，而目的地（D）在路由域之内。根据[RFC2460]中的规定，起源于S的IPv6数据包使用正常IPv6转发转发到R。路由器R（是PAN的已知边界路由器）根据[RFC4944]中的规定，从IPv6数据包创建低PAN封装数据包。然后，R添加网状寻址报头和DFF报头（如第13.2.2节所述）。发起者地址设置为R，目的地地址设置为D，DFF报头中的序列号在R上本地生成。使用此规范将数据包转发给D。当路由器D接收到数据包时，它从低泛封装的数据包恢复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中，流量的来源和目的地都在路由域之外。根据[RFC2460]中的规定，起源于S的IPv6数据包通过正常IPv6转发转发到R1。路由器R1（是PAN的已知边界路由器）根据[RFC4944]中的规定，从IPv6数据包创建低PAN封装数据包。然后，它添加网状寻址报头和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. 路由器必须丢弃数据包。
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“数据包太大”消息，并向下一跳MTU报告，其中包括添加报头的开销。
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不修改IP数据报的内容，除了DFF报头（它是“route over”MoP中的逐跳选项扩展报头，因此不受IPsec保护），因此不需要考虑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.
另一种可能的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
恶意路由器可能篡改DFF数据包的“返回”标志，并将其发送回上一跳，但前提是接收路由器已将恶意路由器选择为下一跳（如第9.2节所述）。如果未选择恶意路由器作为下一跳，则接收路由器会丢弃返回的数据包。否则（即，恶意路由器已被接收路由器选择为下一个跃点，并且恶意路由器已设置返回标志），接收路由器然后尝试
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).
另类邻居。这可能导致数据包永远无法到达其目的地，以及网络中不必要的深度优先搜索（带宽耗尽/能量消耗）。
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，并且路由器第二次接收到该数据包（即，它之前已经接收到具有相同发起者地址和序列号的数据包），它将错误地检测到环路。
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已从调度类型字段注册表为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.
雅丽·阿尔科（爱立信）、阿卜杜萨兰国·巴伦（格拉摩根大学）、安东宁·巴斯（理工学院）、托马斯·克劳森（理工学院）、伊格拉希一（日立）、卡祖亚·莫登（日立）、杰夫·穆利根（Proto6）、佐藤广基（日立）、甘尼什·文卡特什（Mobelitix）和易家子（理工学院）对草案和讨论进行了有益的审查，这有助于改进本文件。
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评估期间所做的评论。
[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，“IPv6规范中的通用数据包隧道”，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 42912006年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.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年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）”，RFC6130，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]Krishnan，S.，Woodyatt，J.，Kline，E.，Hoagland，J.，和M.Bhatia，“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 67242012年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，“AMI网络数据转发机制的比较”，2012年IEEE创新智能电网技术会议（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]Iwao，T.，Iwao，T.，Yura，M.，Nakaya，Y.，Cardenas，A.，Lee，S.，和R.Masuoka，“无线网状网络中的动态数据转发”，第一届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\u 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新闻稿]Kit Carson Electric Cooperative（KCEC），“KCEC部署的DFF”，新闻稿，2011年<http://www.kitcarson.com/ index.php？option=com\u 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，“IP版本6（IPv6）的邻居发现”，RFC 48612007年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，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年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）的网络拓扑，它们之间的链路由线表示。假设路由器A根据路由协议通过B和D向G发送分组。
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
+---+
+---+ 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 +-----+
+---+
+---+
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。一旦B检测到数据包无法成功交付给D，因为它没有收到链路层确认，它将遵循第10节中列出的步骤，将DUP标志设置为1，选择E作为新的下一跳，将E添加到已处理元组中的下一跳列表中，然后将数据包转发给E。
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.
A确定它已经为返回的数据包处理了一个元组，重置数据包的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优先于G到C和F的路径。
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
. +---+ |
+...+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
+---+
+---+ 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。因此，它将数据包的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 +-----+
+---+
+-----------------+
| |
| +-+-+
| +---+ 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的大型高级计量基础设施（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已部署在Kit Carson Electric Cooperative（KCEC），这是一家为新墨西哥州约30000名客户配电的非盈利组织。正如一份新闻稿[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
Ulrich Herberg（编辑）Fujitsu 1240 E.Arques Avenue，M/S 345 Sunnyvale，CA 94085美国电话：+1 408 530 4528电子邮件：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.CARDENAS德克萨斯大学达拉斯计算机学院，西TX坎贝尔路800号，EC 31理查德森，美国750803021美国电子邮件：阿尔瓦罗。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市中心，日本东京弥敦区东新桥1-chome 5-2号电话：+81-44-754-3343电子邮件：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
Michael L.Dow飞思卡尔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
Sandra L.Cespedes Icesi大学电话：18#122-135，Pance Cali，Colombia电话：+57（2）5552334电子邮件：scespedes@icesi.edu.co