Network Working Group E. Nordmark
Request for Comments: 5533 Sun Microsystems
Category: Standards Track M. Bagnulo
UC3M
June 2009
Network Working Group E. Nordmark
Request for Comments: 5533 Sun Microsystems
Category: Standards Track M. Bagnulo
UC3M
June 2009
Shim6: Level 3 Multihoming Shim Protocol for IPv6
Shim6:IPv6的3级多主Shim协议
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). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document defines the Shim6 protocol, a layer 3 shim for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties, without assuming that a multihomed site will have a provider-independent IPv6 address prefix announced in the global IPv6 routing table. The hosts in a site that has multiple provider-allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working.
本文档定义了Shim6协议，这是一个第3层垫片，用于在传输协议下提供定位灵活性，因此可以为具有故障切换和负载共享属性的IPv6提供多主服务，而无需假设多主站点将在全局IPv6路由表中宣布独立于提供商的IPv6地址前缀。具有多个提供商分配的IPv6地址前缀的站点中的主机将使用本文档中指定的Shim6协议设置对等主机的状态，以便在原始定位器对停止工作时，该状态稍后可用于故障切换到其他定位器对。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Goals ......................................................5
1.2. Non-Goals ..................................................5
1.3. Locators as Upper-Layer Identifiers (ULID) .................6
1.4. IP Multicast ...............................................7
1.5. Renumbering Implications ...................................8
1.6. Placement of the Shim ......................................9
1.7. Traffic Engineering .......................................11
2. Terminology ....................................................12
2.1. Definitions ...............................................12
2.2. Notational Conventions ....................................15
2.3. Conceptual ................................................15
3. Assumptions ....................................................15
4. Protocol Overview ..............................................17
4.1. Context Tags ..............................................19
4.2. Context Forking ...........................................19
4.3. API Extensions ............................................20
4.4. Securing Shim6 ............................................20
4.5. Overview of Shim Control Messages .........................21
4.6. Extension Header Order ....................................22
5. Message Formats ................................................23
5.1. Common Shim6 Message Format ...............................23
5.2. Shim6 Payload Extension Header Format .....................24
5.3. Common Shim6 Control Header ...............................25
5.4. I1 Message Format .........................................26
5.5. R1 Message Format .........................................28
5.6. I2 Message Format .........................................29
5.7. R2 Message Format .........................................31
5.8. R1bis Message Format ......................................33
5.9. I2bis Message Format ......................................34
5.10. Update Request Message Format ............................37
5.11. Update Acknowledgement Message Format ....................38
5.12. Keepalive Message Format .................................40
5.13. Probe Message Format .....................................40
5.14. Error Message Format .....................................40
5.15. Option Formats ...........................................42
5.15.1. Responder Validator Option Format .................44
5.15.2. Locator List Option Format ........................44
5.15.3. Locator Preferences Option Format .................46
5.15.4. CGA Parameter Data Structure Option Format ........48
5.15.5. CGA Signature Option Format .......................49
5.15.6. ULID Pair Option Format ...........................49
5.15.7. Forked Instance Identifier Option Format ..........50
5.15.8. Keepalive Timeout Option Format ...................50
6. Conceptual Model of a Host .....................................51
6.1. Conceptual Data Structures ................................51
1. Introduction ....................................................4
1.1. Goals ......................................................5
1.2. Non-Goals ..................................................5
1.3. Locators as Upper-Layer Identifiers (ULID) .................6
1.4. IP Multicast ...............................................7
1.5. Renumbering Implications ...................................8
1.6. Placement of the Shim ......................................9
1.7. Traffic Engineering .......................................11
2. Terminology ....................................................12
2.1. Definitions ...............................................12
2.2. Notational Conventions ....................................15
2.3. Conceptual ................................................15
3. Assumptions ....................................................15
4. Protocol Overview ..............................................17
4.1. Context Tags ..............................................19
4.2. Context Forking ...........................................19
4.3. API Extensions ............................................20
4.4. Securing Shim6 ............................................20
4.5. Overview of Shim Control Messages .........................21
4.6. Extension Header Order ....................................22
5. Message Formats ................................................23
5.1. Common Shim6 Message Format ...............................23
5.2. Shim6 Payload Extension Header Format .....................24
5.3. Common Shim6 Control Header ...............................25
5.4. I1 Message Format .........................................26
5.5. R1 Message Format .........................................28
5.6. I2 Message Format .........................................29
5.7. R2 Message Format .........................................31
5.8. R1bis Message Format ......................................33
5.9. I2bis Message Format ......................................34
5.10. Update Request Message Format ............................37
5.11. Update Acknowledgement Message Format ....................38
5.12. Keepalive Message Format .................................40
5.13. Probe Message Format .....................................40
5.14. Error Message Format .....................................40
5.15. Option Formats ...........................................42
5.15.1. Responder Validator Option Format .................44
5.15.2. Locator List Option Format ........................44
5.15.3. Locator Preferences Option Format .................46
5.15.4. CGA Parameter Data Structure Option Format ........48
5.15.5. CGA Signature Option Format .......................49
5.15.6. ULID Pair Option Format ...........................49
5.15.7. Forked Instance Identifier Option Format ..........50
5.15.8. Keepalive Timeout Option Format ...................50
6. Conceptual Model of a Host .....................................51
6.1. Conceptual Data Structures ................................51
6.2. Context STATES ............................................52
7. Establishing ULID-Pair Contexts ................................54
7.1. Uniqueness of Context Tags ................................54
7.2. Locator Verification ......................................55
7.3. Normal Context Establishment ..............................56
7.4. Concurrent Context Establishment ..........................56
7.5. Context Recovery ..........................................58
7.6. Context Confusion .........................................60
7.7. Sending I1 Messages .......................................61
7.8. Retransmitting I1 Messages ................................62
7.9. Receiving I1 Messages .....................................62
7.10. Sending R1 Messages ......................................63
7.10.1. Generating the R1 Validator .......................64
7.11. Receiving R1 Messages and Sending I2 Messages ............64
7.12. Retransmitting I2 Messages ...............................65
7.13. Receiving I2 Messages ....................................66
7.14. Sending R2 Messages ......................................67
7.15. Match for Context Confusion ..............................68
7.16. Receiving R2 Messages ....................................69
7.17. Sending R1bis Messages ...................................69
7.17.1. Generating the R1bis Validator ....................70
7.18. Receiving R1bis Messages and Sending I2bis Messages ......71
7.19. Retransmitting I2bis Messages ............................72
7.20. Receiving I2bis Messages and Sending R2 Messages .........72
8. Handling ICMP Error Messages ...................................74
9. Teardown of the ULID-Pair Context ..............................76
10. Updating the Peer .............................................77
10.1. Sending Update Request Messages ..........................77
10.2. Retransmitting Update Request Messages ...................78
10.3. Newer Information while Retransmitting ...................78
10.4. Receiving Update Request Messages ........................79
10.5. Receiving Update Acknowledgement Messages ................81
11. Sending ULP Payloads ..........................................81
11.1. Sending ULP Payload after a Switch .......................82
12. Receiving Packets .............................................83
12.1. Receiving Payload without Extension Headers ..............83
12.2. Receiving Shim6 Payload Extension Headers ................83
12.3. Receiving Shim Control Messages ..........................84
12.4. Context Lookup ...........................................84
13. Initial Contact ...............................................86
14. Protocol Constants ............................................87
15. Implications Elsewhere ........................................88
15.1. Congestion Control Considerations ........................88
15.2. Middle-Boxes Considerations ..............................88
15.3. Operation and Management Considerations ..................89
15.4. Other Considerations .....................................90
16. Security Considerations .......................................91
16.1. Interaction with IPSec ...................................93
6.2. Context STATES ............................................52
7. Establishing ULID-Pair Contexts ................................54
7.1. Uniqueness of Context Tags ................................54
7.2. Locator Verification ......................................55
7.3. Normal Context Establishment ..............................56
7.4. Concurrent Context Establishment ..........................56
7.5. Context Recovery ..........................................58
7.6. Context Confusion .........................................60
7.7. Sending I1 Messages .......................................61
7.8. Retransmitting I1 Messages ................................62
7.9. Receiving I1 Messages .....................................62
7.10. Sending R1 Messages ......................................63
7.10.1. Generating the R1 Validator .......................64
7.11. Receiving R1 Messages and Sending I2 Messages ............64
7.12. Retransmitting I2 Messages ...............................65
7.13. Receiving I2 Messages ....................................66
7.14. Sending R2 Messages ......................................67
7.15. Match for Context Confusion ..............................68
7.16. Receiving R2 Messages ....................................69
7.17. Sending R1bis Messages ...................................69
7.17.1. Generating the R1bis Validator ....................70
7.18. Receiving R1bis Messages and Sending I2bis Messages ......71
7.19. Retransmitting I2bis Messages ............................72
7.20. Receiving I2bis Messages and Sending R2 Messages .........72
8. Handling ICMP Error Messages ...................................74
9. Teardown of the ULID-Pair Context ..............................76
10. Updating the Peer .............................................77
10.1. Sending Update Request Messages ..........................77
10.2. Retransmitting Update Request Messages ...................78
10.3. Newer Information while Retransmitting ...................78
10.4. Receiving Update Request Messages ........................79
10.5. Receiving Update Acknowledgement Messages ................81
11. Sending ULP Payloads ..........................................81
11.1. Sending ULP Payload after a Switch .......................82
12. Receiving Packets .............................................83
12.1. Receiving Payload without Extension Headers ..............83
12.2. Receiving Shim6 Payload Extension Headers ................83
12.3. Receiving Shim Control Messages ..........................84
12.4. Context Lookup ...........................................84
13. Initial Contact ...............................................86
14. Protocol Constants ............................................87
15. Implications Elsewhere ........................................88
15.1. Congestion Control Considerations ........................88
15.2. Middle-Boxes Considerations ..............................88
15.3. Operation and Management Considerations ..................89
15.4. Other Considerations .....................................90
16. Security Considerations .......................................91
16.1. Interaction with IPSec ...................................93
16.2. Residual Threats .........................................94
17. IANA Considerations ...........................................95
18. Acknowledgements ..............................................97
19. References ....................................................97
19.1. Normative References .....................................97
19.2. Informative References ...................................97
Appendix A. Possible Protocol Extensions ........................100
Appendix B. Simplified STATE Machine ............................101
B.1. Simplified STATE Machine Diagram ........................108
Appendix C. Context Tag Reuse ...................................109
C.1. Context Recovery ........................................109
C.2. Context Confusion .......................................109
C.3. Three-Party Context Confusion .........................110
C.4. Summary .................................................110
Appendix D. Design Alternatives .................................111
D.1. Context Granularity .....................................111
D.2. Demultiplexing of Data Packets in Shim6 Communications ..111
D.2.1. Flow Label .........................................112
D.2.2. Extension Header ...................................115
D.3. Context-Loss Detection ................................115
D.4. Securing Locator Sets ...................................117
D.5. ULID-Pair Context-Establishment Exchange ............120
D.6. Updating Locator Sets ...................................121
D.7. State Cleanup ...........................................122
16.2. Residual Threats .........................................94
17. IANA Considerations ...........................................95
18. Acknowledgements ..............................................97
19. References ....................................................97
19.1. Normative References .....................................97
19.2. Informative References ...................................97
Appendix A. Possible Protocol Extensions ........................100
Appendix B. Simplified STATE Machine ............................101
B.1. Simplified STATE Machine Diagram ........................108
Appendix C. Context Tag Reuse ...................................109
C.1. Context Recovery ........................................109
C.2. Context Confusion .......................................109
C.3. Three-Party Context Confusion .........................110
C.4. Summary .................................................110
Appendix D. Design Alternatives .................................111
D.1. Context Granularity .....................................111
D.2. Demultiplexing of Data Packets in Shim6 Communications ..111
D.2.1. Flow Label .........................................112
D.2.2. Extension Header ...................................115
D.3. Context-Loss Detection ................................115
D.4. Securing Locator Sets ...................................117
D.5. ULID-Pair Context-Establishment Exchange ............120
D.6. Updating Locator Sets ...................................121
D.7. State Cleanup ...........................................122
This document describes a layer 3 shim approach and protocol for providing locator agility below the transport protocols, so that multihoming can be provided for IPv6 with failover and load-sharing properties [11], without assuming that a multihomed site will have a provider-independent IPv6 address announced in the global IPv6 routing table. The hosts in a site that has multiple provider-allocated IPv6 address prefixes will use the Shim6 protocol specified in this document to set up state with peer hosts so that the state can later be used to failover to a different locator pair, should the original one stop working (the term locator is defined in Section 2).
本文档描述了一种第3层垫片方法和协议，用于在传输协议下提供定位灵活性，从而可以为具有故障切换和负载共享属性的IPv6提供多主服务[11]，而不必假设多主站点将在全局IPv6路由表中公布独立于提供商的IPv6地址。具有多个提供商分配的IPv6地址前缀的站点中的主机将使用本文档中指定的Shim6协议设置对等主机的状态，以便在原始定位器对停止工作时，该状态可用于故障切换到不同的定位器对（术语定位器在第2节中定义）。
The Shim6 protocol is a site-multihoming solution in the sense that it allows existing communication to continue when a site that has multiple connections to the Internet experiences an outage on a subset of these connections or further upstream. However, Shim6 processing is performed in individual hosts rather than through site-wide mechanisms.
Shim6协议是一种站点多主解决方案，因为它允许在具有多个Internet连接的站点的一个子集或更上游发生中断时继续现有通信。但是，Shim6处理是在单个主机中执行的，而不是通过站点范围的机制。
We assume that redirection attacks are prevented using Hash-Based Addresses (HBA) as defined in [3].
我们假设使用[3]中定义的基于哈希的地址（HBA）可以防止重定向攻击。
The reachability and failure-detection mechanisms, including how a new working locator pair is discovered after a failure, are specified in RFC 5534 [4]. This document allocates message types and option types for that sub-protocol, and leaves the specification of the message and option formats, as well as the protocol behavior, to RFC 5534.
RFC 5534[4]规定了可达性和故障检测机制，包括故障后如何发现新的工作定位器对。本文档为该子协议分配消息类型和选项类型，并将消息和选项格式以及协议行为的规范留给RFC 5534。
The goals for this approach are to:
这种方法的目标是：
o Preserve established communications in the presence of certain classes of failures, for example, TCP connections and UDP streams.
o 在出现某些类别的故障（例如TCP连接和UDP流）时保留已建立的通信。
o Have minimal impact on upper-layer protocols in general and on transport protocols and applications in particular.
o 对上层协议，尤其是传输协议和应用程序的影响最小。
o Address the security threats in [15] through a combination of the HBA/CGA approach specified in RFC 5535 [3] and the techniques described in this document.
o 通过结合RFC 5535[3]中规定的HBA/CGA方法和本文档中描述的技术，解决[15]中的安全威胁。
o Not require an extra roundtrip up front to set up shim-specific state. Instead, allow the upper-layer traffic (e.g., TCP) to flow as normal and defer the set up of the shim state until some number of packets have been exchanged.
o 不需要额外的前向往返来设置垫片特定状态。相反，允许上层流量（例如TCP）正常流动，并推迟垫片状态的设置，直到交换了一定数量的数据包。
o Take advantage of multiple locators/addresses for load spreading so that different sets of communication to a host (e.g., different connections) might use different locators of the host. Note that this might cause load to be spread unevenly; thus, we use the term "load spreading" instead of "load balancing". This capability might enable some forms of traffic engineering, but the details for traffic engineering, including what requirements can be satisfied, are not specified in this document, and form part of potential extensions to this protocol.
o 利用多个定位器/地址进行负载分配，以便与主机的不同通信集（例如，不同连接）可以使用主机的不同定位器。注意，这可能导致荷载分布不均匀；因此，我们使用术语“负载扩展”而不是“负载平衡”。此功能可能支持某些形式的流量工程，但本文件未规定流量工程的细节，包括可满足的要求，并构成本协议潜在扩展的一部分。
The problem we are trying to solve is site multihoming, with the ability to have the set of site prefixes change over time due to site renumbering. Further, we assume that such changes to the set of locator prefixes can be relatively slow and managed: slow enough to allow updates to the DNS to propagate (since the protocol defined in this document depends on the DNS to find the appropriate locator sets). However, note that it is an explicit non-goal to make communication survive a renumbering event (which causes all the locators of a host to change to a new set of locators). This proposal does not attempt to solve the related problem of host
我们试图解决的问题是站点多宿主，由于站点重新编号，站点前缀集能够随着时间的推移而改变。此外，我们假设对定位器前缀集的此类更改可能会相对缓慢并得到管理：其速度足以允许对DNS的更新传播（因为本文中定义的协议依赖于DNS来找到适当的定位器集）。但是，请注意，让通信在重新编号事件（这会导致主机的所有定位器更改为一组新定位器）后继续存在是一个明确的非目标。本提案并不试图解决主机的相关问题
mobility. However, it might turn out that the Shim6 protocol can be a useful component for future host mobility solutions, e.g., for route optimization.
流动性然而，事实可能证明，对于未来的主机移动性解决方案，例如路由优化，Shim6协议可能是一个有用的组件。
Finally, this proposal also does not try to provide a new network-level or transport-level identifier name space distinct from the current IP address name space. Even though such a concept would be useful to upper-layer protocols (ULPs) and applications, especially if the management burden for such a name space was negligible and there was an efficient yet secure mechanism to map from identifiers to locators, such a name space isn't necessary (and furthermore doesn't seem to help) to solve the multihoming problem.
最后，此建议也不尝试提供与当前IP地址名称空间不同的新网络级别或传输级别标识符名称空间。即使这样的概念对上层协议（ULP）和应用程序很有用，特别是如果这样的名称空间的管理负担可以忽略不计，并且有一种高效而安全的机制将标识符映射到定位器，那么这样的名称空间是不必要的（而且似乎也没有帮助）解决多宿问题。
The Shim6 proposal doesn't fully separate the identifier and locator functions that have traditionally been overloaded in the IP address. However, throughout this document the term "identifier" or, more specifically, upper-layer identifier (ULID), refers to the identifying function of an IPv6 address. "Locator" refers to the network-layer routing and forwarding properties of an IPv6 address.
Shim6提案没有完全分离传统上在IP地址中重载的标识符和定位器功能。然而，在本文档中，术语“标识符”或更具体地说，上层标识符（ULID）指的是IPv6地址的识别功能。“定位器”是指IPv6地址的网络层路由和转发属性。
The approach described in this document does not introduce a new identifier name space but instead uses the locator that is selected in the initial contact with the remote peer as the preserved upper-layer identifier (ULID). While there may be subsequent changes in the selected network-level locators over time (in response to failures in using the original locator), the upper-level protocol stack elements will continue to use this upper-level identifier without change.
本文档中描述的方法没有引入新的标识符名称空间，而是使用在与远程对等方的初始接触中选择的定位器作为保留的上层标识符（ULID）。虽然随着时间的推移，选定的网络级定位器可能会发生后续更改（响应于使用原始定位器的失败），但上层协议栈元素将继续使用该上层标识符，而不会发生更改。
This implies that the ULID selection is performed as today's default address selection as specified in RFC 3484 [7]. Some extensions are needed to RFC 3484 to try different source addresses, whether or not the Shim6 protocol is used, as outlined in [9]. Underneath, and transparently, the multihoming shim selects working locator pairs with the initial locator pair being the ULID pair. If communication subsequently fails, the shim can test and select alternate locators. A subsequent section discusses the issues that arise when the selected ULID is not initially working, which creates the need to switch locators up front.
这意味着按照RFC 3484[7]中的规定，ULID选择作为今天的默认地址选择执行。RFC 3484需要一些扩展来尝试不同的源地址，无论是否使用Shim6协议，如[9]中所述。在下面，多归宿垫片透明地选择工作定位器对，初始定位器对为ULID对。如果随后通信失败，垫片可以测试并选择备用定位器。接下来的一节将讨论所选ULID最初不工作时出现的问题，这需要提前切换定位器。
Using one of the locators as the ULID has certain benefits for applications that have long-lived session state or that perform callbacks or referrals, because both the Fully Qualified Domain Name (FQDN) and the 128-bit ULID work as handles for the applications.
使用其中一个定位器作为ULID对于具有长期会话状态或执行回调或引用的应用程序具有某些好处，因为完全限定域名（FQDN）和128位ULID都可以作为应用程序的句柄。
However, using a single 128-bit ULID doesn't provide seamless communication when that locator is unreachable. See [18] for further discussion of the application implications.
但是，当无法访问定位器时，使用单个128位ULID无法提供无缝通信。有关应用含义的进一步讨论，请参见[18]。
There has been some discussion of using non-routable addresses, such as Unique-Local Addresses (ULAs) [14], as ULIDs in a multihoming solution. While this document doesn't specify all aspects of this, it is believed that the approach can be extended to handle the non-routable address case. For example, the protocol already needs to handle ULIDs that are not initially reachable. Thus, the same mechanism can handle ULIDs that are permanently unreachable from outside their site. The issue becomes how to make the protocol perform well when the ULID is known a priori to be unreachable (e.g., the ULID is a ULA), for instance, avoiding any timeout and retries in this case. In addition, one would need to understand how the ULAs would be entered in the DNS to avoid a performance impact on existing, non-Shim6-aware IPv6 hosts potentially trying to communicate to the (unreachable) ULA.
对于在多宿解决方案中使用不可路由地址（如唯一本地地址（ULA）[14]）作为ULID，已经进行了一些讨论。虽然本文档没有详细说明这方面的所有内容，但相信该方法可以扩展到处理不可路由地址的情况。例如，协议已经需要处理最初无法访问的ulid。因此，相同的机制可以处理从站点外部永久无法访问的ULID。问题在于，当事先知道ULID是不可访问的（例如，ULID是一个ULA）时，如何使协议运行良好，例如，在这种情况下避免任何超时和重试。此外，还需要了解如何在DNS中输入ULA，以避免对可能尝试与（无法访问）ULA通信的现有、不支持Shim6的IPv6主机造成性能影响。
IP multicast requires that the IP Source Address field contain a topologically correct locator for the interface that is used to send the packet, since IP multicast routing uses both the source address and the destination group to determine where to forward the packet. In particular, IP multicast routing needs to be able to do the Reverse Path Forwarding (RPF) check. (This isn't much different than the situation with widely implemented ingress filtering [6] for unicast.)
IP多播要求IP源地址字段包含用于发送数据包的接口的拓扑正确的定位器，因为IP多播路由使用源地址和目标组来确定数据包转发的位置。特别是，IP多播路由需要能够执行反向路径转发（RPF）检查。（这与广泛实施的单播入口过滤[6]的情况没有太大区别。）
While in theory it would be possible to apply the shim re-mapping of the IP address fields between ULIDs and locators, the fact that all the multicast receivers would need to know the mapping to perform makes such an approach difficult in practice. Thus, it makes sense to have multicast ULPs operate directly on locators and not use the shim. This is quite a natural fit for protocols that use RTP [10], since RTP already has an explicit identifier in the form of the synchronization source (SSRC) field in the RTP headers. Thus, the actual IP address fields are not important to the application.
虽然理论上可以在ulid和定位器之间应用IP地址字段的垫片重新映射，但所有多播接收器都需要知道要执行的映射这一事实使得这种方法在实践中很困难。因此，让多播ULP直接在定位器上操作而不使用垫片是有意义的。这非常适合使用RTP的协议[10]，因为RTP已经在RTP头中以同步源（SSRC）字段的形式具有显式标识符。因此，实际的IP地址字段对应用程序并不重要。
In summary, IP multicast will not need the shim to remap the IP addresses.
总之，IP多播不需要垫片来重新映射IP地址。
This doesn't prevent the receiver of multicast to change its locators, since the receiver is not explicitly identified; the destination address is a multicast address and not the unicast locator of the receiver.
这不会阻止多播的接收者更改其定位器，因为接收者没有明确标识；目标地址是多播地址，而不是接收器的单播定位器。
As stated above, this approach does not try to make communication survive renumbering in the general case.
如上所述，这种方法并不试图使通信在一般情况下重新编号后仍然有效。
When a host is renumbered, the effect is that one or more locators become invalid, and zero or more locators are added to the host's network interface. This means that the set of locators that is used in the shim will change, which the shim can handle as long as not all the original locators become invalid at the same time; the shim's ability to handle this also depends on the time that is required to update the DNS and for those updates to propagate.
当主机重新编号时，其效果是一个或多个定位器无效，并且零个或多个定位器添加到主机的网络接口。这意味着垫片中使用的定位器集将发生变化，只要不是所有原始定位器同时失效，垫片就可以处理该变化；垫片处理此问题的能力还取决于更新DNS和传播这些更新所需的时间。
But IP addresses are also used as ULIDs, and making the communication survive locators becoming invalid can potentially cause some confusion at the upper layers. The fact that a ULID might be used with a different locator over time opens up the possibility that communication between two ULIDs might continue to work after one or both of those ULIDs are no longer reachable as locators, for example, due to a renumbering event. This opens up the possibility that the ULID (or at least the prefix on which it is based) may be reassigned to another site while it is still being used (with another locator) for existing communication.
但是IP地址也被用作ULID，使通信定位器失效可能会在上层造成一些混乱。随着时间的推移，一个ULID可能与不同的定位器一起使用，这一事实使得两个ULID之间的通信有可能在一个或两个ULID不再作为定位器时继续工作，例如，由于重新编号事件。这使得ULID（或至少它所基于的前缀）有可能被重新分配到另一个站点，而它仍在（与另一个定位器）用于现有通信。
In the worst case, we could end up with two separate hosts using the same ULID while both of them are communicating with the same host.
在最坏的情况下，当两台主机都在与同一台主机通信时，我们可能会遇到使用相同ULID的两台独立主机。
This potential source for confusion is avoided by requiring that any communication using a ULID MUST be terminated when the ULID becomes invalid (due to the underlying prefix becoming invalid). This behavior can be accomplished by explicitly discarding the shim state when the ULID becomes invalid. The context-recovery mechanism will then make the peer aware that the context is gone and that the ULID is no longer present at the same locator(s).
通过要求在ULID变得无效时（由于基础前缀变得无效），必须终止使用ULID的任何通信，可以避免这种潜在的混淆源。当ULID变得无效时，可以通过显式放弃垫片状态来实现此行为。然后，上下文恢复机制将使对等方意识到上下文已消失，并且ULID不再存在于同一定位器上。
-----------------------
| Transport Protocols |
-----------------------
-----------------------
| Transport Protocols |
-----------------------
-------------- ------------- IP endpoint
| Frag/reass | | Dest opts | sub-layer
-------------- -------------
-------------- ------------- IP endpoint
| Frag/reass | | Dest opts | sub-layer
-------------- -------------
---------------------
| Shim6 shim layer |
---------------------
---------------------
| Shim6 shim layer |
---------------------
------ IP routing
| IP | sub-layer
------
------ IP routing
| IP | sub-layer
------
Figure 1: Protocol Stack
图1：协议栈
The proposal uses a multihoming shim layer within the IP layer, i.e., below the ULPs, as shown in Figure 1, in order to provide ULP independence. The multihoming shim layer behaves as if it is associated with an extension header, which would be placed after any routing-related headers in the packet (such as any hop-by-hop options). However, when the locator pair is the ULID pair, there is no data that needs to be carried in an extension header; thus, none is needed in that case.
如图1所示，该方案在IP层内（即ULP下方）使用多归宿垫片层，以提供ULP独立性。多主垫片层的行为就好像它与扩展头关联一样，扩展头将放在数据包中任何与路由相关的头之后（例如任何逐跳选项）。然而，当定位器对是ULID对时，不存在需要在扩展报头中携带的数据；因此，在这种情况下不需要。
Layering the Fragmentation header above the multihoming shim makes reassembly robust in the case that there is broken multi-path routing that results in using different paths, hence potentially different source locators, for different fragments. Thus, the multihoming shim layer is placed between the IP endpoint sublayer (which handles fragmentation and reassembly) and the IP routing sublayer (which selects the next hop and interface to use for sending out packets).
在多归宿垫片上方分层碎片标头，使得在多路径路由中断导致对不同碎片使用不同路径（因此可能不同的源定位器）的情况下，重新组装具有鲁棒性。因此，多归属垫片层被放置在IP端点子层（处理碎片和重组）和IP路由子层（选择下一跳和用于发送数据包的接口）之间。
Applications and upper-layer protocols use ULIDs that the Shim6 layer maps to/from different locators. The Shim6 layer maintains state, called ULID-pair context, per ULID pair (that is, such state applies to all ULP connections between the ULID pair) in order to perform this mapping. The mapping is performed consistently at the sender and the receiver so that ULPs see packets that appear to be sent using ULIDs from end to end. This property is maintained even though the packets travel through the network containing locators in the IP address fields, and even though those locators may be changed by the transmitting Shim6 layer.
应用程序和上层协议使用ULID，Shim6层映射到不同的定位器或从不同的定位器映射。为了执行此映射，Shim6层维护每个ULID对的状态，称为ULID对上下文（即，这种状态应用于ULID对之间的所有ULP连接）。在发送方和接收方一致地执行映射，以便ULP可以看到似乎是使用ULID从端到端发送的数据包。即使数据包通过包含IP地址字段中的定位器的网络传输，并且即使这些定位器可能被传输层改变，该属性仍然保持。
The context state is maintained per remote ULID, i.e., approximately per peer host, and not at any finer granularity. In particular, the context state is independent of the ULPs and any ULP connections. However, the forking capability enables Shim6-aware ULPs to use more than one locator pair at a time for a single ULID pair.
上下文状态是按每个远程ULID维护的，即大约按每个对等主机维护，而不是按任何更精细的粒度维护。特别是，上下文状态独立于ULP和任何ULP连接。但是，分叉功能使支持Shim6的ULP能够对单个ULID对一次使用多个定位器对。
---------------------------- ----------------------------
| Sender A | | Receiver B |
| | | |
| ULP | | ULP |
| | src ULID(A)=L1(A) | | ^ |
| | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) |
| v | | | dst ULID(B)=L1(B) |
| multihoming shim | | multihoming shim |
| | src L2(A) | | ^ |
| | dst L3(B) | | | src L2(A) |
| v | | | dst L3(B) |
| IP | | IP |
---------------------------- ----------------------------
| ^
------- cloud with some routers -------
---------------------------- ----------------------------
| Sender A | | Receiver B |
| | | |
| ULP | | ULP |
| | src ULID(A)=L1(A) | | ^ |
| | dst ULID(B)=L1(B) | | | src ULID(A)=L1(A) |
| v | | | dst ULID(B)=L1(B) |
| multihoming shim | | multihoming shim |
| | src L2(A) | | ^ |
| | dst L3(B) | | | src L2(A) |
| v | | | dst L3(B) |
| IP | | IP |
---------------------------- ----------------------------
| ^
------- cloud with some routers -------
Figure 2: Mapping with Changed Locators
图2：使用更改的定位器进行映射
The result of this consistent mapping is that there is no impact on the ULPs. In particular, there is no impact on pseudo-header checksums and connection identification.
这种一致映射的结果是对ULP没有影响。特别是，对伪报头校验和和和连接标识没有影响。
Conceptually, one could view this approach as if both ULIDs and locators are present in every packet, and as if a header-compression mechanism is applied that removes the need for the ULIDs to be carried in the packets once the compression state has been established. In order for the receiver to re-create a packet with the correct ULIDs, there is a need to include some "compression tag" in the data packets. This serves to indicate the correct context to use for decompression when the locator pair in the packet is insufficient to uniquely identify the context.
从概念上讲，可以将此方法视为每个分组中都存在ulid和定位器，并且应用了报头压缩机制，一旦建立了压缩状态，就不需要在分组中携带ulid。为了使接收器使用正确的ulid重新创建分组，需要在数据分组中包括一些“压缩标签”。当数据包中的定位器对不足以唯一标识上下文时，这用于指示用于解压缩的正确上下文。
There are different types of interactions between the Shim6 layer and other protocols. Those interactions are influenced by the usage of the addresses in these other protocols and the impact of the Shim6 mapping on these usages. A detailed analysis of the interactions of different protocols, including the Stream Control Transmission Protocol (SCTP), mobile IP (MIP), and Host Identity Protocol (HIP), can be found in [19]. Moreover, some applications may need to have a richer interaction with the Shim6 sublayer. In order to enable that, an API [23] has been defined to enable greater control and information exchange for those applications that need it.
在Shim6层和其他协议之间存在不同类型的交互。这些交互受这些其他协议中地址的使用以及Shim6映射对这些使用的影响。关于不同协议（包括流控制传输协议（SCTP）、移动IP（MIP）和主机标识协议（HIP））的交互作用的详细分析，请参见[19]。此外，一些应用程序可能需要与Shim6子层进行更丰富的交互。为了实现这一点，定义了API[23]，以便为需要它的应用程序提供更好的控制和信息交换。
At the time of this writing, it is not clear what requirements for traffic engineering make sense for the Shim6 protocol, since the requirements must both result in some useful behavior as well as be implementable using a host-to-host locator agility mechanism like Shim6.
在撰写本文时，尚不清楚什么样的流量工程需求对Shim6协议有意义，因为这些需求必须产生一些有用的行为，并且可以使用主机到主机定位器敏捷机制（如Shim6）实现。
Inherent in a scalable multihoming mechanism that separates the locator function of the IP address from identifying function of the IP address is that each host ends up with multiple locators. This means that, at least for initial contact, it is the remote peer application (or layer working on its behalf) that needs to select an initial ULID, which automatically becomes the initial locator. In the case of Shim6, this is performed by applying RFC 3484 address selection.
将IP地址的定位器功能与IP地址的标识功能分离的可伸缩多宿主机制的固有特性是，每个主机最终都有多个定位器。这意味着，至少对于初始联系人，需要选择初始ULID的是远程对等应用程序（或代表其工作的层），该初始ULID自动成为初始定位器。在Shim6的情况下，这是通过应用RFC 3484地址选择来执行的。
This is quite different than the common case of IPv4 multihoming where the site has a single IP address prefix, since in that case the peer performs no destination address selection.
这与IPv4多宿的常见情况大不相同，在IPv4多宿中，站点只有一个IP地址前缀，因为在这种情况下，对等方不执行目标地址选择。
Thus, in "single prefix multihoming", the site (and in many cases its upstream ISPs) can use BGP to exert some control of the ingress path used to reach the site. This capability does not by itself exist in "multiple prefix multihoming" approaches such as Shim6. It is conceivable that extensions allowing site or provider guidance of host-based mechanisms could be developed. But it should be noted that traffic engineering via BGP, MPLS, or other similar techniques can still be applied for traffic on each individual prefix; Shim6 does not remove the capability for this. It does provide some additional capabilities for hosts to choose between prefixes.
因此，在“单前缀多归属”中，站点（以及在许多情况下其上游ISP）可以使用BGP对用于到达站点的入口路径施加某种控制。这种能力本身并不存在于“多前缀多归属”方法中，如Shim6。可以想象，可以开发允许站点或提供商指导基于主机的机制的扩展。但是应该注意，通过BGP、MPLS或其他类似技术的流量工程仍然可以应用于每个前缀上的流量；Shim6不会删除此功能。它确实为主机提供了一些额外的功能来选择前缀。
These capabilities also carry some risk for non-optimal behaviour when more than one mechanism attempts to correct problems at the same time. However, it should be noted that this is not necessarily a situation brought about by Shim6. A more constrained form of this capability already exists in IPv6, itself, via its support of multiple prefixes and address-selection rules for starting new communications. Even IPv4 hosts with multiple interfaces may have limited capabilities to choose interfaces on which they communicate. Similarly, upper layers may choose different addresses.
当多个机制试图同时纠正问题时，这些功能也会带来一些非最优行为的风险。然而，应该注意的是，这不一定是由Shim6带来的情况。IPv6本身已经存在一种更受限制的这种能力，它支持多个前缀和地址选择规则来启动新的通信。即使是具有多个接口的IPv4主机也可能在选择其通信接口方面能力有限。类似地，上层可以选择不同的地址。
In general, it is expected that Shim6 is applicable in relatively small sites and individual hosts where BGP-style traffic engineering operations are unavailable, unlikely, or if run with provider-independent addressing, possibly even harmful, considering the growth rates in the global routing table.
一般来说，考虑到全局路由表中的增长率，预计Shim6适用于相对较小的站点和单个主机，在这些站点和主机中，BGP式流量工程操作不可用、不太可能，或者如果使用独立于提供商的寻址运行，甚至可能有害。
The protocol provides a placeholder, in the form of the Locator Preferences option, that can be used by hosts to express priority and weight values for each locator. This option is merely a placeholder when it comes to providing traffic engineering; in order to use this in a large site, there would have to be a mechanism by which the host can find out what preference values to use, either statically (e.g., some new DHCPv6 option) or dynamically.
该协议以定位器首选项选项的形式提供占位符，主机可以使用该占位符来表示每个定位器的优先级和权重值。当涉及到提供交通工程时，此选项只是一个占位符；为了在大型站点中使用此选项，必须有一种机制，通过该机制，主机可以静态（例如，一些新的DHCPv6选项）或动态地找到要使用的首选项值。
Thus, traffic engineering is listed as a possible extension in Appendix A.
因此，交通工程在附录a中被列为可能的扩展。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This document introduces the following terms:
本文件介绍了以下术语：
upper-layer protocol (ULP) A protocol layer immediately above IP. Examples are transport protocols such as TCP and UDP; control protocols such as ICMP; routing protocols such as OSPF; and Internet or lower-layer protocols being "tunneled" over (i.e., encapsulated in) IP, such as the Internet Packet Exchange (IPX), AppleTalk, or IP itself.
上层协议（ULP）IP之上的协议层。例如TCP和UDP等传输协议；控制协议，如ICMP；路由协议，如OSPF；以及在（即封装在）IP上“隧道”的因特网或较低层协议，例如因特网分组交换（IPX）、AppleTalk或IP本身。
interface A node's attachment to a link.
将节点的附件连接到链接。
address An IP-layer name that both contains topological significance and acts as a unique identifier for an interface. 128 bits. This document only uses the "address" term in the case where it isn't specific whether it is a locator or an identifier.
地址一个IP层名称，它既包含拓扑意义，又充当接口的唯一标识符。128位。本文档仅在“地址”一词不明确是定位器还是标识符的情况下使用。
locator An IP-layer topological name for an interface or a set of interfaces. 128 bits. The locators are carried in the IP address fields as the packets traverse the network.
定位器一个接口或一组接口的IP层拓扑名称。128位。当数据包穿越网络时，定位符被携带在IP地址字段中。
identifier An IP-layer name for an IP-layer endpoint. The transport endpoint name is a function of the transport protocol and would typically include the IP identifier plus a port number.
标识符IP层终结点的IP层名称。传输端点名称是传输协议的函数，通常包括IP标识符和端口号。
NOTE: This proposal does not specify any new form of IP-layer identifier, but still separates the identifying and locating properties of the IP addresses.
注：此方案未指定任何新形式的IP层标识符，但仍将IP地址的标识和定位属性分开。
upper-layer identifier (ULID) An IP address that has been selected for communication with a peer to be used by the upper-layer protocol. 128 bits. This is used for pseudo-header checksum computation and connection identification in the ULP. Different sets of communication to a host (e.g., different connections) might use different ULIDs in order to enable load spreading.
上层标识符（ULID）：已选择用于与上层协议使用的对等方通信的IP地址。128位。这用于ULP中的伪报头校验和计算和连接识别。与主机的不同通信集（例如，不同的连接）可能使用不同的ULID以实现负载分散。
Since the ULID is just one of the IP locators/ addresses of the node, there is no need for a separate name space and allocation mechanisms.
由于ULID只是节点的IP定位器/地址之一，因此不需要单独的名称空间和分配机制。
address field The Source and Destination Address fields in the IPv6 header. As IPv6 is currently specified, these fields carry "addresses". If identifiers and locators are separated, these fields will contain locators for packets on the wire.
地址字段IPv6标头中的源和目标地址字段。由于当前指定了IPv6，这些字段带有“地址”。如果标识符和定位器分开，则这些字段将包含导线上数据包的定位器。
FQDN Fully Qualified Domain Name
FQDN完全限定域名
ULID-pair context The state that the multihoming shim maintains between a pair of upper-layer identifiers. The context is identified by a Context Tag for each direction of the communication and also by a ULID-pair and a Forked Instance Identifier (see below).
ULID对上下文多归宿垫片在一对上层标识符之间保持的状态。上下文由每个通信方向的上下文标记以及ULID对和分叉实例标识符标识（见下文）。
Context Tag Each end of the context allocates a Context Tag for the context. This is used to uniquely associate both received control packets and Shim6 Payload Extension headers as belonging to the context.
上下文标记上下文的每一端都为上下文分配一个上下文标记。这用于将接收到的控制数据包和Shim6有效负载扩展头唯一地关联为属于上下文。
current locator pair Each end of the context has a current locator pair that is used to send packets to the peer. However, the two ends might use different current locator pairs.
当前定位器对上下文的每一端都有一个用于向对等方发送数据包的当前定位器对。但是，两端可能使用不同的当前定位器对。
default context At the sending end, the shim uses the ULID pair (passed down from the ULP) to find the context for that pair. Thus, normally, a host can have at most one context for a ULID pair. We call this the "default context".
默认上下文在发送端，垫片使用ULID对（从ULP向下传递）查找该对的上下文。因此，通常情况下，主机最多可以有一个ULID对的上下文。我们称之为“默认上下文”。
context forking A mechanism that allows ULPs that are aware of multiple locators to use separate contexts for the same ULID pair, in order to be able use different locator pairs for different communication to the same ULID. Context forking causes more than just the default context to be created for a ULID pair.
上下文分叉一种机制，允许知道多个定位器的ULP为同一ULID对使用单独的上下文，以便能够使用不同的定位器对与同一ULID进行不同的通信。上下文分叉导致为ULID对创建的不仅仅是默认上下文。
Forked Instance Identifier (FII) In order to handle context forking, a context is identified by a ULID pair and a Forked Context Identifier. The default context has an FII of zero.
分叉实例标识符（FII）为了处理上下文分叉，上下文由ULID对和分叉上下文标识符标识。默认上下文的FII为零。
initial contact We use this term to refer to the pre-shim communication when a ULP decides to start communicating with a peer by sending and receiving ULP packets. Typically, this would not invoke any operations in the shim, since the shim can defer the context establishment until some arbitrary, later point in time.
初始联系我们使用此术语来指ULP决定通过发送和接收ULP数据包开始与对等方通信时的预垫片通信。通常，这不会调用垫片中的任何操作，因为垫片可以将上下文建立延迟到某个任意的、稍后的时间点。
Hash-Based Addresses (HBA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of all the prefixes assigned to the host. See [3].
基于哈希的地址（HBA）IPv6地址的一种形式，其中接口ID来自分配给主机的所有前缀的加密哈希。见[3]。
Cryptographically Generated Addresses (CGA) A form of IPv6 address where the interface ID is derived from a cryptographic hash of the public key. See [2].
加密生成地址（CGA）IPv6地址的一种形式，其中接口ID来自公钥的加密散列。见[2]。
CGA Parameter Data Structure (PDS) The information that CGA and HBA exchange in order to inform the peer of how the interface ID was computed. See [2] and [3].
CGA参数数据结构（PDS）：CGA和HBA交换的信息，用于通知对等方如何计算接口ID。见[2]和[3]。
A, B, and C are hosts. X is a potentially malicious host.
A、 B和C是主机。X是一个潜在的恶意主机。
FQDN(A) is the Fully Qualified Domain Name for A.
FQDN（A）是A的完全限定域名。
Ls(A) is the locator set for A, which consists of the locators L1(A), L2(A), ... Ln(A). The locator set is not ordered in any particular way other than maybe what is returned by the DNS. A host might form different locator sets containing different subnets of the host's IP addresses. This is necessary in some cases for security reasons. See Section 16.1.
Ls（A）是A的定位器集，由定位器L1（A）、L2（A）和。。。Ln（A）。除了DNS返回的内容外，定位器集没有以任何特定方式排序。主机可能会形成不同的定位器集，其中包含主机IP地址的不同子网。在某些情况下，出于安全原因，这是必要的。见第16.1节。
ULID(A) is an upper-layer identifier for A. In this proposal, ULID(A) is always one member of A's locator set.
ULID（A）是A的上层标识符。在本方案中，ULID（A）始终是A的定位器集的一个成员。
CT(A) is a Context Tag assigned by A.
CT（A）是由A指定的上下文标记。
STATE (in uppercase) refers to the specific state of the state machine described in Section 6.2
状态（大写）是指第6.2节中描述的状态机的特定状态
This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. See Section 6 for a description of the conceptual data structures.
本文档还使用内部概念变量来描述协议行为和实现必须允许系统管理员更改的外部变量。提供特定变量名称、其值如何更改以及其设置如何影响协议行为，以演示协议行为。只要实现的外部行为与本文档中描述的一致，则不要求实现的外部行为与本文中描述的完全相同。有关概念数据结构的描述，请参见第6节。
The design intent is to ensure that the Shim6 protocol is capable of handling path failures independently of the number of IP addresses (locators) available to the two communicating hosts, and independently of which host detects the failure condition.
设计目的是确保Shim6协议能够独立于两台通信主机可用的IP地址（定位器）数量，并独立于哪台主机检测到故障情况，处理路径故障。
Consider, for example, the case in which both A and B have active Shim6 state and where A has only one locator while B has multiple locators. In this case, it might be that B is trying to send a packet to A, and has detected a failure condition with the current locator pair. Since B has multiple locators, it presumably has multiple ISPs, and (consequently) likely has alternate egress paths
例如，考虑A和B都具有活动SHIM6状态的情况，其中A只有一个定位器，而B具有多个定位器。在这种情况下，可能是B正试图向a发送数据包，并且已检测到当前定位器对的故障情况。由于B有多个定位器，它可能有多个ISP，并且（因此）可能有备用出口路径
toward A. B cannot vary the destination address (i.e., A's locator), since A has only one locator. However, B may need to vary the source address in order to ensure packet delivery.
朝向A。B不能改变目的地地址（即A的定位器），因为A只有一个定位器。然而，B可能需要改变源地址以确保分组传送。
In many cases, normal operation of IP routing may cause the packets to follow a path towards the correct (currently operational) egress. In some cases, it is possible that a path may be selected based on the source address, implying that B will need to select a source address corresponding to the currently operating egress. The details of how routing can be accomplished is beyond the scope of this document.
在许多情况下，IP路由的正常操作可能导致分组沿着正确（当前可操作）出口的路径。在一些情况下，可能基于源地址选择路径，这意味着B将需要选择对应于当前操作出口的源地址。如何完成路由的细节超出了本文档的范围。
Also, when the site's ISPs perform ingress filtering based on packet source addresses, Shim6 assumes that packets sent with different source and destination combinations have a reasonable chance of making it through the relevant ISP's ingress filters. This can be accomplished in several ways (all outside the scope of this document), such as having the ISPs relax their ingress filters or selecting the egress such that it matches the IP source address prefix. In the case that one egress path has failed but another is operating correctly, it may be necessary for the packet's source (node B in the previous paragraph) to select a source address that corresponds to the operational egress, in order to pass the ISP's ingress filters.
此外，当站点的ISP根据数据包源地址执行入口过滤时，Shim6假设以不同的源和目的地组合发送的数据包有合理的机会通过相关ISP的入口过滤器。这可以通过几种方式实现（均不在本文档范围内），例如让ISP放松其入口过滤器或选择出口，使其与IP源地址前缀匹配。在一个出口路径失败但另一个出口路径正常运行的情况下，可能需要分组的源（上一段中的节点B）选择对应于操作出口的源地址，以便通过ISP的入口过滤器。
The Shim6 approach assumes that there are no IPv6-to-IPv6 NATs on the paths, i.e., that the two ends can exchange their own notion of their IPv6 addresses and that those addresses will also make sense to their peer.
Shim6方法假设路径上没有IPv6-to-IPv6 NAT，即两端可以交换各自的IPv6地址概念，并且这些地址对对等方也有意义。
The security of the Shim6 protocol relies on the usage of Hash-Based Addresses (HBA) [3] and/or Cryptographically Generated Addresses (CGA) [2]. In the case that HBAs are used, all the addresses assigned to the host that are included in the Shim6 protocol (either as a locator or as a ULID) must be part of the same HBA set. In the case that CGAs are used, the address used as ULID must be a CGA, but the other addresses that are used as locators do not need to be either CGAs or HBAs. It should be noted that it is perfectly acceptable to run the Shim6 protocol between a host that has multiple locators and another host that has a single IP address. In this case, the address of the host with a single address does not need to be an HBA or a CGA.
Shim6协议的安全性依赖于基于哈希的地址（HBA）[3]和/或加密生成的地址（CGA）[2]的使用。在使用HBA的情况下，Shim6协议中包含的分配给主机的所有地址（作为定位器或ULID）必须是同一HBA集的一部分。在使用CGA的情况下，用作ULID的地址必须是CGA，但用作定位器的其他地址不需要是CGA或HBA。应该注意的是，在一个具有多个定位器的主机和另一个具有单个IP地址的主机之间运行Shim6协议是完全可以接受的。在这种情况下，具有单个地址的主机的地址不需要是HBA或CGA。
The Shim6 protocol operates in several phases over time. The following sequence illustrates the concepts:
随着时间的推移，Shim6协议分几个阶段运行。以下顺序说明了这些概念：
o An application on host A decides to contact an application on host B using some upper-layer protocol. This results in the ULP on host A sending packets to host B. We call this the initial contact. Assuming the IP addresses selected by default address selection [7] and its extensions [9] work, then there is no action by the shim at this point in time. Any shim context establishment can be deferred until later.
o 主机A上的应用程序决定使用某种上层协议联系主机B上的应用程序。这导致主机A上的ULP向主机B发送数据包。我们称之为初始接触。假设默认地址选择[7]及其扩展[9]所选择的IP地址正常工作，那么此时垫片没有任何操作。任何shim上下文的建立都可以推迟到以后。
o Some heuristic on A or B (or both) determine that it is appropriate to pay the Shim6 overhead to make this host-to-host communication robust against locator failures. For instance, this heuristic might be that more than 50 packets have been sent or received, or that there was a timer expiration while active packet exchange was in place. This makes the shim initiate the 4-way, context-establishment exchange. The purpose of this heuristic is to avoid setting up a shim context when only a small number of packets is exchanged between two hosts.
o A或B（或两者）上的一些启发式方法确定，支付Shim6开销以使此主机对主机通信对定位器故障具有鲁棒性是合适的。例如，这种启发式可能是发送或接收了50多个数据包，或者在进行活动数据包交换时，计时器过期。这使得垫片启动4路上下文建立交换。此启发式的目的是避免在两台主机之间仅交换少量数据包时设置垫片上下文。
As a result of this exchange, both A and B will know a list of locators for each other.
作为交换的结果，a和B都将知道彼此的定位器列表。
If the context-establishment exchange fails, the initiator will then know that the other end does not support Shim6, and will continue with standard (non-Shim6) behavior for the session.
如果上下文建立交换失败，则发起方将知道另一端不支持Shim6，并将继续会话的标准（非Shim6）行为。
o Communication continues without any change for the ULP packets. In particular, there are no Shim6 Extension headers added to the ULP packets, since the ULID pair is the same as the locator pair. In addition, there might be some messages exchanged between the shim sublayers for (un)reachability detection.
o 通信继续，ULP数据包没有任何变化。特别是，由于ULID对与定位器对相同，因此没有向ULP数据包添加Shim6扩展头。此外，可能会在垫片子层之间交换一些消息以进行（un）可达性检测。
o At some point in time, something fails. Depending on the approach to reachability detection, there might be some advice from the ULP, or the shim (un)reachability detection might discover that there is a problem.
o 在某个时间点，有些东西失败了。根据可达性检测的方法，ULP可能会给出一些建议，或者shim（un）可达性检测可能会发现存在问题。
At this point in time, one or both ends of the communication need to probe the different alternate locator pairs until a working pair is found, and then switch to using that locator pair.
此时，通信的一端或两端需要探测不同的备用定位器对，直到找到工作对，然后切换到使用该定位器对。
o Once a working alternative locator pair has been found, the shim will rewrite the packets on transmit and tag the packets with the Shim6 Payload Extension header, which contains the receiver's
o 一旦找到工作的替代定位器对，垫片将在传输时重写数据包，并使用包含接收器的Shim6有效负载扩展报头标记数据包
Context Tag. The receiver will use the Context Tag to find the context state, which will indicate which addresses to place in the IPv6 header before passing the packet up to the ULP. The result is that, from the perspective of the ULP, the packet passes unmodified end-to-end, even though the IP routing infrastructure sends the packet to a different locator.
上下文标记。接收器将使用上下文标记查找上下文状态，该状态将指示在将数据包向上传递到ULP之前在IPv6报头中放置哪些地址。结果是，从ULP的角度来看，即使IP路由基础设施将数据包发送到不同的定位器，数据包也会在未经修改的情况下端到端地传递。
o The shim (un)reachability detection will monitor the new locator pair as it monitored the original locator pair, so that subsequent failures can be detected.
o 垫片（un）可达性检测将在监控原始定位器对时监控新定位器对，以便检测后续故障。
o In addition to failures detected based on end-to-end observations, one endpoint might know for certain that one or more of its locators is not working. For instance, the network interface might have failed or gone down (at layer 2), or an IPv6 address might have become deprecated or invalid. In such cases, the host can signal its peer that trying this address is no longer recommended. This triggers something similar to a failure handling, and a new working locator pair must be found.
o 除了根据端到端观察检测到的故障外，一个端点可能确定其一个或多个定位器不工作。例如，网络接口可能出现故障或停机（在第2层），或者IPv6地址可能已被弃用或无效。在这种情况下，主机可以通知其对等方不再建议尝试此地址。这会触发类似于故障处理的事件，必须找到新的工作定位器对。
The protocol also has the ability to express other forms of locator preferences. A change in any preference can be signaled to the peer, which will have made the peer record the new preferences. A change in the preferences might optionally make the peer want to use a different locator pair. In this case, the peer follows the same locator switching procedure as after a failure (by verifying that its peer is indeed present at the alternate locator, etc).
该协议还能够表示其他形式的定位器首选项。任何偏好的变化都可以通知对等方，这将使对等方记录新的偏好。首选项的更改可能会使对等方希望使用不同的定位器对。在这种情况下，对等方遵循与故障后相同的定位器切换程序（通过验证其对等方确实存在于备用定位器等）。
o When the shim thinks that the context state is no longer used, it can garbage collect the state; there is no coordination necessary with the peer host before the state is removed. There is a recovery message defined to be able to signal when there is no context state, which can be used to detect and recover from both premature garbage collection as well as from complete state loss (crash and reboot) of a peer.
o 当垫片认为不再使用上下文状态时，它可以对该状态进行垃圾收集；在删除状态之前，无需与对等主机进行协调。有一条恢复消息被定义为在没有上下文状态时能够发出信号，它可用于检测并从过早的垃圾收集以及对等机的完全状态丢失（崩溃和重新启动）中恢复。
The exact mechanism to determine when the context state is no longer used is implementation dependent. For example, an implementation might use the existence of ULP state (where known to the implementation) as an indication that the state is still used, combined with a timer (to handle ULP state that might not be known to the shim sublayer) to determine when the state is likely to no longer be used.
确定何时不再使用上下文状态的确切机制取决于实现。例如，一个实现可以使用ULP状态的存在（在实现已知的情况下）作为该状态仍在使用的指示，并结合计时器（用于处理垫片子层可能不知道的ULP状态）来确定该状态何时可能不再被使用。
NOTE 1: The ULP packets in Shim6 can be carried completely unmodified as long as the ULID pair is used as the locator pair. After a switch to a different locator pair, the packets are "tagged" with a Shim6
注1：只要ULID对用作定位器对，就可以完全不经修改地携带Shim6中的ULP数据包。在切换到不同的定位器对之后，数据包被一个Shim6“标记”
Extension header so that the receiver can always determine the context to which they belong. This is accomplished by including an 8-octet Shim6 Payload Extension header before the (extension) headers that are processed by the IP endpoint sublayer and ULPs. If, subsequently, the original ULIDs are selected as the active locator pair, then the tagging of packets with the Shim6 Extension header is no longer necessary.
扩展标头，以便接收方始终可以确定它们所属的上下文。这是通过在IP端点子层和ULPs处理的（扩展）报头之前包含一个8-octet Shim6有效负载扩展报头来实现的。如果随后选择原始ulid作为活动定位器对，则不再需要使用Shim6扩展头标记数据包。
A context between two hosts is actually a context between two ULIDs. The context is identified by a pair of Context Tags. Each end gets to allocate a Context Tag, and once the context is established, most Shim6 control messages contain the Context Tag that the receiver of the message allocated. Thus, at a minimum, the combination of <peer ULID, local ULID, local Context Tag> have to uniquely identify one context. But, since the Shim6 Payload Extension headers are demultiplexed without looking at the locators in the packet, the receiver will need to allocate Context Tags that are unique for all its contexts. The Context Tag is a 47-bit number (the largest that can fit in an 8-octet extension header), while preserving one bit to differentiate the Shim6 signaling messages from the Shim6 header included in data packets, allowing both to use the same protocol number.
两个主机之间的上下文实际上是两个ulid之间的上下文。上下文由一对上下文标记标识。每个端点都可以分配一个上下文标记，一旦建立了上下文，大多数Shim6控制消息都包含消息接收方分配的上下文标记。因此，至少，<peer ULID，local ULID，local Context Tag>的组合必须唯一地标识一个上下文。但是，由于在不查看数据包中的定位器的情况下解复用了Shim6有效负载扩展报头，因此接收器将需要分配对其所有上下文唯一的上下文标记。上下文标记是一个47位的数字（8-octet扩展报头中可以容纳的最大数字），同时保留一位以区分数据包中包含的Shim6信令消息和Shim6报头，允许两者使用相同的协议号。
The mechanism for detecting a loss of context state at the peer assumes that the receiver can tell the packets that need locator rewriting, even after it has lost all state (e.g., due to a crash followed by a reboot). This is achieved because, after a rehoming event, the packets that need receive-side rewriting carry the Shim6 Payload Extension header.
用于在对等端检测上下文状态丢失的机制假设接收器可以告知需要定位器重写的数据包，即使在其丢失所有状态之后（例如，由于崩溃之后重新启动）。这是因为，在重新命名事件之后，需要接收端重写的数据包携带Shim6有效负载扩展报头。
It has been asserted that it will be important for future ULPs -- in particular, future transport protocols -- to be able to control which locator pairs are used for different communication. For instance, host A and host B might communicate using both Voice over IP (VoIP) traffic and ftp traffic, and those communications might benefit from using different locator pairs. However, the basic Shim6 mechanism uses a single current locator pair for each context; thus, a single context cannot accomplish this.
有人断言，未来的ULP——特别是未来的传输协议——能够控制哪些定位器对用于不同的通信将是非常重要的。例如，主机A和主机B可能同时使用IP语音（VoIP）通信和ftp通信进行通信，并且这些通信可能受益于使用不同的定位器对。然而，基本的Shim6机制对每个上下文使用单个当前定位器对；因此，单一环境无法实现这一点。
For this reason, the Shim6 protocol supports the notion of context forking. This is a mechanism by which a ULP can specify (using some API not yet defined) that a context, e.g., the ULID pair <A1, B2>,
因此，Shim6协议支持上下文分叉的概念。这是一种机制，通过该机制，ULP可以指定（使用一些尚未定义的API）上下文，例如ULID对<A1，B2>，
should be forked into two contexts. In this case, the forked-off context will be assigned a non-zero Forked Instance Identifier, while the default context has FII zero.
应该分为两种情况。在这种情况下，分叉上下文将被分配一个非零分叉实例标识符，而默认上下文的FII为零。
The Forked Instance Identifier (FII) is a 32-bit identifier that has no semantics in the protocol other than being part of the tuple that identifies the context. For example, a host might allocate FIIs as sequential numbers for any given ULID pair.
分叉实例标识符（FII）是一个32位标识符，在协议中除了作为标识上下文的元组的一部分之外没有任何语义。例如，主机可能会将FII分配为任何给定ULID对的序列号。
No other special considerations are needed in the Shim6 protocol to handle forked contexts.
在Shim6协议中不需要其他特殊考虑来处理分叉上下文。
Note that forking as specified does NOT allow A to be able to tell B that certain traffic (a 5-tuple?) should be forked for the reverse direction. The Shim6 forking mechanism as specified applies only to the sending of ULP packets. If some ULP wants to fork for both directions, it is up to the ULP to set this up and then instruct the shim at each end to transmit using the forked context.
请注意，指定的分叉不允许A告诉B某些流量（5元组？）应该为反向分叉。指定的Shim6分叉机制仅适用于ULP数据包的发送。如果某个ULP想要在两个方向上进行分叉，则由ULP设置此设置，然后指示每端的垫片使用分叉上下文进行传输。
Several API extensions have been discussed for Shim6, but their actual specification is out of scope for this document. The simplest one would be to add a socket option to be able to have traffic bypass the shim (not create any state and not use any state created by other traffic). This could be an IPV6_DONTSHIM socket option. Such an option would be useful for protocols, such as DNS, where the application has its own failover mechanism (multiple NS records in the case of DNS) and using the shim could potentially add extra latency with no added benefits.
已经讨论了Shim6的几个API扩展，但它们的实际规范超出了本文档的范围。最简单的方法是添加一个socket选项，使流量绕过垫片（不创建任何状态，也不使用其他流量创建的任何状态）。这可能是一个IPV6\u DONTSHIM套接字选项。这样的选项对于协议（如DNS）非常有用，因为应用程序有自己的故障切换机制（在DNS的情况下有多个NS记录），使用垫片可能会增加额外的延迟，而不会带来额外的好处。
Some other API extensions are discussed in Appendix A. The actual API extensions are defined in [23].
附录A中讨论了其他一些API扩展。实际的API扩展在[23]中定义。
The mechanisms are secured using a combination of techniques:
这些机构采用多种技术进行固定：
o The HBA technique [3] for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else.
o HBA技术[3]，用于验证定位器，以防止攻击者将数据包流重定向到其他地方。
o Requiring a Reachability Probe+Reply (defined in [4]) before a new locator is used as the destination, in order to prevent 3rd party flooding attacks.
o 在将新定位器用作目的地之前，需要可达性探测+应答（定义见[4]），以防止第三方洪泛攻击。
o The first message does not create any state on the responder. Essentially, a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all memory on the responder) at least provides an IPv6 address that the attacker was using.
o 第一条消息不会在响应程序上创建任何状态。本质上，在响应者创建任何状态之前，需要进行三方交换。这意味着基于状态的DoS攻击（试图耗尽响应程序上的所有内存）至少提供了攻击者正在使用的IPv6地址。
o The context-establishment messages use nonces to prevent replay attacks and to prevent off-path attackers from interfering with the establishment.
o 上下文建立消息使用nonce来防止重播攻击，并防止非路径攻击者干扰建立。
o Every control message of the Shim6 protocol, past the context establishment, carries the Context Tag assigned to the particular context. This implies that an attacker needs to discover that Context Tag before being able to spoof any Shim6 control message. Such discovery probably requires any potential attacker to be along the path in order to sniff the Context Tag value. The result is that through this technique, the Shim6 protocol is protected against off-path attackers.
o Shim6协议的每个控制消息经过上下文建立后，都携带分配给特定上下文的上下文标记。这意味着攻击者需要先发现该上下文标记，然后才能伪造任何Shim6控制消息。这种发现可能需要任何潜在的攻击者沿着路径进行，以便嗅探上下文标记值。结果是，通过这种技术，Shim6协议受到保护，不受非路径攻击者的攻击。
The Shim6 context establishment is accomplished using four messages; I1, R1, I2, R2. Normally, they are sent in that order from initiator and responder, respectively. Should both ends attempt to set up context state at the same time (for the same ULID pair), then their I1 messages might cross in flight, and result in an immediate R2 message. (The names of these messages are borrowed from HIP [20].)
使用四条消息完成了Shim6上下文的建立；I1，R1，I2，R2。通常，它们分别从发起方和响应方按该顺序发送。如果两端同时尝试设置上下文状态（对于同一ULID对），则它们的I1消息可能会在飞行中交叉，并立即生成R2消息。（这些信息的名称借用自HIP[20]。）
R1bis and I2bis messages are defined; they are used to recover a context after it has been lost. An R1bis message is sent when a Shim6 control or Shim6 Payload Extension header arrives and there is no matching context state at the receiver. When such a message is received, it will result in the re-creation of the Shim6 context using the I2bis and R2 messages.
定义了R1bis和I2bis消息；它们用于在上下文丢失后恢复上下文。当Shim6控件或Shim6有效负载扩展报头到达且接收方没有匹配的上下文状态时，将发送R1bis消息。当收到此类消息时，将导致使用I2bis和R2消息重新创建Shim6上下文。
The peers' lists of locators are normally exchanged as part of the context-establishment exchange. But the set of locators might be dynamic. For this reason, there are Update Request and Update Acknowledgement messages as well as a Locator List option.
对等方的定位器列表通常作为上下文建立交换的一部分进行交换。但是定位器集可能是动态的。因此，存在更新请求和更新确认消息以及定位器列表选项。
Even when the list of locators is fixed, a host might determine that some preferences might have changed. For instance, it might determine that there is a locally visible failure that implies that some locator(s) are no longer usable. This uses a Locator Preferences option in the Update Request message.
即使定位器列表是固定的，主机也可能会确定某些首选项可能已更改。例如，它可能确定存在本地可见的故障，这意味着某些定位器不再可用。这将在更新请求消息中使用定位器首选项选项。
The mechanism for (un)reachability detection is called Forced Bidirectional Communication (FBD). FBD uses a Keepalive message which is sent when a host has received packets from its peer but has not yet sent any packets from its ULP to the peer. The message type is reserved in this document, but the message format and processing rules are specified in [4].
用于（非）可达性检测的机制称为强制双向通信（FBD）。FBD使用Keepalive消息，当主机已从其对等方接收到数据包，但尚未从其ULP向对等方发送任何数据包时，将发送该消息。本文档中保留了消息类型，但在[4]中指定了消息格式和处理规则。
In addition, when the context is established and there is a subsequent failure, there needs to be a way to probe the set of locator pairs to efficiently find a working pair. This document reserves a Probe message type, with the packet format and processing rules specified in [4].
此外，当建立上下文并且随后出现故障时，需要有一种方法来探测定位器对集，以高效地找到工作对。本文档保留探测消息类型，数据包格式和处理规则如[4]所述。
The above Probe and Keepalive messages assume we have an established ULID-pair context. However, communication might fail during the initial contact (that is, when the application or transport protocol is trying to set up some communication). This is handled using the mechanisms in the ULP to try different address pairs as specified in [7] and [9]. In future versions of the protocol, and with a richer API between the ULP and the shim, the shim might be able to help optimize discovering a working locator pair during initial contact. This is for further study.
上面的探测和Keepalive消息假设我们有一个已建立的ULID对上下文。但是，在初始接触期间（即，当应用程序或传输协议尝试设置某些通信时），通信可能会失败。这是使用ULP中的机制来处理的，以尝试[7]和[9]中指定的不同地址对。在该协议的未来版本中，由于ULP和垫片之间的API更丰富，垫片可能有助于优化在初始接触期间发现工作定位器对。这是为了进一步研究。
Since the shim is placed between the IP endpoint sublayer and the IP routing sublayer, the Shim header will be placed before any Endpoint Extension headers (Fragmentation headers, Destination Options header, AH, ESP) but after any routing-related headers (Hop-by-Hop Extensions header, Routing header, and a Destinations Options header, which precedes a Routing header). When tunneling is used, whether IP-in-IP tunneling or the special form of tunneling that Mobile IPv6 uses (with Home Address options and Routing header type 2), there is a choice whether the shim applies inside the tunnel or outside the tunnel, which affects the location of the Shim6 header.
由于垫片位于IP端点子层和IP路由子层之间，因此垫片头将放在任何端点扩展头（碎片头、目标选项头、AH、ESP）之前，但放在任何路由相关头之后（逐跳扩展标头、路由标头和位于路由标头之前的目的地选项标头）。使用隧道时，无论是IP-in-IP隧道还是移动IPv6使用的特殊形式的隧道（带有家庭地址选项和路由标头类型2），可以选择是在通道内部还是通道外部使用垫片，这会影响Shim6收割台的位置。
In most cases, IP-in-IP tunnels are used as a routing technique; thus, it makes sense to apply them on the locators, which means that the sender would insert the Shim6 header after any IP-in-IP encapsulation. This is what occurs naturally when routers apply IP-in-IP encapsulation. Thus, the packets would have:
在大多数情况下，IP隧道中的IP被用作路由技术；因此，在定位器上应用它们是有意义的，这意味着发送方将在任何IP-in-IP封装之后插入Shim6头。这是路由器在IP封装中应用IP时自然发生的情况。因此，分组将具有：
o Outer IP header
o 外部IP报头
o Inner IP header
o 内部IP报头
o Shim6 Extension header (if needed)
o Shim6扩展头（如果需要）
o ULP
o ULP
But the shim can also be used to create "shimmed tunnels", i.e., where an IP-in-IP tunnel uses the shim to be able to switch the tunnel endpoint addresses between different locators. In such a case, the packets would have:
但垫片也可用于创建“垫片隧道”，即IP-in-IP隧道使用垫片能够在不同定位器之间切换隧道端点地址。在这种情况下，分组将具有：
o Outer IP header
o 外部IP报头
o Shim6 Extension header (if needed)
o Shim6扩展头（如果需要）
o Inner IP header
o 内部IP报头
o ULP
o ULP
In any case, the receiver behavior is well-defined; a receiver processes the Extension headers in order. However, the precise interaction between Mobile IPv6 and Shim6 is for further study; it might make sense to have Mobile IPv6 operate on locators as well, meaning that the shim would be layered on top of the MIPv6 mechanism.
在任何情况下，接收者的行为都是明确定义的；接收方按顺序处理扩展头。然而，移动IPv6和Shim6之间的精确交互有待进一步研究；让移动IPv6也在定位器上运行可能是有意义的，这意味着垫片将分层在MIPv6机制之上。
The Shim6 messages are all carried using a new IP protocol number (140). The Shim6 messages have a common header (defined below) with some fixed fields, followed by type-specific fields.
Shim6消息都使用新的IP协议号（140）进行传输。Shim6消息有一个公共标头（定义如下），其中包含一些固定字段，后跟特定于类型的字段。
The Shim6 messages are structured as an IPv6 Extension header since the Shim6 Payload Extension header is used to carry the ULP packets after a locator switch. The Shim6 control messages use the same extension header formats so that a single "protocol number" needs to be allowed through firewalls in order for Shim6 to function across the firewall.
Shim6消息被构造为IPv6扩展头，因为Shim6有效负载扩展头用于在定位器切换之后承载ULP数据包。Shim6控制消息使用相同的扩展头格式，因此需要允许一个“协议号”通过防火墙，以便Shim6在防火墙上运行。
The first 17 bits of the Shim6 header is common for the Shim6 Payload Extension header and for the control messages. It looks as follows:
Shim6报头的前17位对于Shim6有效负载扩展报头和控制消息是公共的。情况如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: The payload that follows this header.
下一个收割台：跟随此收割台的有效负载。
Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 8-octet units, not including the first 8 octets.
Hdr Ext Len:8位无符号整数。Shim6标头的长度，以8个八位字节为单位，不包括前8个八位字节。
P: A single bit to distinguish Shim6 Payload Extension headers from control messages.
P：用于区分Shim6有效负载扩展头和控制消息的单个位。
Shim6 signaling packets may not be larger than 1280 bytes, including the IPv6 header and any intermediate headers between the IPv6 header and the Shim6 header. One way to meet this requirement is to omit part of the locator address information if, with this information included, the packet would become larger than 1280 bytes. Another option is to perform option engineering, dividing into different Shim6 messages the information to be transmitted. An implementation may impose administrative restrictions to avoid excessively large Shim6 packets, such as a limitation on the number of locators to be used.
Shim6信令数据包不得大于1280字节，包括IPv6报头以及IPv6报头和Shim6报头之间的任何中间报头。满足此要求的一种方法是省略定位器地址信息的一部分，如果包含此信息，则数据包将变得大于1280字节。另一个选项是执行选项工程，将要传输的信息划分为不同的Shim6消息。实现可以施加管理限制以避免过大的Shim6分组，例如对要使用的定位器的数量的限制。
The Shim6 Payload Extension header is used to carry ULP packets where the receiver must replace the content of the Source and/or Destination fields in the IPv6 header before passing the packet to the ULP. Thus, this extension header is required when the locator pair that is used is not the same as the ULID pair.
Shim6有效负载扩展报头用于承载ULP数据包，其中接收器必须在将数据包传递给ULP之前替换IPv6报头中的源和/或目标字段的内容。因此，当所使用的定位器对与ULID对不同时，需要此扩展标头。
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 | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 0 |1| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: The payload that follows this header.
下一个收割台：跟随此收割台的有效负载。
Hdr Ext Len: 0 (since the header is 8 octets).
Hdr Ext Len:0（因为标头是8个八位字节）。
P: Set to one. A single bit to distinguish this from the Shim6 control messages.
P:设为1。用于将其与Shim6控制消息区分开来的单个位。
Receiver Context Tag: 47-bit unsigned integer. Allocated by the receiver to identify the context.
接收器上下文标记：47位无符号整数。由接收方分配以标识上下文。
The common part of the header has a Next Header field and a Header Extension Length field that are consistent with the other IPv6 Extension headers, even if the Next Header value is always "NO NEXT HEADER" for the control messages.
报头的公共部分具有与其他IPv6扩展报头一致的下一个报头字段和报头扩展长度字段，即使控制消息的下一个报头值始终为“无下一个报头”。
The Shim6 headers must be a multiple of 8 octets; hence, the minimum size is 8 octets.
Shim6报头必须是8个八位字节的倍数；因此，最小大小为8个八位字节。
The common Shim6 Control message header is as follows:
常见的Shim6控制消息头如下所示：
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 |P| Type |Type-specific|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type-specific format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |P| Type |Type-specific|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Type-specific format |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: 8-bit selector. Normally set to NO_NXT_HDR (59).
下一个标题：8位选择器。通常设置为NO_NXT_HDR（59）。
Hdr Ext Len: 8-bit unsigned integer. Length of the Shim6 header in 8-octet units, not including the first 8 octets.
Hdr Ext Len:8位无符号整数。Shim6标头的长度，以8个八位字节为单位，不包括前8个八位字节。
P: Set to zero. A single bit to distinguish this from the Shim6 Payload Extension header.
P:设置为零。用于将其与Shim6有效负载扩展标头区分开来的单个位。
Type: 7-bit unsigned integer. Identifies the actual message from the table below. Type codes 0-63 will not trigger R1bis messages on a missing context, while codes 64-127 will trigger R1bis.
类型：7位无符号整数。标识下表中的实际消息。类型代码0-63不会触发缺失上下文上的R1bis消息，而代码64-127将触发R1bis。
S: A single bit set to zero that allows Shim6 and HIP to have a common header format yet still distinguishes between Shim6 and HIP messages.
S：一个设置为零的单个位，允许Shim6和HIP具有一个通用的头格式，但仍然可以区分Shim6和HIP消息。
Checksum: 16-bit unsigned integer. The checksum is the 16-bit one's complement of the one's complement sum of the entire Shim6 header message, starting with the Shim6
校验和：16位无符号整数。校验和是从Shim6开始的整个Shim6头消息的16位一的补码和
Next Header field and ending as indicated by the Hdr Ext Len. Thus, when there is a payload following the Shim6 header, the payload is NOT included in the Shim6 checksum. Note that, unlike protocols like ICMPv6, there is no pseudo-header checksum part of the checksum; this provides locator agility without having to change the checksum.
下一个标题字段和结尾由Hdr Ext Len指示。因此，当在Shim6报头之后存在有效负载时，该有效负载不包括在Shim6校验和中。注意，与ICMPv6等协议不同，校验和中没有伪报头校验和部分；这提供了无需更改校验和的定位器灵活性。
Type-specific: Part of the message that is different for different message types.
类型特定：消息的一部分，对于不同的消息类型是不同的。
+------------+----------------------------------------------------+
| Type Value | Message |
+------------+----------------------------------------------------+
| 1 | I1 (1st establishment message from the initiator) |
| 2 | R1 (1st establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to an R1bis message) |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
+------------+----------------------------------------------------+
+------------+----------------------------------------------------+
| Type Value | Message |
+------------+----------------------------------------------------+
| 1 | I1 (1st establishment message from the initiator) |
| 2 | R1 (1st establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to an R1bis message) |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
+------------+----------------------------------------------------+
Table 1
表1
The I1 message is the first message in the context-establishment exchange.
I1消息是上下文建立交换中的第一条消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 1 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 1
类型：1
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
启动器上下文标记：47位字段。启动器已为上下文分配的上下文标记。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R1 message.
启动器Nonce:32位无符号整数。发起者选择的随机数，响应者将在R1消息中返回。
The following options are defined for this message:
为此消息定义了以下选项：
ULID pair: When the IPv6 source and destination addresses in the IPv6 header does not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context.
ULID对：当IPv6标头中的IPv6源地址和目标地址与ULID对不匹配时，必须包含此选项。从丢失的上下文中恢复时就是一个例子。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one.
分叉实例标识符：当创建具有相同ULID对的现有上下文的另一个实例时，必须包含分叉实例标识符选项，以区分此新实例与现有实例。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
The R1 message is the second message in the context-establishment exchange. The responder sends this in response to an I1 message, without creating any state specific to the initiator.
R1消息是上下文建立交换中的第二条消息。响应者发送此消息以响应I1消息，而不创建特定于启动器的任何状态。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 2 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 2
类型：2
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Reserved2: 16-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
Reserved2：16位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Initiator Nonce: 32-bit unsigned integer. Copied from the I1 message.
启动器Nonce:32位无符号整数。从I1消息复制。
Responder Nonce: 32-bit unsigned integer. A number picked by the responder, which the initiator will return in the I2 message.
响应程序Nonce:32位无符号整数。响应程序拾取的数字，启动器将在I2消息中返回该数字。
The following options are defined for this message:
为此消息定义了以下选项：
Responder Validator: Variable length option. This option MUST be included in the R1 message. Typically, it contains a hash generated by the responder, which the responder uses together with the Responder Nonce value to verify that an I2 message is indeed sent in response to an R1 message, and that the parameters in the I2 message are the same as those in the I1 message.
响应者验证程序：可变长度选项。此选项必须包含在R1消息中。通常，它包含由响应程序生成的哈希，响应程序将其与响应程序Nonce值一起使用，以验证I2消息确实是响应R1消息而发送的，并且I2消息中的参数与I1消息中的参数相同。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
The I2 message is the third message in the context-establishment exchange. The initiator sends this in response to an R1 message, after checking the Initiator Nonce, etc.
I2消息是上下文建立交换中的第三条消息。在检查启动器Nonce等之后，启动器发送此消息以响应R1消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 3 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 2, since the header is 24 octets when there are no options.
Hdr Ext Len：至少2个，因为在没有选项时，报头是24个八位字节。
Type: 3
类型：3
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
启动器上下文标记：47位字段。启动器已为上下文分配的上下文标记。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R2 message.
启动器Nonce:32位无符号整数。发起者选择的随机数，响应者将在R2消息中返回。
Responder Nonce: 32-bit unsigned integer. Copied from the R1 message.
响应程序Nonce:32位无符号整数。从R1消息复制。
Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the options start on a multiple of 8 octet boundary.)
Reserved2:32位字段。保留供将来使用。传输时为零。必须在收到时忽略。（需要使选项在8个八位组的倍数边界上开始。）
The following options are defined for this message:
为此消息定义了以下选项：
Responder Validator: Variable length option. This option MUST be included in the I2 message and MUST be generated by copying the Responder Validator option received in the R1 message.
响应者验证程序：可变长度选项。此选项必须包含在I2消息中，并且必须通过复制R1消息中接收到的响应者验证程序选项来生成。
ULID pair: When the IPv6 source and destination addresses in the IPv6 header do not match the ULID pair, this option MUST be included. An example of this is when recovering from a lost context.
ULID对：当IPv6标头中的IPv6源地址和目标地址与ULID对不匹配时，必须包括此选项。从丢失的上下文中恢复时就是一个例子。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option MUST be included to distinguish this new instance from the existent one.
分叉实例标识符：当创建具有相同ULID对的现有上下文的另一个实例时，必须包含分叉实例标识符选项，以区分此新实例与现有实例。
Locator List: Optionally sent when the initiator immediately wants to tell the responder its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
定位器列表：当发起方立即想要告诉响应方其定位器列表时，可以选择发送定位器列表。发送时，还必须包括用于验证定位器列表的必要HBA/CGA信息。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
定位器首选项：当定位器的首选项不一致时，可以选择发送。
CGA Parameter Data Structure: This option MUST be included in the I2 message when the locator list is included so the receiver can verify the locator list.
CGA参数数据结构：当包含定位器列表时，此选项必须包含在I2消息中，以便接收方可以验证定位器列表。
CGA Signature: This option MUST be included in the I2 message when some of the locators in the list use CGA (and not HBA) for verification.
CGA签名：当列表中的某些定位器使用CGA（而不是HBA）进行验证时，I2消息中必须包含此选项。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
The R2 message is the fourth message in the context-establishment exchange. The responder sends this in response to an I2 message. The R2 message is also used when both hosts send I1 messages at the same time and the I1 messages cross in flight.
R2消息是上下文建立交换中的第四条消息。响应者发送此消息以响应I2消息。当两台主机同时发送I1消息且I1消息在飞行中交叉时，也会使用R2消息。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Responder Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 4 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Responder Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 4
类型：4
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Responder Context Tag: 47-bit field. The Context Tag that the responder has allocated for the context.
响应程序上下文标记：47位字段。响应程序为上下文分配的上下文标记。
Initiator Nonce: 32-bit unsigned integer. Copied from the I2 message.
启动器Nonce:32位无符号整数。从I2消息复制。
The following options are defined for this message:
为此消息定义了以下选项：
Locator List: Optionally sent when the responder immediately wants to tell the initiator its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
定位器列表：当响应者立即想要告诉启动器其定位器列表时，可以选择发送。发送时，还必须包括用于验证定位器列表的必要HBA/CGA信息。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
定位器首选项：当定位器的首选项不一致时，可以选择发送。
CGA Parameter Data Structure: Included when the locator list is included so the receiver can verify the locator list.
CGA参数数据结构：包括定位器列表时包括，以便接收方可以验证定位器列表。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGA签名：当列表中的某些定位器使用CGA（而不是HBA）进行验证时，会包含CGA签名。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
Should a host receive a packet with a Shim6 Payload Extension header or Shim6 control message with type code 64-127 (such as an Update or Probe message), and the host does not have any context state for the received Context Tag, then it will generate a R1bis message.
如果主机接收到带有Shim6有效负载扩展头的数据包或类型代码为64-127的Shim6控制消息（例如更新或探测消息），并且主机没有任何接收到的上下文标记的上下文状态，则它将生成R1bis消息。
This message allows the sender of the packet referring to the non-existent context to re-establish the context with a reduced context-establishment exchange. Upon the reception of the R1bis message, the receiver can proceed with re-establishing the lost context by directly sending an I2bis message.
此消息允许引用不存在上下文的数据包的发送方通过减少的上下文建立交换重新建立上下文。在接收到R1bis消息后，接收器可以通过直接发送I2bis消息来继续重建丢失的上下文。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 5 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 5 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 5
类型：5
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Packet Context Tag: 47-bit unsigned integer. The Context Tag contained in the received packet that triggered the generation of the R1bis message.
数据包上下文标记：47位无符号整数。接收到的数据包中包含的上下文标记，用于触发R1bis消息的生成。
Responder Nonce: 32-bit unsigned integer. A number picked by the responder which the initiator will return in the I2bis message.
响应程序Nonce:32位无符号整数。响应程序拾取的数字，启动器将在I2bis消息中返回该数字。
The following options are defined for this message:
为此消息定义了以下选项：
Responder Validator: Variable length option. Typically, a hash generated by the responder, which the responder uses together with the Responder Nonce value to verify that an I2bis message is indeed sent in response to an R1bis message.
响应者验证程序：可变长度选项。通常，由响应程序生成的哈希，响应程序将其与响应程序Nonce值一起使用，以验证是否确实发送了I2bis消息以响应R1bis消息。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
The I2bis message is the third message in the context-recovery exchange. This is sent in response to an R1bis message, after checking that the R1bis message refers to an existing context, etc.
I2bis消息是上下文恢复交换中的第三条消息。这是在检查R1bis消息是否引用现有上下文等后，作为对R1bis消息的响应而发送的。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 6 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Initiator Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Packet Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 3, since the header is 32 octets when there are no options.
Hdr Ext Len：至少3个，因为在没有选项时，报头是32个八位字节。
Type: 6
类型：6
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Initiator Context Tag: 47-bit field. The Context Tag that the initiator has allocated for the context.
启动器上下文标记：47位字段。启动器已为上下文分配的上下文标记。
Initiator Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the responder will return in the R2 message.
启动器Nonce:32位无符号整数。发起者选择的随机数，响应者将在R2消息中返回。
Responder Nonce: 32-bit unsigned integer. Copied from the R1bis message.
响应程序Nonce:32位无符号整数。从R1bis消息复制。
Reserved2: 49-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Note that 17 bits are not sufficient since the options need to start on a multiple-of-8-octet boundary.)
Reserved2:49位字段。保留供将来使用。传输时为零。必须在收到时忽略。（请注意，17位是不够的，因为选项需要在8个八位组的多个边界上启动。）
Packet Context Tag: 47-bit unsigned integer. Copied from the Packet Context Tag field contained in the received R1bis.
数据包上下文标记：47位无符号整数。从接收到的R1bis中包含的数据包上下文标记字段复制。
The following options are defined for this message:
为此消息定义了以下选项：
Responder Validator: Variable length option. Just a copy of the Responder Validator option in the R1bis message.
响应者验证程序：可变长度选项。只是R1bis消息中响应者验证程序选项的副本。
ULID pair: When the IPv6 source and destination addresses in the IPv6 header do not match the ULID pair, this option MUST be included.
ULID对：当IPv6标头中的IPv6源地址和目标地址与ULID对不匹配时，必须包括此选项。
Forked Instance Identifier: When another instance of an existent context with the same ULID pair is being created, a Forked Instance Identifier option is included to distinguish this new instance from the existent one.
分叉实例标识符：当创建具有相同ULID对的现有上下文的另一个实例时，将包括分叉实例标识符选项，以区分此新实例与现有实例。
Locator List: Optionally sent when the initiator immediately wants to tell the responder its list of locators. When it is sent, the necessary HBA/CGA information for verifying the locator list MUST also be included.
定位器列表：当发起方立即想要告诉响应方其定位器列表时，可以选择发送定位器列表。发送时，还必须包括用于验证定位器列表的必要HBA/CGA信息。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
定位器首选项：当定位器的首选项不一致时，可以选择发送。
CGA Parameter Data Structure: Included when the locator list is included so the receiver can verify the locator list.
CGA参数数据结构：包括定位器列表时包括，以便接收方可以验证定位器列表。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGA签名：当列表中的某些定位器使用CGA（而不是HBA）进行验证时，会包含CGA签名。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
The Update Request message is used to update either the list of locators, the locator preferences, or both. When the list of locators is updated, the message also contains the option(s) necessary for HBA/CGA to secure this. The basic sanity check that prevents off-path attackers from generating bogus updates is the Context Tag in the message.
更新请求消息用于更新定位器列表和/或定位器首选项。更新定位器列表时，该消息还包含HBA/CGA保护此定位器所需的选项。防止非路径攻击者生成虚假更新的基本健全性检查是消息中的上下文标记。
The Update Request message contains options (the Locator List and the Locator Preferences) that, when included, completely replace the previous locator list and locator preferences, respectively. Thus, there is no mechanism to just send deltas to the locator list.
更新请求消息包含选项（定位器列表和定位器首选项），包括这些选项后，将分别完全替换以前的定位器列表和定位器首选项。因此，不存在只向定位器列表发送增量的机制。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 64 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 64 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 64
类型：64
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Receiver Context Tag: 47-bit field. The Context Tag that the receiver has allocated for the context.
接收器上下文标记：47位字段。接收方已为上下文分配的上下文标记。
Request Nonce: 32-bit unsigned integer. A random number picked by the initiator, which the peer will return in the Update Acknowledgement message.
请求Nonce:32位无符号整数。发起方选择的随机数，对等方将在更新确认消息中返回。
The following options are defined for this message:
为此消息定义了以下选项：
Locator List: The list of the sender's (new) locators. The locators might be unchanged and only the preferences have changed.
定位器列表：发件人（新）定位器的列表。定位器可能未更改，只有首选项已更改。
Locator Preferences: Optionally sent when the locators don't all have equal preference.
定位器首选项：当定位器的首选项不一致时，可以选择发送。
CGA Parameter Data Structure (PDS): Included when the locator list is included and the PDS was not included in the I2/ I2bis/R2 messages, so the receiver can verify the locator list.
CGA参数数据结构（PDS）：包含定位器列表时包含，而PDS未包含在I2/I2bis/R2消息中，因此接收方可以验证定位器列表。
CGA Signature: Included when some of the locators in the list use CGA (and not HBA) for verification.
CGA签名：当列表中的某些定位器使用CGA（而不是HBA）进行验证时，会包含CGA签名。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
This message is sent in response to an Update Request message. It implies that the Update Request has been received and that any new locators in the Update Request can now be used as the source locators of packets. But it does not imply that the (new) locators have been verified to be used as a destination, since the host might defer the verification of a locator until it sees a need to use a locator as the destination.
此消息是响应更新请求消息发送的。这意味着已接收到更新请求，并且更新请求中的任何新定位器现在都可以用作数据包的源定位器。但这并不意味着（新）定位器已被验证为用作目的地，因为主机可能会推迟定位器的验证，直到它发现需要使用定位器作为目的地。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 65 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 65 | Reserved1 |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum |R| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Receiver Context Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Options +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets when there are no options.
Hdr Ext Len：至少1，因为在没有选项时，头是16个八位字节。
Type: 65
类型：65
Reserved1: 7-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
保留1：7位字段。保留供将来使用。传输时为零。必须在收到时忽略。
R: 1-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt.
R：1位字段。保留供将来使用。传输时为零。必须在收到时忽略。
Receiver Context Tag: 47-bit field. The Context Tag the receiver has allocated for the context.
接收器上下文标记：47位字段。接收方为上下文分配的上下文标记。
Request Nonce: 32-bit unsigned integer. Copied from the Update Request message.
请求Nonce:32位无符号整数。从更新请求消息复制。
No options are currently defined for this message.
当前未为此邮件定义任何选项。
Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation. See Section 5.15.
未来的协议扩展可能会为此消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。见第5.15节。
This message format is defined in [4].
此消息格式在[4]中定义。
The message is used to ensure that when a peer is sending ULP packets on a context, it always receives some packets in the reverse direction. When the ULP is sending bidirectional traffic, no extra packets need to be inserted. But for a unidirectional ULP traffic pattern, the shim will send back some Keepalive messages when it is receiving ULP packets.
该消息用于确保当对等方在上下文上发送ULP数据包时，它总是以相反的方向接收一些数据包。当ULP发送双向流量时，不需要插入额外的数据包。但是，对于单向ULP通信模式，垫片在接收ULP数据包时会发回一些保留消息。
This message and its semantics are defined in [4].
此消息及其语义在[4]中有定义。
The goal of this mechanism is to test whether or not locator pairs work in the general case. In particular, this mechanism is to be able to handle the case when one locator pair works from A to B and another locator pair works from B to A, but there is no locator pair that works in both directions. The protocol mechanism is that, as A is sending Probe messages to B, B will observe which locator pairs it has received and report that back in Probe messages it sends to A.
该机制的目标是测试定位器对在一般情况下是否工作。特别地，该机制能够处理一个定位器对从A到B工作，另一个定位器对从B到A工作，但没有在两个方向上工作的定位器对的情况。协议机制是，当A向B发送探测消息时，B将观察它接收到的定位器对，并在发送给A的探测消息中报告。
The Error message is generated by a Shim6 receiver upon the reception of a Shim6 message containing critical information that cannot be processed properly.
错误消息由Shim6接收器在接收到包含无法正确处理的关键信息的Shim6消息时生成。
In the case that a Shim6 node receives a Shim6 packet that contains information that is critical for the Shim6 protocol and that is not supported by the receiver, it sends an Error Message back to the originator of the Shim6 message. The Error message is unacknowledged.
如果Shim6节点接收到包含对Shim6协议至关重要且接收器不支持的信息的Shim6数据包，则它会将错误消息发送回Shim6消息的发起人。错误消息未被确认。
In addition, Shim6 Error messages defined in this section can be used to identify problems with Shim6 implementations. In order to do so, a range of Error Code types is reserved for that purpose. In particular, implementations may generate Shim6 Error messages with Code types in that range, instead of silently discarding Shim6 packets during the debugging process.
此外，本节中定义的Shim6错误消息可用于识别Shim6实现中的问题。为此，保留了一系列错误代码类型。具体而言，实现可能会生成代码类型在该范围内的Shim6错误消息，而不是在调试过程中自动丢弃Shim6数据包。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 68 | Error Code |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Packet in error +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 59 | Hdr Ext Len |0| Type = 68 | Error Code |0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Packet in error +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Next Header: NO_NXT_HDR (59).
下一个标题：NO_NXT_HDR（59）。
Hdr Ext Len: At least 1, since the header is 16 octets. Depends on the specific Error Data.
Hdr Ext Len：至少1，因为标头是16个八位字节。取决于具体的错误数据。
Type: 68
类型：68
Error Code: 7-bit field describing the error that generated the Error message. See Error Code list below.
错误代码：描述生成错误消息的错误的7位字段。请参阅下面的错误代码列表。
Pointer: 16-bit field. Identifies the octet offset within the invoking packet where the error was detected.
指针：16位字段。标识检测到错误的调用数据包内的八位字节偏移量。
Packet in error: As much of invoking packet as possible without the Error message packet exceeding the minimum IPv6 MTU.
数据包出错：在错误消息数据包不超过最小IPv6 MTU的情况下，尽可能多地调用数据包。
The following Error Codes are defined:
定义了以下错误代码：
+---------+---------------------------------------------------------+
| Code | Description |
| Value | |
+---------+---------------------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical option not recognized |
| 2 | Locator verification method failed (Pointer to the |
| | inconsistent verification method octet) |
| 3 | Locator List Generation number out of sync. |
| 4 | Error in the number of locators in a Locator Preference |
| | option |
| 120-127 | Reserved for debugging purposes |
+---------+---------------------------------------------------------+
+---------+---------------------------------------------------------+
| Code | Description |
| Value | |
+---------+---------------------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical option not recognized |
| 2 | Locator verification method failed (Pointer to the |
| | inconsistent verification method octet) |
| 3 | Locator List Generation number out of sync. |
| 4 | Error in the number of locators in a Locator Preference |
| | option |
| 120-127 | Reserved for debugging purposes |
+---------+---------------------------------------------------------+
Table 2
表2
The format of the options is a snapshot of the current HIP option format [20]. However, there is no intention to track any changes to the HIP option format, nor is there an intent to use the same name space for the option type values. But using the same format will hopefully make it easier to import HIP capabilities into Shim6 as extensions to Shim6, should this turn out to be useful.
选项的格式是当前HIP选项格式的快照[20]。但是，无意跟踪HIP选项格式的任何更改，也无意为选项类型值使用相同的名称空间。但是使用相同的格式将有助于将HIP功能作为对Shim6的扩展导入到Shim6中，如果这被证明是有用的话。
All of the TLV parameters have a length (including Type and Length fields) that is a multiple of 8 bytes. When needed, padding MUST be added to the end of the parameter so that the total length becomes a multiple of 8 bytes. This rule ensures proper alignment of data. If padding is added, the Length field MUST NOT include the padding. Any added padding bytes MUST be zeroed by the sender, and their values SHOULD NOT be checked by the receiver.
所有TLV参数的长度（包括类型和长度字段）都是8字节的倍数。需要时，必须将填充添加到参数的末尾，以便总长度为8字节的倍数。此规则确保数据的正确对齐。如果添加了填充，则长度字段不得包含填充。任何添加的填充字节必须由发送方归零，接收方不应检查其值。
Consequently, the Length field indicates the length of the Contents field (in bytes). The total length of the TLV parameter (including Type, Length, Contents, and Padding) is related to the Length field according to the following formula:
因此，长度字段指示内容字段的长度（以字节为单位）。TLV参数的总长度（包括类型、长度、内容和填充）根据以下公式与长度字段相关：
Total Length = 11 + Length - (Length + 3) mod 8;
Total Length = 11 + Length - (Length + 3) mod 8;
The total length of the option is the smallest multiple of 8 bytes that allows for the 4 bytes of the Option header and option, itself. The amount of padding required can be calculated as follows:
选项的总长度是8个字节中的最小倍数，允许选项头和选项本身的4个字节。所需的填充量可按如下方式计算：
padding = 7 - ((Length + 3) mod 8)
padding = 7 - ((Length + 3) mod 8)
And:
以及：
Total Length = 4 + Length + padding
Total Length = 4 + Length + padding
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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Contents ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |C| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ Contents ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Type: 15-bit identifier of the type of option. The options defined in this document are below.
类型：选项类型的15位标识符。本文件中定义的选项如下。
C: Critical. One, if this parameter is critical and MUST be recognized by the recipient; zero otherwise. An implementation might view the C-bit as part of the Type field by multiplying the type values in this specification by two.
C:很关键。第一，如果此参数是关键参数，并且必须由接收方识别；否则为零。实现可以通过将本规范中的类型值乘以2，将C位视为类型字段的一部分。
Length: Length of the Contents, in bytes.
长度：内容的长度，以字节为单位。
Contents: Parameter-specific, defined by Type.
内容：参数特定，按类型定义。
Padding: Padding, 0-7 bytes, added if needed.
填充：填充，0-7字节，根据需要添加。
+------+------------------------------+
| Type | Option Name |
+------+------------------------------+
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 10 | Keepalive Timeout Option |
+------+------------------------------+
+------+------------------------------+
| Type | Option Name |
+------+------------------------------+
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 10 | Keepalive Timeout Option |
+------+------------------------------+
Table 3
表3
Future protocol extensions might define additional options for the Shim6 messages. The C-bit in the option format defines how such a new option will be handled by an implementation.
未来的协议扩展可能会为Shim6消息定义其他选项。选项格式中的C位定义了实现如何处理此类新选项。
If a host receives an option that it does not understand (an option that was defined in some future extension to this protocol) or that is not listed as a valid option for the different message types above, then the Critical bit in the option determines the outcome.
如果主机接收到一个它不理解的选项（该选项在该协议的某个未来扩展中定义）或未列为上述不同消息类型的有效选项，则该选项中的关键位决定结果。
o If C=0, then the option is silently ignored, and the rest of the message is processed.
o 如果C=0，则该选项将被静默忽略，并处理消息的其余部分。
o If C=1, then the host SHOULD send back a Shim6 Error message with Error Code=1, with the Pointer field referencing the first octet in the Option Type field. When C=1, the rest of the message MUST NOT be processed.
o 如果C=1，则主机应返回一条错误代码为1的Shim6错误消息，指针字段引用选项类型字段中的第一个八位字节。当C=1时，不得处理消息的其余部分。
The responder can choose exactly what input is used to compute the validator and what one-way function (such as MD5 or SHA1) it uses, as long as the responder can check that the validator it receives back in the I2 or I2bis message is indeed one that:
只要响应者能够检查它在I2或I2bis消息中收到的验证程序是否确实是一个：
1) computed,
1) 计算，
2) computed for the particular context, and
2) 针对特定上下文计算，以及
3) isn't a replayed I2/I2bis message.
3) 不是重播的I2/I2bis消息。
Some suggestions on how to generate the validators are captured in Sections 7.10.1 and 7.17.1.
第7.10.1节和第7.17.1节提供了一些关于如何生成验证器的建议。
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 = 1 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Validator ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 1 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Validator ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Validator: Variable length content whose interpretation is local to the responder.
验证程序：长度可变的内容，其解释对响应者来说是本地的。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
填充：填充，0-7字节，根据需要添加。见第5.15节。
The Locator List option is used to carry all the locators of the sender. Note that the order of the locators is important, since the Locator Preferences option refers to the locators by using the index in the list.
定位器列表选项用于携带发件人的所有定位器。请注意，定位器的顺序很重要，因为定位器首选项选项通过使用列表中的索引来引用定位器。
Note that we carry all the locators in this option even though some of them can be created automatically from the CGA Parameter Data Structure.
请注意，我们在该选项中包含所有定位器，即使其中一些定位器可以从CGA参数数据结构自动创建。
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 = 2 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Locators | N Octets of Verification Method |
+-+-+-+-+-+-+-+-+ |
~ ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Locators 1 through N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 2 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Locators | N Octets of Verification Method |
+-+-+-+-+-+-+-+-+ |
~ ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Locators 1 through N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Locator List Generation: 32-bit unsigned integer. Indicates a generation number that is increased by one for each new locator list. This is used to ensure that the index in the Locator Preferences refers to the right version of the locator list.
定位器列表生成：32位无符号整数。指示为每个新定位器列表增加一个的生成编号。这用于确保定位器首选项中的索引引用定位器列表的正确版本。
Num Locators: 8-bit unsigned integer. The number of locators that are included in the option. We call this number "N" below.
Num定位器：8位无符号整数。包含在选项中的定位器的数量。下面我们称这个号码为“N”。
Verification Method: N octets. The ith octet specifies the verification method for the ith locator.
验证方法：N个八位字节。第i个八位字节指定了第i个定位器的验证方法。
Padding: Padding, 0-7 bytes, added if needed so that the Locators start on a multiple-of-8-octet boundary. Note that for this option, there is never a need to pad at the end since the Locators are a multiple-of-8- octets in length. This internal padding is included in the Length field.
Padding：填充，0-7字节，如果需要添加，以便定位器从8个八位组的多个边界开始。请注意，对于此选项，永远不需要在末尾填充，因为定位器的长度是8个八位元的倍数。此内部填充包含在长度字段中。
Locators: N 128-bit locators.
定位器：N 128位定位器。
The defined verification methods are:
定义的验证方法包括：
+---------+----------------------------------+
| Value | Method |
+---------+----------------------------------+
| 0 | Reserved |
| 1 | HBA |
| 2 | CGA |
| 3-200 | Allocated using Standards action |
| 201-254 | Experimental use |
| 255 | Reserved |
+---------+----------------------------------+
+---------+----------------------------------+
| Value | Method |
+---------+----------------------------------+
| 0 | Reserved |
| 1 | HBA |
| 2 | CGA |
| 3-200 | Allocated using Standards action |
| 201-254 | Experimental use |
| 255 | Reserved |
+---------+----------------------------------+
Table 4
表4
The Locator Preferences option can have some flags to indicate whether or not a locator is known to work. In addition, the sender can include a notion of preferences. It might make sense to define "preferences" as a combination of priority and weight, the same way that DNS SRV records have such information. The priority would provide a way to rank the locators, and, within a given priority, the weight would provide a way to do some load sharing. See [5] for how SRV defines the interaction of priority and weight.
Locator Preferences选项可以有一些标志来指示是否已知定位器工作。此外，发送方可以包含偏好的概念。将“首选项”定义为优先级和权重的组合可能是有意义的，与DNS SRV记录具有此类信息的方式相同。优先级将提供一种对定位器进行排序的方法，在给定优先级内，权重将提供一种进行负载共享的方法。有关SRV如何定义优先级和权重的交互作用，请参见[5]。
The minimum notion of preferences we need is to be able to indicate that a locator is "dead". We can handle this using a single octet flag for each locator.
我们需要的偏好的最低概念是能够指示定位器“死了”。我们可以为每个定位器使用一个八位组标志来处理这个问题。
We can extend that by carrying a larger "element" for each locator. This document presently also defines 2-octet and 3-octet elements, and we can add more information by having even larger elements if need be.
我们可以通过为每个定位器携带一个更大的“元素”来扩展它。本文档目前还定义了2-octet和3-octet元素，如果需要，我们可以通过使用更大的元素来添加更多信息。
The locators are not included in the preference list. Instead, the first element refers to the locator that was in the first element in the Locator List option. The generation number carried in this option and the Locator List option is used to verify that they refer to the same version of the locator list.
定位器不包括在首选项列表中。相反，第一个元素是指定位器列表选项中第一个元素中的定位器。此选项和定位器列表选项中包含的生成编号用于验证它们是否引用了相同版本的定位器列表。
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 = 3 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Len | Element[1] | Element[2] | Element[3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 3 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator List Generation |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element Len | Element[1] | Element[2] | Element[3] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Case of Element Len = 1 is depicted.
描述了元素Len＝1的情况。
Fields:
领域：
Locator List Generation: 32-bit unsigned integer. Indicates a generation number for the locator list to which the elements should apply.
定位器列表生成：32位无符号整数。指示元素应应用到的定位器列表的生成编号。
Element Len: 8-bit unsigned integer. The length in octets of each element. This specification defines the cases when the length is 1, 2, or 3.
元素Len：8位无符号整数。每个元素的长度（以八位字节为单位）。本规范定义了长度为1、2或3的情况。
Element[i]: A field with a number of octets defined by the Element Len field. Provides preferences for the ith locator in the Locator List option that is in use.
元素[i]：包含由元素Len字段定义的八位字节数的字段。为正在使用的定位器列表选项中的第i个定位器提供首选项。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
填充：填充，0-7字节，根据需要添加。见第5.15节。
When the Element length equals one, then the element consists of only a one-octet Flags field. The currently defined set of flags are:
当元素长度等于1时，元素仅由一个八位字节标志字段组成。当前定义的标志集包括：
BROKEN: 0x01
断开：0x01
TRANSIENT: 0x02
瞬态：0x02
The intent of the BROKEN flag is to inform the peer that a given locator is known to be not working. The intent of TRANSIENT is to allow the distinction between more stable addresses and less stable addresses when Shim6 is combined with IP mobility, and when we might have more stable home locators and less stable care-of-locators.
断开标志的目的是通知对等方已知给定定位器不工作。TRANSIENT的目的是，当Shim6与IP移动性结合时，以及当我们可能有更稳定的家庭定位器和更不稳定的托管定位器时，允许区分更稳定的地址和更不稳定的地址。
When the Element length equals two, then the element consists of a one-octet Flags field followed by a one-octet Priority field. This Priority field has the same semantics as the Priority field in DNS SRV records.
当元素长度等于2时，元素由一个八位字节标志字段和一个八位字节优先级字段组成。此优先级字段与DNS SRV记录中的优先级字段具有相同的语义。
When the Element length equals three, then the element consists of a one-octet Flags field followed by a one-octet Priority field and a one-octet Weight field. This Weight field has the same semantics as the Weight field in DNS SRV records.
当元素长度等于3时，元素由一个八位字节标志字段、一个八位字节优先级字段和一个八位字节权重字段组成。此权重字段与DNS SRV记录中的权重字段具有相同的语义。
This document doesn't specify the format when the Element length is more than three, except that any such formats MUST be defined so that the first three octets are the same as in the above case, that is, a one-octet Flags field followed by a one-octet Priority field, and a one-octet Weight field.
当元素长度大于三时，本文档不指定格式，除非必须定义任何此类格式，以便前三个八位字节与上述情况相同，即，一个八位字节标志字段后跟一个八位字节优先级字段，以及一个八位字节权重字段。
This option contains the CGA Parameter Data Structure (PDS). When HBA is used to verify the locators, the PDS contains the HBA multiprefix extension in addition to the PDS mandatory fields and other extensions unrelated to Shim6 that the PDS might have. When CGA is used to verify the locators, in addition to the PDS option, the host also needs to include the signature in the form of a CGA Signature option.
此选项包含CGA参数数据结构（PDS）。当使用HBA验证定位器时，PDS除了包含PDS必填字段和PDS可能具有的与Shim6无关的其他扩展之外，还包含HBA multiprefix扩展。当使用CGA验证定位器时，除了PDS选项外，主机还需要以CGA签名选项的形式包含签名。
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 = 4 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Parameter Data Structure ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 4 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Parameter Data Structure ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
CGA Parameter Data Structure: Variable length content. Content defined in [2] and [3].
CGA参数数据结构：可变长度内容。[2]和[3]中定义的内容。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
填充：填充，0-7字节，根据需要添加。见第5.15节。
When CGA is used for verification of one or more of the locators in the Locator List option, then the message in question will need to contain this option.
当CGA用于验证定位器列表选项中的一个或多个定位器时，相关消息将需要包含此选项。
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 = 5 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Signature ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 5 |0| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ CGA Signature ~
~ +-+-+-+-+-+-+-+-+
~ | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
CGA Signature: A variable-length field containing a PKCS#1 v1.5 signature, constructed by using the sender's private key over the following sequence of octets:
CGA签名：包含PKCS#1 v1.5签名的可变长度字段，使用发送方的私钥在以下八位字节序列上构造：
1. The 128-bit CGA Message Type tag [CGA] value for Shim6: 0x4A 30 5662 4858 574B 3655 416F 506A 6D48. (The tag value has been generated randomly by the editor of this specification.).
1. Shim6的128位CGA消息类型标记[CGA]值：0x4A 30 5662 4858 574B 3655 416F 506A 6D48。（标签值是由本规范的编辑器随机生成的。）。
2. The Locator List Generation number of the correspondent Locator List option.
2. 对应定位器列表选项的定位器列表生成编号。
3. The subset of locators included in the correspondent Locator List option whose verification method is set to CGA. The locators MUST be included in the order in which they are listed in the Locator List Option.
3. 对应定位器列表选项中包含的定位器子集，其验证方法设置为CGA。定位器必须按照在定位器列表选项中列出的顺序包含。
Padding: Padding, 0-7 bytes, added if needed. See Section 5.15.
填充：填充，0-7字节，根据需要添加。见第5.15节。
I1, I2, and I2bis messages MUST contain the ULID pair; normally, this is in the IPv6 Source and Destination fields. In case the ULID for the context differs from the address pair included in the Source and Destination Address fields of the IPv6 packet used to carry the I1/ I2/I2bis message, the ULID Pair option MUST be included in the I1/I2/ I2bis message.
I1、I2和I2bis消息必须包含ULID对；通常，这在IPv6源和目标字段中。如果上下文的ULID与用于承载I1/I2/I2bis消息的IPv6数据包的源地址和目标地址字段中包含的地址对不同，则必须在I1/I2/I2bis消息中包含ULID对选项。
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 = 6 |0| Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sender ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receiver ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 6 |0| Length = 36 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sender ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Receiver ULID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Reserved2: 32-bit field. Reserved for future use. Zero on transmit. MUST be ignored on receipt. (Needed to make the ULIDs start on a multiple-of-8-octet boundary.)
Reserved2:32位字段。保留供将来使用。传输时为零。必须在收到时忽略。（需要使ULID在8个八位组的多个边界上启动。）
Sender ULID: A 128-bit IPv6 address.
发送方ULID：128位IPv6地址。
Receiver ULID: A 128-bit IPv6 address.
接收器ULID：128位IPv6地址。
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 = 7 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forked Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 7 |0| Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forked Instance Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
领域：
Forked Instance Identifier: 32-bit field containing the identifier of the particular forked instance.
分叉实例标识符：包含特定分叉实例标识符的32位字段。
This option is defined in [4].
此选项在[4]中定义。
This section describes a conceptual model of one possible data structure organization that hosts will maintain for the purposes of Shim6. The described organization is provided to facilitate the explanation of how the Shim6 protocol should behave. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
本节描述了一个可能的数据结构组织的概念模型，主机将为Shim6维护该组织。提供所述组织是为了便于解释Shim6协议的行为方式。本文档并不要求实现遵守此模型，只要其外部行为与本文档中描述的一致。
The key conceptual data structure for the Shim6 protocol is the ULID-pair context. This is a data structure that contains the following information:
Shim6协议的关键概念数据结构是ULID对上下文。这是一个包含以下信息的数据结构：
o The state of the context. See Section 6.2.
o 上下文的状态。见第6.2节。
o The peer ULID: ULID(peer).
o 对等ULID:ULID（peer）。
o The local ULID: ULID(local).
o 本地ULID:ULID（local）。
o The Forked Instance Identifier: FII. This is zero for the default context, i.e., when there is no forking.
o 分叉实例标识符：FII。对于默认上下文，即没有分叉时，该值为零。
o The list of peer locators with their preferences: Ls(peer).
o 对等定位器及其首选项的列表：Ls（对等）。
o The generation number for the most recently received, verified peer locator list.
o 最近接收的、已验证的对等定位器列表的生成编号。
o For each peer locator, the verification method to use (from the Locator List option).
o 对于每个对等定位器，使用的验证方法（从定位器列表选项）。
o For each peer locator, a flag specifying whether it has been verified using HBA or CGA, and a bit specifying whether the locator has been probed to verify that the ULID is present at that location.
o 对于每个对等定位器，一个标志指定是否已使用HBA或CGA对其进行了验证，一个位指定是否已探测定位器以验证该位置是否存在ULID。
o The current peer locator is the locator used as the destination address when sending packets: Lp(peer).
o 当前对等定位器是发送数据包时用作目标地址的定位器：Lp（对等）。
o The set of local locators and the preferences: Ls(local).
o 本地定位器集和首选项：Ls（本地）。
o The generation number for the most recently sent Locator List option.
o 最近发送的定位器列表选项的生成编号。
o The current local locator is the locator used as the source address when sending packets: Lp(local).
o 当前本地定位器是发送数据包时用作源地址的定位器：Lp（本地）。
o The Context Tag used to transmit control messages and Shim6 Payload Extension headers; this is allocated by the peer: CT(peer).
o 用于传输控制消息和Shim6有效负载扩展头的上下文标记；这由对等方分配：CT（对等方）。
o The context to expect in received control messages and Shim6 Payload Extension headers; this is allocated by the local host: CT(local).
o 接收到的控制消息和Shim6有效负载扩展头中预期的上下文；这是由本地主机分配的：CT（本地）。
o Timers for retransmission of the messages during context-establishment and update messages.
o 用于在上下文建立和更新消息期间重新传输消息的计时器。
o Depending how an implementation determines whether a context is still in use, there might be a need to track the last time a packet was sent/received using the context.
o 根据实现如何确定上下文是否仍在使用，可能需要跟踪上次使用上下文发送/接收数据包的时间。
o Reachability state for the locator pairs as specified in [4].
o [4]中规定的定位器对的可达性状态。
o During pair exploration, information about the Probe messages that have been sent and received as specified in [4].
o 在对探索期间，按照[4]中的规定发送和接收的有关探测消息的信息。
o During context-establishment phase, the Initiator Nonce, Responder Nonce, Responder Validator, and timers related to the different packets sent (I1,I2, R2), as described in Section 7.
o 在上下文建立阶段，发起方Nonce、响应方Nonce、响应方验证器和与发送的不同数据包（I1、I2、R2）相关的计时器，如第7节所述。
The STATES that are used to describe the Shim6 protocol are as follows:
用于描述Shim6协议的国家如下：
+---------------------+---------------------------------------------+
| STATE | Explanation |
+---------------------+---------------------------------------------+
| IDLE | State machine start |
| | |
| I1-SENT | Initiating context-establishment exchange |
| | |
| I2-SENT | Waiting to complete context-establishment |
| | exchange |
| | |
| I2BIS-SENT | Potential context loss detected |
| | |
| ESTABLISHED | SHIM context established |
| | |
| E-FAILED | Context-establishment exchange failed |
| | |
| NO-SUPPORT | ICMP Unrecognized Next Header type |
| | (type 4, code 1) received, indicating |
| | that Shim6 is not supported |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| STATE | Explanation |
+---------------------+---------------------------------------------+
| IDLE | State machine start |
| | |
| I1-SENT | Initiating context-establishment exchange |
| | |
| I2-SENT | Waiting to complete context-establishment |
| | exchange |
| | |
| I2BIS-SENT | Potential context loss detected |
| | |
| ESTABLISHED | SHIM context established |
| | |
| E-FAILED | Context-establishment exchange failed |
| | |
| NO-SUPPORT | ICMP Unrecognized Next Header type |
| | (type 4, code 1) received, indicating |
| | that Shim6 is not supported |
+---------------------+---------------------------------------------+
In addition, in each of the aforementioned STATES, the following state information is stored:
此外，在上述每个状态中，存储以下状态信息：
+---------------------+---------------------------------------------+
| STATE | Information |
+---------------------+---------------------------------------------+
| IDLE | None |
| | |
| I1-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, Lp(local), Lp(peer), Ls(local) |
| | |
| I2-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, RESP Nonce, Lp(local), Lp(peer),|
| | Ls(local), Responder Validator |
| | |
| ESTABLISHED | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), INIT Nonce?(to receive late R2) |
| | |
| I2BIS-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), CT(R1bis), RESP Nonce, |
| | INIT Nonce, Responder Validator |
| | |
| E-FAILED | ULID(peer), ULID(local) |
| | |
| NO-SUPPORT | ULID(peer), ULID(local) |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| STATE | Information |
+---------------------+---------------------------------------------+
| IDLE | None |
| | |
| I1-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, Lp(local), Lp(peer), Ls(local) |
| | |
| I2-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | INIT Nonce, RESP Nonce, Lp(local), Lp(peer),|
| | Ls(local), Responder Validator |
| | |
| ESTABLISHED | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), INIT Nonce?(to receive late R2) |
| | |
| I2BIS-SENT | ULID(peer), ULID(local), [FII], CT(local), |
| | CT(peer), Lp(local), Lp(peer), Ls(local), |
| | Ls(peer), CT(R1bis), RESP Nonce, |
| | INIT Nonce, Responder Validator |
| | |
| E-FAILED | ULID(peer), ULID(local) |
| | |
| NO-SUPPORT | ULID(peer), ULID(local) |
+---------------------+---------------------------------------------+
ULID-pair contexts are established using a 4-way exchange, which allows the responder to avoid creating state on the first packet. As part of this exchange, each end allocates a Context Tag and shares this Context Tag and its set of locators with the peer.
ULID对上下文是使用4路交换建立的，这允许响应者避免在第一个数据包上创建状态。作为交换的一部分，每一端分配一个上下文标记，并与对等方共享该上下文标记及其定位器集。
In some cases, the 4-way exchange is not necessary -- for instance, when both ends try to set up the context at the same time, or when recovering from a context that has been garbage collected or lost at one of the hosts.
在某些情况下，4路交换是不必要的——例如，当两端同时尝试设置上下文时，或者当从某个主机上已被垃圾收集或丢失的上下文中恢复时。
As part of establishing a new context, each host has to assign a unique Context Tag. Since the Shim6 Payload Extension headers are demultiplexed based solely on the Context Tag value (without using the locators), the Context Tag MUST be unique for each context.
作为建立新上下文的一部分，每个主机必须分配一个唯一的上下文标记。由于Shim6有效负载扩展头仅基于上下文标记值（不使用定位器）进行解复用，因此上下文标记对于每个上下文都必须是唯一的。
It is important that Context Tags are hard to guess for off-path attackers. Therefore, if an implementation uses structure in the Context Tag to facilitate efficient lookups, at least 30 bits of the Context Tag MUST be unstructured and populated by random or pseudo-random bits.
对于非路径攻击者来说，上下文标记很难猜测，这一点很重要。因此，如果实现使用上下文标记中的结构来促进高效查找，则上下文标记中至少30位必须是非结构化的，并且由随机或伪随机位填充。
In addition, in order to minimize the reuse of Context Tags, the host SHOULD randomly cycle through the unstructured tag name space that is reserved for randomly assigned Context Tag values (e.g., following the guidelines described in [13]).
此外，为了最大限度地减少上下文标记的重用，主机应在为随机分配的上下文标记值保留的非结构化标记名称空间中随机循环（例如，遵循[13]中描述的指南）。
The peer's locators might need to be verified during context establishment as well as when handling locator updates in Section 10.
在上下文建立期间以及在第10节中处理定位器更新时，可能需要验证对等方的定位器。
There are two separate aspects of locator verification. One is to verify that the locator is tied to the ULID, i.e., that the host that "owns" the ULID is also the one that is claiming the locator "ownership". The Shim6 protocol uses the HBA or CGA techniques for doing this verification. The other aspect is to verify that the host is indeed reachable at the claimed locator. Such verification is needed not only to make sure communication can proceed but also to prevent 3rd party flooding attacks [15]. These different aspects of locator verification happen at different times since the first might need to be performed before packets can be received by the peer with the source locator in question, but the latter verification is only needed before packets are sent to the locator.
定位器验证有两个独立的方面。一个是验证定位器是否绑定到ULID，即“拥有”ULID的主机也是声称定位器“所有权”的主机。Shim6协议使用HBA或CGA技术进行验证。另一个方面是验证主机确实可以在声明的定位器处访问。这种验证不仅是为了确保通信能够继续进行，而且也是为了防止第三方洪水攻击[15]。定位器验证的这些不同方面发生在不同的时间，因为第一个验证可能需要在具有所讨论的源定位器的对等方能够接收到分组之前执行，但是后一个验证仅在分组被发送到定位器之前需要。
Before a host can use a locator (different than the ULID) as the source locator, it must know that the peer will accept packets with that source locator as part of this context. Thus, the HBA/CGA verification SHOULD be performed by the host before the host acknowledges the new locator by sending either an Update Acknowledgement message or an R2 message.
在主机可以使用定位器（不同于ULID）作为源定位器之前，它必须知道对等方将接受带有该源定位器的数据包作为该上下文的一部分。因此，主机应在通过发送更新确认消息或R2消息确认新定位器之前执行HBA/CGA验证。
Before a host can use a locator (different than the ULID) as the destination locator, it MUST perform the HBA/CGA verification if this was not performed upon reception of the locator set. In addition, it MUST verify that the ULID is indeed present at that locator. This verification is performed by doing a return-routability test as part of the Probe sub-protocol [4].
在主机可以使用定位器（不同于ULID）作为目标定位器之前，如果在接收定位器集时未执行HBA/CGA验证，则必须先执行HBA/CGA验证。此外，它必须验证ULID确实存在于该定位器上。作为探测子协议[4]的一部分，通过执行返回可路由性测试来执行此验证。
If the verification method in the Locator List option is not supported by the host, or if the verification method is not consistent with the CGA Parameter Data Structure (e.g., the Parameter Data Structure doesn't contain the multiprefix extension and the verification method says to use HBA), then the host MUST ignore the
如果主机不支持定位器列表选项中的验证方法，或者验证方法与CGA参数数据结构不一致（例如，参数数据结构不包含multiprefix扩展，验证方法表示使用HBA），则主机必须忽略
Locator List and the message in which it is contained. The host SHOULD generate a Shim6 Error message with Error Code=2 and with the Pointer referencing the octet in the verification method that was found inconsistent.
定位器列表及其包含的消息。主机应生成一条错误代码为2且指针引用验证方法中发现不一致的八位字节的Shim6错误消息。
The normal context establishment consists of a 4-message exchange in the order of I1, R1, I2, R2, as can be seen in Figure 3.
如图3所示，正常的上下文建立包括按I1、R1、I2、R2顺序的4条消息交换。
Initiator Responder
发起者响应者
IDLE IDLE
------------- I1 -------------->
I1-SENT
<------------ R1 ---------------
IDLE
------------- I2 -------------->
I2-SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
IDLE IDLE
------------- I1 -------------->
I1-SENT
<------------ R1 ---------------
IDLE
------------- I2 -------------->
I2-SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
Figure 3: Normal Context Establishment
图3：正常上下文建立
When both ends try to initiate a context for the same ULID pair, then we might end up with crossing I1 messages. Alternatively, since no state is created when receiving the I1, a host might send an I1 after having sent an R1 message.
当两端尝试为同一ULID对启动上下文时，我们可能会以交叉I1消息结束。或者，由于在接收I1时不创建任何状态，因此主机可能在发送R1消息后发送I1。
Since a host remembers that it has sent an I1, it can respond to an I1 from the peer (for the same ULID pair) with an R2, resulting in the message exchange shown in Figure 4. Such behavior is needed for reasons such as correctly responding to retransmitted I1 messages, which occur when the R2 message has been lost.
因为主机记得它已经发送了一个I1，所以它可以使用R2从对等方（对于相同的ULID对）响应一个I1，从而产生如图4所示的消息交换。这种行为是需要的原因，例如正确响应重新传输的I1消息，这在R2消息丢失时发生。
Host A Host B
主机A主机B
IDLE IDLE
-\
I1-SENT---\
---\ /---
--- I1 ---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<---
IDLE IDLE
-\
I1-SENT---\
---\ /---
--- I1 ---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<---
-\
I1-SENT---\
---\ /---
--- R2 ---\ /--- I1-SENT
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
-\
I1-SENT---\
---\ /---
--- R2 ---\ /--- I1-SENT
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
Figure 4: Crossing I1 Messages
图4：交叉I1消息
If a host has received an I1 and sent an R1, it has no state to remember this. Thus, if the ULP on the host sends down packets, this might trigger the host to send an I1 message itself. Thus, while one end is sending an I1, the other is sending an I2, as can be seen in Figure 5.
如果主机已接收到I1并发送了R1，则它没有状态来记住这一点。因此，如果主机上的ULP发送下行数据包，这可能会触发主机本身发送I1消息。因此，当一端发送I1时，另一端发送I2，如图5所示。
Host A Host B
主机A主机B
IDLE IDLE
-\
---\
I1-SENT ---\
--- I1 ---\
---\
---\
-->
IDLE IDLE
-\
---\
I1-SENT ---\
--- I1 ---\
---\
---\
-->
/---
/--- IDLE
---
/--- R1--/
/---
<---
/---
/--- IDLE
---
/--- R1--/
/---
<---
-\
I2-SENT---\
---\ /---
--- I2---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<--- ESTABLISHED
-\
I2-SENT---\
---\ /---
--- I2---\ /--- I1-SENT
---\
/--- I1 ---/ ---\
/--- -->
<--- ESTABLISHED
-\
I2-SENT---\
---\ /---
--- R2 ---\ /---
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
-\
I2-SENT---\
---\ /---
--- R2 ---\ /---
---\
/--- R2 ---/ ---\
/--- -->
<--- ESTABLISHED
ESTABLISHED
Figure 5: Crossing I2 and I1
图5：交叉点I2和I1
Due to garbage collection, we can end up with one end having and using the context state, and the other end not having any state. We need to be able to recover this state at the end that has lost it before we can use it.
由于垃圾收集，我们最终可能会导致一端拥有并使用上下文状态，而另一端没有任何状态。在使用之前，我们需要能够在丢失状态的最后恢复该状态。
This need can arise in the following cases:
在以下情况下可能会出现这种需要：
o The communication is working using the ULID pair as the locator pair but a problem arises, and the end that has retained the context state decides to probe alternate locator pairs.
o 使用ULID对作为定位器对进行通信，但出现了一个问题，保留上下文状态的端决定探测备用定位器对。
o The communication is working using a locator pair that is not the ULID pair; hence, the ULP packets sent from a peer that has retained the context state use the Shim6 Payload Extension header.
o 通信正在使用不是ULID对的定位器对工作；因此，从保留上下文状态的对等方发送的ULP数据包使用Shim6有效负载扩展报头。
o The host that retained the state sends a control message (e.g., an Update Request message).
o 保留该状态的主机发送控制消息（例如，更新请求消息）。
In all cases, the result is that the peer without state receives a shim message for which it has no context for the Context Tag.
在所有情况下，结果都是没有状态的对等方接收到一条没有上下文标记上下文的垫片消息。
We can recover the context by having the node that doesn't have a context state send back an R1bis message, and then complete the recovery with an I2bis and R2 message, as can be seen in Figure 6.
我们可以通过让没有上下文状态的节点发回R1bis消息来恢复上下文，然后使用I2bis和R2消息完成恢复，如图6所示。
Host A Host B
主机A主机B
Context for CT(peer)=X Discards context for CT(local)=X
CT的上下文（对等）=X丢弃CT的上下文（本地）=X
ESTABLISHED IDLE
固定闲置
---- payload, probe, etc. -----> No context state
for CT(local)=X
---- payload, probe, etc. -----> No context state
for CT(local)=X
<------------ R1bis ------------
IDLE
<------------ R1bis ------------
IDLE
------------- I2bis ----------->
I2BIS_SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
------------- I2bis ----------->
I2BIS_SENT
<------------ R2 ---------------
ESTABLISHED ESTABLISHED
Figure 6: Context Loss at Receiver
图6：接收端的上下文丢失
If one end has garbage collected or lost the context state, it might try to create a new context state (for the same ULID pair), by sending an I1 message. In this case, the peer (that still has the context state) will reply with an R1 message, and the full 4-way exchange will be performed again, as can be seen in Figure 7.
如果一端已垃圾回收或丢失了上下文状态，则它可能会尝试通过发送I1消息来创建新的上下文状态（对于相同的ULID对）。在这种情况下，对等方（仍然具有上下文状态）将使用R1消息进行回复，并且将再次执行完整的4路交换，如图7所示。
Host A Host B
主机A主机B
Context for CT(peer)=X Discards context for ULIDs A1, B1 CT(local)=X
CT的上下文（对等）=X丢弃ULID A1、B1的上下文CT（本地）=X
ESTABLISHED IDLE
固定闲置
Finds <------------ I1 --------------- Tries to set up
existing for ULIDs A1, B1
context,
but CT(peer) I1-SENT
doesn't match
------------- R1 --------------->
Left old context
in ESTABLISHED
Finds <------------ I1 --------------- Tries to set up
existing for ULIDs A1, B1
context,
but CT(peer) I1-SENT
doesn't match
------------- R1 --------------->
Left old context
in ESTABLISHED
<------------ I2 ---------------
Re-create context
with new CT(peer) I2-SENT
and Ls(peer).
<------------ I2 ---------------
Re-create context
with new CT(peer) I2-SENT
and Ls(peer).
ESTABLISHED
------------- R2 -------------->
ESTABLISHED ESTABLISHED
ESTABLISHED
------------- R2 -------------->
ESTABLISHED ESTABLISHED
Figure 7: Context Loss at Sender
图7：发送方的上下文丢失
Since each end might garbage collect the context state, we can have the case where one end has retained the context state and tries to use it, while the other end has lost the state. We discussed this in the previous section on recovery. But, for the same reasons, when one host retains Context Tag X as CT(peer) for ULID pair <A1, B1>, the other end might end up allocating that Context Tag as CT(local) for another ULID pair (e.g., <A3, B1>) between the same hosts. In this case, we cannot use the recovery mechanisms since there needs to be separate Context Tags for the two ULID pairs.
由于每一端都可能对上下文状态进行垃圾收集，因此我们可以看到这样的情况：一端保留了上下文状态并尝试使用它，而另一端则丢失了该状态。我们在关于恢复的上一节中讨论了这一点。但是，出于同样的原因，当一个主机将上下文标记X保留为ULID对<A1，B1>的CT（对等）时，另一端可能最终将该上下文标记分配为相同主机之间另一个ULID对（例如<A3，B1>）的CT（本地）。在这种情况下，我们不能使用恢复机制，因为两个ULID对需要单独的上下文标记。
This type of "confusion" can be observed in two cases (assuming it is A that has retained the state and B that has dropped it):
这种类型的“混乱”可以在两种情况下观察到（假设是A保留了状态，B放弃了状态）：
o B decides to create a context for ULID pair <A3, B1>, allocates X as its Context Tag for this, and sends an I1 to A.
o B决定为ULID对<A3，B1>创建上下文，分配X作为其上下文标记，并向a发送I1。
o A decides to create a context for ULID pair <A3, B1> and starts the exchange by sending I1 to B. When B receives the I2 message, it allocates X as the Context Tag for this context.
o A决定为ULID对<A3，B1>创建上下文，并通过向B发送I1来启动交换。当B接收到I2消息时，它将X分配为该上下文的上下文标记。
In both cases, A can detect that B has allocated X for ULID pair <A3, B1> even though A still has X as CT(peer) for ULID pair <A1, B1>. Thus, A can detect that B must have lost the context for <A1, B1>.
在这两种情况下，A可以检测到B已经为ULID对<A3，B1>分配了X，即使A仍然将X作为ULID对<A1，B1>的CT（对等）。因此，A可以检测到B一定丢失了<A1，B1>的上下文。
The confusion can be detected when I2/I2bis/R2 is received, since we require that those messages MUST include a sufficiently large set of locators in a Locator List option that the peer can determine whether or not two contexts have the same host as the peer by comparing if there is any common locators in Ls(peer).
当接收到I2/I2bis/R2时可以检测到混淆，因为我们要求这些消息必须在定位器列表选项中包含足够大的定位器集，以便对等方可以通过比较Ls（对等方）中是否存在任何公共定位器来确定两个上下文是否与对等方具有相同的主机。
The old context that used the Context Tag MUST be removed; it can no longer be used to send packets. Thus, A would forcibly remove the context state for <A1, B1, X> so that it can accept the new context for <A3, B1, X>. An implementation MAY re-create a context to replace the one that was removed -- in this case, for <A1, B1>. The normal I1, R1, I2, R2 establishment exchange would then pick unique Context Tags for that replacement context. This re-creation is OPTIONAL, but might be useful when there is ULP communication that is using the ULID pair whose context was removed.
必须删除使用上下文标记的旧上下文；它不能再用于发送数据包。因此，A将强制删除<A1，B1，X>的上下文状态，以便它可以接受<A3，B1，X>的新上下文。一个实现可能会重新创建一个上下文来替换被删除的上下文——在本例中是针对<A1，B1>。然后，正常的I1、R1、I2、R2建立交换将为该替换上下文选择唯一的上下文标记。此重新创建是可选的，但在ULP通信正在使用其上下文已被删除的ULID对时可能有用。
Note that an I1 message with a duplicate Context Tag should not cause the removal of the old context state; this operation needs to be deferred until the reception of the I2 message.
请注意，具有重复上下文标记的I1消息不应导致删除旧上下文状态；此操作需要推迟到接收到I2消息。
When the shim layer decides to set up a context for a ULID pair, it starts by allocating and initializing the context state for its end. As part of this, it assigns a random Context Tag to the context that is not being used as CT(local) by any other context . In the case that a new API is used and the ULP requests a forked context, the Forked Instance Identifier value will be set to a non-zero value. Otherwise, the FII value is zero. Then the initiator can send an I1 message and set the context STATE to I1-SENT. The I1 message MUST include the ULID pair -- normally, in the IPv6 Source and Destination fields. But if the ULID pair for the context is not used as a locator pair for the I1 message, then a ULID option MUST be included in the I1 message. In addition, if a Forked Instance Identifier value is non-zero, the I1 message MUST include a Context Instance Identifier option containing the correspondent value.
当填充层决定为ULID对设置上下文时，它首先为其结束分配并初始化上下文状态。作为这项工作的一部分，它为未被任何其他上下文用作CT（本地）的上下文分配一个随机上下文标记。在使用新API且ULP请求分叉上下文的情况下，分叉实例标识符值将设置为非零值。否则，FII值为零。然后，启动器可以发送I1消息，并将上下文状态设置为I1-SENT。I1消息必须包括ULID对——通常在IPv6源和目标字段中。但是，如果上下文的ULID对没有用作I1消息的定位器对，那么I1消息中必须包含ULID选项。此外，如果分叉实例标识符值为非零，则I1消息必须包含包含对应值的上下文实例标识符选项。
If the host does not receive an R1 or R2 message in response to the I1 message after I1_TIMEOUT time, then it needs to retransmit the I1 message. The retransmissions should use a retransmission timer with binary exponential backoff to avoid creating congestion issues for the network when lots of hosts perform I1 retransmissions. Also, the actual timeout value should be randomized between 0.5 and 1.5 of the nominal value to avoid self-synchronization.
如果主机在I1_超时时间后没有收到响应I1消息的R1或R2消息，则需要重新传输I1消息。重传应使用具有二进制指数退避的重传计时器，以避免在许多主机执行I1重传时为网络造成拥塞问题。此外，实际超时值应在标称值的0.5和1.5之间随机化，以避免自同步。
If, after I1_RETRIES_MAX retransmissions, there is no response, then most likely the peer does not implement the Shim6 protocol (or there could be a firewall that blocks the protocol). In this case, it makes sense for the host to remember not to try again to establish a context with that ULID. However, any such negative caching should be retained for at most NO_R1_HOLDDOWN_TIME, in order to be able to later set up a context should the problem have been that the host was not reachable at all when the shim tried to establish the context.
如果在I1_重试_MAX重新传输后，没有响应，则最有可能的是对等方没有实现Shim6协议（或者可能存在阻止该协议的防火墙）。在这种情况下，主机应该记住不要再次尝试使用该ULID建立上下文。但是，任何此类负面缓存最多应保留一段无延迟时间，以便在垫片试图建立上下文时，如果问题是主机根本无法访问，则能够在以后建立上下文。
If the host receives an ICMP error with "Unrecognized Next Header" type (type 4, code 1) and the included packet is the I1 message it just sent, then this is a more reliable indication that the peer ULID does not implement Shim6. Again, in this case, the host should remember not to try again to establish a context with that ULID. Such negative caching should be retained for at most ICMP_HOLDDOWN_TIME, which should be significantly longer than the previous case.
如果主机收到“Unrecognized Next Header”类型（类型4，代码1）的ICMP错误，并且包含的数据包是它刚刚发送的I1消息，则这是对等ULID未实现Shim6的更可靠指示。同样，在这种情况下，主机应该记住不要再次尝试使用该ULID建立上下文。这种负缓存最多应保留ICMP_保持时间，该时间应明显长于前一种情况。
A host MUST silently discard any received I1 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收到的I1消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an I1 message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
在接收到I1消息后，主机从消息中提取ULID对和分叉实例标识符。如果没有ULID对选项，则从IPv6标头中的源和目标字段获取ULID对。如果消息中没有FII选项，则FII值为零。
Next, the host looks for an existing context that matches the ULID pair and the FII.
接下来，主机将查找与ULID对和FII匹配的现有上下文。
If no state is found (i.e., the STATE is IDLE), then the host replies with an R1 message as specified below.
如果未找到任何状态（即，状态为空闲），则主机将按照下面的规定回复R1消息。
If such a context exists in ESTABLISHED STATE, the host verifies that the locator of the initiator is included in Ls(peer). (This check is unnecessary if there is no ULID-pair option in the I1 message.)
如果这种上下文在已建立状态下存在，主机将验证发起程序的定位器是否包含在Ls（对等）中。（如果I1消息中没有ULID对选项，则无需进行此检查。）
If the state exists in ESTABLISHED STATE and the locators do not fall in the locator sets, then the host replies with an R1 message as specified below. This completes the I1 processing, with the context STATE being unchanged.
如果该状态存在于已建立状态，且定位器不在定位器集中，则主机会按照以下规定回复R1消息。这就完成了I1处理，上下文状态保持不变。
If the state exists in ESTABLISHED STATE and the locators do fall in the sets, then the host compares CT(peer) for the context with the CT contained in the I1 message.
如果状态存在于已建立状态，并且定位器确实在集合中，则主机将上下文的CT（对等）与I1消息中包含的CT进行比较。
o If the Context Tags match, then this probably means that the R2 message was lost and this I1 is a retransmission. In this case, the host replies with an R2 message containing the information available for the existent context.
o 如果上下文标记匹配，则这可能意味着R2消息丢失，并且此I1是重传。在这种情况下，主机将使用包含现有上下文可用信息的R2消息进行回复。
o If the Context Tags do not match, then it probably means that the initiator has lost the context information for this context and is trying to establish a new one for the same ULID pair. In this case, the host replies with an R1 message as specified below. This completes the I1 processing, with the context STATE being unchanged.
o 如果上下文标记不匹配，则可能意味着启动器已丢失此上下文的上下文信息，并且正在尝试为同一ULID对建立新的上下文信息。在这种情况下，主机回复R1消息，如下所述。这就完成了I1处理，上下文状态保持不变。
If the state exists in other STATE (I1-SENT, I2-SENT, I2BIS-SENT), we are in the situation of concurrent context establishment, described in Section 7.4. In this case, the host leaves CT(peer) unchanged and replies with an R2 message. This completes the I1 processing, with the context STATE being unchanged.
如果该状态存在于其他状态（I1-SENT、I2-SENT、I2BIS-SENT），则我们处于并发上下文建立的状态，如第7.4节所述。在这种情况下，主机保持CT（对等）不变，并使用R2消息进行回复。这就完成了I1处理，上下文状态保持不变。
When the host needs to send an R1 message in response to the I1 message, it copies the Initiator Nonce from the I1 message to the R1 message, generates a Responder Nonce, and calculates a Responder Validator option as suggested in the following section. No state is created on the host in this case. (Note that the information used to generate the R1 reply message is either contained in the received I1 message or is global information that is not associated with the particular requested context (the S and the Responder Nonce values.))
当主机需要发送R1消息以响应I1消息时，它会将启动器Nonce从I1消息复制到R1消息，生成响应者Nonce，并计算响应者验证器选项，如以下部分所示。在这种情况下，不会在主机上创建任何状态。（注意，用于生成R1应答消息的信息要么包含在接收到的I1消息中，要么是与特定请求的上下文（S和应答器Nonce值）无关的全局信息。）
When the host needs to send an R2 message in response to the I1 message, it copies the Initiator Nonce from the I1 message to the R2 message, and otherwise follows the normal rules for forming an R2 message (see Section 7.14).
当主机需要发送R2消息以响应I1消息时，它会将启动器Nonce从I1消息复制到R2消息，否则会遵循形成R2消息的正常规则（参见第7.14节）。
As it is stated in Section 5.15.1, the validator-generation mechanism is a local choice since the validator is generated and verified by the same node, i.e., the responder. However, in order to provide the required protection, the validator needs to be generated by fulfilling the conditions described in Section 5.15.1. One way for the responder to properly generate validators is to maintain a single secret (S) and a running counter (C) for the Responder Nonce that is incremented in fixed periods of time (this allows the responder to verify the age of a Responder Nonce, independently of the context in which it is used).
正如第5.15.1节所述，由于验证器由同一节点（即响应者）生成和验证，因此验证器生成机制是本地选择。但是，为了提供所需的保护，需要通过满足第5.15.1节中描述的条件生成验证器。响应程序正确生成验证器的一种方法是为响应程序Nonce维护一个单独的秘密和一个在固定时间段内递增的运行计数器（C）（这允许响应程序验证响应程序Nonce的年龄，与使用它的上下文无关）。
When the validator is generated to be included in an R1 message sent in response to a specific I1 message, the responder can perform the following procedure to generate the validator value:
当生成的验证程序包含在响应特定I1消息而发送的R1消息中时，响应程序可以执行以下过程来生成验证程序值：
First, the responder uses the current counter C value as the Responder Nonce.
首先，响应程序使用当前计数器C值作为响应程序Nonce。
Second, it uses the following information (concatenated) as input to the one-way function:
其次，它使用以下信息（连接）作为单向函数的输入：
o The secret S
o 秘密
o That Responder Nonce
o 那个响应者现在
o The Initiator Context Tag from the I1 message
o I1消息中的启动器上下文标记
o The ULIDs from the I1 message
o I1消息中的ulid
o The locators from the I1 message (strictly only needed if they are different from the ULIDs)
o I1消息中的定位器（仅当它们与ULID不同时才需要）
o The Forked Instance Identifier, if such option was included in the I1 message
o 分叉实例标识符（如果I1消息中包含此选项）
Third, it uses the output of the hash function as the validator value included in the R1 message.
第三，它使用散列函数的输出作为R1消息中包含的验证器值。
A host MUST silently discard any received R1 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收R1消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an R1 message, the host extracts the Initiator Nonce and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context that matches the Initiator Nonce and where the locators are contained in Ls(peer) and Ls(local), respectively. If no such context is found, then the R1 message is silently discarded.
在接收到R1消息后，主机将从消息中提取启动器Nonce和定位器对（后者来自IPv6报头中的源和目标字段）。接下来，主机将查找与启动器Nonce匹配的现有上下文，其中定位符分别包含在Ls（对等）和Ls（本地）中。如果没有找到这样的上下文，那么R1消息将被悄悄地丢弃。
If such a context is found, then the host looks at the STATE:
如果找到这样的上下文，则主机将查看以下状态：
o If the STATE is I1-SENT, then it sends an I2 message as specified below.
o 如果状态为I1-SENT，则它将发送一条I2消息，如下所述。
o In any other STATE (I2-SENT, I2BIS-SENT, ESTABLISHED), then the host has already sent an I2 message and this is probably a reply to a retransmitted I1 message, so this R1 message MUST be silently discarded.
o 在任何其他状态（I2-SENT、I2BIS-SENT、ESTABLISHED）下，主机已发送I2消息，这可能是对重新传输的I1消息的回复，因此必须以静默方式丢弃此R1消息。
When the host sends an I2 message, it includes the Responder Validator option that was in the R1 message. The I2 message MUST include the ULID pair -- normally, in the IPv6 Source and Destination fields. If a ULID-pair option was included in the I1 message, then it MUST be included in the I2 message as well. In addition, if the Forked Instance Identifier value for this context is non-zero, the I2 message MUST contain a Forked Instance Identifier option carrying the Forked Instance Identifier value. Besides, the I2 message contains an Initiator Nonce. This is not required to be the same as the one included in the previous I1 message.
当主机发送I2消息时，它包括R1消息中的Responder Validator选项。I2消息必须包括ULID对——通常在IPv6源和目标字段中。如果I1消息中包含ULID对选项，那么它也必须包含在I2消息中。此外，如果此上下文的Forked Instance Identifier值为非零，则I2消息必须包含一个携带Forked Instance Identifier值的Forked Instance Identifier选项。此外，I2消息包含一个启动器Nonce。这不需要与前一条I1消息中包含的相同。
The I2 message may also include the initiator's locator list. If this is the case, then it must also include the CGA Parameter Data Structure. If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then the initiator must also include a CGA Signature option containing the signature.
I2消息还可以包括发起方的定位器列表。如果是这种情况，那么它还必须包括CGA参数数据结构。如果使用CGA（而不是HBA）验证定位器列表中包含的一个或多个定位器，则启动器还必须包含包含该签名的CGA签名选项。
When the I2 message has been sent, the STATE is set to I2-SENT.
发送I2消息后，状态设置为I2-sent。
If the initiator does not receive an R2 message after I2_TIMEOUT time after sending an I2 message, it MAY retransmit the I2 message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime -- that is, the peer might reject Responder Validator options that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In the case that the initiator decides not to retransmit I2 messages, or in the case that
如果发起方在发送I2消息后的I2_超时时间后未收到R2消息，则它可以使用二进制指数退避和随机计时器重新传输I2消息。响应者验证器选项可能有一个有限的生存期——也就是说，对等方可能拒绝比验证器的生存期早的响应者验证器选项，以避免重播攻击。如果启动器决定不重新传输I2消息，或者
the initiator still does not receive an R2 message after retransmitting I2 messages I2_RETRIES_MAX times, the initiator SHOULD fall back to retransmitting the I1 message.
在重新传输I2消息I2\u重试次数最多后，发起程序仍然没有收到R2消息，发起程序应返回到重新传输I1消息。
A host MUST silently discard any received I2 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收到的I2消息：
o The Hdr Ext Len field is at least 2, i.e., the length is at least 24 octets.
o Hdr Ext Len字段至少为2，即长度至少为24个八位字节。
Upon the reception of an I2 message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
在接收到I2消息后，主机从消息中提取ULID对和分叉实例标识符。如果没有ULID对选项，则从IPv6标头中的源和目标字段获取ULID对。如果消息中没有FII选项，则FII值为零。
Next, the host verifies that the Responder Nonce is a recent one (nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent) and that the Responder Validator option matches the validator the host would have computed for the ULID, locators, Responder Nonce, Initiator Nonce, and FII.
接下来，主机验证响应器Nonce是否是最近的（不早于VALIDATOR_MIN_LIFETIME的Nonce应视为最近的），以及响应器VALIDATOR选项是否与主机将为ULID、定位器、响应器Nonce、启动器Nonce和FII计算的验证器匹配。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the message corresponds to the ULID(peer).
如果消息中包含CGA参数数据结构（PDS），则主机必须验证消息中包含的实际PDS是否对应于ULID（对等）。
If any of the above verifications fail, then the host silently discards the message; it has completed the I2 processing.
如果上述任何验证失败，则主机将自动丢弃该消息；它已经完成了I2处理。
If all the above verifications are successful, then the host proceeds to look for a context state for the initiator. The host looks for a context with the extracted ULID pair and FII. If none exist, then STATE of the (non-existing) context is viewed as being IDLE; thus, the actions depend on the STATE as follows:
如果上述所有验证都成功，那么主机将继续查找启动器的上下文状态。主机使用提取的ULID对和FII查找上下文。若不存在，那个么（不存在）上下文的状态被视为空闲；因此，行动取决于以下状态：
o If the STATE is IDLE (i.e., the context does not exist), the host allocates a Context Tag (CT(local)), creates the context state for the context, and sets its STATE to ESTABLISHED. It records CT(peer) and the peer's locator set as well as its own locator set in the context. It SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. Then, the host sends an R2 message back as specified below.
o 如果状态为空闲（即上下文不存在），主机将分配上下文标记（CT（local）），为上下文创建上下文状态，并将其状态设置为已建立。它在上下文中记录CT（对等体）和对等体的定位器集以及它自己的定位器集。按照第7.2节的规定，应在此时对对等方的定位器集执行HBA/CGA验证。然后，主机发送一条R2消息，如下所述。
o If the STATE is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2 message and that the HBA/CGA verification for this specific locator is successful.
o 如果状态为“I1-SENT”，则主机将验证源定位器是否包含在Ls（对等）或I2消息中包含的定位器列表中，以及此特定定位器的HBA/CGA验证是否成功。
* If this is not the case, then the message is silently discarded and the context STATE remains unchanged.
* 如果不是这样，则消息将被静默丢弃，上下文状态保持不变。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2 message, and the host MUST send an R2 message back as specified below. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The host moves to ESTABLISHED STATE.
* 如果是这种情况，那么主机将使用I2消息中包含的数据更新上下文信息（CT（对等）、Ls（对等）），并且主机必须按照以下规定发回R2消息。请注意，在更新Ls（对等）信息之前，主机应按照第7.2节的规定，在此时间点对对等定位器集执行HBA/CGA验证。主机移动到已建立状态。
o If the STATE is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2 message and that the HBA/CGA verification for this specific locator is successful.
o 如果状态已建立、I2已发送或I2BIS已发送，则主机将验证源定位器是否包含在Ls（对等）或I2消息中包含的定位器列表中，以及此特定定位器的HBA/CGA验证是否成功。
* If this is not the case, then the message is silently discarded and the context STATE remains unchanged.
* 如果不是这样，则消息将被静默丢弃，上下文状态保持不变。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2 message, and the host MUST send an R2 message back as specified in Section 7.14. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The context STATE remains unchanged.
* 如果是这种情况，则主机使用I2消息中包含的数据更新上下文信息（CT（对等）、Ls（对等），并且主机必须按照第7.14节的规定发回R2消息。请注意，在更新Ls（对等）信息之前，主机应按照第7.2节的规定，在此时间点对对等定位器集执行HBA/CGA验证。上下文状态保持不变。
Before the host sends the R2 message, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. See Section 7.15.
在主机发送R2消息之前，它必须查找可能的上下文混淆，也就是说，对于同一对等主机，它将使用相同的CT（对等）来结束多个上下文。见第7.15节。
When the host needs to send an R2 message, the host forms the message and its Context Tag, and copies the Initiator Nonce from the triggering message (I2, I2bis, or I1). In addition, it may include alternative locators and necessary options so that the peer can verify them. In particular, the R2 message may include the responder's locator list and the PDS option. If CGA (and not HBA) is used to verify the locator list, then the responder also signs the key parts of the message and includes a CGA Signature option containing the signature.
当主机需要发送R2消息时，主机将形成消息及其上下文标记，并从触发消息（I2、I2bis或I1）复制启动器Nonce。此外，它可以包括替代定位器和必要的选项，以便对等方可以验证它们。具体而言，R2消息可包括响应者的定位器列表和PDS选项。如果使用CGA（而不是HBA）来验证定位器列表，则响应者也会对消息的关键部分进行签名，并包括包含签名的CGA签名选项。
R2 messages are never retransmitted. If the R2 message is lost, then the initiator will retransmit either the I2/I2bis or I1 message. Either retransmission will cause the responder to find the context state and respond with an R2 message.
R2消息永远不会重新传输。如果R2消息丢失，则启动器将重新传输I2/I2bis或I1消息。任一重传都会导致响应者找到上下文状态并用R2消息进行响应。
When the host receives an I2, I2bis, or R2, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. This can happen when the host has received the above messages, since they create a new context with a new CT(peer). The same issue applies when CT(peer) is updated for an existing context.
当主机接收到I2、I2bis或R2时，它必须查找可能的上下文混淆，即，在同一个对等主机上，它将使用相同的CT（对等）来结束多个上下文。当主机接收到上述消息时，可能会发生这种情况，因为它们使用新的CT（对等）创建了一个新的上下文。当为现有上下文更新CT（对等）时，同样的问题也适用。
The host takes CT(peer) for the newly created or updated context, and looks for other contexts which:
主机将CT（对等）用于新创建或更新的上下文，并查找以下其他上下文：
o Are in STATE ESTABLISHED or I2BIS-SENT
o 处于已建立状态或I2BIS-SENT状态
o Have the same CT(peer)
o 具有相同的CT（对等）
o Have an Ls(peer) that has at least one locator in common with the newly created or updated context
o 具有至少一个与新创建或更新的上下文相同的定位器的Ls（对等）
If such a context is found, then the host checks if the ULID pair or the Forked Instance Identifier are different than the ones in the newly created or updated context:
如果找到这样的上下文，则主机将检查ULID对或分叉实例标识符是否与新创建或更新的上下文中的不同：
o If either or both are different, then the peer is reusing the Context Tag for the creation of a context with different ULID pair or FII, which is an indication that the peer has lost the original context. In this case, we are in a context confusion situation, and the host MUST NOT use the old context to send any packets. It MAY just discard the old context (after all, the peer has discarded it), or it MAY attempt to re-establish the old context by sending a new I1 message and moving its STATE to I1-SENT. In any case, once that this situation is detected, the host MUST NOT keep two contexts with overlapping Ls(peer) locator sets and the same Context Tag in ESTABLISHED STATE, since this would result in demultiplexing problems on the peer.
o 如果其中一个或两个不同，则对等方正在重用上下文标记以创建具有不同ULID对或FII的上下文，这表示对等方已丢失原始上下文。在这种情况下，我们处于上下文混乱的情况下，主机不能使用旧上下文发送任何数据包。它可能只是丢弃旧的上下文（毕竟，对等方已经丢弃了它），或者它可能通过发送新的I1消息并将其状态移动到I1-SENT来尝试重新建立旧的上下文。在任何情况下，一旦检测到这种情况，主机不得将具有重叠Ls（对等）定位器集和相同上下文标记的两个上下文保持在已建立状态，因为这将导致对等上的解复用问题。
o If both are the same, then this context is actually the context that is created or updated; hence, there is no confusion.
o 如果两者相同，那么该上下文实际上就是创建或更新的上下文；因此，没有混淆。
A host MUST silently discard any received R2 messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收R2消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an R2 message, the host extracts the Initiator Nonce and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context that matches the Initiator Nonce and where the locators are Lp(peer) and Lp(local), respectively. Based on the STATE:
接收到R2消息后，主机将从消息中提取启动器Nonce和定位器对（后者来自IPv6报头中的源和目标字段）。接下来，主机查找与启动器Nonce匹配的现有上下文，其中定位器分别为Lp（对等）和Lp（本地）。根据国家：
o If no such context is found, i.e., the STATE is IDLE, then the message is silently dropped.
o 如果没有找到这样的上下文，即状态为空闲，则消息将被静默地丢弃。
o If STATE is I1-SENT, I2-SENT, or I2BIS-SENT, then the host performs the following actions. If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify that the actual PDS contained in the message corresponds to the ULID(peer) as specified in Section 7.2. If the verification fails, then the message is silently dropped. If the verification succeeds, then the host records the information from the R2 message in the context state; it records the peer's locator set and CT(peer). The host SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. The host sets its STATE to ESTABLISHED.
o 如果状态为I1-SENT、I2-SENT或I2BIS-SENT，则主机将执行以下操作。如果消息中包含CGA参数数据结构（PDS），则主机必须验证消息中包含的实际PDS是否与第7.2节中规定的ULID（对等）相对应。如果验证失败，则消息将自动删除。如果验证成功，则主机在上下文状态下记录来自R2消息的信息；它记录对等方的定位器集和CT（对等方）。按照第7.2节的规定，主机应在此时对对等机的定位器集执行HBA/CGA验证。主机将其状态设置为“已建立”。
o If the STATE is ESTABLISHED, the R2 message is silently ignored, (since this is likely to be a reply to a retransmitted I2 message).
o 如果建立状态，R2消息将被静默忽略（因为这可能是对重新传输的I2消息的回复）。
Before the host completes the R2 processing, it MUST look for a possible context confusion, i.e., where it would end up with multiple contexts using the same CT(peer) for the same peer host. See Section 7.15.
在主机完成R2处理之前，它必须查找可能的上下文混淆，也就是说，对于同一对等主机，它将使用相同的CT（对等）来结束多个上下文。见第7.15节。
Upon the receipt of a Shim6 Payload Extension header where there is no current Shim6 context at the receiver, the receiver is to respond with an R1bis message in order to enable a fast re-establishment of the lost Shim6 context.
在接收到在接收机处没有当前Shim6上下文的Shim6有效负载扩展报头时，接收机将用R1bis消息响应，以便能够快速重新建立丢失的Shim6上下文。
Also, a host is to respond with an R1bis upon receipt of any control messages that have a message type in the range 64-127 (i.e., excluding the context-setup messages such as I1, R1, R1bis, I2, I2bis, R2, and future extensions), where the control message refers to a non-existent context.
此外，主机在接收到消息类型在64-127范围内的任何控制消息（即，不包括上下文设置消息，如I1、R1、R1bis、I2、I2bis、R2和未来扩展）时，将使用R1bis进行响应，其中控制消息指代不存在的上下文。
We assume that all the incoming packets that trigger the generation of an R1bis message contain a locator pair (in the address fields of the IPv6 header) and a Context Tag.
我们假设触发R1bis消息生成的所有传入数据包都包含一个定位器对（在IPv6报头的地址字段中）和一个上下文标记。
Upon reception of any of the packets described above, the host will reply with an R1bis including the following information:
在接收到上述任何分组后，主机将使用包括以下信息的R1bis进行应答：
o The Responder Nonce is a number picked by the responder that the initiator will return in the I2bis message.
o 响应程序Nonce是由响应程序拾取的数字，启动器将在I2bis消息中返回该数字。
o Packet Context Tag is the Context Tag contained in the received packet that triggered the generation of the R1bis message.
o 数据包上下文标记是接收到的数据包中包含的上下文标记，该数据包触发了R1bis消息的生成。
o The Responder Validator option is included, with a validator that is computed as suggested in the next section.
o 包括响应者验证器选项，验证器将按照下一节中的建议进行计算。
One way for the responder to properly generate validators is to maintain a single secret (S) and a running counter C for the Responder Nonce that is incremented in fixed periods of time (this allows the responder to verify the age of a Responder Nonce, independently of the context in which it is used).
响应程序正确生成验证器的一种方法是为响应程序Nonce维护一个秘密和一个在固定时间段内递增的运行计数器C（这允许响应程序验证响应程序Nonce的年龄，与使用它的上下文无关）。
When the validator is generated to be included in an R1bis message -- that is, sent in response to a specific control packet or a packet containing the Shim6 Payload Extension header message -- the responder can perform the following procedure to generate the validator value:
当生成要包含在R1bis消息中的验证器时（即，响应于特定控制数据包或包含Shim6有效负载扩展报头消息的数据包而发送），响应者可以执行以下过程来生成验证器值：
First, the responder uses the counter C value as the Responder Nonce.
首先，响应程序使用计数器C值作为响应程序Nonce。
Second, it uses the following information (concatenated) as input to the one-way function:
其次，它使用以下信息（连接）作为单向函数的输入：
o The secret S
o 秘密
o That Responder Nonce
o 那个响应者现在
o The Receiver Context Tag included in the received packet
o 接收到的数据包中包含的接收器上下文标记
o The locators from the received packet
o 从接收到的数据包中删除定位器
Third, it uses the output of the hash function as the validator string.
第三，它使用哈希函数的输出作为验证器字符串。
A host MUST silently discard any received R1bis messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收到的R1bis消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an R1bis message, the host extracts the Packet Context Tag and the Locator Pair from the message (the latter from the Source and Destination fields in the IPv6 header). Next, the host looks for an existing context where the Packet Context Tag matches CT(peer) and where the locators match Lp(peer) and Lp(local), respectively.
接收到R1bis消息后，主机从消息中提取数据包上下文标记和定位器对（后者从IPv6报头中的源和目标字段）。接下来，主机查找包上下文标记分别与CT（对等）和定位器匹配Lp（对等）和Lp（本地）的现有上下文。
o If no such context is found, i.e., the STATE is IDLE, then the R1bis message is silently discarded.
o 如果没有找到这样的上下文，即状态为IDLE，则R1bis消息将被静默丢弃。
o If the STATE is I1-SENT, I2-SENT, or I2BIS-SENT, then the R1bis message is silently discarded.
o 如果状态为I1-SENT、I2-SENT或I2BIS-SENT，则R1bis消息将被静默丢弃。
o If the STATE is ESTABLISHED, then we are in the case where the peer has lost the context, and the goal is to try to re-establish it. For that, the host leaves CT(peer) unchanged in the context state, transitions to I2BIS-SENT STATE, and sends an I2bis message, including the computed Responder Validator option, the Packet Context Tag, and the Responder Nonce that were received in the R1bis message. This I2bis message is sent using the locator pair included in the R1bis message. In the case that this locator pair differs from the ULID pair defined for this context, then a ULID option MUST be included in the I2bis message. In addition, if the Forked Instance Identifier for this context is non-zero, then a Forked Instance Identifier option carrying the instance identifier value for this context MUST be included in the I2bis message. The I2bis message may also include a locator list. If this is the case, then it must also include the CGA Parameter Data Structure. If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then the initiator must also include a CGA Signature option containing the signature.
o 如果建立了状态，那么我们的情况就是对等方失去了上下文，目标是尝试重新建立它。为此，主机在上下文状态中保持CT（对等）不变，转换到I2BIS-SENT状态，并发送I2BIS消息，包括计算响应器验证器选项、数据包上下文标记和在R1bis消息中接收的响应器Nonce。此I2bis消息使用R1bis消息中包含的定位器对发送。如果此定位器对不同于为此上下文定义的ULID对，则I2bis消息中必须包含ULID选项。此外，如果此上下文的分叉实例标识符为非零，则I2bis消息中必须包含携带此上下文的实例标识符值的分叉实例标识符选项。I2bis消息还可以包括定位器列表。如果是这种情况，那么它还必须包括CGA参数数据结构。如果使用CGA（而不是HBA）验证定位器列表中包含的一个或多个定位器，则启动器还必须包含包含该签名的CGA签名选项。
If the initiator does not receive an R2 message after I2bis_TIMEOUT time after sending an I2bis message, it MAY retransmit the I2bis message, using binary exponential backoff and randomized timers. The Responder Validator option might have a limited lifetime -- that is, the peer might reject Responder Validator options that are older than VALIDATOR_MIN_LIFETIME to avoid replay attacks. In the case that the initiator decides not to retransmit I2bis messages, or in the case that the initiator still does not receive an R2 message after retransmitting I2bis messages I2bis_RETRIES_MAX times, the initiator SHOULD fall back to retransmitting the I1 message.
如果启动器在发送I2bis消息后的I2bis_超时时间后未收到R2消息，则可以使用二进制指数退避和随机计时器重新传输I2bis消息。响应者验证器选项可能有一个有限的生存期——也就是说，对等方可能拒绝比验证器的生存期早的响应者验证器选项，以避免重播攻击。如果启动器决定不重新传输I2bis消息，或者在重新传输I2bis消息I2bis重试次数最多后，启动器仍然没有收到R2消息，则启动器应返回到重新传输I1消息。
A host MUST silently discard any received I2bis messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收到的I2bis消息：
o The Hdr Ext Len field is at least 3, i.e., the length is at least 32 octets.
o Hdr Ext Len字段至少为3，即长度至少为32个八位字节。
Upon the reception of an I2bis message, the host extracts the ULID pair and the Forked Instance Identifier from the message. If there is no ULID-pair option, then the ULID pair is taken from the Source and Destination fields in the IPv6 header. If there is no FII option in the message, then the FII value is taken to be zero.
在接收到I2bis消息后，主机从消息中提取ULID对和分叉实例标识符。如果没有ULID对选项，则从IPv6标头中的源和目标字段获取ULID对。如果消息中没有FII选项，则FII值为零。
Next, the host verifies that the Responder Nonce is a recent one (nonces that are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent) and that the Responder Validator option matches the validator the host would have computed for the locators, Responder Nonce, and Receiver Context Tag as part of sending an R1bis message.
接下来，主机验证响应程序Nonce是否是最近的（不早于VALIDATOR_MIN_LIFETIME的Nonce应视为最近的），以及响应程序VALIDATOR选项是否与主机在发送R1bis消息时为定位器、响应程序Nonce和接收方上下文标记计算的验证器匹配。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the message corresponds to the ULID(peer).
如果消息中包含CGA参数数据结构（PDS），则主机必须验证消息中包含的实际PDS是否对应于ULID（对等）。
If any of the above verifications fail, then the host silently discards the message; it has completed the I2bis processing.
如果上述任何验证失败，则主机将自动丢弃该消息；它已完成I2bis处理。
If both verifications are successful, then the host proceeds to look for a context state for the initiator. The host looks for a context with the extracted ULID pair and FII. If none exist, then STATE of the (non-existing) context is viewed as being IDLE; thus, the actions depend on the STATE as follows:
如果两次验证都成功，则主机继续查找启动器的上下文状态。主机使用提取的ULID对和FII查找上下文。若不存在，那个么（不存在）上下文的状态被视为空闲；因此，行动取决于以下状态：
o If the STATE is IDLE (i.e., the context does not exist), the host allocates a Context Tag (CT(local)), creates the context state for the context, and sets its STATE to ESTABLISHED. The host SHOULD NOT use the Packet Context Tag in the I2bis message for CT(local); instead, it should pick a new random Context Tag just as when it processes an I2 message. It records CT(peer) and the peer's locator set as well as its own locator set in the context. It SHOULD perform the HBA/CGA verification of the peer's locator set at this point in time, as specified in Section 7.2. Then the host sends an R2 message back as specified in Section 7.14.
o 如果状态为空闲（即上下文不存在），主机将分配上下文标记（CT（local）），为上下文创建上下文状态，并将其状态设置为已建立。主机不应在CT（本地）的I2bis消息中使用数据包上下文标记；相反，它应该像处理I2消息一样选择一个新的随机上下文标记。它在上下文中记录CT（对等体）和对等体的定位器集以及它自己的定位器集。按照第7.2节的规定，应在此时对对等方的定位器集执行HBA/CGA验证。然后，主机按照第7.14节的规定发回一条R2消息。
o If the STATE is I1-SENT, then the host verifies if the source locator is included in Ls(peer) or in the Locator List contained in the I2bis message and if the HBA/CGA verification for this specific locator is successful.
o 如果状态为I1-SENT，则主机将验证源定位器是否包含在Ls（对等）或I2bis消息中包含的定位器列表中，以及是否成功验证了此特定定位器的HBA/CGA。
* If this is not the case, then the message is silently discarded. The context STATE remains unchanged.
* 如果不是这样，则消息将被悄悄地丢弃。上下文状态保持不变。
* If this is the case, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2bis message, and the host MUST send an R2 message back as specified below. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The host moves to ESTABLISHED STATE.
* 如果是这种情况，则主机将使用I2bis消息中包含的数据更新上下文信息（CT（对等）、Ls（对等）），并且主机必须按照以下规定发回R2消息。请注意，在更新Ls（对等）信息之前，主机应按照第7.2节的规定，在此时间点对对等定位器集执行HBA/CGA验证。主机移动到已建立状态。
o If the STATE is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host determines whether at least one of the two following conditions hold: i) if the source locator is included in Ls(peer) or, ii) if the source locator is included in the Locator List contained in the I2bis message and if the HBA/CGA verification for this specific locator is successful.
o 如果状态已建立、I2-SENT或I2BIS-SENT，则主机确定以下两个条件中的至少一个是否成立：i）源定位器是否包含在Ls（对等）中，或，ii）源定位器是否包含在I2bis消息中的定位器列表中，以及该特定定位器的HBA/CGA验证是否成功。
* If none of the two aforementioned conditions hold, then the message is silently discarded. The context STATE remains unchanged.
* 如果上述两个条件均不成立，则消息将被静默丢弃。上下文状态保持不变。
* If at least one of the two aforementioned conditions hold, then the host updates the context information (CT(peer), Ls(peer)) with the data contained in the I2bis message, and the host MUST send an R2 message back, as specified in Section 7.14. Note that before updating Ls(peer) information, the host SHOULD perform the HBA/CGA validation of the peer's locator set at this point in time, as specified in Section 7.2. The context STATE remains unchanged.
* 如果上述两个条件中至少有一个条件成立，则主机使用I2bis消息中包含的数据更新上下文信息（CT（对等）、Ls（对等）），并且主机必须按照第7.14节的规定发回R2消息。请注意，在更新Ls（对等）信息之前，主机应按照第7.2节的规定，在此时间点对对等定位器集执行HBA/CGA验证。上下文状态保持不变。
The routers in the path as well as the destination might generate ICMP error messages. In some cases, the Shim6 can take action and solve the problem that resulted in the error. In other cases, the Shim6 layer cannot solve the problem, and it is critical that these packets make it back up to the ULPs so that they can take appropriate action.
路径和目标中的路由器可能会生成ICMP错误消息。在某些情况下，Shim6可以采取措施解决导致错误的问题。在其他情况下，Shim6层无法解决问题，这些数据包必须备份到ULP，以便它们能够采取适当的措施。
This is an implementation issue in the sense that the mechanism is completely local to the host itself. But the issue of how ICMP errors are correctly dispatched to the ULP on the host are important; hence, this section specifies the issue.
这是一个实现问题，因为该机制对于主机本身来说是完全本地的。但是，如何将ICMP错误正确地发送到主机上的ULP的问题很重要；因此，本节规定了问题。
All ICMP messages MUST be delivered to the ULP in all cases, except when Shim6 successfully acts on the message (e.g., selects a new path). There SHOULD be a configuration option to unconditionally deliver all ICMP messages (including ones acted on by shim6) to the ULP.
在任何情况下，所有ICMP消息都必须发送到ULP，除非Shim6成功地对消息进行操作（例如，选择新路径）。应该有一个配置选项来无条件地将所有ICMP消息（包括由shim6执行的消息）传递到ULP。
According to that recommendation, the following ICMP error messages should be processed by the Shim6 layer and not passed to the ULP:
根据该建议，以下ICMP错误消息应由Shim6层处理，而不是传递给ULP：
ICMP error Destination Unreachable, with codes: 0 (No route to destination) 1 (Communication with destination administratively prohibited) 2 (Beyond scope of source address) 3 (Address unreachable) 5 (Source address failed ingress/egress policy) 6 (Reject route to destination)
ICMP错误目标不可访问，代码为：0（无到目标的路由）1（与目标的通信被管理禁止）2（超出源地址范围）3（地址不可访问）5（源地址失败的入口/出口策略）6（拒绝到目标的路由）
ICMP Time exceeded error.
超过ICMP时间错误。
ICMP Parameter problem error, with the parameter that caused the error being a Shim6 parameter.
ICMP参数问题错误，导致错误的参数为Shim6参数。
The following ICMP error messages report problems that cannot be addressed by the Shim6 layer and that should be passed to the ULP (as described below):
以下ICMP错误消息报告了Shim6层无法解决的问题，应将这些问题传递给ULP（如下所述）：
ICMP Packet too big error.
ICMP数据包太大错误。
ICMP Destination Unreachable with Code 4 (Port unreachable).
代码为4的ICMP目标不可访问（端口不可访问）。
ICMP Parameter problem (if the parameter that caused the problem is not a Shim6 parameter).
ICMP参数问题（如果导致问题的参数不是Shim6参数）。
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Can be dispatched
IPv6 | sent by ULP | unmodified to ULP
| on host | ICMP error handler
Packet +--------------+
| ULP |
in | Header |
+--------------+
Error | |
~ Data ~
| |
- - +--------------+ - -
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Can be dispatched
IPv6 | sent by ULP | unmodified to ULP
| on host | ICMP error handler
Packet +--------------+
| ULP |
in | Header |
+--------------+
Error | |
~ Data ~
| |
- - +--------------+ - -
Figure 8: ICMP Error Handling without the Shim6 Payload Extension Header
图8：没有Shim6有效负载扩展头的ICMP错误处理
When the ULP packets are sent without the Shim6 Payload Extension header -- that is, while the initial locators=ULIDs are working -- this introduces no new concerns; an implementation's existing mechanism for delivering these errors to the ULP will work. See Figure 8.
当ULP数据包在没有Shim6有效负载扩展头的情况下发送时——也就是说，当初始定位器=ULID工作时——这不会带来新的问题；实现将这些错误传递给ULP的现有机制将起作用。参见图8。
But when the shim on the transmitting side inserts the Shim6 Payload Extension header and replaces the ULIDs in the IP address fields with some other locators, then an ICMP error coming back will have a "packet in error", which is not a packet that the ULP sent. Thus, the implementation will have to apply reverse mapping to the "packet in error" before passing the ICMP error up to the ULP, including the ICMP extensions defined in [25]. See Figure 9.
但是，当发送端的垫片插入Shim6有效负载扩展报头并用一些其他定位器替换IP地址字段中的ULID时，返回的ICMP错误将具有“错误中的数据包”，该数据包不是ULP发送的数据包。因此，在将ICMP错误传递给ULP（包括[25]中定义的ICMP扩展）之前，实现必须对“错误数据包”应用反向映射。参见图9。
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Needs to be
IPv6 | modified by | transformed to
| shim on host | have ULIDs
+--------------+ in src, dst fields,
Packet | Shim6 ext. | and Shim6 Ext.
| Header | header removed
in +--------------+ before it can be
| Transport | dispatched to the ULP
Error | Header | ICMP error handler.
+--------------+
| |
~ Data ~
| |
- - +--------------+ - -
+--------------+
| IPv6 Header |
| |
+--------------+
| ICMPv6 |
| Header |
- - +--------------+ - -
| IPv6 Header |
| src, dst as | Needs to be
IPv6 | modified by | transformed to
| shim on host | have ULIDs
+--------------+ in src, dst fields,
Packet | Shim6 ext. | and Shim6 Ext.
| Header | header removed
in +--------------+ before it can be
| Transport | dispatched to the ULP
Error | Header | ICMP error handler.
+--------------+
| |
~ Data ~
| |
- - +--------------+ - -
Figure 9: ICMP Error Handling with the Shim6 Payload Extension Header
图9:Shim6有效负载扩展头的ICMP错误处理
Note that this mapping is different than when receiving packets from the peer with Shim6 Payload Extension headers because, in that case, the packets contain CT(local). But the ICMP errors have a "packet in error" with a Shim6 Payload Extension header containing CT(peer). This is because they were intended to be received by the peer. In any case, since the <Source Locator, Destination Locator, CT(peer)> has to be unique when received by the peer, the local host should also only be able to find one context that matches this tuple.
请注意，此映射与从具有Shim6有效负载扩展头的对等方接收数据包时不同，因为在这种情况下，数据包包含CT（本地）。但是ICMP错误有一个“数据包出错”，其Shim6有效负载扩展头包含CT（对等）。这是因为它们旨在被对等方接收。在任何情况下，由于对等方接收到的<Source Locator，Destination Locator，CT（peer）>必须是唯一的，因此本地主机也应该只能找到一个与此元组匹配的上下文。
If the ICMP error is a "packet too big", the reported MTU must be adjusted to be 8 octets less, since the shim will add 8 octets when sending packets.
如果ICMP错误为“数据包太大”，则必须将报告的MTU调整为少8个八位字节，因为垫片在发送数据包时将添加8个八位字节。
After the "packet in error" has had the original ULIDs inserted, then this Shim6 Payload Extension header can be removed. The result is a "packet in error" that is passed to the ULP which looks as if the shim did not exist.
在“错误中的数据包”插入了原始ulid之后，可以删除这个Shim6有效负载扩展头。结果是一个“错误数据包”被传递到ULP，看起来好像垫片不存在。
Each host can unilaterally decide when to tear down a ULID-pair context. It is RECOMMENDED that hosts do not tear down the context when they know that there is some upper-layer protocol that might use
每个主机都可以单方面决定何时删除ULID对上下文。建议主机在知道可能使用某些上层协议时不要破坏上下文
the context. For example, an implementation might know this if there is an open socket that is connected to the ULID(peer). However, there might be cases when the knowledge is not readily available to the shim layer, for instance, for UDP applications that do not connect their sockets or for any application that retains some higher-level state across (TCP) connections and UDP packets.
上下文。例如，如果存在连接到ULID（对等）的开放套接字，则实现可能知道这一点。但是，在某些情况下，垫片层可能不容易获得这些知识，例如，对于未连接套接字的UDP应用程序，或者对于在（TCP）连接和UDP数据包之间保留某些更高级别状态的任何应用程序。
Thus, it is RECOMMENDED that implementations minimize premature teardown by observing the amount of traffic that is sent and received using the context, and tear down the state only after it appears quiescent. A reasonable approach would be to not tear down a context until at least 5 minutes have passed since the last message was sent or received using the context. (Note that packets that use the ULID pair as a locator pair and that do not require address rewriting by the Shim6 layer are also considered as packets using the associated Shim6 context.)
因此，建议实现通过观察使用上下文发送和接收的通信量来最大限度地减少过早的拆卸，并且只有在状态看起来静止后才拆除状态。一种合理的方法是，在使用上下文发送或接收最后一条消息至少5分钟后，才删除上下文。（请注意，使用ULID对作为定位器对并且不需要由Shim6层重写地址的数据包也被视为使用关联的Shim6上下文的数据包。）
Since there is no explicit, coordinated removal of the context state, there are potential issues around Context Tag reuse. One end might remove the state and potentially reuse that Context Tag for some other communication, and the peer might later try to use the old context (which it didn't remove). The protocol has mechanisms to recover from this, which work whether the state removal was total and accidental (e.g., crash and reboot of the host) or just a garbage collection of shim state that didn't seem to be used. However, the host should try to minimize the reuse of Context Tags by trying to randomly cycle through the 2^47 Context Tag values. (See Appendix C for a summary of how the recovery works in the different cases.)
由于上下文状态并没有明确的、协调的删除，所以上下文标记重用存在潜在的问题。一端可能会删除状态，并可能将该上下文标记重新用于其他通信，而另一端可能稍后尝试使用旧上下文（它没有删除）。该协议具有从中恢复的机制，无论状态删除是完全的和意外的（例如，主机崩溃和重新启动），还是只是对似乎未使用的垫片状态进行垃圾收集，该机制都可以工作。但是，主机应该通过尝试随机循环2^47个上下文标记值来尽量减少上下文标记的重用。（有关不同情况下恢复工作的总结，请参见附录C。）
The Update Request and Acknowledgement are used both to update the list of locators (only possible when CGA is used to verify the locator(s)) and to update the preferences associated with each locator.
更新请求和确认既用于更新定位器列表（仅当CGA用于验证定位器时才可能），也用于更新与每个定位器相关联的偏好。
When a host has a change in the locator set, it can communicate this to the peer by sending an Update Request. When a host has a change in the preferences for its locator set, it can also communicate this to the peer. The Update Request message can include just a Locator List option (to convey the new set of locators), just a Locator Preferences option, or both a new Locator List and new Locator Preferences.
当主机的定位器集发生更改时，它可以通过发送更新请求将此更改传达给对等方。当主机的定位器集的首选项发生变化时，它还可以将此信息传达给对等方。更新请求消息可以仅包括定位器列表选项（用于传递新的定位器集）、定位器首选项选项，或者同时包括新定位器列表和新定位器首选项。
Should the host send a new Locator List, the host picks a new random, local generation number, records this in the context, and puts it in the Locator List option. Any Locator Preference option, whether sent in the same Update Request or in some future Update Request, will use that generation number to make sure the preferences get applied to the correct version of the locator list.
如果主机发送一个新的定位器列表，主机将选择一个新的随机本地生成号，将其记录在上下文中，并将其放入定位器列表选项中。任何定位器首选项选项，无论是在同一个更新请求中发送还是在将来的某个更新请求中发送，都将使用该生成号来确保首选项应用于定位器列表的正确版本。
The host picks a random Request Nonce for each update and keeps the same nonce for any retransmissions of the Update Request. The nonce is used to match the acknowledgement with the request.
主机为每次更新选择一个随机请求Nonce，并为更新请求的任何重新传输保留相同的Nonce。nonce用于将确认与请求匹配。
The Update Request message can also include a CGA Parameter Data Structure (this is needed if the CGA PDS was not previously exchanged). If CGA (and not HBA) is used to verify one or more of the locators included in the locator list, then a CGA Signature option containing the signature must also be included in the Update Request message.
更新请求消息还可以包括CGA参数数据结构（如果之前未交换CGA PDS，则需要此结构）。如果使用CGA（而非HBA）验证定位器列表中包含的一个或多个定位器，则更新请求消息中还必须包含包含该签名的CGA签名选项。
If the host does not receive an Update Acknowledgement R2 message in response to the Update Request message after UPDATE_TIMEOUT time, then it needs to retransmit the Update Request message. The retransmissions should use a retransmission timer with binary exponential backoff to avoid creating congestion issues for the network when lots of hosts perform Update Request retransmissions. Also, the actual timeout value should be randomized between 0.5 and 1.5 of the nominal value to avoid self-synchronization.
如果主机在更新超时时间后没有收到更新确认R2消息以响应更新请求消息，则需要重新传输更新请求消息。重传应使用具有二进制指数退避的重传计时器，以避免在许多主机执行更新请求重传时为网络造成拥塞问题。此外，实际超时值应在标称值的0.5和1.5之间随机化，以避免自同步。
Should there be no response, the retransmissions continue forever. The binary exponential backoff stops at MAX_UPDATE_TIMEOUT. But the only way the retransmissions would stop when there is no acknowledgement is when Shim6, through the REAP protocol or some other mechanism, decides to discard the context state due to lack of ULP usage in combination with no responses to the REAP protocol.
如果没有响应，则重新传输将永远继续。二进制指数退避在最大更新超时时停止。但是，当没有确认时，重新传输将停止的唯一方式是，当Shim6通过REAP协议或某些其他机制，决定放弃上下文状态时，由于缺少ULP使用，并且没有对REAP协议的响应。
There can be at most one outstanding Update Request message at any time. Thus until, for example, an update with a new Locator List has been acknowledged, any newer Locator List or new Locator Preferences cannot just be sent. However, when there is newer information and the older information has not yet been acknowledged, the host can, instead of waiting for an acknowledgement, abandon the previous update and construct a new Update Request (with a new Request Nonce) that includes the new information as well as the information that hasn't yet been acknowledged.
任何时候最多只能有一条未完成的更新请求消息。因此，例如，在确认使用新定位器列表的更新之前，不能仅发送任何更新的定位器列表或新定位器首选项。但是，当存在较新的信息且较旧的信息尚未确认时，主机可以放弃先前的更新，而不是等待确认，并构造一个新的更新请求（使用新的请求Nonce），其中包括新信息以及尚未确认的信息。
For example, if the original locator list was just (A1, A2), and if an Update Request with the Locator List (A1, A3) is outstanding, and the host determines that it should both add A4 to the locator list and mark A1 as BROKEN, then it would need to:
例如，如果原始定位器列表仅为（A1，A2），并且如果定位器列表（A1，A3）的更新请求未完成，并且主机确定应将A4添加到定位器列表并将A1标记为已断开，则需要：
o Pick a new random Request Nonce for the new Update Request.
o 为新的更新请求选择一个新的随机请求Nonce。
o Pick a new random generation number for the new locator list.
o 为新定位器列表选择新的随机生成编号。
o Form the new locator list: (A1, A3, A4).
o 形成新的定位器列表：（A1、A3、A4）。
o Form a Locator Preference option that uses the new generation number and has the BROKEN flag for the first locator.
o 形成一个定位器首选项选项，该选项使用新一代编号并具有第一个定位器的断开标志。
o Send the Update Request and start a retransmission timer.
o 发送更新请求并启动重新传输计时器。
Any Update Acknowledgement that doesn't match the current Request Nonce (for instance, an acknowledgement for the abandoned Update Request) will be silently ignored.
任何与当前请求Nonce不匹配的更新确认（例如，放弃的更新请求的确认）都将被静默忽略。
A host MUST silently discard any received Update Request messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的收到的更新请求消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an Update Request message, the host extracts the Context Tag from the message. It then looks for a context that has a CT(local) that matches the Context Tag. If no such context is found, it sends an R1bis message as specified in Section 7.17.
在接收到更新请求消息后，主机从消息中提取上下文标记。然后，它将查找具有与上下文标记匹配的CT（本地）的上下文。如果未找到此类上下文，则发送第7.17节规定的R1bis消息。
Since Context Tags can be reused, the host MUST verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If this is not the case, the sender of the Update Request has a stale context that happens to match the CT(local) for this context. In this case, the host MUST send an R1bis message and otherwise ignore the Update Request message.
由于可以重用上下文标记，主机必须验证IPv6源地址字段是否是Ls（对等）的一部分，以及IPv6目标地址字段是否是Ls（本地）的一部分。如果不是这种情况，则更新请求的发送方有一个过时的上下文，该上下文恰好与此上下文的CT（本地）匹配。在这种情况下，主机必须发送R1bis消息，否则将忽略更新请求消息。
If a CGA Parameter Data Structure (PDS) is included in the message, then the host MUST verify if the actual PDS contained in the packet corresponds to the ULID(peer). If this verification fails, the message is silently discarded.
如果消息中包含CGA参数数据结构（PDS），则主机必须验证数据包中包含的实际PDS是否对应于ULID（对等）。如果此验证失败，消息将被自动丢弃。
Then, depending on the STATE of the context:
然后，根据上下文的状态：
o If ESTABLISHED, proceed to process message.
o 如果建立，则继续处理消息。
o If I1-SENT, discard the message and stay in I1-SENT.
o 如果I1-SENT，则丢弃该消息并保持I1-SENT状态。
o If I2-SENT, send I2 and proceed to process the message.
o 如果I2已发送，则发送I2并继续处理该消息。
o If I2BIS-SENT, send I2bis and proceed to process the message.
o 如果I2BIS-SENT，则发送I2BIS并继续处理该消息。
The verification issues for the locators carried in the Update Request message are specified in Section 7.2. If the locator list cannot be verified, this procedure should send a Shim6 Error message with Error Code=2. In any case, if it cannot be verified, there is no further processing of the Update Request.
第7.2节规定了更新请求消息中所载定位器的验证问题。如果无法验证定位器列表，此过程应发送错误代码为2的Shim6错误消息。在任何情况下，如果无法验证，则不会进一步处理更新请求。
Once any Locator List option in the Update Request has been verified, the peer generation number in the context is updated to be the one in the Locator List option.
验证更新请求中的任何定位器列表选项后，上下文中的对等生成编号将更新为定位器列表选项中的编号。
If the Update Request message contains a Locator Preference option, then the generation number in the preference option is compared with the peer generation number in the context. If they do not match, then the host generates a Shim6 Error message with Error Code=3 and with the Pointer field referring to the first octet in the Locator List Generation number in the Locator Preference option. In addition, if the number of elements in the Locator Preference option does not match the number of locators in Ls(peer), then a Shim6 Error message with Error Code=4 is sent with the Pointer field referring to the first octet of the Length field in the Locator Preference option. In both cases of failure, no further processing is performed for the Update Request message.
如果更新请求消息包含定位器首选项选项，则首选项选项中的生成编号将与上下文中的对等生成编号进行比较。如果它们不匹配，则主机生成一条错误代码为3的Shim6错误消息，指针字段引用定位器首选项选项中定位器列表生成编号中的第一个八位字节。此外，如果定位器首选项选项中的元素数量与Ls（对等）中的定位器数量不匹配，则发送错误代码为4的Shim6错误消息，指针字段引用定位器首选项选项中长度字段的第一个八位字节。在这两种故障情况下，不会对更新请求消息执行进一步的处理。
If the generation numbers match, the locator preferences are recorded in the context.
如果生成编号匹配，则定位器首选项将记录在上下文中。
Once the Locator List option (if present) has been verified and any new locator list or locator preferences have been recorded, the host sends an Update Acknowledgement message, copying the nonce from the request and using the CT(peer) as the Receiver Context Tag.
一旦验证了定位器列表选项（如果存在）并且记录了任何新的定位器列表或定位器首选项，主机将发送更新确认消息，从请求中复制nonce并使用CT（对等）作为接收器上下文标记。
Any new locators (or, more likely, new locator preferences) might result in the host wanting to select a different locator pair for the context -- for instance, if the Locator Preferences option lists the current Lp(peer) as BROKEN. The host uses the reachability exploration procedure described in [4] to verify that the new locator is reachable before changing Lp(peer).
任何新的定位器（或者更可能是新的定位器首选项）都可能导致主机想要为上下文选择不同的定位器对——例如，如果定位器首选项将当前Lp（对等）列为已断开。主机使用[4]中所述的可达性探索程序，在更改Lp（对等）之前验证新定位器是否可达。
A host MUST silently discard any received Update Acknowledgement messages that do not satisfy all of the following validity checks in addition to those specified in Section 12.3:
除第12.3节规定的有效性检查外，主机必须以静默方式丢弃任何未满足以下所有有效性检查的接收到的更新确认消息：
o The Hdr Ext Len field is at least 1, i.e., the length is at least 16 octets.
o Hdr Ext Len字段至少为1，即长度至少为16个八位字节。
Upon the reception of an Update Acknowledgement message, the host extracts the Context Tag and the Request Nonce from the message. It then looks for a context that has a CT(local) that matches the Context Tag. If no such context is found, it sends an R1bis message as specified in Section 7.17.
在接收到更新确认消息后，主机从消息中提取上下文标记和请求Nonce。然后，它将查找具有与上下文标记匹配的CT（本地）的上下文。如果未找到此类上下文，则发送第7.17节规定的R1bis消息。
Since Context Tags can be reused, the host MUST verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If this is not the case, the sender of the Update Acknowledgement has a stale context that happens to match the CT(local) for this context. In this case, the host MUST send an R1bis message and otherwise ignore the Update Acknowledgement message.
由于可以重用上下文标记，主机必须验证IPv6源地址字段是否是Ls（对等）的一部分，以及IPv6目标地址字段是否是Ls（本地）的一部分。如果不是这种情况，则更新确认的发送方有一个过时的上下文，该上下文恰好与此上下文的CT（本地）匹配。在这种情况下，主机必须发送R1bis消息，否则将忽略更新确认消息。
Then, depending on the STATE of the context:
然后，根据上下文的状态：
o If ESTABLISHED, proceed to process message.
o 如果建立，则继续处理消息。
o If I1-SENT, discard the message and stay in I1-SENT.
o 如果I1-SENT，则丢弃该消息并保持I1-SENT状态。
o If I2-SENT, send R2 and proceed to process the message.
o 如果I2已发送，则发送R2并继续处理该消息。
o If I2BIS-SENT, send R2 and proceed to process the message.
o 如果I2B已发送，则发送R2并继续处理该消息。
If the Request Nonce doesn't match the nonce for the last sent Update Request for the context, then the Update Acknowledgement is silently ignored. If the nonce matches, then the update has been completed and the Update retransmit timer can be reset.
如果请求Nonce与上一次发送的上下文更新请求的Nonce不匹配，则会自动忽略更新确认。如果nonce匹配，则更新已完成，可以重置更新重传计时器。
When there is no context state for the ULID pair on the sender, there is no effect on how ULP packets are sent. If the host is using some heuristic for determining when to perform a deferred context establishment, then the host might need to do some accounting (count the number of packets sent and received) even before there is a ULID-pair context.
当发送方上的ULID对没有上下文状态时，对ULP数据包的发送方式没有影响。如果主机正在使用某种启发式方法来确定何时执行延迟上下文建立，那么即使在存在ULID对上下文之前，主机也可能需要进行一些记帐（计算发送和接收的数据包的数量）。
If the context is not in ESTABLISHED or I2BIS-SENT STATE, then there is also no effect on how the ULP packets are sent. Only in the ESTABLISHED and I2BIS-SENT STATEs does the host have CT(peer) and Ls(peer) set.
如果上下文未处于已建立或I2BIS-SENT状态，则对ULP数据包的发送方式也没有影响。只有在已建立和I2BIS-SENT状态下，主机才会设置CT（对等）和Ls（对等）。
If there is a ULID-pair context for the ULID pair, then the sender needs to verify whether the context uses the ULIDs as locators -- that is, whether Lp(peer) == ULID(peer) and Lp(local) == ULID(local).
如果ULID对存在ULID对上下文，那么发送方需要验证上下文是否使用ULID作为定位器——即Lp（peer）==ULID（peer）和Lp（local）==ULID（local）。
If this is the case, then packets can be sent unmodified by the shim. If it is not the case, then the logic in Section 11.1 will need to be used.
如果是这种情况，那么数据包可以不经垫片修改地发送。如果不是这样，则需要使用第11.1节中的逻辑。
There will also be some maintenance activity relating to (un)reachability detection, whether or not packets are sent with the original locators. The details of this are out of scope for this document and are specified in [4].
还将有一些与（非）可达性检测相关的维护活动，无论包是否与原始定位器一起发送。这方面的详细信息超出了本文件的范围，并在[4]中进行了规定。
When sending packets, if there is a ULID-pair context for the ULID pair, and if the ULID pair is no longer used as the locator pair, then the sender needs to transform the packet. Apart from replacing the IPv6 Source and Destination fields with a locator pair, an 8-octet header is added so that the receiver can find the context and inverse the transformation.
发送数据包时，如果ULID对存在ULID对上下文，并且如果ULID对不再用作定位器对，则发送方需要转换数据包。除了用定位器对替换IPv6源和目标字段外，还添加了一个8-octet报头，以便接收方可以找到上下文并反转转换。
If there has been a failure causing a switch, and later the context switches back to sending things using the ULID pair as the locator pair, then there is no longer a need to do any packet transformation by the sender; hence, there is no need to include the 8-octet Extension header.
如果出现了导致切换的故障，并且随后上下文切换回使用ULID对作为定位器对发送东西，则发送方不再需要进行任何分组转换；因此，不需要包括8-octet扩展头。
First, the IP address fields are replaced. The IPv6 Source Address field is set to Lp(local) and the Destination Address field is set to Lp(peer). Note that this MUST NOT cause any recalculation of the ULP checksums, since the ULP checksums are carried end-to-end and the ULP pseudo-header contains the ULIDs that are preserved end-to-end.
首先，替换IP地址字段。IPv6源地址字段设置为Lp（本地），目标地址字段设置为Lp（对等）。请注意，这不得导致ULP校验和的任何重新计算，因为ULP校验和是端到端进行的，并且ULP伪报头包含端到端保留的ULID。
The sender skips any "Routing Sublayer Extension headers" that the ULP might have included; thus, it skips any Hop-by-Hop Extension header, any Routing header, and any Destination Options header that is followed by a Routing header. After any such headers, the Shim6 Extension header will be added. This might be before a Fragment header, a Destination Options header, an ESP or AH header, or a ULP header.
发送方跳过ULP可能包含的任何“路由子层扩展头”；因此，它跳过任何逐跳扩展头、任何路由头和后跟路由头的任何目的地选项头。在任何这样的头之后，将添加Shim6扩展头。这可能在片段头、目标选项头、ESP或AH头或ULP头之前。
The inserted Shim6 Payload Extension header includes the peer's Context Tag. It takes on the Next Header value from the preceding Extension header, since that Extension header will have a Next Header value of Shim6.
插入的Shim6有效负载扩展头包括对等方的上下文标记。它接受上一个扩展标头的下一个标头值，因为该扩展标头的下一个标头值为Shim6。
The receive side of the communication can receive packets associated to a Shim6 context, with or without the Shim6 Extension header. In case the ULID pair is being used as a locator pair, the packets received will not have the Shim6 Extension header and will be processed by the Shim6 layer as described below. If the received packet does carry the Shim6 Extension header, as in normal IPv6 receive-side packet processing, the receiver parses the (extension) headers in order. Should it find a Shim6 Extension header, it will look at the "P" field in that header. If this bit is zero, then the packet must be passed to the Shim6 payload handling for rewriting. Otherwise, the packet is passed to the Shim6 control handling.
通信的接收端可以接收与Shim6上下文相关联的数据包，包括或不包括Shim6扩展头。在ULID对被用作定位器对的情况下，所接收的分组将不具有Shim6扩展报头，并且将由Shim6层进行如下所述的处理。如果接收到的数据包确实携带了Shim6扩展头，就像在正常的IPv6接收端数据包处理中一样，那么接收器将按顺序解析（扩展）头。如果它找到一个Shim6扩展头，它将查看该头中的“P”字段。如果该位为零，则必须将数据包传递给Shim6有效负载处理以进行重写。否则，数据包将传递给Shim6控制处理。
The receiver extracts the IPv6 Source and Destination fields and uses this to find a ULID-pair context, such that the IPv6 address fields match the ULID(local) and ULID(peer). If such a context is found, the context appears not to be quiescent; this should be remembered in order to avoid tearing down the context and for reachability detection purposes as described in [4]. The host continues with the normal processing of the IP packet.
接收器提取IPv6源和目标字段，并使用此字段查找ULID对上下文，以便IPv6地址字段与ULID（本地）和ULID（对等）匹配。如果找到了这样的上下文，那么上下文似乎不是静止的；应记住这一点，以避免破坏上下文，并达到[4]中所述的可达性检测目的。主机继续正常处理IP数据包。
The receiver extracts the Context Tag from the Shim6 Payload Extension header and uses this to find a ULID-pair context. If no context is found, the receiver SHOULD generate an R1bis message (see Section 7.17).
接收器从Shim6有效负载扩展头中提取上下文标记，并使用该标记查找ULID对上下文。如果未找到上下文，接收方应生成R1bis消息（见第7.17节）。
Then, depending on the STATE of the context:
然后，根据上下文的状态：
o If ESTABLISHED, proceed to process message.
o 如果建立，则继续处理消息。
o If I1-SENT, discard the message and stay in I1-SENT.
o 如果I1-SENT，则丢弃该消息并保持I1-SENT状态。
o If I2-SENT, send I2 and proceed to process the message.
o 如果I2已发送，则发送I2并继续处理该消息。
o If I2BIS-SENT, send I2bis and proceed to process the message.
o 如果I2BIS-SENT，则发送I2BIS并继续处理该消息。
With the context in hand, the receiver can now replace the IP address fields with the ULIDs kept in the context. Finally, the Shim6 Payload Extension header is removed from the packet (so that the ULP doesn't get confused by it), and the Next Header value in the preceding header is set to be the actual protocol number for the payload. Then the packet can be passed to the protocol identified by the Next Header value (which might be some function associated with the IP endpoint sublayer or a ULP).
有了上下文，接收方现在可以用上下文中保存的ulid替换IP地址字段。最后，从数据包中删除Shim6有效负载扩展报头（以便ULP不会被它弄糊涂），并将前一报头中的下一个报头值设置为有效负载的实际协议号。然后，可以将数据包传递给由下一个报头值（可能是与IP端点子层或ULP相关联的某个函数）标识的协议。
If the host is using some heuristic for determining when to perform a deferred context establishment, then the host might need to do some accounting (count the number of packets sent and received) for packets that do not have a Shim6 Extension header and for which there is no context. But the need for this depends on what heuristics the implementation has chosen.
如果主机正在使用某种启发式方法来确定何时执行延迟上下文建立，那么主机可能需要对没有Shim6扩展头且没有上下文的数据包进行一些记帐（计算发送和接收的数据包数量）。但这一需求取决于实现所选择的启发式。
A shim control message has the Checksum field verified. The Shim Header Length field is also verified against the length of the IPv6 packet to make sure that the shim message doesn't claim to end past the end of the IPv6 packet. Finally, it checks that neither the IPv6 Destination field nor the IPv6 Source field is a multicast address or an unspecified address. If any of those checks fail, the packet is silently dropped.
垫片控制消息已验证校验和字段。还将根据IPv6数据包的长度验证Shim Header Length字段，以确保Shim消息不会声明结束于IPv6数据包的结尾。最后，它检查IPv6目标字段和IPv6源字段是否都不是多播地址或未指定的地址。如果这些检查中的任何一个失败，数据包将被无声地丢弃。
The message is then dispatched based on the shim message type. Each message type is then processed as described elsewhere in this document. If the packet contains a shim message type that is unknown to the receiver, then a Shim6 Error message with Error Code=0 is generated and sent back. The Pointer field is set to point at the first octet of the shim message type.
然后根据垫片消息类型发送消息。然后按照本文档其他地方的说明处理每种消息类型。如果数据包包含接收器未知的垫片消息类型，则生成并发回错误代码为0的Shim6错误消息。指针字段设置为指向垫片消息类型的第一个八位字节。
All the control messages can contain any options with C=0. If there is any option in the message with C=1 that isn't known to the host, then the host MUST send a Shim6 Error message with Error Code=1 with the Pointer field referencing the first octet of the Option Type.
所有控制消息都可以包含C=0的任何选项。如果主机不知道消息中C=1的任何选项，则主机必须发送错误代码为1的Shim6错误消息，指针字段引用选项类型的第一个八位字节。
We assume that each shim context has its own STATE machine. We assume that a dispatcher delivers incoming packets to the STATE machine that it belongs to. Here, we describe the rules used for the dispatcher to deliver packets to the correct shim context STATE machine.
我们假设每个垫片上下文都有自己的状态机。我们假设调度器将传入的数据包传递给它所属的状态机。这里，我们描述调度器将数据包传递到正确的shim上下文状态机所使用的规则。
There is one STATE machine per identified context that is conceptually identified by the ULID pair and Forked Instance Identifier (which is zero by default) or identified by CT(local). However, the detailed lookup rules are more complex, especially during context establishment.
每个已识别的上下文都有一个状态机，它在概念上由ULID对和分叉实例标识符（默认为零）标识，或者由CT（本地）标识。但是，详细的查找规则更加复杂，尤其是在上下文建立期间。
Clearly, if the required context is not established, it will be in IDLE STATE.
显然，如果未建立所需的上下文，它将处于空闲状态。
During context establishment, the context is identified as follows:
在上下文建立过程中，上下文的标识如下：
o I1 packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
o I1数据包：传递到与ULID对和分叉实例标识符关联的上下文。
o I2 packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
o I2数据包：传递到与ULID对和分叉实例标识符关联的上下文。
o R1 packets: Deliver to the context with the locator pair included in the packet and the Initiator Nonce included in the packet (R1 does not contain a ULID pair or the CT(local)). If no context exists with this locator pair and Initiator Nonce, then silently discard.
o R1数据包：通过数据包中包含的定位器对和数据包中包含的启动器Nonce（R1不包含ULID对或CT（本地））传递到上下文。如果此定位器对和启动器Nonce不存在上下文，则静默放弃。
o R2 packets: Deliver to the context with the locator pair included in the packet and the Initiator Nonce included in the packet (R2 does not contain a ULID pair or the CT(local)). If no context exists with this locator pair and Initiator Nonce, then silently discard.
o R2数据包：通过数据包中包含的定位器对和数据包中包含的启动器Nonce（R2不包含ULID对或CT（本地））传递到上下文。如果此定位器对和启动器Nonce不存在上下文，则静默放弃。
o R1bis packets: Deliver to the context that has the locator pair and the CT(peer) equal to the Packet Context Tag included in the R1bis packet.
o R1bis数据包：传递到具有定位器对和CT（对等）等于R1bis数据包中包含的数据包上下文标记的上下文。
o I2bis packets: Deliver to the context associated with the ULID pair and the Forked Instance Identifier.
o I2bis数据包：传递到与ULID对和分叉实例标识符关联的上下文。
o Shim6 Payload Extension headers: Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet.
o Shim6有效负载扩展头：将CT（本地）等于数据包中包含的接收方上下文标记的内容传递到上下文。
o Other control messages (Update, Keepalive, Probe): Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet. Verify that the IPv6 Source Address field is part of Ls(peer) and that the IPv6 Destination Address field is part of Ls(local). If not, send an R1bis message.
o 其他控制消息（Update、Keepalive、Probe）：传递到上下文，其中CT（local）等于数据包中包含的接收方上下文标记。验证IPv6源地址字段是否为Ls（对等）的一部分，以及IPv6目标地址字段是否为Ls（本地）的一部分。如果没有，发送R1bis消息。
o Shim6 Error messages and ICMP errors that contain a Shim6 Payload Extension header or other shim control packet in the "packet in error": Use the "packet in error" for dispatching as follows. Deliver to the context with CT(peer) equal to the Receiver Context Tag -- Lp(local) being the IPv6 source address and Lp(peer) being the IPv6 destination address.
o “数据包出错”中包含Shim6有效负载扩展头或其他垫片控制数据包的Shim6错误消息和ICMP错误：使用“数据包出错”进行调度，如下所示。传递到上下文，CT（peer）等于接收方上下文标记——Lp（local）是IPv6源地址，Lp（peer）是IPv6目标地址。
In addition, the shim on the sending side needs to be able to find the context state when a ULP packet is passed down from the ULP. In that case, the lookup key is the pair of ULIDs and FII=0. If we have a ULP API that allows the ULP to do context forking, then presumably the ULP would pass down the Forked Instance Identifier.
此外，当ULP数据包从ULP向下传递时，发送端的垫片需要能够找到上下文状态。在这种情况下，查找键是ulid和FII=0的对。如果我们有一个允许ULP进行上下文分叉的ULP API，那么ULP可能会传递分叉实例标识符。
The initial contact is some non-shim communication between two ULIDs, as described in Section 2. At that point in time, there is no activity in the shim.
初始接触是两个ULID之间的一些非垫片通信，如第2节所述。此时，垫片中没有任何活动。
Whether or not the shim ends up being used (e.g., the peer might not support Shim6), it is highly desirable that the initial contact can be established even if there is a failure for one or more IP addresses.
无论垫片是否最终被使用（例如，对等方可能不支持Shim6），即使一个或多个IP地址出现故障，也非常希望能够建立初始联系。
The approach taken is to rely on the applications and the transport protocols to retry with different source and destination addresses, consistent with what is already specified in "Default Address Selection for IPv6" [7] as well as with some fixes to that specification [9], to make it try different source addresses and not only different destination addresses.
所采取的方法是依靠应用程序和传输协议使用不同的源地址和目标地址重试，这与“IPv6的默认地址选择”[7]中已经指定的内容以及对该规范的一些修复一致[9]，要使它成为一个新的应用程序，请尝试不同的源地址，而不仅仅是不同的目标地址。
The implementation of such an approach can potentially result in long timeouts. For instance, consider a naive implementation at the socket API that uses getaddrinfo() to retrieve all destination addresses and then tries to bind() and connect() to try all source and destination address combinations and waits for TCP to time out for each combination before trying the next one.
这种方法的实施可能会导致长时间的超时。例如，在Socket API中使用一个天真的实现，使用GETAdRunFuffe（）来检索所有的目标地址，然后尝试绑定（）和连接（）来尝试所有的源地址和目的地址组合，并等待TCP在尝试下一个组合之前超时。
However, if implementations encapsulate this in some new connect-by-name() API and use non-blocking connect calls, it is possible to cycle through the available combinations in a more rapid manner until a working source and destination pair is found. Thus, the issues in this domain are issues of implementations and the current socket API, and not issues of protocol specification. In all honesty, while providing an easy to use connect-by-name() API for TCP and other connection-oriented transports is easy, providing a similar
但是，如果实现将其封装在一些新的connect-by-name（）API中，并使用非阻塞连接调用，则可以以更快速的方式循环使用可用的组合，直到找到工作的源和目标对。因此，这个领域的问题是实现和当前套接字API的问题，而不是协议规范的问题。老实说，虽然为TCP和其他面向连接的传输提供易于使用的connect-by-name（）API很容易，但提供类似的
capability at the API for UDP is hard due to the protocol itself not providing any "success" feedback. Yet, even the UDP issue is one of APIs and implementation.
由于协议本身不提供任何“成功”反馈，UDP API的功能很难实现。然而，甚至UDP问题也是API和实现的问题之一。
The protocol uses the following constants:
协议使用以下常量：
I1_RETRIES_MAX = 4
I1_RETRIES_MAX = 4
I1_TIMEOUT = 4 seconds
I1_TIMEOUT = 4 seconds
NO_R1_HOLDDOWN_TIME = 1 min
NO_R1_HOLDDOWN_TIME = 1 min
ICMP_HOLDDOWN_TIME = 10 min
ICMP_HOLDDOWN_TIME = 10 min
I2_TIMEOUT = 4 seconds
I2_TIMEOUT = 4 seconds
I2_RETRIES_MAX = 2
I2_RETRIES_MAX = 2
I2bis_TIMEOUT = 4 seconds
I2bis_TIMEOUT = 4 seconds
I2bis_RETRIES_MAX = 2
I2bis_RETRIES_MAX = 2
VALIDATOR_MIN_LIFETIME = 30 seconds
VALIDATOR_MIN_LIFETIME = 30 seconds
UPDATE_TIMEOUT = 4 seconds
UPDATE_TIMEOUT = 4 seconds
MAX_UPDATE_TIMEOUT = 120 seconds
MAX_UPDATE_TIMEOUT = 120 seconds
The retransmit timers (I1_TIMEOUT, I2_TIMEOUT, UPDATE_TIMEOUT) are subject to binary exponential backoff as well as to randomization across a range of 0.5 and 1.5 times the nominal (backed off) value. This removes any risk of synchronization between lots of hosts performing independent shim operations at the same time.
重传计时器（I1_超时、I2_超时、更新_超时）受到二进制指数回退以及在标称（回退）值的0.5到1.5倍范围内的随机化的影响。这消除了同时执行独立垫片操作的许多主机之间的同步风险。
The randomization is applied after the binary exponential backoff. Thus, the first retransmission would happen based on a uniformly distributed random number in the range of [0.5*4, 1.5*4] seconds; the second retransmission, [0.5*8, 1.5*8] seconds after the first one, etc.
在二元指数退避后应用随机化。因此，第一次重传将基于[0.5×4,1.5×4]秒范围内的均匀分布的随机数发生；第二次重传在第一次重传后[0.5*8,1.5*8]秒，以此类推。
When the locator pair currently used for exchanging packets in a Shim6 context becomes unreachable, the Shim6 layer will divert the communication through an alternative locator pair, which in most cases will result in redirecting the packet flow through an alternative network path. In this case, it is recommended that the Shim6 follows the recommendation defined in [21] and informs the upper layers about the path change, in order to allow the congestion control mechanisms of the upper layers to react accordingly.
当当前用于交换Shim6上下文中的分组的定位器对变得不可访问时，Shim6层将通过替代定位器对转移通信，这在大多数情况下将导致通过替代网络路径重定向分组流。在这种情况下，建议Shim6遵循[21]中定义的建议，并将路径变化通知上层，以允许上层的拥塞控制机制做出相应反应。
Data packets belonging to a Shim6 context carrying the Shim6 Payload header contain alternative locators other than the ULIDs in the Source and Destination Address fields of the IPv6 header. On the other hand, the upper layers of the peers involved in the communication operate on the ULID pair presented to them by the Shim6 layer, rather than on the locator pair contained in the IPv6 header of the actual packets. It should be noted that the Shim6 layer does not modify the data packets but, because a constant ULID pair is presented to upper layers irrespective of the locator pair changes, the relation between the upper-layer header (such as TCP, UDP, ICMP, ESP, etc) and the IPv6 header is modified. In particular, when the Shim6 Extension header is present in the packet, if those data packets are TCP, UDP, or ICMP packets, the pseudo-header used for the checksum calculation will contain the ULID pair, rather than the locator pair contained in the data packet.
属于承载Shim6有效负载报头的Shim6上下文的数据包在IPv6报头的源和目标地址字段中包含除ULID之外的其他定位器。另一方面，参与通信的对等方的上层在由Shim6层呈现给它们的ULID对上操作，而不是在实际分组的IPv6报头中包含的定位器对上操作。应该注意，Shim6层不修改数据分组，但是，由于无论定位器对如何更改，都会向上层提供一个恒定的ULID对，因此修改了上层报头（例如TCP、UDP、ICMP、ESP等）与IPv6报头之间的关系。特别是，当数据包中存在Shim6扩展报头时，如果这些数据包是TCP、UDP或ICMP数据包，则用于校验和计算的伪报头将包含ULID对，而不是数据包中包含的定位器对。
It is possible that some firewalls or other middle-boxes will try to verify the validity of upper-layer sanity checks of the packet on the fly. If they do that based on the actual source and destination addresses contained in the IPv6 header without considering the Shim6 context information (in particular, without replacing the locator pair by the ULID pair used by the Shim6 context), such verifications may fail. Those middle-boxes need to be updated in order to be able to parse the Shim6 Payload header and find the next header. It is recommended that firewalls and other middle-boxes do not drop packets that carry the Shim6 Payload header with apparently incorrect upper-layer validity checks that involve the addresses in the IPv6 header for their computation, unless they are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair for the verification of the validity check.
一些防火墙或其他中间框可能会尝试在运行中验证数据包的上层健全性检查的有效性。如果它们基于IPv6报头中包含的实际源地址和目标地址而不考虑Shim6上下文信息（特别是，没有用Shim6上下文使用的ULID对替换定位器对），则此类验证可能失败。这些中间框需要更新，以便能够解析Shim6有效负载头并找到下一个头。建议防火墙和其他中间盒不要丢弃带有明显不正确的上层有效性检查（涉及IPv6报头中用于计算的地址）的Shim6有效负载报头的数据包，除非他们能够确定与数据包关联的Shim6上下文的ULID对，并使用ULID对验证有效性检查。
In the particular case of TCP, UDP, and ICMP checksums, it is recommended that firewalls and other middle-boxes do not drop TCP, UDP, and ICMP packets that carry the Shim6 Payload header with apparently incorrect checksums when using the addresses in the IPv6 header for the pseudo-header computation, unless they are able to determine the ULID pair of the Shim6 context associated to the data packet and use the ULID pair to determine the checksum that must be present in a packet with addresses rewritten by Shim6.
在TCP、UDP和ICMP校验和的特殊情况下，建议防火墙和其他中间盒在使用IPv6报头中的地址进行伪报头计算时，不要丢弃带有明显错误校验和的Shim6有效负载报头的TCP、UDP和ICMP数据包，除非他们能够确定与数据包关联的Shim6上下文的ULID对，并使用ULID对确定地址由Shim6重写的数据包中必须存在的校验和。
In addition, firewalls that today pass limited traffic, e.g., outbound TCP connections, would presumably block the Shim6 protocol. This means that even when Shim6-capable hosts are communicating, the I1 messages would be dropped; hence, the hosts would not discover that their peer is Shim6-capable. This is, in fact, a benefit since, if the hosts managed to establish a ULID-pair context, the firewall would probably drop the "different" packets that are sent after a failure (those using the Shim6 Payload Extension header with a TCP packet inside it). Thus, stateful firewalls that are modified to pass Shim6 messages should also be modified to pass the Shim6 Payload Extension header so that the shim can use the alternate locators to recover from failures. This presumably implies that the firewall needs to track the set of locators in use by looking at the Shim6 control exchanges. Such firewalls might even want to verify the locators using the HBA/CGA verification themselves, which they can do without modifying any of the Shim6 packets through which they pass.
此外，今天通过有限流量（例如出站TCP连接）的防火墙可能会阻止Shim6协议。这意味着，即使支持Shim6的主机正在通信，I1消息也会被丢弃；因此，主机不会发现其对等机支持Shim6。事实上，这是一个好处，因为如果主机设法建立一个ULID对上下文，防火墙可能会丢弃故障后发送的“不同”数据包（那些使用Shim6有效负载扩展头并在其中包含TCP数据包的数据包）。因此，修改为传递Shim6消息的有状态防火墙也应修改为传递Shim6有效负载扩展头，以便垫片可以使用备用定位器从故障中恢复。这可能意味着防火墙需要通过查看Shim6控制交换来跟踪正在使用的定位器集。此类防火墙甚至可能希望使用HBA/CGA验证本身来验证定位器，而无需修改它们传递的任何Shim6数据包。
This section considers some aspects related to the operations and management of the Shim6 protocol.
本节考虑与Shim6协议的运行和管理相关的一些方面。
Deployment of the Shim6 protocol: The Shim6 protocol is a host-based solution. So, in order to be deployed, the stacks of the hosts using the Shim6 protocol need to be updated to support it. This enables an incremental deployment of the protocol since it does not require a flag day for the deployment -- just single host updates. If the Shim6 solution will be deployed in a site, the host can be gradually updated to support the solution. Moreover, for supporting the Shim6 protocol, only end hosts need to be updated and no router changes are required. However, it should be noted that, in order to benefit from the Shim6 protocol, both ends of a communication should support the protocol, meaning that both hosts must be updated to be able to use the Shim6 protocol. Nevertheless, the Shim6 protocol uses a deferred context-setup capability that allows end hosts to establish normal IPv6 communications and, later on, if both endpoints are Shim6- capable, establish the Shim6 context using the Shim6 protocol. This
Shim6协议的部署：Shim6协议是基于主机的解决方案。因此，为了部署，需要更新使用Shim6协议的主机堆栈以支持它。这支持协议的增量部署，因为部署不需要标志日——只需要单主机更新。如果将在站点中部署Shim6解决方案，则可以逐步更新主机以支持该解决方案。此外，为了支持Shim6协议，只需要更新终端主机，不需要更改路由器。但是，应该注意，为了从Shim6协议中获益，通信的两端都应该支持该协议，这意味着必须更新两台主机才能使用Shim6协议。然而，Shim6协议使用延迟上下文设置功能，允许终端主机建立正常的IPv6通信，然后，如果两个端点都支持Shim6，则使用Shim6协议建立Shim6上下文。这
has an important deployment benefit, since Shim6-enabled nodes can talk perfectly to non-Shim6-capable nodes without introducing any problem into the communication.
具有重要的部署优势，因为启用了Shim6的节点可以与不支持Shim6的节点完美对话，而不会给通信带来任何问题。
Configuration of Shim6-capable nodes: The Shim6 protocol itself does not require any specific configuration to provide its basic features. The Shim6 protocol is designed to provide a default service to upper layers that should satisfy general applications. The Shim6 layer would automatically attempt to protect long-lived communications by triggering the establishment of the Shim6 context using some predefined heuristics. Of course, if some special tunning is required by some applications, this may require additional configuration. Similar considerations apply to a site attempting to perform some forms of traffic engineering by using different preferences for different locators.
支持Shim6的节点的配置：Shim6协议本身不需要任何特定的配置来提供其基本功能。Shim6协议旨在为上层提供一个默认服务，以满足一般应用。Shim6层将自动尝试通过使用一些预定义的试探法触发Shim6上下文的建立来保护长期通信。当然，如果某些应用程序需要一些特殊的调谐，这可能需要额外的配置。类似的考虑也适用于试图通过对不同的定位器使用不同的首选项来执行某些形式的交通工程的站点。
Address and prefix configuration: The Shim6 protocol assumes that, in a multihomed site, multiple prefixes will be available. Such configuration can increase the operation work in a network. However, it should be noted that the capability of having multiple prefixes in a site and multiple addresses assigned to an interface is an IPv6 capability that goes beyond the Shim6 case, and it is expected to be widely used. So, even though this is the case for Shim6, we consider that the implications of such a configuration is beyond the particular case of Shim6 and must be addressed for the generic IPv6 case. Nevertheless, Shim6 also assumes the usage of CGA/HBA addresses by Shim6 hosts. This implies that Shim6-capable hosts should configure addresses using HBA/CGA generation mechanisms. Additional consideration about this issue can be found at [19].
地址和前缀配置：Shim6协议假设在多址站点中，有多个前缀可用。这种配置可以增加网络中的操作工作量。然而，应该注意的是，在一个站点中具有多个前缀并为一个接口分配多个地址的能力是一种IPv6能力，它超越了Shim6的情况，预计将被广泛使用。因此，即使这是SHIM6的情况，我们认为这样的配置的影响超出了SIM6的特定情况，并且必须针对通用IPv6情况来解决。然而，Shim6还假设Shim6主机使用CGA/HBA地址。这意味着支持Shim6的主机应该使用HBA/CGA生成机制配置地址。关于这个问题的更多考虑可参见[19]。
The general Shim6 approach as well as the specifics of this proposed solution have implications elsewhere, including:
一般的Shim6方法以及该拟议解决方案的细节在其他方面具有影响，包括：
o Applications that perform referrals or callbacks using IP addresses as the 'identifiers' can still function in limited ways, as described in [18]. But, in order for such applications to be able to take advantage of the multiple locators for redundancy, the applications need to be modified to either use Fully Qualified Domain Names as the 'identifiers' or they need to pass all the locators as the 'identifiers', i.e., the 'identifier' from the application's perspective becomes a set of IP addresses instead of a single IP address.
o 使用IP地址作为“标识符”执行转介或回调的应用程序仍然可以以有限的方式运行，如[18]所述。但是，为了使此类应用程序能够利用多个定位器实现冗余，需要修改应用程序以使用完全限定的域名作为“标识符”，或者它们需要将所有定位器作为“标识符”传递，即。，从应用程序的角度来看，“标识符”成为一组IP地址，而不是单个IP地址。
o Signaling protocols for QoS or for other things that involve having devices in the network path look at IP addresses and port numbers (or at IP addresses and Flow Labels) need to be invoked on
o 需要在网络上调用用于QoS的信令协议或涉及让网络路径中的设备查看IP地址和端口号（或IP地址和流标签）的其他内容的信令协议
the hosts when the locator pair changes due to a failure. At that point in time, those protocols need to inform the devices that a new pair of IP addresses will be used for the flow. Note that this is the case even though this protocol, unlike some earlier proposals, does not overload the Flow Label as a Context Tag; the in-path devices need to know about the use of the new locators even though the Flow Label stays the same.
定位器对因故障而更改时的主机。此时，这些协议需要通知设备一对新的IP地址将用于流。注意，这种情况下，即使这个协议，不像以前的一些建议，没有过载流标签作为上下文标签；路径内设备需要知道新定位器的使用情况，即使流标签保持不变。
o MTU implications. By computing a minimum over the recently observed path MTUs, the path MTU mechanisms we use are robust against different packets taking different paths through the Internet. When Shim6 fails over from using one locator pair to another, this means that packets might travel over a different path through the Internet; hence, the path MTU might be quite different. In order to deal with this change in the MTU, the usage of Packetization Layer Path MTU Discovery as defined in [24] is recommended.
o MTU的影响。通过计算最近观察到的路径MTU上的最小值，我们使用的路径MTU机制对通过Internet的不同路径的不同数据包具有鲁棒性。当Shim6从一个定位器对故障切换到另一个定位器对时，这意味着数据包可能通过互联网的不同路径传输；因此，MTU的路径可能完全不同。为了处理MTU中的这种变化，建议使用[24]中定义的打包层路径MTU发现。
The fact that the shim will add an 8-octet Shim6 Payload Extension header to the ULP packets after a locator switch can also affect the usable path MTU for the ULPs. In this case, the MTU change is local to the sending host; thus, conveying the change to the ULPs is an implementation matter. By conveying the information to the transport layer, it can adapt and reduce the Maximum Segment Size (MSS) accordingly.
垫片将在定位器开关之后向ULP数据包添加8-octet Shim6有效负载扩展报头的事实也会影响ULP的可用路径MTU。在这种情况下，MTU更改是发送主机的本地更改；因此，将更改传递给ULP是一个实现问题。通过将信息传输到传输层，它可以相应地调整和减小最大段大小（MSS）。
This document satisfies the concerns specified in [15] as follows:
本文件满足[15]中规定的问题，如下所示：
o The HBA [3] and CGA [2] techniques for verifying the locators to prevent an attacker from redirecting the packet stream to somewhere else, prevent threats described in Sections 4.1.1, 4.1.2, 4.1.3, and 4.2 of [15]. These two techniques provide a similar level of protection but also provide different functionality with different computational costs.
o HBA[3]和CGA[2]技术用于验证定位器，以防止攻击者将数据包流重定向到其他地方，防止[15]第4.1.1、4.1.2、4.1.3和4.2节所述的威胁。这两种技术提供了相似的保护级别，但也以不同的计算成本提供了不同的功能。
The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach, addresses incorporate a cryptographic one-way hash of the prefix set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the alternative addresses proposed for continuing the communication are bound to the initial address through a simple hash calculation.
HBA机制依赖于将多宿主主机的所有地址生成为一组不可更改的内部绑定IPv6地址（称为HBA集）的能力。在这种方法中，地址将前缀集的加密单向散列合并到接口标识符部分中。结果是，所有可用地址之间的绑定在地址本身中进行编码，从而提供劫持保护。使用shim协议节点的任何对等方都可以通过简单的散列计算有效地验证为继续通信而提议的备选地址是否绑定到初始地址。
In a CGA-based approach, the address used as the ULID is a CGA that contains a hash of a public key in its interface identifier. The result is a secure binding between the ULID and the associated key pair. This allows each peer to use the corresponding private key to sign the shim messages that convey locator set information. The trust chain in this case is the following: the ULID used for the communication is securely bound to the key pair because it contains the hash of the public key, and the locator set is bound to the public key through the signature.
在基于CGA的方法中，用作ULID的地址是在其接口标识符中包含公钥散列的CGA。结果是ULID和关联密钥对之间的安全绑定。这允许每个对等方使用相应的私钥对传递定位器集信息的垫片消息进行签名。在这种情况下，信任链如下：用于通信的ULID安全地绑定到密钥对，因为它包含公钥的散列，定位器集通过签名绑定到公钥。
Either of these two mechanisms, HBA and CGA, provides time-shifted attack protection (as described in Section 4.1.2 of [15]), since the ULID is securely bound to a locator set that can only be defined by the owner of the ULID. The minimum acceptable key length for RSA keys used in the generation of CGAs MUST be at least 1024 bits. Any implementation should follow prudent cryptographic practice in determining the appropriate key lengths.
这两种机制（HBA和CGA）中的任何一种都提供时移攻击保护（如[15]第4.1.2节所述），因为ULID安全地绑定到只能由ULID所有者定义的定位器集。用于生成CGA的RSA密钥的最小可接受密钥长度必须至少为1024位。在确定适当的密钥长度时，任何实现都应遵循谨慎的加密实践。
o 3rd party flooding attacks, described in Section 4.3 of [15], are prevented by requiring a Shim6 peer to perform a successful Reachability probe + reply exchange before accepting a new locator for use as a packet destination.
o [15]第4.3节中描述的第三方洪泛攻击通过要求Shim6对等方在接受用作数据包目的地的新定位器之前执行成功的可达性探测+应答交换来防止。
o The first message does not create any state on the responder. Essentially, a 3-way exchange is required before the responder creates any state. This means that a state-based DoS attack (trying to use up all memory on the responder) at least requires the attacker to create state, consuming his own resources; it also provides an IPv6 address that the attacker was using.
o 第一条消息不会在响应程序上创建任何状态。本质上，在响应者创建任何状态之前，需要进行三方交换。这意味着基于状态的DoS攻击（试图耗尽响应程序上的所有内存）至少需要攻击者创建状态，消耗自己的资源；它还提供了攻击者正在使用的IPv6地址。
o The context-establishment messages use nonces to prevent replay attacks, which are described in Section 4.1.4 of [15], and to prevent off-path attackers from interfering with the establishment.
o 上下文建立消息使用nonce来防止[15]第4.1.4节中描述的重播攻击，并防止非路径攻击者干扰建立。
o Every control message of the Shim6 protocol, past the context establishment, carry the Context Tag assigned to the particular context. This implies that an attacker needs to discover that Context Tag before being able to spoof any Shim6 control message as described in Section 4.4 of [15]. Such discovery probably requires an attacker to be along the path in order to sniff the Context Tag value. The result is that, through this technique, the Shim6 protocol is protected against off-path attackers.
o Shim6协议的每个控制消息，经过上下文建立后，都带有分配给特定上下文的上下文标记。这意味着攻击者需要在能够欺骗任何Shim6控制消息之前发现该上下文标记，如[15]第4.4节所述。这种发现可能需要攻击者沿着路径嗅探上下文标记值。结果是，通过这种技术，可以保护Shim6协议免受非路径攻击者的攻击。
Shim6 has two modes of processing data packets. If the ULID pair is also the locator pair being used, then the data packet is not modified by Shim6. In this case, the interaction with IPSec is exactly the same as if the Shim6 layer was not present in the host.
Shim6有两种处理数据包的模式。如果ULID对也是正在使用的定位器对，那么数据包不会被Shim6修改。在这种情况下，与IPSec的交互与主机中不存在Shim6层时完全相同。
If the ULID pair differs from the current locator pair for that Shim6 context, then Shim6 will take the data packet, replace the ULIDs contained in the IP Source and Destination Address fields with the current locator pair, and add the Shim6 extension with the corresponding Context Tag. In this case, as is mentioned in Section 1.6, Shim6 conceptually works as a tunnel mechanism, where the inner header contains the ULID and the outer header contains the locators. The main difference is that the inner header is "compressed" and a compression tag, namely the Context Tag, is added to decompress the inner header at the receiving end.
如果ULID对与该Shim6上下文的当前定位器对不同，则Shim6将获取数据包，用当前定位器对替换IP源和目标地址字段中包含的ULID，并使用相应的上下文标记添加Shim6扩展。在这种情况下，如第1.6节所述，Shim6在概念上作为隧道机制工作，其中内部收割台包含ULID，外部收割台包含定位器。主要区别在于内部头是“压缩”的，并且添加了压缩标记，即上下文标记，以在接收端解压缩内部头。
In this case, the interaction between IPSec and Shim6 is then similar to the interaction between IPSec and a tunnel mechanism. When the packet is generated by the upper-layer protocol, it is passed to the IP layer containing the ULIDs in the IP Source and Destination field. IPSec is then applied to this packet. Then the packet is passed to the Shim6 sublayer, which "encapsulates" the received packet and includes a new IP header containing the locator pair in the IP Source and Destination field. This new IP packet is in turn passed to IPSec for processing, just as in the case of a tunnel. This can be viewed as if IPSec is located both above and below the Shim6 sublayer and as if IPSec policies apply both to ULIDs and locators.
在这种情况下，IPSec和Shim6之间的交互类似于IPSec和隧道机制之间的交互。当数据包由上层协议生成时，它被传递到包含IP源和目标字段中的ULID的IP层。然后将IPSec应用于该数据包。然后，数据包被传递到Shim6子层，该子层“封装”接收到的数据包，并在IP源和目标字段中包含包含定位器对的新IP报头。这个新的IP数据包依次被传递到IPSec进行处理，就像在隧道中一样。这可以被视为IPSec位于Shim6子层的上方和下方，并且IPSec策略同时应用于ULID和定位器。
When IPSec processed the packet after the Shim6 sublayer has processed it (i.e., the packet carrying the locators in the IP Source and Destination Address field), the Shim6 sublayer may have added the Shim6 Extension header. In that case, IPSec needs to skip the Shim6 Extension header to find the selectors for the next layer's protocols (e.g., TCP, UDP, Stream Control Transmission Protocol (SCTP)).
当IPSec在Shim6子层处理数据包后处理该数据包时（即，在IP源和目标地址字段中携带定位器的数据包），Shim6子层可能已添加了Shim6扩展头。在这种情况下，IPSec需要跳过Shim6扩展头来查找下一层协议（例如TCP、UDP、流控制传输协议（SCTP））的选择器。
When a packet is received at the other end, it is processed based on the order of the extension headers. Thus, if an ESP or AH header precedes a Shim6 header, that determines the order. Shim6 introduces the need to do policy checks, analogous to how they are done for tunnels, when Shim6 receives a packet and the ULID pair for that packet is not identical to the locator pair in the packet.
当在另一端接收到数据包时，将根据扩展头的顺序对其进行处理。因此，如果ESP或AH头位于Shim6头之前，则决定顺序。当Shim6接收到数据包且该数据包的ULID对与数据包中的定位器对不相同时，Shim6引入了执行策略检查的需要，类似于对隧道执行策略检查的方式。
Some of the residual threats in this proposal are:
本提案中的一些剩余威胁包括：
o An attacker that arrives late on the path (after the context has been established) can use the R1bis message to cause one peer to re-create the context and, at that point in time, can observe all of the exchange. But this doesn't seem to open any new doors for the attacker since such an attacker can observe the Context Tags that are being used and, once known, can use those to send bogus messages.
o 延迟到达路径的攻击者（在建立上下文后）可以使用R1bis消息使一个对等方重新创建上下文，并在该时间点观察所有交换。但这似乎并没有为攻击者打开任何新的大门，因为这样的攻击者可以观察正在使用的上下文标记，一旦知道，就可以使用这些标记发送虚假消息。
o An attacker present on the path in order to find out the Context Tags can generate an R1bis message after it has moved off the path. For this packet to be effective, it needs to have a source locator that belongs to the context; thus, there cannot be "too much" ingress filtering between the attacker's new location and the communicating peers. But this doesn't seem to be that severe because, once the R1bis causes the context to be re-established, a new pair of Context Tags will be used, which will not be known to the attacker. If this is still a concern, we could require a 2-way handshake, "did you really lose the state?", in response to the error message.
o 存在于路径上以找出上下文标记的攻击者可在其移出路径后生成R1bis消息。为了使这个包有效，它需要有一个属于上下文的源定位器；因此，在攻击者的新位置和通信对等方之间不会有“太多”的入口过滤。但这似乎没有那么严重，因为一旦R1bis导致重新建立上下文，就会使用一对新的上下文标记，而攻击者不知道这些标记。如果这仍然是一个问题，我们可能需要双向握手，“您真的失去了状态吗？”，以响应错误消息。
o It might be possible for an attacker to try random 47-bit Context Tags and see if they can cause disruption for communication between two hosts. In particular, in the case of payload packets, the effects of such an attack would be similar to those of an attacker sending packets with a spoofed source address. In the case of control packets, it is not enough to find the correct Context Tag -- additional information is required (e.g., nonces, proper source addresses; see previous bullet for the case of R1bis). If a 47-bit tag, which is the largest that fits in an 8-octet Extension header, isn't sufficient, one could use an even larger tag in the Shim6 control messages and use the low-order 47 bits in the Shim6 Payload Extension header.
o 攻击者可能会尝试随机的47位上下文标记，并查看它们是否会导致两台主机之间的通信中断。特别是，在有效载荷数据包的情况下，此类攻击的效果类似于攻击者发送具有伪造源地址的数据包的效果。在控制数据包的情况下，仅仅找到正确的上下文标记是不够的——需要额外的信息（例如，nonce、正确的源地址；R1bis的情况见前面的项目符号）。如果一个47位的标签（8-octet扩展头中的最大标签）不够，可以在Shim6控制消息中使用更大的标签，并在Shim6有效负载扩展头中使用低阶47位。
o When the Shim6 Payload Extension header is used, an attacker that can guess the 47-bit random Context Tag can inject packets into the context with any source locator. Thus, if there is ingress filtering between the attacker and its target, this could potentially allow the attacker to bypass the ingress filtering. However, in addition to guessing the 47-bit Context Tag, the attacker also needs to find a context where, after the receiver's replacement of the locators with the ULIDs, the ULP checksum is correct. But even this wouldn't be sufficient with ULPs like TCP, since the TCP port numbers and sequence numbers must match an existing connection. Thus, even though the issues for off-path
o 使用Shim6有效负载扩展标头时，能够猜出47位随机上下文标记的攻击者可以使用任何源定位器将数据包注入上下文。因此，如果攻击者与其目标之间存在入口过滤，这可能允许攻击者绕过入口过滤。但是，除了猜测47位上下文标记外，攻击者还需要找到一个上下文，在接收者用ULID替换定位器后，ULP校验和是正确的。但对于像TCP这样的ULP，即使这样也不够，因为TCP端口号和序列号必须与现有连接匹配。因此，即使这些问题偏离了轨道
attackers injecting packets are different than today with ingress filtering, it is still very hard for an off-path attacker to guess. If IPsec is applied, then the issue goes away completely.
注入数据包的攻击者与现在的入口过滤不同，对于非路径攻击者来说，猜测仍然非常困难。如果应用了IPsec，那么问题就完全消失了。
o The validator included in the R1 and R1bis packets is generated as a hash of several input parameters. While most of the inputs are actually determined by the sender, and only the secret value S is unknown to the sender, the resulting protection is deemed to be enough since it would be easier for the attacker to just obtain a new validator by sending an I1 packet than to perform all the computations required to determine the secret S. Nevertheless, it is recommended that the host change the secret S periodically.
o R1和R1bis数据包中包含的验证器作为多个输入参数的散列生成。虽然大多数输入实际上是由发送方确定的，并且只有机密值S是发送方未知的，但由此产生的保护被认为是足够的，因为对于攻击者来说，通过发送I1数据包来获取新的验证器比执行确定机密S所需的所有计算更容易。然而，建议主机定期更改密码。
IANA allocated a new IP Protocol Number value (140) for the Shim6 Protocol.
IANA为Shim6协议分配了一个新的IP协议编号值（140）。
IANA recorded a CGA message type for the Shim6 protocol in the CGA Extension Type Tags registry with the value 0x4A30 5662 4858 574B 3655 416F 506A 6D48.
IANA在CGA扩展类型标记注册表中记录了Shim6协议的CGA消息类型，其值为0x4A30 5662 4858 574B 3655 416F 506A 6D48。
IANA established a Shim6 Parameter Registry with four components: Shim6 Type registrations, Shim6 Options registrations, Shim6 Error Code registrations, and Shim6 Verification Method registrations.
IANA建立了一个包含四个组件的Shim6参数注册表：Shim6类型注册、Shim6选项注册、Shim6错误代码注册和Shim6验证方法注册。
The initial contents of the Shim6 Type registry are as follows:
Shim6类型注册表的初始内容如下：
+------------+-----------------------------------------------------+
| Type Value | Message |
+------------+-----------------------------------------------------+
| 0 | RESERVED |
| 1 | I1 (first establishment message from the initiator) |
| 2 | R1 (first establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to a R1bis message) |
| 7-59 | Allocated using Standards action |
| 60-63 | For Experimental use |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
| 69-123 | Allocated using Standards action |
| 124-127 | For Experimental use |
+------------+-----------------------------------------------------+
+------------+-----------------------------------------------------+
| Type Value | Message |
+------------+-----------------------------------------------------+
| 0 | RESERVED |
| 1 | I1 (first establishment message from the initiator) |
| 2 | R1 (first establishment message from the responder) |
| 3 | I2 (2nd establishment message from the initiator) |
| 4 | R2 (2nd establishment message from the responder) |
| 5 | R1bis (Reply to reference to non-existent context) |
| 6 | I2bis (Reply to a R1bis message) |
| 7-59 | Allocated using Standards action |
| 60-63 | For Experimental use |
| 64 | Update Request |
| 65 | Update Acknowledgement |
| 66 | Keepalive |
| 67 | Probe Message |
| 68 | Error Message |
| 69-123 | Allocated using Standards action |
| 124-127 | For Experimental use |
+------------+-----------------------------------------------------+
The initial contents of the Shim6 Options registry are as follows:
Shim6选项注册表的初始内容如下：
+-------------+----------------------------------+
| Type | Option Name |
+-------------+----------------------------------+
| 0 | RESERVED |
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 8-9 | Allocated using Standards action |
| 10 | Keepalive Timeout Option |
| 11-16383 | Allocated using Standards action |
| 16384-32767 | For Experimental use |
+-------------+----------------------------------+
+-------------+----------------------------------+
| Type | Option Name |
+-------------+----------------------------------+
| 0 | RESERVED |
| 1 | Responder Validator |
| 2 | Locator List |
| 3 | Locator Preferences |
| 4 | CGA Parameter Data Structure |
| 5 | CGA Signature |
| 6 | ULID Pair |
| 7 | Forked Instance Identifier |
| 8-9 | Allocated using Standards action |
| 10 | Keepalive Timeout Option |
| 11-16383 | Allocated using Standards action |
| 16384-32767 | For Experimental use |
+-------------+----------------------------------+
The initial contents of the Shim6 Error Code registry are as follows:
Shim6错误代码注册表的初始内容如下：
+------------+--------------------------------------------+
| Code Value | Description |
+------------+--------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical Option not recognized |
| 2 | Locator verification method failed |
| 3 | Locator List Generation number out of sync |
| 4 | Error in the number of locators |
| 5-19 | Allocated using Standards action |
| 120-127 | Reserved for debugging purposes |
+------------+--------------------------------------------+
+------------+--------------------------------------------+
| Code Value | Description |
+------------+--------------------------------------------+
| 0 | Unknown Shim6 message type |
| 1 | Critical Option not recognized |
| 2 | Locator verification method failed |
| 3 | Locator List Generation number out of sync |
| 4 | Error in the number of locators |
| 5-19 | Allocated using Standards action |
| 120-127 | Reserved for debugging purposes |
+------------+--------------------------------------------+
The initial contents of the Shim6 Verification Method registry are as follows:
Shim6验证方法注册表的初始内容如下：
+---------+----------------------------------+
| Value | Verification Method |
+---------+----------------------------------+
| 0 | RESERVED |
| 1 | CGA |
| 2 | HBA |
| 3-200 | Allocated using Standards action |
| 201-254 | For Experimental use |
| 255 | RESERVED |
+---------+----------------------------------+
+---------+----------------------------------+
| Value | Verification Method |
+---------+----------------------------------+
| 0 | RESERVED |
| 1 | CGA |
| 2 | HBA |
| 3-200 | Allocated using Standards action |
| 201-254 | For Experimental use |
| 255 | RESERVED |
+---------+----------------------------------+
Over the years, many people active in the multi6 and shim6 WGs have contributed ideas and suggestions that are reflected in this specification. Special thanks to the careful comments from Sam Hartman, Cullen Jennings, Magnus Nystrom, Stephen Kent, Geoff Huston, Shinta Sugimoto, Pekka Savola, Dave Meyer, Deguang Le, Jari Arkko, Iljitsch van Beijnum, Jim Bound, Brian Carpenter, Sebastien Barre, Matthijs Mekking, Dave Thaler, Bob Braden, Wesley Eddy, Pasi Eronen, and Tom Henderson on earlier versions of this document.
多年来，许多活跃于multi6和shim6工作组的人员都提出了一些想法和建议，这些想法和建议反映在本规范中。特别感谢Sam Hartman、Cullen Jennings、Magnus Nystrom、Stephen Kent、Geoff Huston、Shinta Sugimoto、Pekka Savola、Dave Meyer、Deguang Le、Jari Arkko、Iljitsch van Beijnum、Jim Bound、Brian Carpenter、Sebastien Barre、Matthijs Mekking、Dave Thaler、Bob Braden、Wesley Eddy、Pasi Eronen的细心评论，和Tom Henderson在这份文件的早期版本上。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[2] Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[3] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[3] Bagnulo，M.，“基于哈希的地址（HBA）”，RFC 55352009年6月。
[4] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[4] Arkko，J.和I.van Beijnum，“IPv6多宿的故障检测和定位器对探测协议”，RFC 5534，2009年6月。
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[6] Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[7] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[7] Draves，R.，“因特网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[8] Nordmark, E., "Multihoming without IP Identifiers", Work in Progress, July 2004.
[8] Nordmark，E.，“无IP标识符的多宿”，正在进行的工作，2004年7月。
[9] Bagnulo, M., "Updating RFC 3484 for multihoming support", Work in Progress, November 2007.
[9] Bagnulo，M.，“更新RFC 3484以获得多宿支持”，正在进行的工作，2007年11月。
[10] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[10] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[11] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[11] Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[12] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, "IPv6 Flow Label Specification", RFC 3697, March 2004.
[12] Rajahalme，J.，Conta，A.，Carpenter，B.，和S.Deering，“IPv6流标签规范”，RFC 36972004年3月。
[13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[13] Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
[14] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[14] Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC4193，2005年10月。
[15] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[15] Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，2005年10月。
[16] Huitema, C., "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, September 2005.
[16] Huitema，C.，“IPv6多宿主站点的入口过滤兼容性”，正在进行的工作，2005年9月。
[17] Bagnulo, M. and E. Nordmark, "SHIM - MIPv6 Interaction", Work in Progress, July 2005.
[17] Bagnulo，M.和E.Nordmark，“垫片-MIPv6相互作用”，正在进行的工作，2005年7月。
[18] Nordmark, E., "Shim6-Application Referral Issues", Work in Progress, July 2005.
[18] Nordmark，E.，“Shim6应用程序转介问题”，正在进行的工作，2005年7月。
[19] Bagnulo, M. and J. Abley, "Applicability Statement for the Level 3 Multihoming Shim Protocol (Shim6)", Work in Progress, July 2007.
[19] Bagnulo，M.和J.Abley，“3级多宿主垫片协议（Shim6）的适用性声明”，正在进行的工作，2007年7月。
[20] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[20] Moskowitz，R.，Nikander，P.，Jokela，P.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[21] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[21] Schuetz，S.，Koutsianas，N.，Eggert，L.，Eddy，W.，Swami，Y.，和K.Le，“TCP对下层连接变化指示的响应”，正在进行的工作，2008年2月。
[22] Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008.
[22] Williams，N.和M.Richardson，“比没有更好的安全性：未经验证的IPsec模式”，RFC 5386，2008年11月。
[23] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, "Socket Application Program Interface (API) for Multihoming Shim", Work in Progress, November 2008.
[23] Komu，M.，Bagnulo，M.，Slavov，K.，和S.Sugimoto，“多主垫片的套接字应用程序接口（API）”，正在进行的工作，2008年11月。
[24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[24] Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
[25] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007.
[25] Bonica，R.，Gan，D.，Tappan，D.，和C.Pignataro，“扩展ICMP以支持多部分消息”，RFC 4884，2007年4月。
During the development of this protocol, several issues have been brought up that are important to address but that do not need to be in the base protocol itself; instead, these can be done as extensions to the protocol. The key ones are:
在本协议的制定过程中，提出了几个重要的问题，需要解决，但基本协议本身不需要解决；相反，这些可以作为协议的扩展。关键是：
o As stated in the assumptions in Section 3, in order for the Shim6 protocol to be able to recover from a wide range of failures (for instance, when one of the communicating hosts is single-homed) and to cope with a site's ISPs that do ingress filtering based on the source IPv6 address, there is a need for the host to be able to influence the egress selection from its site. Further discussion of this issue is captured in [16].
o 如第3节中的假设所述，为了使Shim6协议能够从各种故障中恢复（例如，当其中一台通信主机为单主机时），并应对基于源IPv6地址进行入口过滤的站点ISP，主机需要能够影响其站点的出口选择。关于这个问题的进一步讨论见[16]。
o Is there need for keeping the list of locators private between the two communicating endpoints? We can potentially accomplish that when using CGA (not when using HBA), but only at the cost of doing some public key encryption and decryption operations as part of the context establishment. The suggestion is to leave this for a future extension to the protocol.
o 是否需要在两个通信端点之间保持定位器列表的私有性？我们可以在使用CGA时（而不是在使用HBA时）潜在地实现这一点，但代价是作为上下文建立的一部分执行一些公钥加密和解密操作。建议将此保留下来，以便将来对议定书进行扩展。
o Defining some form of end-to-end "compression" mechanism that removes the need to include the Shim6 Payload Extension header when the locator pair is not the ULID pair.
o 定义某种形式的端到端“压缩”机制，当定位器对不是ULID对时，不需要包括Shim6有效负载扩展头。
o Supporting the dynamic setting of locator preferences on a site-wide basis and using the Locator Preference option in the Shim6 protocol to convey these preferences to remote communicating hosts. This could mirror the DNS SRV record's notion of priority and weight.
o 支持在站点范围内动态设置定位器首选项，并使用Shim6协议中的定位器首选项将这些首选项传递给远程通信主机。这可能反映DNS SRV记录的优先级和权重概念。
o Specifying APIs in order for the ULPs to be aware of the locators that the shim is using and to be able to influence the choice of locators (controlling preferences as well as triggering a locator-pair switch). This includes providing APIs that the ULPs can use to fork a shim context.
o 指定API，以便ULP了解垫片正在使用的定位器，并能够影响定位器的选择（控制首选项以及触发定位器对开关）。这包括提供ULP可用于派生垫片上下文的API。
o Determining whether it is feasible to relax the suggestions for when context state is removed so that one can end up with an asymmetric distribution of the context state and still get (most of) the shim benefits. For example, the busy server would go through the context setup but would quickly remove the context state after this (in order to save memory); however, the not-so-busy client would retain the context state. The context-recovery mechanism presented in Section 7.5 would then re-create the state should the client send either a shim control message (e.g., Probe message because it sees a problem) or a ULP packet in a Shim6
o 确定在删除上下文状态时放松建议是否可行，这样就可以得到上下文状态的非对称分布，并且仍然可以获得（大部分）好处。例如，繁忙的服务器将进行上下文设置，但随后会快速删除上下文状态（以节省内存）；但是，不太繁忙的客户端将保留上下文状态。第7.5节中介绍的上下文恢复机制将在客户端发送垫片控制消息（例如，由于发现问题而发送探测消息）或Shim6中的ULP数据包时重新创建状态
Payload Extension header (because it had earlier failed over to an alternative locator pair but had been silent for a while). This seems to provide the benefits of the shim as long as the client can detect the failure. If the client doesn't send anything and it is the server that tries to send, then it will not be able to recover because the shim on the server has no context state and hence doesn't know any alternate locator pairs.
有效负载扩展标头（因为它先前已故障切换到另一个定位器对，但已沉默了一段时间）。这似乎提供了垫片的好处，只要客户端能够检测到故障。如果客户端不发送任何内容，而尝试发送的是服务器，那么它将无法恢复，因为服务器上的垫片没有上下文状态，因此不知道任何备用定位器对。
o Study what it would take to make the Shim6 control protocol not rely at all on a stable source locator in the packets. This can probably be accomplished by having all the shim control messages include the ULID-pair option.
o 研究如何使Shim6控制协议完全不依赖于数据包中的稳定源定位器。这可能通过让所有垫片控制消息包括ULID对选项来实现。
o If each host might have lots of locators, then the current requirement to include essentially all of them in the I2 and R2 messages might be constraining. If this is the case, we can look into using the CGA Parameter Data Structure for the comparison, instead of the prefix sets, to be able to detect context confusion. This would place some constraint on a (logical) only using, for example, one CGA public key; it would also require some carefully crafted rules on how two PDSs are compared for "being the same host". But if we don't expect more than a handful of locators per host, then we don't need this added complexity.
o 如果每个主机可能都有很多定位器，那么在I2和R2消息中包含所有定位器的当前需求可能会受到限制。如果是这种情况，我们可以研究使用CGA参数数据结构进行比较，而不是前缀集，以便能够检测上下文混淆。这将对仅使用（例如）一个CGA公钥的（逻辑）应用程序设置一些约束；它还需要一些精心编制的规则，说明如何比较两个PDS的“同一主机”。但是，如果我们不希望每个主机有超过几个定位器，那么我们就不需要增加这种复杂性。
o ULP-specified timers for the reachability detection mechanism (which can be particularly useful when there are forked contexts).
o ULP为可达性检测机制指定了计时器（当存在分叉上下文时，该机制特别有用）。
o Pre-verify some "backup" locator pair, so that the failover time can be shorter.
o 预先验证一些“备份”定位器对，以便缩短故障切换时间。
o Study how Shim6 and Mobile IPv6 might interact [17].
o 研究Shim6和移动IPv6如何相互作用[17]。
The STATEs are defined in Section 6.2. The intent is for the stylized description below to be consistent with the textual description in the specification; however, should they conflict, the textual description is normative.
第6.2节对这些状态进行了定义。目的是使下面的样式化描述与规范中的文本描述一致；但是，如果它们冲突，文本描述是规范性的。
The following table describes the possible actions in STATE IDLE and their respective triggers:
下表描述了空闲状态下可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay in IDLE |
| | |
| Heuristics trigger | Send I1 and move to I1-SENT |
| a new context | |
| establishment | |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and | ESTABLISHED |
| RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| R1, R1bis, R2 | N/A (This context lacks the required info |
| | for the dispatcher to deliver them) |
| | |
| Receive Payload | Send R1bis and stay in IDLE |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1 | Send R1 and stay in IDLE |
| | |
| Heuristics trigger | Send I1 and move to I1-SENT |
| a new context | |
| establishment | |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and | ESTABLISHED |
| RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, stay in IDLE |
| | |
| R1, R1bis, R2 | N/A (This context lacks the required info |
| | for the dispatcher to deliver them) |
| | |
| Receive Payload | Send R1bis and stay in IDLE |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I1-SENT and their respective triggers:
下表描述了状态I1-SENT中可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R1, verify | If successful, send I2 and move to I2-SENT |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I1 | Send R2 and stay in I1-SENT |
| | |
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Timeout, increment | If counter =< I1_RETRIES_MAX, send I1 and |
| timeout counter | stay in I1-SENT |
| | |
| | If counter > I1_RETRIES_MAX, go to E-FAILED |
| | |
| Receive ICMP payload| Move to E-FAILED |
| unknown error | |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Discard and stay in I1-SENT |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R1, verify | If successful, send I2 and move to I2-SENT |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I1 | Send R2 and stay in I1-SENT |
| | |
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2, verify | If successful, send R2 and move to |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Receive I2bis, | If successful, send R2 and move to |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | If fail, discard and stay in I1-SENT |
| | |
| Timeout, increment | If counter =< I1_RETRIES_MAX, send I1 and |
| timeout counter | stay in I1-SENT |
| | |
| | If counter > I1_RETRIES_MAX, go to E-FAILED |
| | |
| Receive ICMP payload| Move to E-FAILED |
| unknown error | |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Discard and stay in I1-SENT |
| Extension header | |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I2-SENT and their respective triggers:
下表描述了状态I2-SENT中可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2-SENT |
| | |
| Receive I1 | Send R2 and stay in I2-SENT |
| | |
| Receive I2, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2 and |
| timeout counter | stay in I2-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and go |
| | to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2 (probably R2 was sent |
| Extension header | by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2-SENT |
| | |
| Receive I1 | Send R2 and stay in I2-SENT |
| | |
| Receive I2, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2 and |
| timeout counter | stay in I2-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and go |
| | to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2 (probably R2 was sent |
| Extension header | by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE I2BIS-SENT and their respective triggers:
下表描述了I2BIS-SENT状态下可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2BIS-SENT |
| | |
| Receive I1 | Send R2 and stay in I2BIS-SENT |
| | |
| Receive I2, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2BIS-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2bis |
| timeout counter | and stay in I2BIS-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and |
| | go to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2bis (probably R2 was |
| Extension header | sent by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive R2, verify | If successful, move to ESTABLISHED |
| INIT Nonce | |
| | If fail, stay in I2BIS-SENT |
| | |
| Receive I1 | Send R2 and stay in I2BIS-SENT |
| | |
| Receive I2, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive I2bis, | Send R2 and stay in I2BIS-SENT |
| verify validator | |
| and RESP Nonce | |
| | |
| Receive R1 | Discard and stay in I2BIS-SENT |
| | |
| Timeout, increment | If counter =< I2_RETRIES_MAX, send I2bis |
| timeout counter | and stay in I2BIS-SENT |
| | |
| | If counter > I2_RETRIES_MAX, send I1 and |
| | go to I1-SENT |
| | |
| R1bis | N/A (Dispatcher doesn't deliver since |
| | CT(peer) is not set) |
| | |
| Receive Payload | Accept and send I2bis (probably R2 was |
| Extension header | sent by peer and lost) |
| or other control | |
| packet | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE ESTABLISHED and their respective triggers:
下表描述了处于已建立状态的可能操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1, compare | If no match, send R1 and stay in ESTABLISHED|
| CT(peer) with | |
| received CT | If match, send R2 and stay in ESTABLISHED |
| | |
| | |
| Receive I2, verify | If successful, send R2 and stay in |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive I2bis, | If successful, send R2 and stay in |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive R2 | Discard and stay in ESTABLISHED |
| | |
| Receive R1 | Discard and stay in ESTABLISHED |
| | |
| Receive R1bis | Send I2bis and move to I2BIS-SENT |
| | |
| | |
| Receive Payload | Process and stay in ESTABLISHED |
| Extension header | |
| or other control | |
| packet | |
| | |
| Implementation- | Discard state and go to IDLE |
| specific heuristic | |
| (e.g., No open ULP | |
| sockets and idle | |
| for some time ) | |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Receive I1, compare | If no match, send R1 and stay in ESTABLISHED|
| CT(peer) with | |
| received CT | If match, send R2 and stay in ESTABLISHED |
| | |
| | |
| Receive I2, verify | If successful, send R2 and stay in |
| validator and RESP | ESTABLISHED |
| Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive I2bis, | If successful, send R2 and stay in |
| verify validator | ESTABLISHED |
| and RESP Nonce | |
| | Otherwise, discard and stay in ESTABLISHED |
| | |
| Receive R2 | Discard and stay in ESTABLISHED |
| | |
| Receive R1 | Discard and stay in ESTABLISHED |
| | |
| Receive R1bis | Send I2bis and move to I2BIS-SENT |
| | |
| | |
| Receive Payload | Process and stay in ESTABLISHED |
| Extension header | |
| or other control | |
| packet | |
| | |
| Implementation- | Discard state and go to IDLE |
| specific heuristic | |
| (e.g., No open ULP | |
| sockets and idle | |
| for some time ) | |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE E-FAILED and their respective triggers:
下表描述了E-FAILED状态下可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| NO_R1_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| NO_R1_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
The following table describes the possible actions in STATE NO-SUPPORT and their respective triggers:
下表描述了NO-SUPPORT状态下可能的操作及其各自的触发器：
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| ICMP_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
+---------------------+---------------------------------------------+
| Trigger | Action |
+---------------------+---------------------------------------------+
| Wait for | Go to IDLE |
| ICMP_HOLDDOWN_TIME | |
| | |
| Any packet | Process as in IDLE |
+---------------------+---------------------------------------------+
Timeout/Null +------------+
I1/R1 +------------------| NO SUPPORT |
Payload or Control/R1bis | +------------+
+---------+ | ^
| | | ICMP Error/Null|
| V V |
+-----------------+ Timeout/Null +----------+ |
| |<---------------| E-FAILED | |
+-| IDLE | +----------+ |
I2 or I2bis/R2 | | | ^ |
| +-----------------+ (Tiemout#>MAX)/Null| |
| ^ | | |
| | +------+ | |
I2 or I2bis/R2 | | Heuristic/I1| I1/R2 | |
Payload/Null | | | Control/Null | |
I1/R1 or R2 | +--+ | Payload/Null | |
R1 or R2/Null | |Heuristic/Null | (Tiemout#<MAX)/I1 | |
+----------+ | | | +--------+ | |
| V V | | | V | |
+-------------------+ R2/Null | +----------------+
| | I2 or I2bis/R2 +------->| |
| ESTABLISHED |<----------------------------| I1-SENT |
| | | |
+-------------------+ +----------------+
| ^ ^ | ^ ^
| | |R2/Null +-------------+ | |
| | +----------+ |R1/I2 | |
| | | V | |
| | +------------------+ | |
| | | |-------------+ |
| | | I2-SENT | (Timeout#>Max)/I1 |
| | | | |
| | +------------------+ |
| | | ^ |
| | +--------------+ |
| | I1 or I2bis or I2/R2 |
| | (Timeout#<Max) or Payload/I2 |
| | R1 or R1bis/Null |
| +-------+ (Timeout#>Max)/I1 |
| R2/Null| +------------------------------------------+
| V |
| +-------------------+
| | |<-+ (Timeout#<Max)/I2bis
+-------->| I2bis-SENT | | I1 or I2 or I2bis/R2
R1bis/I2bis | |--+ R1 or R1bis/Null
+-------------------+ Payload/I2bis
Timeout/Null +------------+
I1/R1 +------------------| NO SUPPORT |
Payload or Control/R1bis | +------------+
+---------+ | ^
| | | ICMP Error/Null|
| V V |
+-----------------+ Timeout/Null +----------+ |
| |<---------------| E-FAILED | |
+-| IDLE | +----------+ |
I2 or I2bis/R2 | | | ^ |
| +-----------------+ (Tiemout#>MAX)/Null| |
| ^ | | |
| | +------+ | |
I2 or I2bis/R2 | | Heuristic/I1| I1/R2 | |
Payload/Null | | | Control/Null | |
I1/R1 or R2 | +--+ | Payload/Null | |
R1 or R2/Null | |Heuristic/Null | (Tiemout#<MAX)/I1 | |
+----------+ | | | +--------+ | |
| V V | | | V | |
+-------------------+ R2/Null | +----------------+
| | I2 or I2bis/R2 +------->| |
| ESTABLISHED |<----------------------------| I1-SENT |
| | | |
+-------------------+ +----------------+
| ^ ^ | ^ ^
| | |R2/Null +-------------+ | |
| | +----------+ |R1/I2 | |
| | | V | |
| | +------------------+ | |
| | | |-------------+ |
| | | I2-SENT | (Timeout#>Max)/I1 |
| | | | |
| | +------------------+ |
| | | ^ |
| | +--------------+ |
| | I1 or I2bis or I2/R2 |
| | (Timeout#<Max) or Payload/I2 |
| | R1 or R1bis/Null |
| +-------+ (Timeout#>Max)/I1 |
| R2/Null| +------------------------------------------+
| V |
| +-------------------+
| | |<-+ (Timeout#<Max)/I2bis
+-------->| I2bis-SENT | | I1 or I2 or I2bis/R2
R1bis/I2bis | |--+ R1 or R1bis/Null
+-------------------+ Payload/I2bis
The Shim6 protocol doesn't have a mechanism for coordinated state removal between the peers because such state removal doesn't seem to help, given that a host can crash and reboot at any time. A result of this is that the protocol needs to be robust against a Context Tag being reused for some other context. This section summarizes the different cases in which a Tag can be reused, and how the recovery works.
Shim6协议没有对等方之间协调状态删除的机制，因为这种状态删除似乎没有帮助，因为主机可能随时崩溃和重新启动。这样做的一个结果是，该协议需要对用于其他上下文的上下文标记具有鲁棒性。本节总结了可重用标记的不同情况，以及恢复的工作方式。
The different cases are exemplified by the following case. Assume hosts A and B were communicating using a context with the ULID pair <A1, B2>, and that B had assigned Context Tag X to this context. We assume that B uses only the Context Tag to demultiplex the received Shim6 Payload Extension headers, since this is the more general case. Further, we assume that B removes this context state, while A retains it. B might then at a later time assign CT(local)=X to some other context, at which time, we have several possible cases:
下面的案例举例说明了不同的案例。假设主机A和B使用一个上下文与ULID对<A1，B2>进行通信，并且B已将上下文标记X分配给该上下文。我们假设B只使用上下文标记来解复用接收到的Shim6有效负载扩展头，因为这是更一般的情况。此外，我们假设B删除了这个上下文状态，而A保留它。B随后可能会将CT（local）=X分配给其他上下文，此时，我们有几种可能的情况：
o The Context Tag is reassigned to a context for the same ULID pair <A1, B2>. We've called this "context recovery" in this document.
o 将上下文标记重新分配给同一ULID对<A1，B2>的上下文。我们在本文档中称之为“上下文恢复”。
o The Context Tag is reassigned to a context for a different ULID pair between the same two hosts, e.g., <A3, B3>. We've called this "context confusion" in this document.
o 将上下文标记重新分配给相同两台主机之间不同ULID对的上下文，例如，<A3，B3>。我们在本文档中称之为“上下文混淆”。
o The Context Tag is reassigned to a context between B and another host C, for instance, for the ULID pair <C3, B2>. That is a form of three-party context confusion.
o 例如，对于ULID对<C3，B2>，上下文标记被重新分配到B和另一个主机C之间的上下文。这是一种三方背景的混乱。
This case is relatively simple and is discussed in Section 7.5. The observation is that since the ULID pair is the same, when either A or B tries to establish the new context, A can keep the old context while B re-creates the context with the same Context Tag CT(B) = X.
这种情况相对简单，第7.5节对此进行了讨论。观察结果是，由于ULID对相同，当A或B尝试建立新上下文时，A可以保留旧上下文，而B使用相同的上下文标记CT（B）=X重新创建上下文。
This case is a bit more complex and is discussed in Section 7.6. When the new context is created, whether A or B initiates it, host A can detect when it receives B's locator set (in the I2 or R2 message) in that it ends up with two contexts to the same peer host (overlapping Ls(peer) locator sets) that have the same Context Tag: CT(peer) = X. At this point in time, host A can clear up any possibility of causing confusion by not using the old context to send any more packets. It either just discards the old context (it might not be used by any ULP traffic, since B had discarded it) or it re-
这种情况有点复杂，在第7.6节中讨论。创建新上下文时，无论是A还是B发起，主机A都可以检测何时接收到B的定位器集（在I2或R2消息中），因为它最终将两个上下文发送到具有相同上下文标记的同一对等主机（重叠的Ls（对等）定位器集）：CT（对等）=X。此时，主机A可以通过不使用旧的上下文发送更多的数据包来消除造成混淆的任何可能性。它要么只是丢弃旧的上下文（它可能不会被任何ULP通信使用，因为B已经丢弃了它），要么重新使用它-
creates a different context for the old ULID pair (<A1, B2>), for which B will assign a unique CT(B) as part of the normal context-establishment mechanism.
为旧ULID对（<A1，B2>）创建不同的上下文，B将为其分配唯一的CT（B），作为正常上下文建立机制的一部分。
The third case does not have a place where the old state on A can be verified since the new context is established between B and C. Thus, when B receives Shim6 Payload Extension headers with X as the Context Tag, it will find the context for <C3, B2> and, hence, will rewrite the packets to have C3 in the Source Address field and B2 in the Destination Address field before passing them up to the ULP. This rewriting is correct when the packets are in fact sent by host C, but if host A ever happens to send a packet using the old context, then the ULP on A sends a packet with ULIDs <A1, B2> and the packet arrives at the ULP on B with ULIDs <C3, B2>.
第三种情况没有一个地方可以验证a上的旧状态，因为新上下文是在B和C之间建立的。因此，当B接收到带有X作为上下文标记的Shim6有效负载扩展头时，它将找到<C3，B2>的上下文，因此，在将数据包传递到ULP之前，将重写数据包，使其在源地址字段中包含C3，在目标地址字段中包含B2。当数据包实际上由主机C发送时，这种重写是正确的，但是如果主机A碰巧使用旧上下文发送数据包，则A上的ULP发送ULID<A1，B2>的数据包，并且数据包到达B上的ULP，ULID<C3，B2>。
This is clearly an error, and the packet will most likely be rejected by the ULP on B due to a bad pseudo-header checksum. Even if the checksum is okay (probability 2^-16), the ULP isn't likely to have a connection for those ULIDs and port numbers. And if the ULP is connection-less, processing the packet is most likely harmless; such a ULP must be able to copy with random packets being sent by random peers in any case.
这显然是一个错误，并且由于错误的伪报头校验和，数据包很可能被B上的ULP拒绝。即使校验和正常（概率为2^-16），ULP也不太可能连接这些ULID和端口号。如果ULP连接较少，则处理数据包很可能是无害的；这样的ULP必须能够在任何情况下通过随机对等方发送的随机数据包进行复制。
This broken state, where packets are sent from A to B using the old context on host A, might persist for some time but will not remain for very long. The unreachability detection on host A will kick in because it does not see any return traffic (payload or Keepalive messages) for the context. This will result in host A sending Probe messages to host B to find a working locator pair. The effect of this is that host B will notice that it does not have a context for the ULID pair <A1, B2> and CT(B) = X, which will make host B send an R1bis packet to re-establish that context. The re-established context, just like in the previous section, will get a unique CT(B) assigned by host B; thus, there will no longer be any confusion.
这种中断状态，即使用主机A上的旧上下文将数据包从A发送到B，可能会持续一段时间，但不会持续很长时间。主机A上的不可访问性检测将启动，因为它没有看到上下文的任何返回流量（有效负载或Keepalive消息）。这将导致主机A向主机B发送探测消息以查找工作定位器对。这样做的效果是主机B将注意到它没有ULID对<A1，B2>和CT（B）=X的上下文，这将使主机B发送一个R1bis数据包来重新建立该上下文。与上一节一样，重新建立的上下文将获得由主机B分配的唯一CT（B）；因此，将不再有任何混乱。
In summary, there are cases where a Context Tag might be reused while some peer retains the state, but the protocol can recover from it. The probability of these events is low, given the 47-bit Context Tag size. However, it is important that these recovery mechanisms be tested. Thus, during development and testing, it is recommended that implementations not use the full 47-bit space but instead keep, for example, the top 40 bits as zero, only leaving the host with 128 unique Context Tags. This will help test the recovery mechanisms.
总之，在某些情况下，当某些对等方保留状态时，上下文标记可能被重用，但协议可以从中恢复。考虑到47位上下文标记的大小，这些事件的概率很低。但是，测试这些恢复机制很重要。因此，在开发和测试期间，建议实现不要使用完整的47位空间，而是将前40位保留为零，只留下128个唯一的上下文标记。这将有助于测试恢复机制。
This document has picked a certain set of design choices in order to try to work out a bunch of the details and to stimulate discussion. But, as has been discussed on the mailing list, there are other choices that make sense. This appendix tries to enumerate some alternatives.
本文档选择了一组特定的设计选项，以尝试解决一系列细节问题并激发讨论。但是，正如邮件列表中所讨论的，还有其他选择是有意义的。本附录试图列举一些备选方案。
Over the years, various suggestions have been made whether the shim should, even if it operates at the IP layer, be aware of ULP connections and sessions and, as a result, be able to make separate shim contexts for separate ULP connections and sessions. A few different options have been discussed:
多年来，人们提出了各种各样的建议，即即使shim在IP层运行，它是否应该了解ULP连接和会话，并因此能够为单独的ULP连接和会话创建单独的shim上下文。已经讨论了几个不同的选项：
o Each ULP connection maps to its own shim context.
o 每个ULP连接映射到其自己的垫片上下文。
o The shim is unaware of the ULP notion of connections and just operates on a host-to-host (IP address) granularity.
o shim不知道ULP连接的概念，只在主机到主机（IP地址）粒度上运行。
o Hybrids in which the shim is aware of some ULPs (such as TCP) and handles other ULPs on a host-to-host basis.
o shim知道某些ULP（如TCP）并在主机对主机的基础上处理其他ULP的混合。
Having shim state for every ULP connection potentially means higher overhead since the state-setup overhead might become significant; there is utility in being able to amortize this over multiple connections.
为每个ULP连接提供垫片状态可能意味着更高的开销，因为状态设置开销可能会变得更大；能够在多个连接上摊销这一点很有用。
But being completely unaware of the ULP connections might hamper ULPs that want different communication to use different locator pairs, for instance, for quality or cost reasons.
但完全不知道ULP连接可能会妨碍需要不同通信的ULP使用不同的定位器对，例如，出于质量或成本原因。
The protocol has a shim that operates with host-level granularity (strictly speaking, with ULID-pair granularity) to be able to amortize the context establishment over multiple ULP connections. This is combined with the ability for Shim6-aware ULPs to request context forking so that different ULP traffic can use different locator pairs.
该协议有一个使用主机级粒度（严格来说，使用ULID对粒度）操作的垫片，以便能够在多个ULP连接上分摊上下文建立。这与支持Shim6的ULP请求上下文分叉的能力相结合，以便不同的ULP流量可以使用不同的定位器对。
Once a ULID-pair context is established between two hosts, packets may carry locators that differ from the ULIDs presented to the ULPs using the established context. One of the main functions of the Shim6 layer is to perform the mapping between the locators used to forward packets through the network and the ULIDs presented to the ULP. In order to perform that translation for incoming packets, the
一旦在两个主机之间建立了ULID对上下文，分组就可以携带不同于使用所建立的上下文呈现给ulp的ULID的定位器。Shim6层的主要功能之一是执行用于通过网络转发数据包的定位器与呈现给ULP的ULID之间的映射。为了对传入的数据包执行该转换
Shim6 layer needs to first identify which of the incoming packets need to be translated and then perform the mapping between locators and ULIDs using the associated context. Such operation is called "demultiplexing". It should be noted that, because any address can be used both as a locator and as a ULID, additional information, other than the addresses carried in packets, needs to be taken into account for this operation.
Shim6层需要首先确定哪些传入数据包需要翻译，然后使用相关上下文执行定位器和ULID之间的映射。这种操作称为“解复用”。应当注意，由于任何地址都可以用作定位器和ULID，因此在该操作中需要考虑除了分组中携带的地址之外的附加信息。
For example, if a host has addresses A1 and A2 and starts communicating with a peer with addresses B1 and B2, then some communication (connections) might use the pair <A1, B1> as ULID and others might use, for example, <A2, B2>. Initially there are no failures, so these address pairs are used as locators, i.e., in the IP address fields in the packets on the wire. But when there is a failure, the Shim6 layer on A might decide to send packets that used <A1, B1> as ULIDs using <A2, B2> as the locators. In this case, B needs to be able to rewrite the IP address field for some packets and not others, but the packets all have the same locator pair.
例如，如果主机具有地址A1和A2，并开始与具有地址B1和B2的对等机通信，则某些通信（连接）可能会像ULID一样使用对<A1，B1>，而其他主机可能会使用，例如<A2，B2>。最初不存在故障，因此这些地址对用作定位器，即，在线路上数据包的IP地址字段中。但是当出现故障时，a上的Shim6层可能会决定使用<A1，B1>作为ULID发送数据包，并使用<A2，B2>作为定位器。在这种情况下，B需要能够重写某些数据包的IP地址字段，而不是其他数据包的IP地址字段，但是这些数据包都具有相同的定位器对。
In order to accomplish the demultiplexing operation successfully, data packets carry a Context Tag that allows the receiver of the packet to determine the shim context to be used to perform the operation.
为了成功完成解复用操作，数据分组携带上下文标记，该上下文标记允许分组的接收器确定用于执行该操作的垫片上下文。
Two mechanisms for carrying the Context Tag information have been considered in depth during the shim protocol design: those carrying the Context Tag in the Flow Label field of the IPv6 header and those using a new Extension header to carry the Context Tag. In this appendix, we will describe the pros and cons of each mechanism and justify the selected option.
在shim协议设计期间，已深入考虑了两种承载上下文标记信息的机制：在IPv6标头的流标签字段中承载上下文标记的机制和使用新扩展标头来承载上下文标记的机制。在本附录中，我们将描述每种机制的优缺点，并说明所选选项的合理性。
A possible approach is to carry the Context Tag in the Flow Label field of the IPv6 header. This means that when a Shim6 context is established, a Flow Label value is associated with this context (and perhaps a separate Flow Label for each direction).
一种可能的方法是在IPv6标头的流标签字段中携带上下文标记。这意味着当建立一个Shim6上下文时，一个流标签值与该上下文相关联（可能每个方向都有一个单独的流标签）。
The simplest way to do this is to have the triple <Flow Label, Source Locator, Destination Locator> identify the context at the receiver.
最简单的方法是让三重<Flow Label，Source Locator，Destination Locator>在接收方识别上下文。
The problem with this approach is that, because the locator sets are dynamic, it is not possible at any given moment to be sure that two contexts for which the same Context Tag is allocated will have disjoint locator sets during the lifetime of the contexts.
这种方法的问题在于，由于定位器集是动态的，因此在任何给定时刻都不可能确保为其分配相同上下文标记的两个上下文在上下文的生存期内具有不相交的定位器集。
Suppose that Node A has addresses IPA1, IPA2, IPA3, and IPA4 and that Host B has addresses IPB1 and IPB2.
假设节点A具有地址IPA1、IPA2、IPA3和IPA4，主机B具有地址IPB1和IPB2。
Suppose that two different contexts are established between Host A and Host B.
假设在主机A和主机B之间建立了两个不同的上下文。
Context #1 is using IPA1 and IPB1 as ULIDs. The locator set associated to IPA1 is IPA1 and IPA2, while the locator set associated to IPB1 is just IPB1.
上下文#1使用IPA1和IPB1作为ULID。与IPA1关联的定位器集为IPA1和IPA2，而与IPB1关联的定位器集仅为IPB1。
Context #2 uses IPA3 and IPB2 as ULIDs. The locator set associated to IPA3 is IPA3 and IPA4, while the locator set associated to IPB2 is just IPB2.
上下文#2使用IPA3和IPB2作为ULID。与IPA3关联的定位器集为IPA3和IPA4，而与IPB2关联的定位器集仅为IPB2。
Because the locator sets of Context #1 and Context #2 are disjoint, hosts could think that the same Context Tag value can be assigned to both of them. The problem arrives when, later on, IPA3 is added as a valid locator for IPA1 in Context #2 and IPB2 is added as a valid locator for IPB1 in Context #1. In this case, the triple <Flow Label, Source Locator, Destination Locator> would not identify a unique context anymore, and correct demultiplexing is no longer possible.
因为上下文#1和上下文#2的定位器集是不相交的，所以主机可能认为可以为它们分配相同的上下文标记值。当稍后将IPA3添加为上下文#2中IPA1的有效定位器，并将IPB2添加为上下文#1中IPB1的有效定位器时，问题就会出现。在这种情况下，三重<Flow Label，Source Locator，Destination Locator>将不再识别唯一的上下文，并且不再可能进行正确的解复用。
A possible approach to overcome this limitation is to simply not repeat the Flow Label values for any communication established in a host. This basically means that each time a new communication that is using different ULIDs is established, a new Flow Label value is assigned to it. By these means, each communication that is using different ULIDs can be differentiated because each has a different Flow Label value.
克服这一限制的一种可能方法是不重复主机中建立的任何通信的流标签值。这基本上意味着每次建立使用不同ulid的新通信时，都会为其分配一个新的流标签值。通过这些方法，可以区分使用不同ulid的每个通信，因为每个ulid具有不同的流标签值。
The problem with such an approach is that it requires the receiver of the communication to allocate the Flow Label value used for incoming packets, in order to assign them uniquely. For this, a shim negotiation of the Flow Label value to use in the communication is needed before exchanging data packets. This poses problems with non-Shim6-capable hosts, since they would not be able to negotiate an acceptable value for the Flow Label. This limitation can be lifted by marking the packets that belong to shim sessions from those that do not. These markings would require at least a bit in the IPv6 header that is not currently available, so more creative options would be required, for instance, using new Next Header values to indicate that the packet belongs to a Shim6-enabled communication and that the Flow Label carries context information as proposed in [8]. However, even if new Next Header values are used in this way, such an approach is incompatible with the deferred-establishment capability of the shim protocol, which is a preferred function since it suppresses delay due to shim context establishment prior to the initiation of communication. Such capability also allows nodes to
这种方法的问题在于，它要求通信的接收器分配用于传入分组的流标签值，以便唯一地分配它们。为此，在交换数据包之前，需要对通信中使用的流标签值进行协商。这给不支持Shim6的主机带来了问题，因为它们无法协商流标签的可接受值。通过将属于垫片会话的数据包与不属于垫片会话的数据包进行标记，可以解除此限制。这些标记将要求IPv6报头中至少有一个当前不可用的位，因此需要更多的创造性选项，例如，使用新的下一个报头值来指示数据包属于支持Shim6的通信，并且流标签包含[8]中提出的上下文信息。然而，即使以这种方式使用新的下一报头值，这种方法也与垫片协议的延迟建立能力不兼容，垫片协议是首选功能，因为它抑制了由于在通信开始之前垫片上下文建立而导致的延迟。这种能力还允许节点
define at which stage of the communication they decide, based on their own policies, that a given communication requires protection by the shim.
定义在通信的哪个阶段，他们根据自己的策略决定给定的通信需要垫片的保护。
In order to cope with the identified limitations, an alternative approach that does not constrain the Flow Label values that are used by communications using ULIDs equal to the locators (i.e., no shim translation) is to only require that different Flow Label values are assigned to different shim contexts. In such an approach, communications start with unmodified Flow Label usage (could be zero or as suggested in [12]). The packets sent after a failure when a different locator pair is used would use a completely different Flow Label, and this Flow Label could be allocated by the receiver as part of the shim context establishment. Since it is allocated during the context establishment, the receiver of the "failed over" packets can pick a Flow Label of its choosing (that is unique in the sense that no other context is using it as a Context Tag), without any performance impact, respecting that, for each locator pair, the Flow Label value used for a given locator pair doesn't change due to the operation of the multihoming shim.
为了应对已识别的限制，不限制使用与定位器相等的ULID的通信所使用的流标签值（即，无垫片转换）的替代方法是仅要求将不同的流标签值分配给不同的垫片上下文。在这种方法中，通信从未修改的流标签使用开始（可以是零或如[12]中所建议的）。当使用不同的定位器对时，故障后发送的数据包将使用完全不同的流标签，并且该流标签可由接收器分配，作为垫片上下文建立的一部分。由于它是在上下文建立期间分配的，“故障转移”分组的接收器可以选择其选择的流标签（这在没有其他上下文将其用作上下文标签的意义上是唯一的），而没有任何性能影响，关于这一点，对于每个定位器对，用于给定定位器对的流量标签值不会因多归位垫片的操作而改变。
In this approach, the constraint is that Flow Label values being used as context identifiers cannot be used by other communications that use non-disjoint locator sets. This means that once a given Flow Label value has been assigned to a shim context that has a certain locator sets associated, the same value cannot be used for other communications that use an address pair that is contained in the locator sets of the context. This is a constraint in the potential Flow Label allocation strategies.
在这种方法中，约束是用作上下文标识符的流标签值不能被使用非不相交定位器集的其他通信使用。这意味着，一旦将给定的流标签值分配给具有关联的特定定位器集的垫片上下文，相同的值就不能用于使用上下文定位器集中包含的地址对的其他通信。这是潜在流标签分配策略中的一个约束。
A possible workaround to this constraint is to mark shim packets that require translation, in order to differentiate them from regular IPv6 packets, using the artificial Next Header values described above. In this case, the Flow Label values constrained are only those of the packets that are being translated by the shim. This last approach would be the preferred approach if the Context Tag is to be carried in the Flow Label field. This is the case not only because it imposes the minimum constraints to the Flow Label allocation strategies, limiting the restrictions only to those packets that need to be translated by the shim, but also because context-loss detection mechanisms greatly benefit from the fact that shim data packets are identified as such, allowing the receiving end to identify if a shim context associated to a received packet is supposed to exist, as will be discussed in the context-loss detection appendix below.
此约束的一个可能的解决方法是使用上述人工下一个报头值标记需要转换的垫片数据包，以便将其与常规IPv6数据包区分开来。在这种情况下，受约束的流标签值仅是垫片正在转换的数据包的值。如果要在流标签字段中携带上下文标记，则最后一种方法将是首选方法。这种情况不仅是因为它对流标签分配策略施加了最小限制，将限制仅限于需要由垫片翻译的那些分组，而且还因为上下文丢失检测机制极大地受益于垫片数据分组被识别为这样的事实，允许接收端识别与接收到的分组相关联的垫片上下文是否应该存在，这将在下面的上下文丢失检测附录中讨论。
Another approach, which is the one selected for this protocol, is to carry the Context Tag in a new Extension header. These Context Tags are allocated by the receiving end during the Shim6 protocol initial negotiation, implying that each context will have two Context Tags, one for each direction. Data packets will be demultiplexed using the Context Tag carried in the Extension header. This seems a clean approach since it does not overload existing fields. However, it introduces additional overhead in the packet due to the additional header. The additional overhead introduced is 8 octets. However, it should be noted that the Context Tag is only required when a locator other than the one used as ULID is contained in the packet. Packets where both the Source and Destination Address fields contain the ULIDs do not require a Context Tag, since no rewriting is necessary at the receiver. This approach would reduce the overhead because the additional header is only required after a failure. On the other hand, this approach would cause changes in the available MTU for some packets, since packets that include the Extension header will have an MTU that is 8 octets shorter. However, path changes through the network can result in a different MTU in any case; thus, having a locator change, which implies a path change, affect the MTU doesn't introduce any new issues.
另一种方法，也就是为该协议选择的方法，是在新的扩展头中携带上下文标记。这些上下文标记由接收端在Shim6协议初始协商期间分配，这意味着每个上下文将有两个上下文标记，每个方向一个。数据包将使用扩展头中携带的上下文标记进行解复用。这似乎是一种干净的方法，因为它不会使现有字段过载。然而，由于额外的报头，它在数据包中引入了额外的开销。引入的额外开销是8个八位字节。然而，应该注意，只有当数据包中包含除用作ULID的定位器之外的定位器时，才需要上下文标记。源地址字段和目标地址字段都包含ulid的数据包不需要上下文标记，因为在接收方不需要重写。这种方法将减少开销，因为只有在发生故障后才需要额外的报头。另一方面，这种方法将导致某些分组的可用MTU发生变化，因为包括扩展报头的分组将具有短8个八位字节的MTU。然而，通过网络的路径改变在任何情况下都可能导致不同的MTU；因此，更改定位器（这意味着路径更改）不会影响MTU，不会带来任何新问题。
In this appendix, we will present different approaches considered to detect context loss and potential context-recovery strategies. The scenario being considered is the following: Node A and Node B are communicating using IPA1 and IPB1. Sometime later, a shim context is established between them, with IPA1 and IPB1 as ULIDs and with IPA1,...,IPAn and IPB1,...,IPBm as locator sets, respectively.
在本附录中，我们将介绍用于检测上下文丢失和潜在上下文恢复策略的不同方法。考虑的场景如下：节点A和节点B使用IPA1和IPB1进行通信。稍后，将在它们之间建立一个垫片上下文，其中IPA1和IPB1分别作为ULID，IPA1、…、IPAn和IPB1、…、IPBm分别作为定位器集。
It may happen that, later on, one of the hosts (e.g., Host A) loses the shim context. The reason for this can be that Host A has a more aggressive garbage collection policy than Host B or that an error occurred in the shim layer at Host A and resulted in the loss of the context state.
稍后，可能会发生一个主机（例如主机A）丢失垫片上下文的情况。原因可能是主机A的垃圾收集策略比主机B更激进，或者主机A的填充层中发生错误，导致上下文状态丢失。
The mechanisms considered in this appendix are aimed at dealing with this problem. There are essentially two tasks that need to be performed in order to cope with this problem: first, the context loss must be detected and, second, the context needs to be recovered/ re-established.
本附录中考虑的机制旨在处理这一问题。为了解决这个问题，基本上需要执行两个任务：第一，必须检测上下文丢失，第二，需要恢复/重新建立上下文。
Mechanisms for detecting context loss.
检测上下文丢失的机制。
These mechanisms basically consist in each end of the context that periodically sends a packet containing context-specific information to the other end. Upon reception of such packets, the receiver verifies that the required context exists. In the case that the context does not exist, it sends a packet notifying the sender of the problem.
这些机制基本上包含在上下文的每一端，它定期向另一端发送包含上下文特定信息的数据包。在接收到这样的分组时，接收器验证所需的上下文是否存在。在上下文不存在的情况下，它会发送一个数据包，通知发送方问题。
An obvious alternative for this would be to create a specific context keepalive exchange, which consists in periodically sending packets with this purpose. This option was considered and discarded because it seemed an overkill to define a new packet exchange to deal with this issue.
一个明显的替代方法是创建一个特定的上下文keepalive交换，它包括为此目的定期发送数据包。考虑并放弃了这个选项，因为定义一个新的包交换来处理这个问题似乎有些过分。
Another alternative is to piggyback the context-loss detection function in other existent packet exchanges. In particular, both shim control and data packets can be used for this.
另一种选择是在其他现有的数据包交换中使用上下文丢失检测功能。特别是，垫片控制和数据包都可用于此目的。
Shim control packets can be trivially used for this because they carry context-specific information. This way, when a node receives one such packet, it will verify if the context exists. However, shim control frequency may not be adequate for context-loss detection since control packet exchanges can be very limited for a session in certain scenarios.
垫片控制数据包可以简单地用于此目的，因为它们携带特定于上下文的信息。这样，当节点收到一个这样的数据包时，它将验证上下文是否存在。然而，垫片控制频率可能不足以检测上下文丢失，因为在某些场景中，会话的控制数据包交换可能非常有限。
Data packets, on the other hand, are expected to be exchanged with a higher frequency but do not necessarily carry context-specific information. In particular, packets flowing before a locator change (i.e., a packet carrying the ULIDs in the address fields) do not need context information since they do not need any shim processing. Packets that carry locators that differ from the ULIDs carry context information.
另一方面，数据分组预期以更高的频率交换，但不一定携带特定于上下文的信息。特别地，在定位器改变之前流动的分组（即，在地址字段中携带ulid的分组）不需要上下文信息，因为它们不需要任何垫片处理。携带与ULID不同的定位器的数据包携带上下文信息。
However, we need to make a distinction here between the different approaches considered to carry the Context Tag -- in particular, between those approaches where packets are explicitly marked as shim packets and those approaches where packets are not marked as such. For instance, in the case where the Context Tag is carried in the Flow Label and packets are not marked as shim packets (i.e., no new Next Header values are defined for shim), a receiver that has lost the associated context is not able to detect that the packet is associated with a missing context. The result is that the packet will be passed unchanged to the upper-layer protocol, which in turn will probably silently discard it due to a checksum error. The resulting behavior is that the context loss is undetected. This is one additional reason to discard an approach that carries the Context Tag in the Flow Label field and does not explicitly mark the shim packets as such. On the other hand, approaches that mark shim data packets (like those that use the Extension header or the Flow Label
然而，我们需要在这里区分被认为携带上下文标记的不同方法——特别是那些包被显式标记为垫片包的方法和那些包没有被标记为垫片包的方法。例如，在流标签中携带上下文标签并且分组未被标记为垫片分组（即，没有为垫片定义新的下一报头值）的情况下，丢失关联上下文的接收器不能检测到分组与丢失的上下文关联。其结果是，数据包将原封不动地传递给上层协议，而上层协议可能会由于校验和错误而自动丢弃数据包。由此产生的行为是未检测到上下文丢失。这是放弃在Flow Label字段中携带上下文标记且不显式标记垫片数据包的方法的另一个原因。另一方面，标记垫片数据包的方法（如使用扩展头或流标签的方法）
with new Next Header values) allow the receiver to detect if the context associated to the received packet is missing. In this case, data packets also perform the function of a context-loss detection exchange. However, it must be noted that only those packets that carry a locator that differs from the ULID are marked. This basically means that context loss will be detected after an outage has occurred, i.e., alternative locators are being used.
使用新的下一个报头值）允许接收器检测与接收到的数据包关联的上下文是否丢失。在这种情况下，数据分组还执行上下文丢失检测交换的功能。但是，必须注意的是，只有那些携带与ULID不同的定位器的数据包才会被标记。这基本上意味着在中断发生后，即使用替代定位器时，将检测到上下文丢失。
Summarizing, the proposed context-loss detection mechanisms use shim control packets and Shim6 Payload Extension headers to detect context loss. Shim control packets detect context loss during the whole lifetime of the context, but the expected frequency in some cases is very low. On the other hand, Shim6 Payload Extension headers have a higher expected frequency in general, but they only detect context loss after an outage. This behavior implies that it will be common that context loss is detected after a failure, i.e., once it is actually needed. Because of that, a mechanism for recovering from context loss is required if this approach is used.
总之，所提出的上下文丢失检测机制使用垫片控制包和Shim6有效负载扩展头来检测上下文丢失。垫片控制数据包在上下文的整个生命周期内检测上下文丢失，但在某些情况下预期的频率非常低。另一方面，Shim6有效负载扩展头通常具有更高的预期频率，但它们仅在中断后检测上下文丢失。这种行为意味着，在发生故障后，即在实际需要时，检测到上下文丢失是很常见的。因此，如果使用这种方法，则需要一种从上下文丢失中恢复的机制。
Overall, the mechanism for detecting lost context would work as follows: the end that still has the context available sends a message referring to the context. Upon the reception of such message, the end that has lost the context identifies the situation and notifies the other end of the context-loss event by sending a packet containing the lost context information extracted from the received packet.
总的来说，检测丢失上下文的机制将如下所示：仍然具有可用上下文的端发送引用上下文的消息。在接收到这样的消息时，丢失上下文的一端识别情况，并通过发送包含从接收到的分组提取的丢失上下文信息的分组来通知上下文丢失事件的另一端。
One option is to simply send an error message containing the received packets (or at least as much of the received packet that the MTU allows to fit). One of the goals of this notification is to allow the other end that still retains context state to re-establish the lost context. The mechanism to re-establish the lost context consists in performing the 4-way initial handshake. This is a time-consuming exchange and, at this point, time may be critical since we are re-establishing a context that is currently needed (because context-loss detection may occur after a failure). So another option, which is the one used in this protocol, is to replace the error message with a modified R1 message so that the time required to perform the context-establishment exchange can be reduced. Upon the reception of this modified R1 message, the end that still has the context state can finish the context-establishment exchange and restore the lost context.
一种选择是简单地发送包含所接收数据包的错误消息（或者至少发送MTU允许容纳的所接收数据包的数量）。此通知的目标之一是允许仍保留上下文状态的另一端重新建立丢失的上下文。重建丢失上下文的机制包括执行4路初始握手。这是一个耗时的交换，在这一点上，时间可能非常关键，因为我们正在重新建立当前所需的上下文（因为上下文丢失检测可能在失败后发生）。因此，本协议中使用的另一个选项是，用修改后的R1消息替换错误消息，以便减少执行上下文建立交换所需的时间。在接收到此修改的R1消息后，仍然具有上下文状态的端可以完成上下文建立交换并恢复丢失的上下文。
The adoption of a protocol like SHIM, which allows the binding of a given ULID with a set of locators, opens the door for different types of redirection attacks as described in [15]. The goal, in terms of
采用类似SHIM的协议允许将给定的ULID与一组定位器绑定，这为[15]中所述的不同类型的重定向攻击打开了大门。目标是
security, for the design of the shim protocol is to not introduce any new vulnerability into the Internet architecture. It is a non-goal to provide additional protection other than what is currently available in the single-homed IPv6 Internet.
安全性，因为shim协议的设计不会在Internet架构中引入任何新的漏洞。除了目前在单宿IPv6 Internet中可用的保护之外，提供其他保护不是我们的目标。
Multiple security mechanisms were considered to protect the shim protocol. In this appendix we will present some of them.
考虑了多种安全机制来保护shim协议。在本附录中，我们将介绍其中一些。
The simplest option to protect the shim protocol is to use cookies, i.e., a randomly generated bit string that is negotiated during the context-establishment phase and then is included in subsequent signaling messages. By these means, it would be possible to verify that the party that was involved in the initial handshake is the same party that is introducing new locators. Moreover, before using a new locator, an exchange is performed through the new locator, verifying that the party located at the new locator knows the cookie, i.e., that it is the same party that performed the initial handshake.
保护垫片协议的最简单选项是使用cookie，即在上下文建立阶段协商的随机生成的位字符串，然后包含在后续信令消息中。通过这些方法，可以验证参与初始握手的一方是引入新定位器的同一方。此外，在使用新定位器之前，通过新定位器执行交换，验证位于新定位器的一方知道cookie，即，它是执行初始握手的同一方。
While this security mechanism does indeed provide a fair amount of protection, it leaves the door open for so-called time-shifted attacks. In these attacks, an attacker on the path discovers the cookie by sniffing any signaling message. After that, the attacker can leave the path and still perform a redirection attack since, as he is in possession of the cookie, he can introduce a new locator into the locator set and can also successfully perform the reachability exchange if he is able to receive packets at the new locator. The difference with the current single-homed IPv6 situation is that in the current situation the attacker needs to be on-path during the whole lifetime of the attack, while in this new situation (where only cookie protection is provided), an attacker that was once on the path can perform attacks after he has left the on-path location.
虽然这种安全机制确实提供了相当数量的保护，但它为所谓的时移攻击打开了大门。在这些攻击中，路径上的攻击者通过嗅探任何信令消息来发现cookie。在此之后，攻击者可以离开路径并仍然执行重定向攻击，因为他拥有cookie，他可以将新定位器引入定位器集中，并且如果他能够在新定位器处接收数据包，也可以成功执行可达性交换。与当前单主IPv6情况的区别在于，在当前情况下，攻击者需要在整个攻击生命周期内都在路径上，而在这种新情况下（仅提供cookie保护），曾经在路径上的攻击者可以在离开路径上位置后执行攻击。
Moreover, because the cookie is included in signaling messages, the attacker can discover the cookie by sniffing any of them, making the protocol vulnerable during the whole lifetime of the shim context. A possible approach to increase security is to use a shared secret, i.e., a bit string that is negotiated during the initial handshake but that is used as a key to protect following messages. With this technique, the attacker must be present on the path and sniffing packets during the initial handshake, since this is the only moment when the shared secret is exchanged. Though it imposes that the attacker must be on path at a very specific moment (the establishment phase), and though it improves security, this approach is still vulnerable to time-shifted attacks. It should be noted that, depending on protocol details, an attacker may be able to force the re-creation of the initial handshake (for instance, by blocking
此外，由于cookie包含在信令消息中，攻击者可以通过嗅探任何cookie来发现cookie，从而使协议在整个shim上下文生命周期中都易受攻击。提高安全性的一种可能方法是使用共享秘密，即在初始握手期间协商的位字符串，但用作密钥以保护后续消息。使用这种技术，攻击者必须在初始握手期间出现在路径上并嗅探数据包，因为这是交换共享秘密的唯一时刻。虽然它强制攻击者必须在非常特定的时刻（建立阶段）在路径上，并且虽然它提高了安全性，但这种方法仍然容易受到时移攻击。需要注意的是，根据协议细节，攻击者可能会强制重新创建初始握手（例如，通过阻止）
messages and making the parties think that the context has been lost); thus, the resulting situation may not differ that much from the cookie-based approach.
信息，使各方认为上下文已丢失）；因此，由此产生的情况可能与基于cookie的方法没有太大区别。
Another option that was discussed during the design of this protocol was the possibility of using IPsec for protecting the shim protocol. Now, the problem under consideration in this scenario is how to securely bind an address that is being used as ULID with a locator set that can be used to exchange packets. The mechanism provided by IPsec to securely bind the address that is used with cryptographic keys is the usage of digital certificates. This implies that an IPsec-based solution would require a common and mutually trusted third party to generate digital certificates that bind the key and the ULID. Considering that the scope of application of the shim protocol is global, this would imply a global public key infrastructure (PKI). The major issues with this approach are the deployment difficulties associated with a global PKI. The other possibility would be to use some form of opportunistic IPSec, like Better-Than-Nothing-Security (BTNS) [22]. However, this would still present some issues. In particular, this approach requires a leap-of-faith in order to bind a given address to the public key that is being used, which would actually prevent the most critical security feature that a Shim6 security solution needs to achieve from being provided: proving identifier ownership. On top of that, using IPsec would require to turn on per-packet AH/ESP just for multihoming to occur.
在设计该协议期间讨论的另一个选项是使用IPsec保护shim协议的可能性。现在，在这个场景中考虑的问题是如何将用作ULID的地址与可用于交换数据包的定位器集安全绑定。IPsec提供的安全绑定与加密密钥一起使用的地址的机制是使用数字证书。这意味着基于IPsec的解决方案需要一个共同且相互信任的第三方来生成绑定密钥和ULID的数字证书。考虑到shim协议的应用范围是全球性的，这意味着需要一个全球性的公钥基础设施（PKI）。这种方法的主要问题是与全球PKI相关的部署困难。另一种可能是使用某种形式的机会主义IPSec，如Better That Nothing Security（BTN）[22]。然而，这仍然会带来一些问题。特别是，为了将给定地址绑定到正在使用的公钥，这种方法需要信心的飞跃，这实际上会阻止提供Shim6安全解决方案需要实现的最关键的安全功能：证明标识符所有权。最重要的是，使用IPsec需要打开每个数据包AH/ESP，才能实现多主。
In general, SHIM6 was expected to work between pairs of hosts that have no prior arrangement, security association, or common, trusted third party. It was also seen as undesirable to have to turn on per-packet AH/ESP just for the multihoming to occur. However, Shim6 should work and have an additional level of security where two hosts choose to use IPsec.
一般来说，SHIM6应该在没有事先安排、安全关联或公共的、受信任的第三方的主机对之间工作。人们还认为，仅仅为了实现多归属，就必须打开每个数据包AH/ESP是不可取的。但是，在两台主机选择使用IPsec的情况下，Shim6应该可以工作并具有额外的安全级别。
Another design alternative would have employed some form of opportunistic or Better-Than-Nothing Security (BTNS) IPsec to perform these tasks with IPsec instead. Essentially, HIP in opportunistic mode is very similar to SHIM6, except that HIP uses IPsec, employs per-packet ESP, and introduces another set of identifiers.
另一种设计方案将采用某种形式的机会主义或优于无的安全（BTNS）IPsec来代替IPsec执行这些任务。本质上，机会主义模式下的HIP与SHIM6非常相似，不同之处在于HIP使用IPsec，采用每包ESP，并引入另一组标识符。
Finally, two different technologies were selected to protect the shim protocol: HBA [3] and CGA [2]. These two techniques provide a similar level of protection but also provide different functionality with different computational costs.
最后，选择了两种不同的技术来保护shim协议：HBA[3]和CGA[2]。这两种技术提供了相似的保护级别，但也以不同的计算成本提供了不同的功能。
The HBA mechanism relies on the capability of generating all the addresses of a multihomed host as an unalterable set of intrinsically bound IPv6 addresses, known as an HBA set. In this approach,
HBA机制依赖于将多宿主主机的所有地址生成为一组不可更改的内部绑定IPv6地址（称为HBA集）的能力。在这种方式下,，
addresses incorporate a cryptographic one-way hash of the prefix set available into the interface identifier part. The result is that the binding between all the available addresses is encoded within the addresses themselves, providing hijacking protection. Any peer using the shim protocol node can efficiently verify that the alternative addresses proposed for continuing the communication are bound to the initial address through a simple hash calculation. A limitation of the HBA technique is that, once generated, the address set is fixed and cannot be changed without also changing all the addresses of the HBA set. In other words, the HBA technique does not support dynamic addition of address to a previously generated HBA set. An advantage of this approach is that it requires only hash operations to verify a locator set, imposing very low computational cost to the protocol.
地址将前缀集的加密单向散列合并到接口标识符部分中。结果是，所有可用地址之间的绑定在地址本身中进行编码，从而提供劫持保护。使用shim协议节点的任何对等方都可以通过简单的散列计算有效地验证为继续通信而提议的备选地址是否绑定到初始地址。HBA技术的一个限制是，一旦生成，地址集是固定的，如果不同时更改HBA集的所有地址，则无法更改地址集。换句话说，HBA技术不支持向先前生成的HBA集动态添加地址。这种方法的一个优点是，它只需要哈希操作来验证定位器集，从而为协议带来非常低的计算成本。
In a CGA-based approach, the address used as ULID is a CGA that contains a hash of a public key in its interface identifier. The result is a secure binding between the ULID and the associated key pair. This allows each peer to use the corresponding private key to sign the shim messages that convey locator set information. The trust chain in this case is the following: the ULID used for the communication is securely bound to the key pair because it contains the hash of the public key, and the locator set is bound to the public key through the signature. The CGA approach then supports dynamic addition of new locators in the locator set, since in order to do that the node only needs to sign the new locator with the private key associated with the CGA used as ULID. A limitation of this approach is that it imposes systematic usage of public key cryptography with its associate computational cost.
在基于CGA的方法中，用作ULID的地址是在其接口标识符中包含公钥散列的CGA。结果是ULID和关联密钥对之间的安全绑定。这允许每个对等方使用相应的私钥对传递定位器集信息的垫片消息进行签名。在这种情况下，信任链如下：用于通信的ULID安全地绑定到密钥对，因为它包含公钥的散列，定位器集通过签名绑定到公钥。然后，CGA方法支持在定位器集中动态添加新定位器，因为为了做到这一点，节点只需要使用与用作ULID的CGA相关联的私钥对新定位器进行签名。这种方法的一个限制是，它强制系统地使用公钥密码及其相关的计算成本。
Either of these two mechanisms, HBA and CGA, provides time-shifted attack protection, since the ULID is securely bound to a locator set that can only be defined by the owner of the ULID.
这两种机制（HBA和CGA）中的任何一种都提供时移攻击保护，因为ULID安全地绑定到只能由ULID所有者定义的定位器集。
So the design decision adopted was that both mechanisms, HBA and CGA, are supported. This way, when only stable address sets are required, the nodes can benefit from the low computational cost offered by HBA, while when dynamic locator sets are required, this can be achieved through CGAs with an additional cost. Moreover, because HBAs are defined as a CGA extension, the addresses available in a node can simultaneously be CGAs and HBAs, allowing the usage of the HBA and CGA functionality when needed, without requiring a change in the addresses used.
因此，采用的设计决策是支持HBA和CGA这两种机制。这样，当只需要稳定的地址集时，节点可以受益于HBA提供的低计算成本，而当需要动态定位器集时，这可以通过CGA以额外成本实现。此外，由于HBA被定义为CGA扩展，因此节点中可用的地址可以同时为CGA和HBA，从而允许在需要时使用HBA和CGA功能，而无需更改所使用的地址。
Two options were considered for the ULID-pair context-establishment exchange: a 2-way handshake and a 4-way handshake.
ULID对上下文建立交换考虑了两个选项：双向握手和四向握手。
A key goal for the design of this exchange was protection against DoS attacks. The attack under consideration was basically a situation where an attacker launches a great amount of ULID-pair establishment-request packets, exhausting the victim's resources similarly to TCP SYN flooding attacks.
此交换设计的一个关键目标是防止DoS攻击。所考虑的攻击基本上是一种情况，即攻击者启动大量ULID对建立请求数据包，耗尽受害者的资源，类似于TCP SYN洪泛攻击。
A 4-way handshake exchange protects against these attacks because the receiver does not create any state associated to a given context until the reception of the second packet, which contains prior-contact proof in the form of a token. At this point, the receiver can verify that at least the address used by the initiator is valid to some extent, since the initiator is able to receive packets at this address. In the worst case, the responder can track down the attacker using this address. The drawback of this approach is that it imposes a 4-packet exchange for any context establishment. This would be a great deal if the shim context needed to be established up front, before the communication can proceed. However, thanks to the deferred context-establishment capability of the shim protocol, this limitation has a reduced impact in the performance of the protocol. (However, it may have a greater impact in the situation of context recovery, as discussed earlier. However, in this case, it is possible to perform optimizations to reduce the number of packets as described above.)
4路握手交换可以防止这些攻击，因为在接收到第二个数据包之前，接收方不会创建与给定上下文相关的任何状态，第二个数据包包含令牌形式的先前联系证明。此时，接收器可以验证至少启动器使用的地址在某种程度上是有效的，因为启动器能够在此地址接收数据包。在最坏的情况下，响应者可以使用此地址追踪攻击者。这种方法的缺点是，它对任何上下文建立都强制进行4包交换。如果在通信可以继续之前需要预先建立垫片上下文，这将是一个很大的问题。然而，由于shim协议的延迟上下文建立能力，该限制对协议性能的影响降低。（但是，如前所述，在上下文恢复的情况下，它可能会产生更大的影响。但是，在这种情况下，可以执行优化以减少如上所述的数据包数量。）
The other option considered was a 2-way handshake with the possibility to fall back to a 4-way handshake in case of attack. In this approach, the ULID-pair establishment exchange normally consists of a 2-packet exchange and does not verify that the initiator has performed a prior contact before creating context state. In case a DoS attack is detected, the responder falls back to a 4-way handshake similar to the one described previously, in order to prevent the detected attack from proceeding. The main difficulty with this attack is how to detect that a responder is currently under attack. It should be noted that, because this is a 2-way exchange, it is not possible to use the number of half-open sessions (as in TCP) to detect an ongoing attack; different heuristics need to be considered.
考虑的另一个选项是双向握手，在受到攻击时可能会退回到4向握手。在这种方法中，ULID对建立交换通常由2包交换组成，并且在创建上下文状态之前不验证发起方是否执行了先前的联系。在检测到DoS攻击的情况下，响应者退回到类似于前面描述的4路握手，以防止检测到的攻击继续进行。此攻击的主要困难在于如何检测响应者当前是否受到攻击。需要注意的是，由于这是双向交换，因此不可能使用半开放会话的数量（如TCP）来检测正在进行的攻击；需要考虑不同的启发式方法。
The design decision taken was that, considering the current impact of DoS attacks and the low impact of the 4-way exchange in the shim protocol (thanks to the deferred context-establishment capability), a 4-way exchange would be adopted for the base protocol.
所作的设计决定是，考虑到DoS攻击的当前影响和shim协议中4路交换的低影响（由于延迟上下文建立能力），将对基本协议采用4路交换。
There are two possible approaches to the addition and removal of locators: atomic and differential approaches. The atomic approach essentially sends the complete locator set each time a variation in the locator set occurs. The differential approach sends the
添加和删除定位器有两种可能的方法：原子方法和差分方法。原子方法本质上是在每次定位器集发生变化时发送完整的定位器集。差分方法发送
differences between the existing locator set and the new one. The atomic approach imposes additional overhead since all of the locator set has to be exchanged each time, while the differential approach requires re-synchronization of both ends through changes (i.e., requires that both ends have the same idea about what the current locator set is).
现有定位器集与新定位器集之间的差异。原子方法带来了额外的开销，因为每次都必须交换所有定位器集，而差分方法需要通过更改重新同步两端（即，要求两端对当前定位器集有相同的概念）。
Because of the difficulties imposed by the synchronization requirement, the atomic approach was selected.
由于同步要求带来的困难，选择了原子方法。
There are essentially two approaches for discarding an existing state about locators, keys, and identifiers of a correspondent node: a coordinated approach and an unilateral approach.
基本上有两种方法可以丢弃对应节点的定位器、键和标识符的现有状态：协调方法和单边方法。
In the unilateral approach, each node discards information about the other node without coordination with the other node, based on some local timers and heuristics. No packet exchange is required for this. In this case, it would be possible that one of the nodes has discarded the state while the other node still hasn't. In this case, a No Context Error message may be required to inform the other node about the situation; possibly a recovery mechanism is also needed.
在单边方法中，每个节点基于一些本地计时器和启发式算法，在不与另一节点协调的情况下丢弃关于另一节点的信息。此操作不需要数据包交换。在这种情况下，其中一个节点可能已经放弃了状态，而另一个节点仍然没有。在这种情况下，可能需要无上下文错误消息来通知另一节点该情况；可能还需要一种恢复机制。
A coordinated approach would use an explicit CLOSE mechanism, akin to the one specified in HIP [20]. If an explicit CLOSE handshake and associated timer is used, then there would no longer be a need for the No Context Error message due to a peer having garbage collected at its end of the context. However, there is still potentially a need to have a No Context Error message in the case of a complete state loss of the peer (also known as a crash followed by a reboot). Only if we assume that the reboot takes at least the time of the CLOSE timer, or that it is okay to not provide complete service until CLOSE-timer minutes after the crash, can we completely do away with the No Context Error message.
协调方法将使用一种明确的闭合机制，类似于HIP[20]中规定的机制。如果使用了显式的近距离握手和相关的计时器，那么就不再需要无上下文错误消息，因为对等方在其上下文的末尾收集了垃圾。但是，在对等机完全失去状态（也称为崩溃，然后重新启动）的情况下，仍然可能需要无上下文错误消息。只有当我们假设重启至少需要关闭计时器的时间，或者在崩溃后关闭计时器几分钟之前不提供完整服务是可以的，我们才能完全消除无上下文错误消息。
In addition, another aspect that is relevant for this design choice is the context confusion issue. In particular, using a unilateral approach to discard context state clearly opens up the possibility of context confusion, where one of the ends unilaterally discards the context state, while the other does not. In this case, the end that has discarded the state can re-use the Context Tag value used for the discarded state for another context, creating potential context confusion. In order to illustrate the cases where problems would arise, consider the following scenario:
此外，与此设计选择相关的另一个方面是上下文混淆问题。特别是，使用单方面方法放弃语境状态显然会造成语境混乱，其中一个目的单方面放弃语境状态，而另一个目的则不会。在这种情况下，已放弃状态的端可以将用于已放弃状态的上下文标记值重新用于另一个上下文，从而造成潜在的上下文混淆。为了说明出现问题的情况，考虑下面的情景：
o Hosts A and B establish context 1 using CTA and CTB as Context Tags.
o 主机A和B使用CTA和CTB作为上下文标记建立上下文1。
o Later on, A discards context 1 and the Context Tag value CTA becomes available for reuse.
o 稍后，A丢弃上下文1，上下文标记值CTA可供重用。
o However, B still keeps context 1.
o 然而，B仍然保持上下文1。
This would create context confusion in the following two cases:
这将在以下两种情况下造成上下文混淆：
o A new context 2 is established between A and B with a different ULID pair (or Forked Instance Identifier), and A uses CTA as the Context Tag. If the locator sets used for both contexts are not disjoint, we have context confusion.
o 使用不同的ULID对（或分叉实例标识符）在A和B之间建立新的上下文2，A使用CTA作为上下文标记。如果用于两个上下文的定位器集不是不相交的，则会产生上下文混淆。
o A new context is established between A and C, and A uses CTA as the Context Tag value for this new context. Later on, B sends Payload Extension header and/or control messages containing CTA, which could be interpreted by A as belonging to context 2 (if no proper care is taken). Again we have context confusion.
o 在A和C之间建立一个新的上下文，A使用CTA作为这个新上下文的上下文标记值。稍后，B发送包含CTA的有效负载扩展报头和/或控制消息，A可以将其解释为属于上下文2（如果没有采取适当的注意）。我们再次遇到了上下文混乱。
One could think that using a coordinated approach would eliminate such context confusion, making the protocol much simpler. However, this is not the case, because even in the case of a coordinated approach using a CLOSE/CLOSE ACK exchange, there is still the possibility of a host rebooting without having the time to perform the CLOSE exchange. So, it is true that the coordinated approach eliminates the possibility of context confusion due to premature garbage collection, but it does not prevent the same situations due to a crash and reboot of one of the involved hosts. The result is that, even if we went for a coordinated approach, we would still need to deal with context confusion and provide the means to detect and recover from these situations.
人们可以认为，采用协调一致的办法将消除这种背景混乱，使议定书更加简单。但是，情况并非如此，因为即使在使用关闭/关闭确认交换的协调方法的情况下，主机仍有可能在没有时间执行关闭交换的情况下重新启动。因此，协调方法确实消除了由于过早的垃圾收集而导致的上下文混淆的可能性，但它不能防止由于其中一个相关主机的崩溃和重新启动而导致的相同情况。结果是，即使我们采取了协调一致的方法，我们仍然需要处理上下文混乱问题，并提供检测和从这些情况中恢复的手段。
Authors' Addresses
作者地址
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park，加利福尼亚州94025
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Phone: +1 650 786 2921
EMail: erik.nordmark@sun.com
Marcelo Bagnulo Universidad Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 SPAIN
马德里卡洛斯三世大学。西班牙马德里勒加内斯30大学28911
Phone: +34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Phone: +34 91 6248814
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es