Network Working Group J. Arkko
Request for Comments: 5534 Ericsson
Category: Standards Track I. van Beijnum
IMDEA Networks
June 2009
Network Working Group J. Arkko
Request for Comments: 5534 Ericsson
Category: Standards Track I. van Beijnum
IMDEA Networks
June 2009
Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming
IPv6多宿故障检测与定位对探测协议
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies how the level 3 multihoming Shim6 protocol (Shim6) detects failures between two communicating nodes. It also specifies an exploration protocol for switching to another pair of interfaces and/or addresses between the same nodes if a failure occurs and an operational pair can be found.
本文件规定了3级多主Shim6协议（Shim6）如何检测两个通信节点之间的故障。它还指定了一个探测协议，用于在发生故障并且可以找到操作对时，在相同节点之间切换到另一对接口和/或地址。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Definitions .....................................................4
3.1. Available Addresses ........................................4
3.2. Locally Operational Addresses ..............................5
3.3. Operational Address Pairs ..................................5
3.4. Primary Address Pair .......................................7
3.5. Current Address Pair .......................................7
4. Protocol Overview ...............................................8
4.1. Failure Detection ..........................................8
4.2. Full Reachability Exploration .............................10
4.3. Exploration Order .........................................11
5. Protocol Definition ............................................13
5.1. Keepalive Message .........................................13
5.2. Probe Message .............................................14
5.3. Keepalive Timeout Option Format ...........................18
6. Behavior .......................................................19
6.1. Incoming Payload Packet ...................................20
6.2. Outgoing Payload Packet ...................................21
6.3. Keepalive Timeout .........................................21
6.4. Send Timeout ..............................................22
6.5. Retransmission ............................................22
6.6. Reception of the Keepalive Message ........................22
6.7. Reception of the Probe Message State=Exploring ............23
6.8. Reception of the Probe Message State=InboundOk ............23
6.9. Reception of the Probe Message State=Operational ..........23
6.10. Graphical Representation of the State Machine ............24
7. Protocol Constants and Variables ...............................24
8. Security Considerations ........................................25
9. Operational Considerations .....................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Example Protocol Runs..................................30
Appendix B. Contributors...........................................35
Appendix C. Acknowledgements.......................................35
1. Introduction ....................................................3
2. Requirements Language ...........................................4
3. Definitions .....................................................4
3.1. Available Addresses ........................................4
3.2. Locally Operational Addresses ..............................5
3.3. Operational Address Pairs ..................................5
3.4. Primary Address Pair .......................................7
3.5. Current Address Pair .......................................7
4. Protocol Overview ...............................................8
4.1. Failure Detection ..........................................8
4.2. Full Reachability Exploration .............................10
4.3. Exploration Order .........................................11
5. Protocol Definition ............................................13
5.1. Keepalive Message .........................................13
5.2. Probe Message .............................................14
5.3. Keepalive Timeout Option Format ...........................18
6. Behavior .......................................................19
6.1. Incoming Payload Packet ...................................20
6.2. Outgoing Payload Packet ...................................21
6.3. Keepalive Timeout .........................................21
6.4. Send Timeout ..............................................22
6.5. Retransmission ............................................22
6.6. Reception of the Keepalive Message ........................22
6.7. Reception of the Probe Message State=Exploring ............23
6.8. Reception of the Probe Message State=InboundOk ............23
6.9. Reception of the Probe Message State=Operational ..........23
6.10. Graphical Representation of the State Machine ............24
7. Protocol Constants and Variables ...............................24
8. Security Considerations ........................................25
9. Operational Considerations .....................................27
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Example Protocol Runs..................................30
Appendix B. Contributors...........................................35
Appendix C. Acknowledgements.......................................35
The Shim6 protocol [RFC5533] extends IPv6 to support multihoming. It is an IP-layer mechanism that hides multihoming from applications. A part of the Shim6 solution involves detecting when a currently used pair of addresses (or interfaces) between two communication nodes has failed and picking another pair when this occurs. We call the former "failure detection", and the latter, "locator pair exploration".
Shim6协议[RFC5533]扩展了IPv6以支持多宿主。它是一种IP层机制，对应用程序隐藏多宿主。Shim6解决方案的一部分涉及检测两个通信节点之间当前使用的一对地址（或接口）何时出现故障，并在出现故障时选择另一对。我们称前者为“故障检测”，后者为“定位器对探测”。
This document specifies the mechanisms and protocol messages to achieve both failure detection and locator pair exploration. This part of the Shim6 protocol is called the REAchability Protocol (REAP).
本文档规定了实现故障检测和定位器对探测的机制和协议消息。Shim6协议的这一部分称为可达性协议（REAP）。
Failure detection is made as lightweight as possible. Payload data traffic in both directions is observed, and in the case where there is no traffic because the communication is idle, failure detection is also idle and doesn't generate any packets. When payload traffic is flowing in both directions, there is no need to send failure detection packets, either. Only when there is traffic in one direction does the failure detection mechanism generate keepalives in the other direction. As a result, whenever there is outgoing traffic and no incoming return traffic or keepalives, there must be failure, at which point the locator pair exploration is performed to find a working address pair for each direction.
故障检测尽可能轻。观察到两个方向上的有效负载数据流量，并且在由于通信空闲而没有流量的情况下，故障检测也空闲并且不生成任何数据包。当有效负载流量双向流动时，也不需要发送故障检测数据包。只有当一个方向上有流量时，故障检测机制才会在另一个方向上生成keepalive。因此，每当有传出通信量而没有传入的返回通信量或保留通信量时，就一定会出现故障，此时将执行定位器对搜索以找到每个方向的工作地址对。
This document is structured as follows: Section 3 defines a set of useful terms, Section 4 gives an overview of REAP, and Section 5 provides a detailed definition. Section 6 specifies behavior, and Section 7 discusses protocol constants. Section 8 discusses the security considerations of REAP.
本文档的结构如下：第3节定义了一组有用的术语，第4节概述了REAP，第5节提供了详细的定义。第6节指定了行为，第7节讨论了协议常量。第8节讨论了REAP的安全注意事项。
In this specification, we consider an address to be synonymous with a locator. Other parts of the Shim6 protocol ensure that the different locators used by a node actually belong together. That is, REAP is not responsible for ensuring that said node ends up with a legitimate locator.
在本规范中，我们认为地址是定位器的同义词。Shim6协议的其他部分确保节点使用的不同定位器实际上属于一起。也就是说，REAP不负责确保所述节点以合法定位器结束。
REAP has been designed to be used with Shim6 and is therefore tailored to an environment where it typically runs on hosts, uses widely varying types of paths, and is unaware of application context. As a result, REAP attempts to be as self-configuring and unobtrusive as possible. In particular, it avoids sending any packets except where absolutely required and employs exponential back-off to avoid congestion. The downside is that it cannot offer the same granularity of detecting problems as mechanisms that have more application context and ability to negotiate or configure parameters.
REAP被设计为与Shim6一起使用，因此适合于它通常在主机上运行、使用各种类型的路径并且不知道应用程序上下文的环境。因此，REAP尝试尽可能地自我配置和低调。特别是，它避免发送任何数据包，除非绝对需要，并采用指数退避来避免拥塞。缺点是它不能提供与具有更多应用程序上下文和协商或配置参数能力的机制相同的问题检测粒度。
Future versions of this specification may consider extensions with such capabilities, for instance, through inheriting some mechanisms from the Bidirectional Forwarding Detection (BFD) protocol [BFD].
本规范的未来版本可以考虑具有这种能力的扩展，例如，通过继承来自双向转发检测（BFD）协议[BFD]的一些机制。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This section defines terms useful for discussing failure detection and locator pair exploration.
本节定义了对讨论故障检测和定位器对探索有用的术语。
Shim6 nodes need to be aware of what addresses they themselves have. If a node loses the address it is currently using for communications, another address must replace it. And if a node loses an address that the node's peer knows about, the peer must be informed. Similarly, when a node acquires a new address it may generally wish the peer to know about it.
Shim6节点需要知道自己拥有什么地址。如果节点丢失了当前用于通信的地址，则必须用另一个地址替换它。如果节点丢失了节点的对等方知道的地址，则必须通知对等方。类似地，当节点获取新地址时，它通常可能希望对等方知道它。
Definition. Available address - an address is said to be available if all the following conditions are fulfilled:
释义可用地址-如果满足以下所有条件，则称地址可用：
o The address has been assigned to an interface of the node.
o 地址已分配给节点的接口。
o The valid lifetime of the prefix (Section 4.6.2 of RFC 4861 [RFC4861]) associated with the address has not expired.
o 与地址相关联的前缀（RFC 4861[RFC4861]第4.6.2节）的有效生存期尚未到期。
o The address is not tentative in the sense of RFC 4862 [RFC4862]. In other words, the address assignment is complete so that communications can be started.
o 地址不是RFC 4862[RFC4862]意义上的暂定地址。换句话说，地址分配已完成，因此可以开始通信。
Note that this explicitly allows an address to be optimistic in the sense of Optimistic Duplicate Address Detection (DAD) [RFC4429] even though implementations may prefer using other addresses as long as there is an alternative.
注意，这显式地允许地址在乐观重复地址检测（DAD）[RFC4429]的意义上是乐观的，即使实现可能更喜欢使用其他地址，只要有替代方案。
o The address is a global unicast or unique local address [RFC4193]. That is, it is not an IPv6 site-local or link-local address.
o 该地址是全局单播或唯一本地地址[RFC4193]。也就是说，它不是IPv6站点本地地址或链路本地地址。
With link-local addresses, the nodes would be unable to determine on which link the given address is usable.
对于链路本地地址，节点将无法确定给定地址在哪个链路上可用。
o The address and interface are acceptable for use according to a local policy.
o 地址和接口可根据当地政策使用。
Available addresses are discovered and monitored through mechanisms outside the scope of Shim6. Shim6 implementations MUST be able to employ information provided by IPv6 Neighbor Discovery [RFC4861], Address Autoconfiguration [RFC4862], and DHCP [RFC3315] (when DHCP is implemented). This information includes the availability of a new address and status changes of existing addresses (such as when an address becomes invalid).
可用地址是通过Shim6范围之外的机制发现和监视的。Shim6实现必须能够使用IPv6邻居发现[RFC4861]、地址自动配置[RFC4862]和DHCP[RFC3315]（在实现DHCP时）提供的信息。此信息包括新地址的可用性和现有地址的状态更改（例如，当地址变为无效时）。
Two different granularity levels are needed for failure detection. The coarser granularity is for individual addresses.
故障检测需要两种不同的粒度级别。较粗的粒度用于单个地址。
Definition. Locally operational address - an available address is said to be locally operational when its use is known to be possible locally. In other words, when the interface is up, a default router (if needed) suitable for this address is known to be reachable, and no other local information points to the address being unusable.
释义本地操作地址-当已知可用地址可在本地使用时，称其为本地操作地址。换句话说，当接口启动时，适合该地址的默认路由器（如果需要）是可访问的，并且没有其他本地信息指向不可用的地址。
Locally operational addresses are discovered and monitored through mechanisms outside the Shim6 protocol. Shim6 implementations MUST be able to employ information provided from Neighbor Unreachability Detection [RFC4861]. Implementations MAY also employ additional, link-layer-specific mechanisms.
本地操作地址是通过Shim6协议之外的机制发现和监视的。Shim6实现必须能够利用邻居不可达性检测[RFC4861]提供的信息。实现还可以采用额外的、特定于链路层的机制。
Note 1: A part of the problem in ensuring that an address is operational is making sure that after a change in link-layer connectivity, we are still connected to the same IP subnet. Mechanisms such as [DNA-SIM] can be used to ensure this.
注1：确保地址可操作的一部分问题是确保在链路层连接发生变化后，我们仍然连接到同一IP子网。可以使用[DNA-SIM]等机制来确保这一点。
Note 2: In theory, it would also be possible for nodes to learn about routing failures for a particular selected source prefix, if only suitable protocols for this purpose existed. Some proposals in this space have been made (see, for instance [ADD-SEL] and [MULTI6]), but none have been standardized to date.
注2：理论上，如果只有适用于此目的的协议存在，节点也可以了解特定选定源前缀的路由故障。在这方面已经提出了一些建议（例如参见[ADD-SEL]和[MULTI6]），但到目前为止还没有标准化。
The existence of locally operational addresses are not, however, a guarantee that communications can be established with the peer. A failure in the routing infrastructure can prevent packets from reaching their destination. For this reason, we need the definition of a second level of granularity, which is used for pairs of addresses.
然而，本地操作地址的存在并不能保证可以与对等方建立通信。路由基础设施中的故障会阻止数据包到达其目的地。因此，我们需要定义第二级粒度，用于地址对。
Definition. Bidirectionally operational address pair - a pair of locally operational addresses are said to be an operational address pair when bidirectional connectivity can be shown between the addresses. That is, a packet sent with one of the addresses in the Source field and the other in the Destination field reaches the destination, and vice versa.
释义双向操作地址对-当地址之间可以显示双向连接时，一对本地操作地址被称为操作地址对。也就是说，使用源字段中的一个地址和目的字段中的另一个地址发送的数据包到达目的地，反之亦然。
Unfortunately, there are scenarios where bidirectionally operational address pairs do not exist. For instance, ingress filtering or network failures may result in one address pair being operational in one direction while another one is operational from the other direction. The following definition captures this general situation.
不幸的是，在某些情况下，双向操作地址对并不存在。例如，入口过滤或网络故障可能导致一个地址对在一个方向上运行，而另一个地址对在另一个方向上运行。以下定义描述了这种一般情况。
Definition. Unidirectionally operational address pair - a pair of locally operational addresses are said to be a unidirectionally operational address pair when packets sent with the first address as the source and the second address as the destination reach the destination.
释义单向操作地址对-当以第一个地址作为源，第二个地址作为目的地发送的数据包到达目的地时，一对本地操作地址被称为单向操作地址对。
Shim6 implementations MUST support the discovery of operational address pairs through the use of explicit reachability tests and Forced Bidirectional Communication (FBD), described later in this specification. Future extensions of Shim6 may specify additional mechanisms. Some ideas of such mechanisms are listed below but are not fully specified in this document:
Shim6实现必须通过使用显式可达性测试和强制双向通信（FBD）来支持操作地址对的发现，本规范稍后将对此进行描述。Shim6的未来扩展可能会指定其他机制。下文列出了此类机制的一些想法，但本文件并未详细说明：
o Positive feedback from upper-layer protocols. For instance, TCP can indicate to the IP layer that it is making progress. This is similar to how IPv6 Neighbor Unreachability Detection can, in some cases, be avoided when upper layers provide information about bidirectional connectivity [RFC4861].
o 来自上层协议的正反馈。例如，TCP可以向IP层表明它正在取得进展。这类似于在某些情况下，当上层提供有关双向连接的信息时，可以避免IPv6邻居不可达性检测[RFC4861]。
In the case of unidirectional connectivity, the upper-layer protocol responses come back using another address pair, but show that the messages sent using the first address pair have been received.
在单向连接的情况下，上层协议响应使用另一个地址对返回，但显示使用第一个地址对发送的消息已被接收。
o Negative feedback from upper-layer protocols. It is conceivable that upper-layer protocols give an indication of a problem to the multihoming layer. For instance, TCP could indicate that there's either congestion or lack of connectivity in the path because it is not getting ACKs.
o 来自上层协议的负反馈。可以想象的是，上层协议向多归属层提供了问题的指示。例如，TCP可能表示路径中存在拥塞或缺乏连接，因为它没有获得ACK。
o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful not to trust these blindly, however. One approach would be to use ICMP error messages only as a hint to perform an explicit reachability test or to move an address pair to a lower place in the list of address pairs to be probed, but
o ICMP错误消息。然而，考虑到欺骗ICMP消息很容易，人们应该小心不要盲目信任这些消息。一种方法是仅将ICMP错误消息用作执行显式可达性测试或将地址对移动到要探测的地址对列表中较低位置的提示，但
not to use these messages as a reason to disrupt ongoing communications without other indications of problems. The situation may be different when certain verifications of the ICMP messages are being performed, as explained by Gont in [GONT]. These verifications can ensure that (practically) only on-path attackers can spoof the messages.
在没有其他问题迹象的情况下，不要将这些消息用作中断正在进行的通信的理由。当执行ICMP消息的某些验证时，情况可能不同，如[Gont]中的Gont所述。这些验证可以确保（实际上）只有路径上的攻击者才能伪造消息。
The primary address pair consists of the addresses that upper-layer protocols use in their interaction with the Shim6 layer. Use of the primary address pair means that the communication is compatible with regular non-Shim6 communication and that no context tag needs to be present.
主地址对由上层协议在与Shim6层交互时使用的地址组成。主地址对的使用意味着通信与常规非Shim6通信兼容，并且不需要存在上下文标记。
Shim6 needs to avoid sending packets that belong to the same transport connection concurrently over multiple paths. This is because congestion control in commonly used transport protocols is based upon a notion of a single path. While routing can introduce path changes as well and transport protocols have means to deal with this, frequent changes will cause problems. Effective congestion control over multiple paths is considered a research topic at the time of publication of this document. Shim6 does not attempt to employ multiple paths simultaneously.
Shim6需要避免通过多条路径并发发送属于同一传输连接的数据包。这是因为常用传输协议中的拥塞控制是基于单一路径的概念。虽然路由也会引入路径更改，而传输协议也有办法处理这种情况，但频繁的更改会导致问题。在本文档发布时，多路径上的有效拥塞控制被认为是一个研究主题。Shim6不尝试同时使用多条路径。
Note: The Stream Control Transmission Protocol (SCTP) and future multipath transport protocols are likely to require interaction with Shim6, at least to ensure that they do not employ Shim6 unexpectedly.
注意：流控制传输协议（SCTP）和未来的多路径传输协议可能需要与Shim6交互，至少要确保它们不会意外地使用Shim6。
For these reasons, it is necessary to choose a particular pair of addresses as the current address pair that will be used until problems occur, at least for the same session.
出于这些原因，有必要选择一对特定的地址作为当前地址对，至少在同一会话中，直到出现问题时才会使用该地址对。
It is theoretically possible to support multiple current address pairs for different transport sessions or Shim6 contexts. However, this is not supported in this version of the Shim6 protocol.
理论上，支持不同传输会话或Shim6上下文的多个当前地址对是可能的。但是，此版本的Shim6协议不支持此功能。
A current address pair need not be operational at all times. If there is no traffic to send, we may not know if the current address pair is operational. Nevertheless, it makes sense to assume that the address pair that worked previously continues to be operational for new communications as well.
当前地址对不必总是可操作的。如果没有要发送的流量，我们可能不知道当前地址对是否可用。然而，假设以前工作的地址对也可以继续用于新的通信是有意义的。
This section discusses the design of the reachability detection and full reachability exploration mechanisms, and gives an overview of the REAP protocol.
本节讨论可达性检测和完全可达性探索机制的设计，并概述REAP协议。
Exploring the full set of communication options between two nodes that both have two or more addresses is an expensive operation as the number of combinations to be explored increases very quickly with the number of addresses. For instance, with two addresses on both sides, there are four possible address pairs. Since we can't assume that reachability in one direction automatically means reachability for the complement pair in the other direction, the total number of two-way combinations is eight. (Combinations = nA * nB * 2.)
探索具有两个或更多地址的两个节点之间的全套通信选项是一项昂贵的操作，因为要探索的组合数量随着地址数量的增加而快速增加。例如，两边都有两个地址，有四个可能的地址对。由于我们不能假设在一个方向上的可达性自动意味着在另一个方向上补码对的可达性，所以双向组合的总数是8。（组合=nA*nB*2。）
An important observation in multihoming is that failures are relatively infrequent, so an operational pair that worked a few seconds ago is very likely to still be operational. Thus, it makes sense to have a lightweight protocol that confirms existing reachability, and to only invoke heavier exploration mechanism when there is a suspected failure.
多宿系统中的一个重要观察结果是，故障相对较少，因此几秒钟前工作的一对操作系统很可能仍然可以工作。因此，有一个轻量级协议来确认现有的可达性是有意义的，并且只有在出现怀疑的故障时才调用更重的探索机制。
Failure detection consists of three parts: tracking local information, tracking remote peer status, and finally verifying reachability. Tracking local information consists of using, for instance, reachability information about the local router as an input. Nodes SHOULD employ techniques listed in Sections 3.1 and 3.2 to track the local situation. It is also necessary to track remote address information from the peer. For instance, if the peer's address in the current address pair is no longer locally operational, a mechanism to relay that information is needed. The Update Request message in the Shim6 protocol is used for this purpose [RFC5533]. Finally, when the local and remote information indicates that communication should be possible and there are upper-layer packets to be sent, reachability verification is necessary to ensure that the peers actually have an operational address pair.
故障检测包括三个部分：跟踪本地信息，跟踪远程对等状态，最后验证可达性。跟踪本地信息包括，例如，使用本地路由器的可达性信息作为输入。节点应采用第3.1节和第3.2节中列出的技术来跟踪当地情况。还需要跟踪来自对等方的远程地址信息。例如，如果当前地址对中的对等地址不再在本地运行，则需要一种机制来中继该信息。Shim6协议中的更新请求消息用于此目的[RFC5533]。最后，当本地和远程信息表明通信应该是可能的，并且存在要发送的上层数据包时，需要进行可达性验证，以确保对等方实际具有操作地址对。
A technique called Forced Bidirectional Detection (FBD) is employed for the reachability verification. Reachability for the currently used address pair in a Shim6 context is determined by making sure that whenever there is payload traffic in one direction, there is also traffic in the other direction. This can be data traffic as well, or it may be transport-layer acknowledgments or a REAP reachability keepalive if there is no other traffic. This way, it is no longer possible to have traffic in only one direction; so whenever
一种称为强制双向检测（FBD）的技术被用于可达性验证。在Shim6上下文中，当前使用的地址对的可达性是通过确保在一个方向上有有效负载流量时，在另一个方向上也有流量来确定的。这也可以是数据通信量，也可以是传输层确认，或者如果没有其他通信量，则可以是获取可达性keepalive。这样，就不再可能只有一个方向的交通；所以无论何时
there is payload traffic going out, but there are no return packets, there must be a failure, and the full exploration mechanism is started.
有有效负载流量流出，但没有返回数据包，一定是出现了故障，并且启动了完整的探索机制。
A more detailed description of the current pair-reachability evaluation mechanism:
当前对可达性评估机制的更详细描述：
1. To prevent the other side from concluding that there is a reachability failure, it's necessary for a node implementing the failure-detection mechanism to generate periodic keepalives when there is no other traffic.
1. 为了防止另一方认为存在可达性故障，实现故障检测机制的节点有必要在没有其他流量的情况下生成周期性保留。
FBD works by generating REAP keepalives if the node is receiving packets from its peer but not sending any of its own. The keepalives are sent at certain intervals so that the other side knows there is a reachability problem when it doesn't receive any incoming packets for the duration of a Send Timeout period. The node communicates its Send Timeout value to the peer as a Keepalive Timeout Option (Section 5.3) in the I2, I2bis, R2, or UPDATE messages. The peer then maps this value to its Keepalive Timeout value.
如果节点正在从其对等方接收数据包，但没有发送任何自己的数据包，则FBD通过生成保留活动来工作。keepalives以一定的间隔发送，这样当另一方在发送超时期间没有收到任何传入数据包时，它就知道存在可达性问题。节点将其发送超时值作为I2、I2bis、R2或更新消息中的Keepalive Timeout选项（第5.3节）传递给对等方。然后，对等方将该值映射到其Keepalive超时值。
The interval after which keepalives are sent is named the Keepalive Interval. The RECOMMENDED approach for the Keepalive Interval is to send keepalives at one-half to one-third of the Keepalive Timeout interval, so that multiple keepalives are generated and have time to reach the peer before it times out.
发送Keepalive之后的间隔称为Keepalive间隔。建议的Keepalive间隔方法是以Keepalive超时间隔的一半到三分之一发送Keepalive，以便生成多个Keepalive，并在其超时之前有时间到达对等方。
2. Whenever outgoing payload packets are generated, a timer is started to reflect the requirement that the peer should generate return traffic from payload packets. The timeout value is set to the value of Send Timeout.
2. 无论何时生成传出有效负载数据包，都会启动一个计时器，以反映对等方应该从有效负载数据包生成返回流量的要求。超时值设置为发送超时值。
For the purposes of this specification, "payload packet" refers to any packet that is part of a Shim6 context, including both upper-layer protocol packets and Shim6 protocol messages, except those defined in this specification. For the latter messages, Section 6 specifies what happens to the timers when a message is transmitted or received.
在本规范中，“有效载荷数据包”是指作为Shim6上下文一部分的任何数据包，包括上层协议数据包和Shim6协议消息，但本规范中定义的数据包除外。对于后一种消息，第6节规定了在发送或接收消息时定时器的情况。
3. Whenever incoming payload packets are received, the timer associated with the return traffic from the peer is stopped, and another timer is started to reflect the requirement for this node to generate return traffic. This timeout value is set to the value of Keepalive Timeout.
3. 每当接收到传入的有效负载数据包时，与来自对等方的返回流量相关联的计时器将停止，并且另一个计时器将启动，以反映该节点生成返回流量的需求。此超时值设置为Keepalive timeout的值。
These two timers are mutually exclusive. In other words, either the node is expecting to see traffic from the peer based on the traffic that the node sent earlier or the node is expecting to respond to the peer based on the traffic that the peer sent earlier (otherwise, the node is in an idle state).
这两个计时器是互斥的。换言之，节点期望基于节点先前发送的通信量看到来自对等方的通信量，或者节点期望基于对等方先前发送的通信量响应对等方（否则，节点处于空闲状态）。
4. The reception of a REAP Keepalive message leads to stopping the timer associated with the return traffic from the peer.
4. 接收到KeapAlive消息会导致停止与来自对等方的返回流量相关联的计时器。
5. Keepalive Interval seconds after the last payload packet has been received for a context, if no other packet has been sent within this context since the payload packet has been received, a REAP Keepalive message is generated for the context in question and transmitted to the peer. A node may send the keepalive sooner than Keepalive Interval seconds if implementation considerations warrant this, but should take care to avoid sending keepalives at an excessive rate. REAP Keepalive messages SHOULD continue to be sent at the Keepalive Interval until either a payload packet in the Shim6 context has been received from the peer or the Keepalive Timeout expires. Keepalives are not sent at all if one or more payload packets were sent within the Keepalive Interval.
5. Keepalive Interval在接收到上下文的最后一个有效负载数据包后的几秒钟内，如果自有效负载数据包被接收以来没有在该上下文内发送任何其他数据包，则会为所讨论的上下文生成一个EAW Keepalive消息，并将其发送给对等方。如果实现方面的考虑可以保证这一点，那么节点发送keepalive的时间可能早于keepalive Interval秒，但应注意避免以过高的速率发送keepalive。REAP Keepalive消息应继续以Keepalive间隔发送，直到从对等方接收到Shim6上下文中的有效负载数据包或Keepalive超时过期。如果在Keepalive间隔内发送了一个或多个有效负载数据包，则根本不发送Keepalive。
6. Send Timeout seconds after the transmission of a payload packet with no return traffic on this context, a full reachability exploration is started.
6. 发送超时在此上下文中传输无返回流量的有效负载数据包后的秒，将开始完全可达性探索。
Section 7 provides some suggested defaults for these timeout values. The actual value SHOULD be randomized in order to prevent synchronization. Experience from the deployment of the Shim6 protocol is needed in order to determine what values are most suitable.
第7节为这些超时值提供了一些建议的默认值。应随机化实际值，以防止同步。为了确定哪些值最合适，需要从部署Shim6协议中获得经验。
As explained in previous sections, the currently used address pair may become invalid, either through one of the addresses becoming unavailable or nonoperational or through the pair itself being declared nonoperational. An exploration process attempts to find another operational pair so that communications can resume.
如前几节所述，当前使用的地址对可能会变得无效，这可能是因为其中一个地址变得不可用或不可操作，或者是因为地址对本身被声明为不可操作。探索过程试图找到另一个操作对，以便恢复通信。
What makes this process hard is the requirement to support unidirectionally operational address pairs. It is insufficient to probe address pairs by a simple request-response protocol. Instead, the party that first detects the problem starts a process where it tries each of the different address pairs in turn by sending a message to its peer. These messages carry information about the state of connectivity between the peers, such as whether the sender has seen any traffic from the peer recently. When the peer receives
这一过程之所以困难，是因为需要支持单向操作的地址对。用简单的请求-响应协议探测地址对是不够的。相反，首先检测到问题的一方启动一个进程，通过向其对等方发送消息，依次尝试每个不同的地址对。这些消息携带有关对等方之间连接状态的信息，例如发送方最近是否看到来自对等方的任何流量。当对等方收到
a message that indicates a problem, it assists the process by starting its own parallel exploration to the other direction, again sending information about the recently received payload traffic or signaling messages.
一种指示问题的消息，它通过向另一个方向开始自己的并行探索，再次发送有关最近接收到的有效负载流量或信令消息的信息，来协助进程。
Specifically, when A decides that it needs to explore for an alternative address pair to B, it will initiate a set of Probe messages, in sequence, until it gets a Probe message from B indicating that (a) B has received one of A's messages and, obviously, (b) that B's Probe message gets back to A. B uses the same algorithm, but starts the process from the reception of the first Probe message from A.
具体地说，当A决定需要探索B的替代地址对时，它将按顺序启动一组探测消息，直到它从B获得探测消息，表明（A）B已收到A的一条消息，显然，（B）B的探测消息返回A。B使用相同的算法，但从接收到来自A的第一条探测消息开始处理。
Upon changing to a new address pair, the network path traversed most likely has changed, so the upper-layer protocol (ULP), SHOULD be informed. This can be a signal for the ULP to adapt, due to the change in path, so that for example, if the ULP is TCP, it could initiate a slow start procedure. However, it's likely that the circumstances that led to the selection of a new path already caused enough packet loss to trigger slow start.
更改为新地址对后，最有可能经过的网络路径已更改，因此应通知上层协议（ULP）。由于路径的变化，这可能是ULP适应的信号，因此，例如，如果ULP是TCP，它可能会启动慢启动程序。然而，导致选择新路径的情况很可能已经导致足够的数据包丢失，从而触发慢启动。
REAP is designed to support failure recovery even in the case of having only unidirectionally operational address pairs. However, due to security concerns discussed in Section 8, the exploration process can typically be run only for a session that has already been established. Specifically, while REAP would in theory be capable of exploration even during connection establishment, its use within the Shim6 protocol does not allow this.
REAP设计用于支持故障恢复，即使在只有单向操作地址对的情况下也是如此。但是，由于第8节中讨论的安全问题，勘探过程通常只能针对已经建立的会话运行。具体地说，尽管REAP在理论上甚至在连接建立期间也能够进行探索，但其在Shim6协议中的使用不允许这样做。
The exploration process assumes an ability to choose address pairs for testing. An overview of the choosing process used by REAP is as follows:
探索过程假设能够选择用于测试的地址对。REAP使用的选择过程概述如下：
o As an input to start the process, the node has knowledge of its own addresses and has been told via Shim6 protocol messages what the addresses of the peer are. A list of possible pairs of addresses can be constructed by combining the two pieces of information.
o 作为启动流程的输入，节点知道自己的地址，并通过Shim6协议消息告知对等方的地址。可以通过组合这两条信息来构建可能的地址对列表。
o By employing standard IPv6 address selection rules, the list is pruned by removing combinations that are inappropriate, such as attempting to use a link-local address when contacting a peer that uses a global unicast address.
o 通过采用标准IPv6地址选择规则，可以通过删除不适当的组合（例如在联系使用全局单播地址的对等方时尝试使用链路本地地址）来修剪列表。
o Similarly, standard IPv6 address selection rules provide a basic priority order for the pairs.
o 类似地，标准IPv6地址选择规则为这些对提供了基本的优先级顺序。
o Local preferences may be applied for some additional tuning of the order in the list. The mechanisms for local preference settings are not specified but can involve, for instance, configuration that sets the preference for using one interface over another.
o 本地首选项可用于对列表中的顺序进行一些额外的调整。本地首选项设置的机制未指定，但可能涉及，例如，设置首选项以使用一个接口而不是另一个接口的配置。
o As a result, the node has a prioritized list of address pairs to try. However, the list may still be long, as there may be a combinatorial explosion when there are many addresses on both sides. REAP employs these pairs sequentially, however, and uses a back-off procedure to avoid a "signaling storm". This ensures that the exploration process is relatively conservative or "safe". The tradeoff is that finding a working path may take time if there are many addresses on both sides.
o 因此，节点有一个按优先级排列的地址对列表可供尝试。然而，名单可能仍然很长，因为当双方都有许多地址时，可能会出现组合爆炸。然而，REAP按顺序使用这些对，并使用退避程序来避免“信号风暴”。这确保了勘探过程相对保守或“安全”。折衷是，如果双方都有许多地址，那么找到一条工作路径可能需要时间。
In more detail, the process is as follows. Nodes first consult the RFC 3484 default address selection rules [RFC3484] to determine what combinations of addresses are allowed from a local point of view, as this reduces the search space. RFC 3484 also provides a priority ordering among different address pairs, possibly making the search faster. (Additional mechanisms may be defined in the future for arriving at an initial ordering of address pairs before testing starts [PAIR].) Nodes may also use local information, such as known quality of service parameters or interface types, to determine what addresses are preferred over others, and try pairs containing such addresses first. The Shim6 protocol also carries preference information in its messages.
更详细地说，过程如下。节点首先参考RFC 3484默认地址选择规则[RFC3484]，以确定从本地角度允许哪些地址组合，因为这减少了搜索空间。RFC 3484还提供了不同地址对之间的优先级排序，可能会加快搜索速度。（将来可能会定义额外的机制，以便在测试开始之前达到地址对的初始顺序[PAIR]）节点还可以使用本地信息，例如已知的服务质量参数或接口类型，来确定哪些地址优于其他地址，并首先尝试包含这些地址的对。Shim6协议在其消息中也包含首选项信息。
Out of the set of possible candidate address pairs, nodes SHOULD attempt to test through all of them until an operational pair is found, and retry the process as necessary. However, all nodes MUST perform this process sequentially and with exponential back-off. This sequential process is necessary in order to avoid a "signaling storm" when an outage occurs (particularly for a complete site). However, it also limits the number of addresses that can, in practice, be used for multihoming, considering that transport- and application-layer protocols will fail if the switch to a new address pair takes too long.
在一组可能的候选地址对中，节点应尝试测试所有这些地址对，直到找到可操作的地址对，并根据需要重试该过程。但是，所有节点都必须按顺序执行此过程，并以指数方式后退。为了避免发生大修时的“信号风暴”（尤其是对于整个站点），此顺序过程是必要的。然而，考虑到传输层和应用层协议在切换到新地址对的时间过长时会失败，它还限制了实际中可用于多主的地址数量。
Section 7 suggests default values for the timers associated with the exploration process. The value Initial Probe Timeout (0.5 seconds) specifies the interval between initial attempts to send probes; the Number of Initial Probes (4) specifies how many initial probes can be sent before the exponential back-off procedure needs to be employed. This process increases the time between every probe if there is no response. Typically, each increase doubles the time, but this specification does not mandate a particular increase.
第7节建议了与勘探过程相关的计时器的默认值。初始探测超时值（0.5秒）指定初始尝试发送探测之间的间隔；初始探测数（4）指定在需要采用指数退避程序之前可以发送多少初始探测。如果没有响应，此过程会增加每次探测之间的时间。通常，每次增加的时间都是原来的两倍，但本规范并不要求特定的增加。
Note: The rationale for sending four packets at a fixed rate before the exponential back-off is employed is to avoid having to send these packets excessively fast. Without this, having 0.5 seconds between the third and fourth probe means that the time between the first and second probe would have to be 0.125 seconds, which gives very little time for a reply to the first packet to arrive. Also, this means that the first four packets are sent within 0.875 seconds rather than 2 seconds, increasing the potential for congestion if a large number of Shim6 contexts need to send probes at the same time after a failure.
注：在采用指数退避之前，以固定速率发送四个数据包的基本原理是避免发送这些数据包过快。否则，在第三和第四个探测之间有0.5秒意味着第一和第二个探测之间的时间必须是0.125秒，这使得对第一个数据包的应答到达的时间非常短。此外，这意味着前四个数据包将在0.875秒内而不是2秒内发送，如果大量Shim6上下文在发生故障后需要同时发送探测，则会增加拥塞的可能性。
Finally, Max Probe Timeout (60 seconds) specifies a limit beyond which the probe interval may not grow. If the exploration process reaches this interval, it will continue sending at this rate until a suitable response is triggered or the Shim6 context is garbage collected, because upper-layer protocols using the Shim6 context in question are no longer attempting to send packets. Reaching the Max Probe Timeout may also serve as a hint to the garbage collection process that the context is no longer usable.
最后，Max Probe Timeout（60秒）指定一个限制，超过该限制，探测间隔可能不会增长。如果探索过程达到此间隔，它将继续以此速率发送，直到触发适当的响应或对Shim6上下文进行垃圾收集，因为使用所讨论的Shim6上下文的上层协议不再尝试发送数据包。达到最大探测超时值也可能会提示垃圾收集进程上下文不再可用。
The format of the Keepalive message is as follows:
Keepalive消息的格式如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 66 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the Shim6 protocol description [RFC5533].
下一个报头，Hdr Ext Len，0，0，校验和——这些如Shim6协议说明[RFC5533]第5.3节所述。
Type This field identifies the Keepalive message and MUST be set to 66 (Keepalive).
键入此字段标识Keepalive消息，必须设置为66（Keepalive）。
Reserved1 This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Reserved1这是一个保留供将来使用的7位字段。它在传输时设置为零，在接收时必须忽略。
R This is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
R这是保留供将来使用的1位字段。它在传输时设置为零，在接收时必须忽略。
Receiver Context Tag This is a 47-bit field for the context tag that the receiver has allocated for the context.
接收者上下文标记这是接收者为上下文分配的上下文标记的47位字段。
Reserved2 This is a 32-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
Reserved2这是一个保留供将来使用的32位字段。它在传输时设置为零，在接收时必须忽略。
Options This field MAY contain one or more Shim6 options. However, there are currently no defined options that are useful in a Keepalive message. The Options field is provided only for future extensibility reasons.
选项此字段可能包含一个或多个Shim6选项。但是，目前没有在Keepalive消息中有用的定义选项。选项字段仅用于将来的扩展性原因。
A valid message conforms to the format above, has a Receiver Context Tag that matches the context known by the receiver, is a valid Shim6 control message as defined in Section 12.3 of the Shim6 protocol description [RFC5533], and has a Shim6 context that is in state ESTABLISHED. The receiver processes a valid message by inspecting its options and executing any actions specified for such options.
有效消息符合上述格式，具有与接收方已知上下文匹配的接收方上下文标记，是有效的Shim6控制消息，如Shim6协议说明[RFC5533]第12.3节所定义，并且具有处于已建立状态的Shim6上下文。接收方通过检查其选项并执行为这些选项指定的任何操作来处理有效消息。
The processing rules for this message are given in more detail in Section 6.
第6节详细介绍了此消息的处理规则。
This message performs REAP exploration. Its format is as follows:
此消息用于执行搜索。其格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precvd| Psent |Sta| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Nth probe sent /
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |0| Type = 67 | Reserved |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Precvd| Psent |Sta| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Nth probe sent /
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe sent +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ First probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Source address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Nth probe received +
| |
+ Destination address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nth Probe Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Options //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header, Hdr Ext Len, 0, 0, Checksum These are as specified in Section 5.3 of the Shim6 protocol description [RFC5533].
下一个报头，Hdr Ext Len，0，0，校验和——这些如Shim6协议说明[RFC5533]第5.3节所述。
Type This field identifies the Probe message and MUST be set to 67 (Probe).
键入此字段标识探测消息，必须设置为67（探测）。
Reserved This is a 7-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
保留这是一个保留供将来使用的7位字段。它在传输时设置为零，在接收时必须忽略。
R This is a 1-bit field reserved for future use. It is set to zero on transmit and MUST be ignored on receipt.
R这是保留供将来使用的1位字段。它在传输时设置为零，在接收时必须忽略。
Receiver Context Tag This is a 47-bit field for the context tag that the receiver has allocated for the context.
接收者上下文标记这是接收者为上下文分配的上下文标记的47位字段。
Psent This is a 4-bit field that indicates the number of sent probes included in this Probe message. The first set of Probe fields pertains to the current message and MUST be present, so the minimum value for this field is 1. Additional sent Probe fields are copies of the same fields sent in (recent) earlier probes and may be included or omitted as per any logic employed by the implementation.
Psent这是一个4位字段，指示此探测消息中包含的已发送探测数。第一组探测字段属于当前消息，必须存在，因此该字段的最小值为1。附加发送的探测字段是在（最近的）早期探测中发送的相同字段的副本，可以根据实现使用的任何逻辑包括或省略。
Precvd This is a 4-bit field that indicates the number of received probes included in this Probe message. Received Probe fields are copies of the same fields in earlier received probes that arrived since the last transition to state Exploring. When a sender is in state InboundOk it MUST include copies of the fields of at least one of the inbound probes. A sender MAY include additional sets of these received Probe fields in any state as per any logic employed by the implementation.
Precvd这是一个4位字段，指示此探测消息中包含的已接收探测数。接收到的探测字段是自上次转换到状态探测后到达的早期接收探测中相同字段的副本。当发送方处于InboundOk状态时，它必须包含至少一个入站探测的字段副本。发送方可以根据实现所采用的任何逻辑，在任何状态下包括这些接收到的探测字段的附加集合。
The fields Probe Source, Probe Destination, Probe Nonce, and Probe Data may be repeated, depending on the value of Psent and Preceived.
根据Psent和precived的值，可以重复探测源、探测目的地、探测当前值和探测数据字段。
Sta (State) This 2-bit State field is used to inform the peer about the state of the sender. It has three legal values:
Sta（状态）此2位状态字段用于通知对等方发送方的状态。它有三个法律价值：
0 (Operational) implies that the sender both (a) believes it has no problem communicating and (b) believes that the recipient also has no problem communicating.
0（可操作）表示发送方（a）认为其通信没有问题，（b）认为接收方通信也没有问题。
1 (Exploring) implies that the sender has a problem communicating with the recipient, e.g., it has not seen any traffic from the recipient even when it expected some.
1（探索）意味着发送方与接收方的通信存在问题，例如，即使在预期的情况下，发送方也没有看到来自接收方的任何通信量。
2 (InboundOk) implies that the sender believes it has no problem communicating, i.e., it at least sees packets from the recipient but that the recipient either has a problem or has not yet confirmed to the sender that the problem has been resolved.
2（InboundOk）表示发送方认为其通信没有问题，即它至少看到了来自接收方的数据包，但接收方存在问题或尚未向发送方确认问题已解决。
Reserved2 MUST be set to zero upon transmission and MUST be ignored upon reception.
Reserved2在传输时必须设置为零，在接收时必须忽略。
Probe Source This 128-bit field contains the source IPv6 address used to send the probe.
探测源此128位字段包含用于发送探测的源IPv6地址。
Probe Destination This 128-bit field contains the destination IPv6 address used to send the probe.
探测目标此128位字段包含用于发送探测的目标IPv6地址。
Probe Nonce This is a 32-bit field that is initialized by the sender with a value that allows it to determine with which sent probes a received probe correlates. It is highly RECOMMENDED that the Nonce field be at least moderately hard to guess so that even on-path attackers can't deduce the next nonce value that will be used. This value SHOULD be generated using a random number generator that is known to have good randomness properties as outlined in RFC 4086 [RFC4086].
Probe Nonce这是一个32位字段，由发送方使用一个值初始化，该值允许发送方确定接收的探测与哪个发送的探测相关。强烈建议Nonce字段至少具有一定的猜测难度，以便即使在路径上，攻击者也无法推断将使用的下一个Nonce值。应使用已知具有RFC 4086[RFC4086]中概述的良好随机性特性的随机数生成器生成该值。
Probe Data This is a 32-bit field with no fixed meaning. The Probe Data field is copied back with no changes. Future flags may define a use for this field.
探测数据这是一个没有固定含义的32位字段。探针数据字段将被复制回，不做任何更改。将来的标志可以定义此字段的用途。
Options For future extensions.
未来扩展的选项。
Either side of a Shim6 context can notify the peer of the value that it would prefer the peer to use as its Keepalive Timeout value. If the node is using a non-default Send Timeout value, it MUST
Shim6上下文的任何一方都可以通知对等方它希望对等方用作其Keepalive超时值的值。如果节点使用的是非默认发送超时值，则它必须
communicate this value as a Keepalive Timeout value to the peer in the below option. This option MAY be sent in the I2, I2bis, R2, or UPDATE messages. The option SHOULD only need to be sent once in a given Shim6 association. If a node receives this option, it SHOULD update its Keepalive Timeout value for the peer.
将此值作为Keepalive超时值传递给以下选项中的对等方。此选项可以在I2、I2bis、R2或更新消息中发送。在给定的Shim6关联中，该选项只需发送一次。如果节点收到此选项，则应更新对等节点的Keepalive超时值。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved | Keepalive Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Reserved | Keepalive Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type This field identifies the option and MUST be set to 10 (Keepalive Timeout).
键入此字段标识选项，必须设置为10（Keepalive Timeout）。
Length This field MUST be set as specified in Section 5.1 of the Shim6 protocol description [RFC5533] -- that is, set to 4.
长度必须按照Shim6协议说明[RFC5533]第5.1节的规定设置此字段——即设置为4。
Reserved A 16-bit field reserved for future use. It is set to zero upon transmit and MUST be ignored upon receipt.
保留为将来使用而保留的16位字段。它在传输时设置为零，在接收时必须忽略。
Keepalive Timeout The value in seconds corresponding to the suggested Keepalive Timeout value for the peer.
Keepalive Timeout与对等方的建议Keepalive Timeout值相对应的值（以秒为单位）。
The required behavior of REAP nodes is specified below in the form of a state machine. The externally observable behavior of an implementation MUST conform to this state machine, but there is no requirement that the implementation actually employ a state machine. Intermixed with the following description, we also provide a state machine description in tabular form. However, that form is only informational.
下面以状态机的形式指定了收割节点所需的行为。实现的外部可观察行为必须符合此状态机，但不要求实现实际使用状态机。与下面的描述混合，我们还以表格形式提供状态机描述。但是，该表单仅提供信息。
On a given context with a given peer, the node can be in one of three states: Operational, Exploring, or InboundOK. In the Operational state, the underlying address pairs are assumed to be operational. In the Exploring state, this node hasn't seen any traffic from the peer for more than a Send Timer period. Finally, in the InboundOK
在具有给定对等方的给定上下文中，节点可以处于三种状态之一：操作、探索或InboundOK。在操作状态下，假定基础地址对是可操作的。在探索状态下，此节点在超过一个发送计时器周期的时间内没有看到来自对等方的任何流量。最后，在InboundOK中
state, this node sees traffic from the peer, but the peer may not yet see any traffic from this node, so the exploration process needs to continue.
状态下，此节点可以看到来自对等方的流量，但对等方可能尚未看到来自此节点的任何流量，因此探索过程需要继续。
The node also maintains the Send Timer (Send Timeout seconds) and Keepalive Timer (Keepalive Timeout seconds). The Send Timer reflects the requirement that when this node sends a payload packet, there should be some return traffic (either payload packets or Keepalive messages) within Send Timeout seconds. The Keepalive Timer reflects the requirement that when this node receives a payload packet, there should a similar response towards the peer. The Keepalive Timer is only used within the Operational state, and the Send Timer within the Operational and InboundOK states. No timer is running in the Exploring state. As explained in Section 4.1, the two timers are mutually exclusive. That is, either the Keepalive Timer or the Send Timer is running, or neither of them is running.
该节点还维护发送计时器（发送超时秒）和Keepalive计时器（Keepalive超时秒）。发送计时器反映了当该节点发送有效负载数据包时，在发送超时秒内应该有一些返回流量（有效负载数据包或Keepalive消息）。Keepalive计时器反映了这样一个需求，即当该节点接收到有效负载数据包时，应该有一个类似的响应指向对等方。Keepalive计时器仅在操作状态下使用，发送计时器在操作和InboundOK状态下使用。没有计时器在探索状态下运行。如第4.1节所述，这两个计时器是互斥的。也就是说，Keepalive计时器或Send计时器正在运行，或者两者都没有运行。
Note that Appendix A gives some examples of typical protocol runs in order to illustrate the behavior.
请注意，附录A给出了一些典型协议运行的示例，以说明该行为。
Upon the reception of a payload packet in the Operational state, the node starts the Keepalive Timer if it was not yet running, and stops the Send Timer if it was running.
在接收到处于操作状态的有效负载数据包后，如果Keepalive计时器尚未运行，则节点启动该计时器，如果发送计时器正在运行，则停止该计时器。
If the node is in the Exploring state, it transitions to the InboundOK state, sends a Probe message, and starts the Send Timer. It fills the Psent and corresponding Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data fields with information about recent Probe messages that have not yet been reported as seen by the peer. It also fills the Precvd and corresponding Probe Source Address, Probe Destination Address, Probe Nonce, and Probe Data fields with information about recent Probe messages it has seen from the peer. When sending a Probe message, the State field MUST be set to a value that matches the conceptual state of the sender after sending the Probe. In this case, the node therefore sets the State field to 2 (InboundOk). The IP source and destination addresses for sending the Probe message are selected as discussed in Section 4.3.
如果节点处于探索状态，它将转换为InboundOK状态，发送探测消息，并启动发送计时器。它用对等方尚未报告的最近探测消息的信息填充Psent和相应的探测源地址、探测目标地址、探测Nonce和探测数据字段。它还使用从对等方看到的有关最近探测消息的信息，填充Precvd和相应的探测源地址、探测目标地址、探测Nonce和探测数据字段。发送探测消息时，状态字段必须设置为与发送探测后发送者的概念状态相匹配的值。在这种情况下，节点因此将状态字段设置为2（InboundOk）。如第4.3节所述，选择用于发送探测消息的IP源地址和目标地址。
In the InboundOK state, the node stops the Send Timer if it was running, but does not do anything else.
在InboundOK状态下，节点停止正在运行的发送计时器，但不执行任何其他操作。
The reception of Shim6 control messages other than the Keepalive and Probe messages are treated the same as the reception of payload packets.
除Keepalive和Probe消息外，对Shim6控制消息的接收与有效负载数据包的接收处理相同。
While the Keepalive Timer is running, the node SHOULD send Keepalive messages to the peer with an interval of Keepalive Interval seconds. Conceptually, a separate timer is used to distinguish between the interval between Keepalive messages and the overall Keepalive Timeout interval. However, this separate timer is not modelled in the tabular or graphical state machines. When sent, the Keepalive message is constructed as described in Section 5.1. It is sent using the current address pair.
当Keepalive计时器运行时，节点应以Keepalive interval秒的间隔向对等方发送Keepalive消息。从概念上讲，单独的计时器用于区分Keepalive消息之间的间隔和整个Keepalive超时间隔。然而，这个单独的计时器不是在表格或图形状态机中建模的。发送时，Keepalive消息的构造如第5.1节所述。它使用当前地址对发送。
In the below tables, "START", "RESTART", and "STOP" refer to starting, restarting, and stopping the Keepalive Timer or the Send Timer, respectively. "GOTO" refers to transitioning to another state. "SEND" refers to sending a message, and "-" refers to taking no action.
在下表中，“启动”、“重新启动”和“停止”分别指启动、重新启动和停止Keepalive计时器或发送计时器。“转到”是指过渡到另一个状态。“发送”是指发送消息，“—”是指不采取任何行动。
Operational Exploring InboundOk
--------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Keepalive START Send
GOTO InboundOk
Operational Exploring InboundOk
--------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Keepalive START Send
GOTO InboundOk
Upon sending a payload packet in the Operational state, the node stops the Keepalive Timer if it was running and starts the Send Timer if it was not running. In the Exploring state there is no effect, and in the InboundOK state the node simply starts the Send Timer if it was not yet running. (The sending of Shim6 control messages is again treated the same.)
在操作状态下发送有效负载数据包时，如果Keepalive计时器正在运行，则节点停止该计时器，如果未运行，则启动发送计时器。在探索状态下没有效果，而在InboundOK状态下，如果发送计时器尚未运行，则节点仅启动发送计时器。（Shim6控制消息的发送再次被视为相同。）
Operational Exploring InboundOk
------------------------------------------------------------------
START Send - START Send
STOP Keepalive
Operational Exploring InboundOk
------------------------------------------------------------------
START Send - START Send
STOP Keepalive
Upon a timeout on the Keepalive Timer, the node sends one last Keepalive message. This can only happen in the Operational state.
当Keepalive计时器超时时，节点发送最后一条Keepalive消息。这只能在操作状态下发生。
The Keepalive message is constructed as described in Section 5.1. It is sent using the current address pair.
Keepalive消息的构造如第5.1节所述。它使用当前地址对发送。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Keepalive - -
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Keepalive - -
Upon a timeout on the Send Timer, the node enters the Exploring state and sends a Probe message. The Probe message is constructed as explained in Section 6.1, except that the State field is set to 1 (Exploring).
发送计时器超时后，节点进入探测状态并发送探测消息。探测消息的构造如第6.1节所述，但状态字段设置为1（探测）。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe Exploring - SEND Probe Exploring
GOTO Exploring GOTO Exploring
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe Exploring - SEND Probe Exploring
GOTO Exploring GOTO Exploring
While in the Exploring state, the node keeps retransmitting its Probe messages to different (or the same) addresses as defined in Section 4.3. A similar process is employed in the InboundOk state, except that upon such retransmission, the Send Timer is started if it was not running already.
当处于探测状态时，节点继续将其探测消息重新传输到第4.3节中定义的不同（或相同）地址。InboundOk状态下采用了类似的过程，除了在重新传输时，如果发送计时器尚未运行，则启动发送计时器。
The Probe messages are constructed as explained in Section 6.1, except that the State field is set to 1 (Exploring) or 2 (InboundOk), depending on which state the sender is in.
探测消息的构造如第6.1节所述，但状态字段设置为1（探测）或2（InboundOk），具体取决于发送方所处的状态。
Operational Exploring InboundOk
-----------------------------------------------------------------
- SEND Probe Exploring SEND Probe InboundOk
START Send
Operational Exploring InboundOk
-----------------------------------------------------------------
- SEND Probe Exploring SEND Probe InboundOk
START Send
Upon the reception of a Keepalive message in the Operational state, the node stops the Send Timer if it was running. If the node is in the Exploring state, it transitions to the InboundOK state, sends a Probe message, and starts the Send Timer. The Probe message is constructed as explained in Section 6.1.
在操作状态下接收到Keepalive消息后，如果发送计时器正在运行，则节点停止发送计时器。如果节点处于探索状态，它将转换为InboundOK状态，发送探测消息，并启动发送计时器。探测消息的构造如第6.1节所述。
In the InboundOK state, the Send Timer is stopped if it was running.
在InboundOK状态下，发送计时器在运行时停止。
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Send
GOTO InboundOk
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send SEND Probe InboundOk STOP Send
START Send
GOTO InboundOk
Upon receiving a Probe message with State set to Exploring, the node enters the InboundOK state, sends a Probe message as described in Section 6.1, stops the Keepalive Timer if it was running, and restarts the Send Timer.
在接收到状态设置为Exploring的探测消息后，节点进入InboundOK状态，按照第6.1节中的描述发送探测消息，如果Keepalive计时器正在运行，则停止它，并重新启动发送计时器。
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe InboundOk SEND Probe InboundOk SEND Probe InboundOk
STOP Keepalive START Send RESTART Send
RESTART Send GOTO InboundOk
GOTO InboundOk
Operational Exploring InboundOk
------------------------------------------------------------------
SEND Probe InboundOk SEND Probe InboundOk SEND Probe InboundOk
STOP Keepalive START Send RESTART Send
RESTART Send GOTO InboundOk
GOTO InboundOk
Upon the reception of a Probe message with State set to InboundOk, the node sends a Probe message, restarts the Send Timer, stops the Keepalive Timer if it was running, and transitions to the Operational state. A new current address pair is chosen for the connection, based on the reports of received probes in the message that we just received. If no received probes have been reported, the current address pair is unchanged.
在接收到状态设置为InboundOk的探测消息后，节点发送探测消息，重新启动发送计时器，如果Keepalive计时器正在运行，则停止它，并转换到操作状态。根据我们刚刚收到的消息中接收到的探测报告，为连接选择一个新的当前地址对。如果未报告收到的探测，则当前地址对不变。
The Probe message is constructed as explained in Section 6.1, except that the State field is set to zero (Operational).
探测消息的构造如第6.1节所述，但状态字段设置为零（可操作）。
Operational Exploring InboundOk
--------------------------------------------------------------------
SEND Probe Operational SEND Probe Operational SEND Probe Operational
RESTART Send RESTART Send RESTART Send
STOP Keepalive GOTO Operational GOTO Operational
Operational Exploring InboundOk
--------------------------------------------------------------------
SEND Probe Operational SEND Probe Operational SEND Probe Operational
RESTART Send RESTART Send RESTART Send
STOP Keepalive GOTO Operational GOTO Operational
Upon the reception of a Probe message with State set to Operational, the node stops the Send Timer if it was running, starts the Keepalive Timer if it was not yet running, and transitions to the Operational state. The Probe message is constructed as explained in Section 6.1, except that the State field is set to zero (Operational).
在接收到状态设置为“可操作”的探测消息后，如果发送计时器正在运行，则节点停止发送计时器，如果尚未运行，则启动Keepalive计时器，并转换到可操作状态。探测消息的构造如第6.1节所述，但状态字段设置为零（可操作）。
Note: This terminates the exploration process when both parties are happy and know that their peer is happy as well.
注意：当双方都很高兴并且知道对方也很高兴时，这将终止探索过程。
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send STOP Send STOP Send
START Keepalive START Keepalive START Keepalive
GOTO Operational GOTO Operational
Operational Exploring InboundOk
------------------------------------------------------------------
STOP Send STOP Send STOP Send
START Keepalive START Keepalive START Keepalive
GOTO Operational GOTO Operational
The reachability detection and exploration process has no effect on payload communications until a new operational address pair has actually been confirmed. Prior to that, the payload packets continue to be sent to the previously used addresses.
在实际确认新的操作地址对之前，可达性检测和探测过程不会对有效载荷通信产生影响。在此之前，有效载荷分组继续被发送到先前使用的地址。
In the PDF version of this specification, an informational drawing illustrates the state machine. Where the text and the drawing differ, the text takes precedence.
在本规范的PDF版本中，一个信息性图形说明了状态机。如果文本和图纸不同，则以文本为准。
The following protocol constants are defined:
定义了以下协议常数：
Initial Probe Timeout 0.5 seconds Number of Initial Probes 4 probes
初始探测超时0.5秒初始探测数4个探测
And these variables have the following default values:
这些变量具有以下默认值：
Send Timeout 15 seconds Keepalive Timeout X seconds, where X is the peer's Send Timeout as communicated in the Keepalive Timeout Option 15 seconds if the peer didn't send a Keepalive Timeout option Keepalive Interval Y seconds, where Y is one-third to one-half of the Keepalive Timeout value (see Section 4.1)
发送超时15秒Keepalive Timeout X seconds，其中X是在Keepalive Timeout选项15秒中通信的对等方的发送超时，如果对等方没有发送Keepalive Timeout选项Keepalive Interval Y seconds，其中Y是Keepalive Timeout值的三分之一到一半（参见第4.1节）
Alternate values of the Send Timeout may be selected by a node and communicated to the peer in the Keepalive Timeout Option. A very small value of the Send Timeout may affect the ability to exchange keepalives over a path that has a long roundtrip delay. Similarly, it may cause Shim6 to react to temporary failures more often than necessary. As a result, it is RECOMMENDED that an alternate Send Timeout value not be under 10 seconds. Choosing a higher value than the one recommended above is also possible, but there is a relationship between Send Timeout and the ability of REAP to discover and correct errors in the communication path. In any case, in order for Shim6 to be useful, it should detect and repair communication
发送超时的备选值可由节点选择，并在Keepalive Timeout选项中与对等方通信。发送超时的极小值可能会影响在具有长往返延迟的路径上交换keepalive的能力。类似地，它可能会导致Shim6对临时故障的反应过于频繁。因此，建议备用发送超时值不低于10秒。也可以选择高于上述建议值的值，但发送超时与REAP发现和纠正通信路径中错误的能力之间存在关系。无论如何，为了使Shim6有用，它应该检测并修复通信
problems long before upper layers give up. For this reason, it is RECOMMENDED that Send Timeout be at most 100 seconds (default TCP R2 timeout [RFC1122]).
问题早在上层放弃之前就出现了。因此，建议发送超时最多为100秒（默认TCP R2超时[RFC1122]）。
Note: It is not expected that the Send Timeout or other values will be estimated based on experienced roundtrip times. Signaling exchanges are performed based on exponential back-off. The keepalive processes send packets only in the relatively rare condition that all traffic is unidirectional.
注意：预计发送超时或其他值不会基于经验的往返时间进行估计。信令交换是基于指数退避执行的。keepalive进程仅在所有通信量都是单向的情况下发送数据包。
Attackers may spoof various indications from lower layers and from the network in an effort to confuse the peers about which addresses are or are not operational. For example, attackers may spoof ICMP error messages in an effort to cause the parties to move their traffic elsewhere or even to disconnect. Attackers may also spoof information related to network attachments, Router Discovery, and address assignments in an effort to make the parties believe they have Internet connectivity when in reality they do not.
攻击者可能从较低层和网络中伪造各种指示，试图混淆对等方关于哪些地址可操作或不可操作的信息。例如，攻击者可能伪造ICMP错误消息，以使各方将其流量转移到其他地方，甚至断开连接。攻击者还可能伪造与网络附件、路由器发现和地址分配相关的信息，以使双方相信他们有互联网连接，而实际上他们没有。
This may cause use of non-preferred addresses or even denial of service.
这可能会导致使用非首选地址，甚至拒绝服务。
This protocol does not provide any protection of its own for indications from other parts of the protocol stack. Unprotected indications SHOULD NOT be taken as a proof of connectivity problems. However, REAP has weak resistance against incorrect information even from unprotected indications in the sense that it performs its own tests prior to picking a new address pair. Denial-of-service vulnerabilities remain, however, as do vulnerabilities against on-path attackers.
该协议本身不为协议栈其他部分的指示提供任何保护。不应将未受保护的指示视为连通性问题的证据。但是，REAP对错误信息的抵抗力很弱，即使是来自未受保护的指示，因为它在选择新地址对之前执行自己的测试。但是，拒绝服务漏洞仍然存在，针对路径上攻击者的漏洞也存在。
Some aspects of these vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as properly dealing with ICMP errors [GONT], link-layer security, or the use of SEND [RFC3971] to protect IPv6 Router and Neighbor Discovery.
这些漏洞的某些方面可以通过使用特定于堆栈其他部分的技术来缓解，例如正确处理ICMP错误[GONT]、链路层安全或使用发送[RFC3971]来保护IPv6路由器和邻居发现。
Other parts of the Shim6 protocol ensure that the set of addresses we are switching between actually belong together. REAP itself provides no such assurances. Similarly, REAP provides some protection against third-party flooding attacks [AURA02]; when REAP is run, its Probe Nonces can be used as a return routability check that the claimed address is indeed willing to receive traffic. However, this needs to be complemented with another mechanism to ensure that the claimed address is also the correct node. Shim6 does this by performing binding of all operations to context tags.
Shim6协议的其他部分确保我们正在切换的地址集实际上属于同一个地址集。REAP本身并没有提供这样的保证。类似地，REAP提供了一些针对第三方洪水攻击的保护[AURA02]；当REAP运行时，它的探测nonce可以用作返回可路由性检查，以确认声明的地址确实愿意接收流量。然而，这需要用另一种机制来补充，以确保声明的地址也是正确的节点。Shim6通过将所有操作绑定到上下文标记来实现这一点。
The keepalive mechanism in this specification is vulnerable to spoofing. On-path attackers that can see a Shim6 context tag can send spoofed Keepalive messages once per Send Timeout interval in order to prevent two Shim6 nodes from sending Keepalives themselves. This vulnerability is only relevant to nodes involved in a one-way communication. The result of the attack is that the nodes enter the exploration phase needlessly, but they should be able to confirm connectivity unless, of course, the attacker is able to prevent the exploration phase from completing. Off-path attackers may not be able to generate spoofed results, given that the context tags are 47- bit random numbers.
此规范中的keepalive机制易受欺骗攻击。能够看到Shim6上下文标记的路径上攻击者可以在每个发送超时间隔发送一次伪造的Keepalive消息，以防止两个Shim6节点自己发送Keepalive。此漏洞仅与单向通信中涉及的节点相关。攻击的结果是节点不必要地进入探索阶段，但它们应该能够确认连接，当然，除非攻击者能够阻止探索阶段的完成。鉴于上下文标记是47位随机数，非路径攻击者可能无法生成伪造结果。
To protect against spoofed Keepalive messages, a node implementing both Shim6 and IPsec MAY ignore incoming REAP keepalives if it has good reason to assume that the other side will be sending IPsec-protected return traffic. In other words, if a node is sending TCP payload data, it can reasonably expect to receive TCP ACKs in return. If no IPsec-protected ACKs come back but unprotected keepalives do, this could be the result of an attacker trying to hide broken connectivity.
为了防止伪造的保留消息，同时实现Shim6和IPsec的节点可以忽略传入的保留消息，如果它有充分的理由认为另一方将发送IPsec保护的返回流量。换句话说，如果节点正在发送TCP有效负载数据，那么它可以合理地期望收到TCP ACK作为回报。如果没有IPsec保护的ACK返回，但未保护的keepalives返回，这可能是攻击者试图隐藏断开的连接的结果。
The exploration phase is vulnerable to attackers that are on the path. Off-path attackers would find it hard to guess either the context tag or the correct probe identifiers. Given that IPsec operates above the Shim6 layer, it is not possible to protect the exploration phase against on-path attackers with IPsec. This is similar to the issues with protecting other Shim6 control exchanges. There are mechanisms in place to prevent the redirection of communications to wrong addresses, but on-path attackers can cause denial-of-service, move communications to less-preferred address pairs, and so on.
探索阶段易受路径上的攻击者攻击。非路径攻击者会发现很难猜测上下文标记或正确的探测标识符。鉴于IPsec在Shim6层之上运行，因此无法使用IPsec保护探索阶段免受路径上攻击者的攻击。这与保护其他Shim6控制交换的问题类似。现有机制可防止通信重定向到错误地址，但路径上攻击者可导致拒绝服务、将通信移动到首选地址对等。
Finally, the exploration itself can cause a number of packets to be sent. As a result, it may be used as a tool for packet amplification in flooding attacks. It is required that the protocol employing REAP has built-in mechanisms to prevent this. For instance, Shim6 contexts are created only after a relatively large number of packets have been exchanged, a cost that reduces the attractiveness of using Shim6 and REAP for amplification attacks. However, such protections are typically not present at connection-establishment time. When exploration would be needed for connection establishment to succeed, its usage would result in an amplification vulnerability. As a result, Shim6 does not support the use of REAP in the connection-establishment stage.
最后，探索本身可以导致发送大量数据包。因此，它可以用作洪水攻击中数据包放大的工具。要求采用REAP的协议具有内置机制来防止这种情况。例如，只有在交换了相对大量的数据包之后才能创建Shim6上下文，这一成本降低了使用Shim6和REAP进行放大攻击的吸引力。然而，这种保护通常在连接建立时不存在。当连接建立成功需要进行探索时，其使用将导致漏洞放大。因此，Shim6不支持在连接建立阶段使用REAP。
When there are no failures, the failure-detection mechanism (and Shim6 in general) are lightweight: keepalives are not sent when a Shim6 context is idle or when there is traffic in both directions. So in normal TCP or TCP-like operations, there would only be one or two keepalives when a session transitions from active to idle.
当没有故障时，故障检测机制（以及通常的Shim6）是轻量级的：当Shim6上下文空闲或在两个方向上都有流量时，不发送keepalives。因此，在正常的TCP或类似TCP的操作中，当会话从活动转换为空闲时，只有一个或两个KeepAlive。
Only when there are failures is there significant failure-detection traffic, especially in the case where a link goes down that is shared by many active sessions and by multiple nodes. When this happens, one keepalive is sent and then a series of probes. This happens per active (traffic-generating) context, all of which will time out within 15 seconds after the failure. This makes the peak traffic that Shim6 generates after a failure around one packet per second per context. Presumably, the sessions that run over those contexts were sending at least that much traffic and most likely more, but if the backup path is significantly lower bandwidth than the failed path, this could lead to temporary congestion.
只有在出现故障时，才会出现显著的故障检测流量，特别是在链路中断的情况下，该链路由多个活动会话和多个节点共享。发生这种情况时，发送一个keepalive，然后发送一系列探测。这在每个活动（流量生成）上下文中发生，所有这些上下文都将在故障后15秒内超时。这使得Shim6在发生故障后产生的峰值流量大约为每秒一个数据包/上下文。据推测，在这些上下文上运行的会话发送的流量至少有那么多，而且很可能更多，但如果备份路径的带宽明显低于故障路径，这可能会导致暂时的拥塞。
However, note that in the case of multihoming using BGP, if the failover is fast enough that TCP doesn't go into slow start, the full payload data traffic that flows over the failed path is switched over to the backup path, and if this backup path is of a lower capacity, there will be even more congestion.
但是，请注意，在使用BGP进行多主的情况下，如果故障切换足够快，TCP不会进入慢启动状态，则流经故障路径的完整有效负载数据流量将切换到备份路径，如果此备份路径的容量较低，则会出现更大的拥塞。
Although the failure detection probing does not perform congestion control as such, the exponential back-off makes sure that the number of packets sent quickly goes down and eventually reaches one per context per minute, which should be sufficiently conservative even on the lowest bandwidth links.
尽管故障检测探测本身不执行拥塞控制，但指数退避确保发送的数据包数量迅速下降，最终达到每分钟一个上下文，即使在带宽最低的链路上也应足够保守。
Section 7 specifies a number of protocol parameters. Possible tuning of these parameters and others that are not mandated in this specification may affect these properties. It is expected that further revisions of this specification provide additional information after sufficient deployment experience has been obtained from different environments.
第7节规定了一些协议参数。这些参数以及本规范中未强制要求的其他参数的可能调整可能会影响这些属性。在从不同环境获得足够的部署经验后，预计本规范的进一步修订将提供更多信息。
Implementations may provide means to monitor their performance and send alarms about problems. Their standardization is, however, the subject of future specifications. In general, Shim6 is most applicable for small sites and nodes, and it is expected that monitoring requirements on such deployments are relatively modest. In any case, where the node is associated with a management system, it is RECOMMENDED that detected failures and failover events are
实现可以提供监视其性能和发送问题警报的方法。然而，它们的标准化是未来规范的主题。一般来说，Shim6最适用于小型站点和节点，预计对此类部署的监控要求相对较低。在任何情况下，如果节点与管理系统相关联，建议删除检测到的故障和故障转移事件
reported via asynchronous notifications to the management system. Similarly, where logging mechanisms are available on the node, these events should be recorded in event logs.
通过异步通知向管理系统报告。类似地，如果节点上有日志记录机制，则应将这些事件记录在事件日志中。
Shim6 uses the same header for both signaling and the encapsulation of payload packets after a rehoming event. This way, fate is shared between the two types of packets, so the situation where reachability probes or keepalives can be transmitted successfully but payload packets cannot, is largely avoided: either all Shim6 packets make it through, so Shim6 functions as intended, or none do, and no Shim6 state is negotiated. Even in the situation where some packets make it through and others do not, Shim6 will generally either work as intended or provide a service that is no worse than in the absence of Shim6, apart from the possible generation of a small amount of signaling traffic.
Shim6在重新发送事件后，对有效负载数据包的信令和封装使用相同的报头。通过这种方式，两种类型的数据包之间的命运是共享的，因此可以在很大程度上避免可达性探测或keepalives可以成功传输，但有效负载数据包无法传输的情况：要么所有的Shim6数据包都能通过，所以Shim6按预期运行，要么没有，并且没有协商任何Shim6状态。即使在某些数据包能够通过而其他数据包不能通过的情况下，除了可能产生少量信令业务外，Shim6通常也会按照预期工作，或者提供不比没有Shim6更糟糕的服务。
Sometimes payload packets (and possibly payload packets encapsulated in the Shim6 header) do not make it through, but signaling and keepalives do. This situation can occur when there is a path MTU discovery black hole on one of the paths. If only large packets are sent at some point, then reachability exploration will be turned on and REAP will likely select another path, which may or may not be affected by the PMTUD black hole.
有时有效负载数据包（可能还有封装在Shim6报头中的有效负载数据包）无法通过，但信令和keepalives可以通过。当其中一条路径上有MTU发现黑洞路径时，就会出现这种情况。如果在某个点只发送大数据包，那么可达性探索将打开，并且REAP可能会选择另一条路径，这可能会也可能不会受到PMTUD黑洞的影响。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 2006.
[RFC4429]Moore，N.，“IPv6的乐观重复地址检测（DAD）”，RFC4429，2006年4月。
[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月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[ADD-SEL] Bagnulo, M., "Address selection in multihomed environments", Work in Progress, October 2005.
[ADD-SEL]Bagnulo，M.，“多址环境中的地址选择”，正在进行的工作，2005年10月。
[AURA02] Aura, T., Roe, M., and J. Arkko, "Security of Internet Location Management", Proceedings of the 18th Annual Computer Security Applications Conference, Las Vegas, Nevada, USA, December 2002.
[AURA02]Aura，T.，Roe，M.，和J.Arkko，“互联网位置管理的安全”，第18届计算机安全应用年会会议记录，美国内华达州拉斯维加斯，2002年12月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD]Katz，D.和D.Ward，“双向转发检测”，正在进行的工作，2009年2月。
[DNA-SIM] Krishnan, S. and G. Daley, "Simple procedures for Detecting Network Attachment in IPv6", Work in Progress, February 2009.
[DNA-SIM]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，正在进行的工作，2009年2月。
[GONT] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2008.
[GONT]GONT，F.，“ICMP对TCP的攻击”，正在进行的工作，2008年10月。
[MULTI6] Huitema, C., "Address selection in multihomed environments", Work in Progress, October 2004.
[MULTI6]Huitema，C.，“多址环境中的地址选择”，正在进行的工作，2004年10月。
[PAIR] Bagnulo, M., "Default Locator-pair selection algorithm for the Shim6 protocol", Work in Progress, October 2008.
[PAIR]Bagnulo，M.，“Shim6协议的默认定位器对选择算法”，正在进行的工作，2008年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
This appendix has examples of REAP protocol runs in typical scenarios. We start with the simplest scenario of two nodes, A and B, that have a Shim6 connection with each other but are not currently sending any payload data. As neither side sends anything, they also do not expect anything back, so there are no messages at all:
本附录提供了在典型场景中运行REAP协议的示例。我们从两个节点A和B的最简单场景开始，这两个节点彼此有一个Shim6连接，但当前没有发送任何有效负载数据。由于双方都不发送任何消息，因此也不希望返回任何消息，因此根本没有任何消息：
EXAMPLE 1: No Communications
例1：无通信
Peer A Peer B
| |
| |
| |
| |
| |
| |
| |
| |
Peer A Peer B
| |
| |
| |
| |
| |
| |
| |
| |
Our second example involves an active connection with bidirectional payload packet flows. Here, the reception of payload data from the peer is taken as an indication of reachability, so again there are no extra packets:
我们的第二个示例涉及具有双向有效负载数据包流的活动连接。这里，从对等方接收有效负载数据被视为可达性的指示，因此同样不存在额外的分组：
EXAMPLE 2: Bidirectional Communications
示例2：双向通信
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
The third example is the first one that involves an actual REAP message. Here, the nodes communicate in just one direction, so REAP messages are needed to indicate to the peer that sends payload packets that its packets are getting through:
第三个示例是第一个涉及实际REAP消息的示例。这里，节点仅在一个方向上通信，因此需要获取消息来向发送有效负载数据包的对等方指示其数据包正在通过：
EXAMPLE 3: Unidirectional Communications
例3：单向通信
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| Keepalive Nonce=p |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
Peer A Peer B
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| payload packet |
|-------------------------------------------->|
| |
| Keepalive Nonce=p |
|<--------------------------------------------|
| |
| payload packet |
|-------------------------------------------->|
| |
| |
The next example involves a failure scenario. Here, A has address A, and B has addresses B1 and B2. The currently used address pairs are (A, B1) and (B1, A). All connections via B1 become broken, which leads to an exploration process:
下一个示例涉及一个故障场景。这里，A有地址A，B有地址B1和B2。当前使用的地址对是（A，B1）和（B1，A）。通过B1的所有连接断开，导致勘探过程：
EXAMPLE 4: Failure Scenario
示例4：故障场景
Peer A Peer B
| |
State: | State:
Operational | Operational
| (A,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A) payload packet |
|<--------------------------------------------| At time T1
| | path A<->B1
| (A,B1) payload packet | becomes
|----------------------------------------/ | broken.
| |
| ( B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B happens to
| | see the problem
| (B1,A) Probe Nonce=p, | first and sends a
| state=exploring | complaint that
| /-----------------------------------------| it is not
| | receiving
| | anything.
| | State:
| | Exploring
| |
| (B2,A) Probe Nonce=q, |
| state=exploring | But it's lost,
|<--------------------------------------------| retransmission
| | uses another pair
A realizes |
that it needs |
to start the |
exploration. |
It picks B2 as the |
Peer A Peer B
| |
State: | State:
Operational | Operational
| (A,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A) payload packet |
|<--------------------------------------------| At time T1
| | path A<->B1
| (A,B1) payload packet | becomes
|----------------------------------------/ | broken.
| |
| ( B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A) payload packet |
| /-----------------------------------------|
| |
| (A,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B happens to
| | see the problem
| (B1,A) Probe Nonce=p, | first and sends a
| state=exploring | complaint that
| /-----------------------------------------| it is not
| | receiving
| | anything.
| | State:
| | Exploring
| |
| (B2,A) Probe Nonce=q, |
| state=exploring | But it's lost,
|<--------------------------------------------| retransmission
| | uses another pair
A realizes |
that it needs |
to start the |
exploration. |
It picks B2 as the |
most likely candidate, |
as it appeared in the |
Probe. |
State: InboundOk |
| |
| (A, B2) Probe Nonce=r, |
| state=inboundok, |
| received probe q | This one gets
|-------------------------------------------->| through.
| | State:
| | Operational
| (B2,A) Probe Nonce=s, |
| state=operational, | B now knows
| received probe r | that A has no
|<--------------------------------------------| problem receiving
| | its packets.
State: Operational |
| |
| (A,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B2,A) payload packet |
|<--------------------------------------------|
most likely candidate, |
as it appeared in the |
Probe. |
State: InboundOk |
| |
| (A, B2) Probe Nonce=r, |
| state=inboundok, |
| received probe q | This one gets
|-------------------------------------------->| through.
| | State:
| | Operational
| (B2,A) Probe Nonce=s, |
| state=operational, | B now knows
| received probe r | that A has no
|<--------------------------------------------| problem receiving
| | its packets.
State: Operational |
| |
| (A,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B2,A) payload packet |
|<--------------------------------------------|
The next example shows when the failure for the current locator pair is in the other direction only. A has addresses A1 and A2, and B has addresses B1 and B2. The current communication is between A1 and B1, but A's packets no longer reach B using this pair.
下一个示例显示当前定位器对的故障仅在另一个方向。A有地址A1和A2，B有地址B1和B2。当前通信在A1和B1之间，但A的数据包不再使用此对到达B。
EXAMPLE 5: One-Way Failure
例5：单向故障
Peer A Peer B
| |
State: | State:
Operational | Operational
| |
| (A1,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet | At time T1
|----------------------------------------/ | path A1->B1
| | becomes
| | broken.
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B notices
| | the problem and
| (B1,A1) Probe Nonce=p, | sends a
| state=exploring | complaint that
|<--------------------------------------------| it is not
| | receiving
| | anything.
A responds. | State: Exploring
State: InboundOk |
| |
| (A1, B1) Probe Nonce=q, |
| state=inboundok, |
| received probe p |
|----------------------------------------/ | A's response
| | is lost.
| (B2,A2) Probe Nonce=r, |
| state=exploring | Next, try a different
Peer A Peer B
| |
State: | State:
Operational | Operational
| |
| (A1,B1) payload packet |
|-------------------------------------------->|
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet | At time T1
|----------------------------------------/ | path A1->B1
| | becomes
| | broken.
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| (B1,A1) payload packet |
|<--------------------------------------------|
| |
| (A1,B1) payload packet |
|----------------------------------------/ |
| |
| | Send Timeout
| | seconds after
| | T1, B notices
| | the problem and
| (B1,A1) Probe Nonce=p, | sends a
| state=exploring | complaint that
|<--------------------------------------------| it is not
| | receiving
| | anything.
A responds. | State: Exploring
State: InboundOk |
| |
| (A1, B1) Probe Nonce=q, |
| state=inboundok, |
| received probe p |
|----------------------------------------/ | A's response
| | is lost.
| (B2,A2) Probe Nonce=r, |
| state=exploring | Next, try a different
|<--------------------------------------------| locator pair.
| |
| (A2, B2) Probe Nonce=s, |
| state=inboundok, |
| received probes p, r | This one gets
|-------------------------------------------->| through.
| | State: Operational
| |
| | B now knows
| | that A has no
| (B2,A2) Probe Nonce=t, | problem receiving
| state=operational, | its packets and
| received probe s | that A's probe
|<--------------------------------------------| gets to B. It
| | sends a
State: Operational | confirmation to A.
| |
| (A2,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B1,A1) payload packet |
|<--------------------------------------------|
|<--------------------------------------------| locator pair.
| |
| (A2, B2) Probe Nonce=s, |
| state=inboundok, |
| received probes p, r | This one gets
|-------------------------------------------->| through.
| | State: Operational
| |
| | B now knows
| | that A has no
| (B2,A2) Probe Nonce=t, | problem receiving
| state=operational, | its packets and
| received probe s | that A's probe
|<--------------------------------------------| gets to B. It
| | sends a
State: Operational | confirmation to A.
| |
| (A2,B2) payload packet |
|-------------------------------------------->| Payload packets
| | flow again.
| (B1,A1) payload packet |
|<--------------------------------------------|
This document attempts to summarize the thoughts and unpublished contributions of many people, including MULTI6 WG design team members Marcelo Bagnulo Braun, Erik Nordmark, Geoff Huston, Kurtis Lindqvist, Margaret Wasserman, and Jukka Ylitalo; MOBIKE WG contributors Pasi Eronen, Tero Kivinen, Francis Dupont, Spencer Dawkins, and James Kempf; and HIP WG contributors such as Pekka Nikander. This document is also in debt to work done in the context of SCTP [RFC4960] and the Host Identity Protocol (HIP) multihoming and mobility extension [RFC5206].
本文件试图总结许多人的想法和未发表的贡献，包括MULTI6 WG设计团队成员Marcelo Bagnulo Braun、Erik Nordmark、Geoff Huston、Kurtis Lindqvist、Margaret Wasserman和Jukka Ylitalo；MOBIKE工作组贡献者Pasi Eronen、Tero Kivinen、Francis Dupont、Spencer Dawkins和James Kempf；以及Pekka Nikander等时尚工作组撰稿人。在SCTP[RFC4960]和主机标识协议（HIP）多宿和移动性扩展[RFC5206]的背景下，本文件也有助于完成工作。
The authors would also like to thank Christian Huitema, Pekka Savola, John Loughney, Sam Xia, Hannes Tschofenig, Sebastien Barre, Thomas Henderson, Matthijs Mekking, Deguang Le, Eric Gray, Dan Romascanu, Stephen Kent, Alberto Garcia, Bernard Aboba, Lars Eggert, Dave Ward, and Tim Polk for interesting discussions in this problem space, and for review of this specification.
作者还要感谢Christian Huitema、Pekka Savola、John Loughney、Sam Xia、Hannes Tschofenig、Sebastien Barre、Thomas Henderson、Matthijs Mekking、Deguang Le、Eric Gray、Dan Romascanu、Stephen Kent、Alberto Garcia、Bernard Aboba、Lars Eggert、Dave Ward和Tim Polk在这个问题空间中进行的有趣讨论，以及本规范的审查。
Authors' Addresses
作者地址
Jari Arkko Ericsson Jorvas 02420 Finland
雅丽爱立信芬兰公司02420
EMail: jari.arkko@ericsson.com
EMail: jari.arkko@ericsson.com
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van Beijnum IMDEA Networks Avda。德尔马尔地中海，22勒加内斯，马德里28918西班牙
EMail: iljitsch@muada.com
EMail: iljitsch@muada.com