Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6629 ICANN
Category: Informational M. Bagnulo
ISSN: 2070-1721 A. Garcia-Martinez
UC3M
June 2012
Internet Engineering Task Force (IETF) J. Abley
Request for Comments: 6629 ICANN
Category: Informational M. Bagnulo
ISSN: 2070-1721 A. Garcia-Martinez
UC3M
June 2012
Considerations on the Application of the Level 3 Multihoming Shim Protocol for IPv6 (Shim6)
IPv6（Shim6）三级多主Shim协议应用的思考
Abstract
摘要
This document discusses some considerations on the applicability of the level 3 multihoming Shim protocol for IPv6 (Shim6) and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.
本文档讨论了有关IPv6的3级多主Shim协议（Shim6）的适用性以及在IPv6中提供站点多主功能的相关支持协议和机制的一些注意事项。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6629.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6629.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Deployment Scenarios ............................................4
3. Addresses and Shim6 .............................................6
3.1. Protocol Version (IPv4 vs. IPv6) ...........................6
3.2. Prefix Lengths .............................................7
3.3. Address Generation and Configuration .......................7
3.4. Use of CGA vs. HBA .........................................7
4. Shim6 in Multihomed Nodes .......................................8
5. Shim6 Capabilities .............................................10
5.1. Fault Tolerance ...........................................10
5.1.1. Establishing Communications After an Outage ........10
5.1.2. Short-Lived and Long-Lived Communications ..........11
5.2. Load Balancing ............................................11
5.3. Traffic Engineering .......................................12
6. Application Considerations .....................................12
7. Interaction with Other Protocols and Mechanisms ................13
7.1. Shim6 and Mobile IPv6 .....................................13
7.1.1. Multihomed Home Network ............................14
7.1.2. Shim6 Between the HA and the MN ....................16
7.2. Shim6 and SEND ............................................16
7.3. Shim6, SCTP and MPTCP .....................................17
7.4. Shim6 and NEMO ............................................18
7.5. Shim6 and HIP .............................................18
7.6. Shim6 and Firewalls .......................................19
7.7. Shim6 and NPTv6 ...........................................20
8. Security Considerations ........................................23
8.1. Privacy Considerations ....................................24
9. Contributors ...................................................24
10. Acknowledgements ..............................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
1. Introduction ....................................................3
2. Deployment Scenarios ............................................4
3. Addresses and Shim6 .............................................6
3.1. Protocol Version (IPv4 vs. IPv6) ...........................6
3.2. Prefix Lengths .............................................7
3.3. Address Generation and Configuration .......................7
3.4. Use of CGA vs. HBA .........................................7
4. Shim6 in Multihomed Nodes .......................................8
5. Shim6 Capabilities .............................................10
5.1. Fault Tolerance ...........................................10
5.1.1. Establishing Communications After an Outage ........10
5.1.2. Short-Lived and Long-Lived Communications ..........11
5.2. Load Balancing ............................................11
5.3. Traffic Engineering .......................................12
6. Application Considerations .....................................12
7. Interaction with Other Protocols and Mechanisms ................13
7.1. Shim6 and Mobile IPv6 .....................................13
7.1.1. Multihomed Home Network ............................14
7.1.2. Shim6 Between the HA and the MN ....................16
7.2. Shim6 and SEND ............................................16
7.3. Shim6, SCTP and MPTCP .....................................17
7.4. Shim6 and NEMO ............................................18
7.5. Shim6 and HIP .............................................18
7.6. Shim6 and Firewalls .......................................19
7.7. Shim6 and NPTv6 ...........................................20
8. Security Considerations ........................................23
8.1. Privacy Considerations ....................................24
9. Contributors ...................................................24
10. Acknowledgements ..............................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Site multihoming is an arrangement by which a site may use multiple paths to the rest of the Internet to provide better reliability for traffic passing in and out of the site than would be possible with a single path. Some of the motivations for operators to multihome their network are described in [RFC3582].
站点多主是一种安排，通过这种安排，站点可以使用多条路径连接到互联网的其余部分，从而为进出站点的流量提供比使用单一路径更好的可靠性。[RFC3582]中描述了运营商将其网络多址化的一些动机。
In IPv4, site multihoming is achieved by injecting the additional state required to allow session resilience over re-homing events [RFC4116] into the global Internet routing system (sometimes referred to as the Default-Free Zone, or DFZ). There is concern that this approach will not scale [RFC3221] [RFC4984].
在IPv4中，站点多宿主是通过将允许会话恢复所需的附加状态（通过重新宿主事件[RFC4116]）注入全局Internet路由系统（有时称为默认自由区或DFZ）来实现的。有人担心这种方法不会扩展[RFC3221][RFC4984]。
Site multihoming in IPv6 can be achieved as in IPv4, thus facing similar scalability concerns. However, IPv6's large address space enables a different solution for site multihoming in IPv6: to assign multiple addresses to each host, one or more from each provider. Deploying site multihoming in this way does not impact the routing system. So such a site multihoming strategy may be extended to a large number of sites, and may be applied to small sites that would not be eligible for site multihoming based on the injection of routes to Provider Independent (PI) prefixes. A drawback of this multihoming approach is that it does not provide transport-layer stability across re-homing events.
IPv6中的站点多主可以像IPv4中一样实现，因此面临类似的可伸缩性问题。然而，IPv6的大地址空间为IPv6中的站点多宿主提供了不同的解决方案：为每个主机分配多个地址，每个提供商提供一个或多个地址。以这种方式部署站点多主不会影响路由系统。因此，这种站点多宿主策略可以扩展到大量站点，并且可以应用于基于向独立于提供商（PI）前缀注入路由而不符合站点多宿主条件的小型站点。这种多归宿方法的一个缺点是它不能在重归宿事件中提供传输层稳定性。
Shim6 provides layer-3 support for making re-homing events transparent to the transport layer by means of a shim approach. Once a Shim6 session has been established, the failure detection mechanism defined for Shim6 allows finding new, valid locator combinations in case of failure and using these locators to continue the communication. However, Shim6 does not provide failure protection to the communication establishment, so if a host within a multihomed site attempts to establish a communication with a remote host and selects an address that corresponds to a failed transit path, the communication will fail. State information relating to the multihoming of two endpoints exchanging unicast traffic is retained on the endpoints themselves, rather than in the network. Communications between Shim6-capable hosts and Shim6-incapable hosts proceed as normal, but without the benefit of transport-layer stability. The Shim6 approach is thought to have better scaling properties with respect to the state held in the DFZ than the PI approach. In order to successfully deploy Shim6 in a multihomed site, additional mechanisms may be required to solve issues, such as selecting the source address appropriate to the destination and to the outgoing provider, or to allow the network manager to perform traffic engineering. Such problems are not specific to Shim6, but are relevant to the hosts of any site that is connected to multiple
Shim6提供第3层支持，通过垫片方法使重设主位置事件对传输层透明。一旦建立了Shim6会话，为Shim6定义的故障检测机制允许在发生故障时找到新的有效定位器组合，并使用这些定位器继续通信。但是，Shim6不为通信设施提供故障保护，因此，如果多宿站点内的主机尝试与远程主机建立通信，并选择与故障传输路径对应的地址，则通信将失败。与交换单播通信量的两个端点的多宿相关的状态信息保留在端点本身，而不是网络中。支持Shim6的主机和不支持Shim6的主机之间的通信正常进行，但没有传输层稳定性的好处。人们认为，相对于DFZ中的状态，Shim6方法比PI方法具有更好的缩放特性。为了在多址站点中成功部署Shim6，可能需要其他机制来解决问题，例如选择适合目标和传出提供商的源地址，或者允许网络管理器执行流量工程。这些问题并非特定于Shim6，而是与连接到多个服务器的任何站点的主机相关
transit providers, and that receives an IPv6 prefix from each of the providers [RFC5220]. Some of these mechanisms are not defined today. However, note that once a Shim6 session has been established, Shim6 reduces the impact of these problems, because if a working path exists, Shim6 will find it.
传输提供程序，并从每个提供程序接收IPv6前缀[RFC5220]。其中一些机制目前尚未确定。但是，请注意，一旦建立了Shim6会话，Shim6将减少这些问题的影响，因为如果存在工作路径，Shim6将找到它。
This note describes the applicability of the Level 3 multihoming (hereafter Shim6) protocol defined in [RFC5533] and the failure detection mechanisms defined in [RFC5534].
本说明描述了[RFC5533]中定义的3级多主（以下简称Shim6）协议的适用性以及[RFC5534]中定义的故障检测机制。
The terminology used in this document, including terms like locator and Upper-Layer Identifier (ULID), is defined in [RFC5533].
本文件中使用的术语，包括定位器和上层标识符（ULID）等术语，在[RFC5533]中定义。
The goal of the Shim6 protocol is to support locator agility in established communications; different layer-3 endpoint addresses may be used to exchange packets belonging to the same transport-layer session, all the time presenting a consistent identifier pair to upper-layer protocols.
Shim6协议的目标是在已建立的通信中支持定位器的灵活性；不同的第3层端点地址可用于交换属于同一传输层会话的数据包，始终向上层协议提供一致的标识符对。
In order to be useful, the Shim6 protocol requires that at least one of the peers have more than one address that could be used on the wire (as locators). In the event of communications failure between an active pair of addresses, the Shim6 protocol attempts to reestablish communication by trying different combinations of locators.
为了发挥作用，Shim6协议要求至少一个对等方具有一个以上的地址，可以在线路上使用（作为定位器）。在一对活动地址之间发生通信故障的情况下，Shim6协议试图通过尝试不同的定位器组合来重新建立通信。
While other multi-addressing scenarios are not precluded, the scenario in which the Shim6 protocol is expected to operate is that of a multihomed site that is connected to multiple transit providers, and that receives an IPv6 prefix from each of them. This configuration is intended to provide protection for the end-site in the event of a failure in some subset of the available transit providers, without requiring the end-site to acquire PI address space or requiring any particular cooperation between the transit providers.
虽然不排除其他多寻址场景，但预计Shim6协议将运行的场景是连接到多个传输提供商并从每个传输提供商接收IPv6前缀的多址站点。此配置旨在在可用传输提供商的某些子集发生故障时为终端站点提供保护，而无需终端站点获取PI地址空间或传输提供商之间的任何特定合作。
,------------------------------------. ,----------------.
| Rest of the Internet +-------+ Remote Host R |
`--+-----------+------------------+--' `----------------'
| | | LR[1] ... LR[m]
,---+----. ,---+----. ,----+---.
| ISP[1] | | ISP[2] | ...... | ISP[n] |
`---+----' `---+----' `----+---'
| | |
,---+-----------+------------------+---.
| Multi-Homed Site S assigned |
| prefixes P[1], P[2], ..., P[n] |
| |
| ,--------. L[1] = P[1]:iid[1], |
| | Host H | L[2] = P[2]:iid[2], ... |
| `--------' L[n] = P[n]:iid[n] |
`--------------------------------------'
,------------------------------------. ,----------------.
| Rest of the Internet +-------+ Remote Host R |
`--+-----------+------------------+--' `----------------'
| | | LR[1] ... LR[m]
,---+----. ,---+----. ,----+---.
| ISP[1] | | ISP[2] | ...... | ISP[n] |
`---+----' `---+----' `----+---'
| | |
,---+-----------+------------------+---.
| Multi-Homed Site S assigned |
| prefixes P[1], P[2], ..., P[n] |
| |
| ,--------. L[1] = P[1]:iid[1], |
| | Host H | L[2] = P[2]:iid[2], ... |
| `--------' L[n] = P[n]:iid[n] |
`--------------------------------------'
Figure 1
图1
In the scenario illustrated in Figure 1, host H communicates with some remote host R. Each of the addresses L[i] configured on host H in the multihomed site S can be reached through provider ISP[i] only, since ISP[i] is solely responsible for advertising a covering prefix for P[i] to the rest of the Internet.
在图1所示的场景中，主机H与某个远程主机R通信。多宿站点S中主机H上配置的每个地址L[i]只能通过提供商ISP[i]访问，因为ISP[i]全权负责向互联网的其余部分公布P[i]的覆盖前缀。
The use of locator L[i] on H hence causes inbound traffic towards H to be routed through ISP[i]. Changing the locator from L[i] to L[j] will have the effect of re-routing inbound traffic to H from ISP[i] to ISP[j]. This is the central mechanism by which the Shim6 protocol aims to provide multihoming functionality: by changing locators, host H can change the upstream ISP used to route inbound packets towards itself. Regarding the outbound traffic to H, the path taken in this case depends on both the actual locator LR[j] used for R, and the administrative exit selection policy of site S. As discussed in Section 4, the site should deliver outgoing packets that have a source address derived from the prefix of ISP[i] to that particular provider, in order to prevent those packets from being filtered due to ingress filtering [RFC2827] being applied by the providers. It is worth noting that in a scenario such as the one depicted in Figure 1, the paths followed by inbound and outbound traffic are determined, to a large extent, by the locators in use for the communication. This is not a particular issue of Shim6, but it is common to any deployment in which hosts are configured with addresses received from different providers. Traffic Engineering in such sites will likely involve proper configuration of address selection policies in the hosts, by means of mechanisms such as the ones discussed in Section 4.
因此，在H上使用定位器L[i]会导致通过ISP[i]路由到H的入站流量。将定位器从L[i]更改为L[j]将产生将入站流量从ISP[i]重新路由到H到ISP[j]的效果。这是Shim6协议旨在提供多主功能的核心机制：通过更改定位器，主机H可以更改用于将入站数据包路由到自身的上游ISP。关于到H的出站流量，在这种情况下采取的路径取决于用于R的实际定位器LR[j]和站点S的管理出口选择策略。如第4节所述，站点应将源地址源自ISP[i]前缀的出站数据包发送给该特定提供商，为了防止由于提供商应用入口过滤[RFC2827]而过滤这些数据包。值得注意的是，在如图1所示的场景中，入站和出站流量所遵循的路径在很大程度上由用于通信的定位器确定。这不是Shim6的一个特殊问题，但对于使用从不同提供商接收的地址配置主机的任何部署来说都是常见的。此类站点中的流量工程可能涉及通过第4节中讨论的机制在主机中正确配置地址选择策略。
The Shim6 protocol has other potential applications beyond site multihoming. For example, since Shim6 is a host-based protocol, it can also be used to support host multihoming. In this case, a failure in communication between a multihomed host and some other remote host might be repaired by selecting a locator associated with a different interface.
Shim6协议除了站点多宿主之外还有其他潜在的应用。例如，由于Shim6是一个基于主机的协议，因此它也可以用于支持主机多宿主。在这种情况下，可以通过选择与不同接口关联的定位器来修复多宿主主机和其他远程主机之间的通信故障。
To allow nodes to benefit from the capabilities provided by Shim6, (discussed in Section 5) such as fault tolerance, nodes should be configured to initiate a Shim6 session with any peer node if they have multiple locators to use. Note that this configuration can be performed transparently to the applications, in the sense that applications do not need to be aware of the Shim6 functionality provided by the node; in particular, nodes are not forced to use the Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should be created after the two nodes have been communicating for some time, i.e., using the deferred context establishment facility provided by Shim6. Otherwise, the cost of the Shim6 4-way handshake used for establishing the session may exceed the benefits provided for short-lived communications (see Section 5.1.2). More advanced node configuration may involve configuring different delays for initiating the session for different applications, for example, based on a per-port configuration. Nodes being able to use a single locator for the communication should not initiate the creation of a Shim6 context, but should participate if another node initiates it. Note that Shim6-aware applications can override this behavior by means of the Shim6 API [RFC6316].
为了让节点从Shim6提供的功能（在第5节中讨论）中受益，例如容错，如果节点有多个定位器可供使用，则应将节点配置为启动与任何对等节点的Shim6会话。注意，该配置可以对应用程序透明地执行，即应用程序不需要知道节点提供的Shim6功能；特别是，节点不会被迫使用Shim6API[RFC6316]来从Shim6中获益。应该在两个节点通信一段时间后创建Shim6会话，即使用Shim6提供的延迟上下文建立功能。否则，用于建立会话的Shim6 4路握手的成本可能超过短命通信的好处（见第5.1.2节）。更高级的节点配置可能涉及例如基于每端口配置为不同的应用程序配置不同的会话启动延迟。能够使用单个定位器进行通信的节点不应启动Shim6上下文的创建，但应在其他节点启动时参与。注意，支持Shim6的应用程序可以通过Shim6API[RFC6316]覆盖此行为。
The Shim6 protocol is defined only for IPv6. While some Shim6-like approaches have been suggested to support IPv4 addresses as a locator [SHIM6-ESD], it is not clear if such extensions are feasible.
Shim6协议仅为IPv6定义。虽然有人建议使用一些类似于Shim6的方法来支持IPv4地址作为定位器[Shim6-ESD]，但目前尚不清楚这种扩展是否可行。
The Shim6 protocol, as specified for IPv6, incorporates cryptographic elements in the construction of locators (see [RFC3972] and [RFC5535]). Since IPv4 addresses are insufficiently large to contain addresses constructed in this fashion, direct use of Shim6 with IPv4 addresses is not possible.
为IPv6指定的Shim6协议在定位器的构造中包含了加密元素（请参见[RFC3972]和[RFC5535]）。由于IPv4地址不够大，无法包含以这种方式构造的地址，因此无法将Shim6与IPv4地址一起直接使用。
In addition, there are other factors to take into account when considering the support of IPv4 addresses, in particular, IPv4 locators. Using multiple IPv4 addresses in a single host in order to support the Shim6 style of multihoming would result in an increased IPv4 address consumption, which would be problematic considering that the IPv4 address space has been exhausted. Besides, Shim6 may
此外，在考虑对IPv4地址的支持时，还需要考虑其他因素，特别是IPv4定位器。在单个主机中使用多个IPv4地址以支持Shim6风格的多宿主将导致IPv4地址消耗增加，考虑到IPv4地址空间已耗尽，这将是一个问题。此外，5月6日
experience additional problems if locators become translated on the wire. Address translation is more likely to involve IPv4 addresses. IPv4 addresses can be translated to other IPv4 addresses (for example, a private IPv4 address into a public IPv4 address and vice versa) or to/from IPv6 addresses (for example, as defined by NAT64 [RFC6146]). When address translation occurs, a locator exchanged by Shim6 could be different from the address needed to reach the corresponding host, either because the translated version of the locator exchanged by Shim6 is not known or because the translation state no longer exists in the translator device. Besides, the translated locators will not be verifiable with the current Cryptographically Generated Address (CGA) and Hash-Based Address (HBA) verification mechanisms, which protect the locators as seen by the node for which they are configured.
如果定位器在导线上转换，则会遇到其他问题。地址转换更可能涉及IPv4地址。IPv4地址可以转换为其他IPv4地址（例如，将专用IPv4地址转换为公用IPv4地址，反之亦然），也可以转换为IPv6地址（例如，根据NAT64[RFC6146]的定义）。当发生地址转换时，由Shim6交换的定位器可能与到达相应主机所需的地址不同，这可能是因为由Shim6交换的定位器的翻译版本未知，或者因为转换器设备中不再存在转换状态。此外，翻译后的定位器将无法使用当前的加密生成地址（CGA）和基于哈希的地址（HBA）验证机制进行验证，这两种机制保护定位器，就像为其配置的节点所看到的那样。
The Shim6 protocol does not assume that all the prefixes assigned to the multihomed site have the same prefix length.
Shim6协议并不假定分配给多址站点的所有前缀具有相同的前缀长度。
However, the use of CGA [RFC3972] and HBA [RFC5535] involves encoding information in the lower 64 bits of the locators. This imposes the requirement that all interface addresses should be able to accommodate 64-bit interface identifiers on Shim6-capable hosts. Note that this is imposed by RFC 4291 [RFC4291].
然而，CGA[RFC3972]和HBA[RFC5535]的使用涉及在定位器的低64位中编码信息。这就要求所有接口地址都能够在支持Shim6的主机上容纳64位接口标识符。请注意，这是由RFC 4291[RFC4291]强制执行的。
The security of the Shim6 protocol is based on the use of CGA and HBA addresses.
Shim6协议的安全性基于CGA和HBA地址的使用。
The CGA and HBA generation process can use the information provided by the stateless auto-configuration mechanism defined in [RFC4862] with the additional considerations presented in [RFC3972] and [RFC5535].
CGA和HBA生成过程可以使用[RFC4862]中定义的无状态自动配置机制提供的信息以及[RFC3972]和[RFC5535]中提出的其他注意事项。
Stateful address auto-configuration using DHCP [RFC3315] is not currently supported, because there is no defined mechanism to convey the CGA Parameter Data Structure and other relevant information from the DHCP server to the host. An analysis of the possible interactions between DHCPv6 and CGA can be found in [DHCPv6-CGA].
目前不支持使用DHCP[RFC3315]的有状态地址自动配置，因为没有定义机制将CGA参数数据结构和其他相关信息从DHCP服务器传送到主机。有关DHCPv6和CGA之间可能的相互作用的分析，请参见[DHCPv6 CGA]。
The choice between CGA and HBA is a trade-off between flexibility and performance.
CGA和HBA之间的选择是灵活性和性能之间的权衡。
The use of HBA is more efficient in the sense that addresses require less computation than CGA, involving only hash operations for both the generation and the verification of locator sets. However, the locators of an HBA set are determined during the generation process and cannot be subsequently changed; the addition of new locators to that initial set is not supported. Therefore, a node using an HBA as a ULID for a Shim6 session can only use the locators associated to that HBA for the considered Shim6 session. If the node wants to use a new set of locators, it has to generate a new HBA including the prefixes of the new locators (which will result with very high probability in different addresses to those of the previous set). New sessions initiated with a ULID belonging to the new HBA address set could use the new locators.
HBA的使用效率更高，因为与CGA相比，地址所需的计算更少，只涉及用于生成和验证定位器集的哈希操作。然而，HBA集的定位器是在生成过程中确定的，并且不能随后更改；不支持向该初始集添加新定位器。因此，将HBA用作Shim6会话的ULID的节点只能将与该HBA关联的定位器用于所考虑的Shim6会话。如果节点想要使用一组新的定位器，它必须生成一个新的HBA，其中包括新定位器的前缀（这将很可能导致与前一组定位器的地址不同的地址）。使用属于新HBA地址集的ULID启动的新会话可以使用新定位器。
The use of CGA is more computationally expensive, involving public-key cryptography in the verification of locator sets. However, CGAs are more flexible in the sense that they support the dynamic modification of locator sets.
CGA的使用在计算上更为昂贵，在定位器集的验证中涉及公钥加密。但是，CGA更灵活，因为它们支持定位器集的动态修改。
Therefore, CGAs are well suited to support dynamic environments such as mobile hosts, where the locator set must be changed frequently. HBAs are better suited for sites where the prefix set remains relatively stable.
因此，CGA非常适合支持动态环境，例如必须频繁更改定位器集的移动主机。HBA更适合前缀集保持相对稳定的站点。
It should be noted that since HBAs are defined as a CGA extension, it is possible to generate an address that incorporates the strengths of both HBA and CGA, i.e., that a single address can be used as an HBA, enabling computationally-cheap validation amongst a fixed set of addresses, and also as a CGA, enabling dynamic manipulation of the locator set. For additional details, see [RFC5535].
应该注意的是，由于HBA被定义为CGA扩展，因此可以生成一个结合了HBA和CGA优点的地址，即单个地址可以用作HBA，从而能够在固定地址集之间进行廉价的计算验证，也可以用作CGA，启用定位器集的动态操作。有关更多详细信息，请参阅[RFC5535]。
Shim6 multihomed nodes are likely to experience problems related to the attachment to different provision domains. Note that these problems are not specific to Shim6. [RFC6418] discusses the problems associated with nodes with multiple interfaces, which may involve difficulties in
Shim6多宿节点可能会遇到与连接到不同供应域相关的问题。请注意，这些问题并非特定于Shim6。[RFC6418]讨论了与具有多个接口的节点相关的问题，这些问题可能涉及
o managing the configuration associated with different providers.
o 管理与不同提供程序关联的配置。
o finding the appropriate DNS server to resolve a query and to match DNS answers to providers.
o 查找适当的DNS服务器以解析查询并将DNS答案与提供程序匹配。
o routing the packets to the right provider.
o 将数据包路由到正确的提供程序。
o selecting the source address appropriate to the destination and to the outgoing provider.
o 选择适合于目标和传出提供程序的源地址。
o performing session management appropriately.
o 适当地执行会话管理。
Some of these problems may also arise in single-interface hosts connected to multiple networks, for example, in configurations in which a customer network receives multiple Provider Aggregatable prefixes. These problems are relevant to other solutions supporting multihoming, such as Stream Control Transmission Protocol (SCTP) [RFC4960], Multipath TCP (MPTCP) [RFC6182], or Host Identity Protocol (HIP) [RFC4423]. Note also that single-homed nodes implementing Shim6 to improve communications with other nodes having multiple addresses will not experience these problems.
其中一些问题也可能出现在连接到多个网络的单接口主机中，例如，在客户网络接收多个提供商可聚合前缀的配置中。这些问题与支持多宿主的其他解决方案相关，例如流控制传输协议（SCTP）[RFC4960]、多路径TCP（MPTCP）[RFC6182]或主机标识协议（HIP）[RFC4423]。还请注意，实现Shim6以改进与具有多个地址的其他节点的通信的单宿主节点不会遇到这些问题。
The compatibility of Shim6 with configurations or mechanisms developed to solve any multihoming problem has to be carefully considered on a case-by-case basis. However, the interaction of Shim6 with some of the solutions discussed in [IPv6NAT] is commented on in the next paragraphs.
必须根据具体情况仔细考虑Shim6与为解决任何多宿问题而开发的配置或机制的兼容性。但是，下文将对Shim6与[IPv6NAT]中讨论的一些解决方案的相互作用进行评论。
In order to configure source and destination address selection, tools such as DHCPv6 can be used to disseminate an [RFC3484] policy table to a host [6MAN]. The impact to Shim6 using this solution, which disseminates the policy table to the hosts, is the following: Shim6 selects the ULID pair to use in communication according to the mechanism described in [RFC3484]. In case different locator pairs need to be explored, nodes also use the rules defined by [RFC3484] to identify valid pairs, and to establish an order among them, as described in [RFC5534].
为了配置源地址和目标地址选择，可以使用DHCPv6等工具将[RFC3484]策略表分发给主机[6MAN]。使用此解决方案（将策略表分发给主机）对Shim6的影响如下：Shim6根据[RFC3484]中描述的机制选择要在通信中使用的ULID对。如果需要探索不同的定位器对，节点还使用[RFC3484]定义的规则来识别有效对，并在它们之间建立顺序，如[RFC5534]中所述。
When a locator has been selected by a host to be used as the source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address in either the host or the network. For IPv6 nodes, the next-hop router to use for a given set of destinations can be configured through Extensions to Router Advertisements, through Default Router Preference and More-Specific Routes [RFC4191], the use of a DHCPv6 option, or the use of a routing protocol. It is also possible to rely on routers that consider source addresses in their forwarding decisions in addition to the usual destination-based forwarding. All these solutions are compatible with Shim6 operation. Note that an improper matching of source address and egress provider may result in packets being dropped if the provider performs ingress filtering [RFC2827], i.e., dropping packets that come from customer networks with source addresses not belonging to the prefix assigned to them to prevent address spoofing.
当主机选择定位器作为Shim6会话的源地址时，Shim6无法在主机或网络中强制该源地址的适当路径。对于IPv6节点，可通过对路由器播发的扩展、通过默认路由器首选项和更具体的路由[RFC4191]、使用DHCPv6选项或使用路由协议来配置用于给定目的地集的下一跳路由器。除了通常的基于目标的转发之外，还可以依赖于转发转发中考虑源地址的路由器。所有这些解决方案都与Shim6操作兼容。请注意，如果源地址和出口提供程序的不正确匹配导致提供程序执行入口过滤[RFC2827]，则可能会丢弃数据包，即丢弃来自客户网络且源地址不属于分配给它们的前缀的数据包，以防地址欺骗。
For some particular configurations, i.e., for a walled-garden or closed service, the node may need to identify the most appropriate DNS server to resolve a particular query. For an analysis of this problem, the reader is referred to [IPv6NAT].
对于某些特定配置，例如，对于有围墙的花园或封闭式服务，节点可能需要识别最合适的DNS服务器来解析特定查询。对于这个问题的分析，读者可以参考[IPv6NAT]。
Finally, note that Shim6 is built to handle communication problems, so it may recover from the misconfiguration (or lack) of some of the mechanisms used to handle the aforementioned problems. For example, if any notification is received from the router dropping the packets with legitimate source addresses as a result of ingress filtering, the affected locator could be associated with a low preference (or not be used at all). But even if such a notification is not received, or not processed by the Shim6 layer, the defective source address or next-hop selection will be treated as a communication failure. Therefore, Shim6 re-homing could finally select a working path in which packets are not filtered, if this path exists. This behavior results from the powerful end-to-end resilience properties exhibited by the REAchability Protocol (REAP) [RFC5534].
最后，请注意，Shim6是为处理通信问题而构建的，因此它可以从用于处理上述问题的某些机制的错误配置（或缺乏）中恢复。例如，如果由于入口过滤而从丢弃具有合法源地址的分组的路由器接收到任何通知，则受影响的定位器可能与低偏好相关联（或者根本不被使用）。但是，即使这样的通知没有被接收，或没有被Shim6层处理，有缺陷的源地址或下一跳选择也将被视为通信故障。因此，如果该路径存在，Shim6重新归巢最终可以选择一个不过滤数据包的工作路径。这种行为源于可达性协议（REAP）[RFC5534]所展示的强大的端到端弹性特性。
If a host within a multihomed site attempts to establish a communication with a remote host and selects a locator that corresponds to a failed transit path, bidirectional communication between the two hosts will not succeed. In order to establish a new communication, the initiating host must try different combinations of (source, destination) locator pairs until it finds a pair that works. The mechanism for this default address selection is described in [RFC3484]. As a result of the use of this mechanism, some failures may not be recovered, even if a valid alternative path exists between two communicating hosts. For example, assuming a failure in ISP[1] (see Figure 1), and host H initiating a communication with host R, the source address selection algorithm described in [RFC3484] may result in the selection of the source address corresponding to ISP[1] for every destination address being tried by the application. However, note that if R is the node initiating the communication, it will find a valid path provided that the application at R tries every available address for H.
如果多宿主站点中的主机尝试与远程主机建立通信，并选择与故障传输路径对应的定位器，则两台主机之间的双向通信将不会成功。为了建立新的通信，发起主机必须尝试（源、目标）定位器对的不同组合，直到找到一对有效为止。[RFC3484]中描述了此默认地址选择的机制。由于使用此机制，即使两台通信主机之间存在有效的备用路径，也可能无法恢复某些故障。例如，假设ISP[1]（见图1）发生故障，主机H启动与主机R的通信，[RFC3484]中描述的源地址选择算法可能导致为应用程序正在尝试的每个目标地址选择对应于ISP[1]的源地址。但是，请注意，如果R是发起通信的节点，则只要R处的应用程序尝试H的每个可用地址，它就会找到有效路径。
Since a Shim6 context is normally established between two hosts only after initial communication has been set up, there is no opportunity for Shim6 to participate in the discovery of a suitable, initial (source, destination) locator pair. The same consideration holds for referrals, as described in Section 6.
由于通常只有在建立初始通信后才在两台主机之间建立Shim6上下文，因此Shim6没有机会参与发现合适的初始（源、目标）定位器对。如第6节所述，同样的考虑也适用于转介。
The Shim6 context establishment operation requires a 4-way packet exchange, and involves some overhead on the participating hosts in memory and CPU.
Shim6上下文建立操作需要4路数据包交换，并且会在参与的主机内存和CPU中产生一些开销。
For short-lived communications between two hosts, the benefit of establishing a Shim6 context might not exceed the cost, perhaps because the protocols concerned are fault tolerant and can arrange their own recovery (e.g., DNS) or because the frequency of re-homing events is sufficiently low that the probability of such a failure occurring during a short-lived exchange is not considered significant.
对于两台主机之间的短命通信，建立Shim6上下文的好处可能不会超过成本，这可能是因为相关协议是容错的，并且可以安排自己的恢复（例如DNS）或者，由于重新引导事件的频率足够低，因此在短寿命交换期间发生此类故障的概率被认为不显著。
It is anticipated that the exchange of Shim6 context will provide the most benefit for exchanges between hosts that are long-lived. For this reason, the default behavior of Shim6-capable hosts is expected to employ deferred context-establishment. Deferred context setup ensures that session-establishment time will not be increased by the use of Shim6. This default behavior can be overridden by applications that prefer immediate context establishment, regardless of transaction longevity, by using [RFC6316].
可以预期，Shim6上下文的交换将为长期存在的主机之间的交换提供最大的好处。因此，支持Shim6的主机的默认行为预计将采用延迟上下文建立。延迟上下文设置确保会话建立时间不会因使用Shim6而增加。使用[RFC6316]时，无论事务的寿命如何，喜欢立即建立上下文的应用程序都可以覆盖此默认行为。
Note that all the above considerations refer to the lifetime of the interaction between the peers, and not the lifetime of a particular connection (e.g., TCP connection). In other words, the Shim6 context is established between ULID pairs and it affects all the communication between these ULIDs. So, two nodes with multiple short-lived communications using the same ULID pair would benefit as much from the Shim6 features as two nodes having a single long-lived communication. One example of such a scenario would be a web-client software downloading web content from a server over multiple TCP connections. Each TCP connection is short-lived, but the communication/contact between the two ULID could be long-lived.
请注意，以上所有注意事项都是指对等方之间交互的生存期，而不是特定连接（例如TCP连接）的生存期。换句话说，在ULID对之间建立Shim6上下文，它影响这些ULID之间的所有通信。因此，使用同一ULID对的具有多个短期通信的两个节点将与具有单个长期通信的两个节点一样从Shim6功能中受益。这种情况的一个例子是web客户端软件通过多个TCP连接从服务器下载web内容。每个TCP连接都是短期的，但两个ULID之间的通信/联系可能是长期的。
The Shim6 protocol does not support load balancing within a single context: all packets associated with a particular context are exchanged using a single locator pair per direction, with the exception of forked contexts, which are created upon explicit requests from the upper-layer protocol.
Shim6协议不支持单个上下文中的负载平衡：与特定上下文相关联的所有数据包都使用每个方向的单个定位器对进行交换，但分叉上下文除外，分叉上下文是根据上层协议的显式请求创建的。
It may be possible to extend the Shim6 protocol to use multiple locator pairs in a single context, but the impact of such an extension on upper-layer protocols (e.g., on TCP congestion control) should be considered carefully.
可以扩展Shim6协议以在单个上下文中使用多个定位器对，但应仔细考虑这种扩展对上层协议（例如，对TCP拥塞控制）的影响。
When many contexts are considered together in aggregation, e.g., on a single host that participates in many simultaneous contexts or in a site full of hosts, some degree of load sharing should occur naturally due to the selection of different locator pairs in each context. However, there is no mechanism defined to ensure that this natural load sharing is arranged to provide a statistical balance between transit providers.
当在聚合中同时考虑多个上下文时，例如，在参与多个同时上下文的单个主机上或在充满主机的站点上，由于在每个上下文中选择不同的定位器对，自然会发生某种程度的负载共享。然而，没有定义任何机制来确保这种自然负荷分担安排能够在公交供应商之间提供统计平衡。
Note that the use of transport-layer solutions enhanced with mechanisms to allow the use of multiple paths for a transport session are more amenable for achieving load-balancing. One such solution is MPTCP [RFC6182].
请注意，使用经过机制增强的传输层解决方案，以允许在传输会话中使用多条路径，对于实现负载平衡更为合适。MPTCP[RFC6182]就是这样一种解决方案。
For sites with prefixes obtained from different providers, the paths followed by inbound and outbound traffic are determined to a large extent by the locators selected for each communication. This is not a particular issue of Shim6, but it is common to any deployment in which hosts are configured with addresses received from different providers. Traffic engineering in such sites will likely involve proper configuration of the address selection policies defined by [RFC3484].
对于具有从不同提供商获得的前缀的站点，入站和出站流量所遵循的路径在很大程度上取决于为每次通信选择的定位器。这不是Shim6的一个特殊问题，但对于使用从不同提供商接收的地址配置主机的任何部署来说都是常见的。此类站点中的流量工程可能涉及[RFC3484]定义的地址选择策略的正确配置。
The Shim6 protocol provides some lightweight traffic engineering capabilities in the form of the Locator Preferences option, which allows a host to inform a remote host of local preferences for locator selection. In this way, the host can influence the incoming path for the communication. This mechanism is only available after a Shim6 context has been established, and it is a host-based capability rather than a site-based capability. There is no defined mechanism that would allow use of the Locator Preferences option amongst a site full of hosts to be managed centrally by the administrator of the site.
Shim6协议以定位器首选项选项的形式提供了一些轻量级流量工程功能，该选项允许主机将定位器选择的本地首选项通知远程主机。这样，主机可以影响通信的传入路径。此机制只有在建立了Shim6上下文之后才可用，它是基于主机的功能，而不是基于站点的功能。没有一种已定义的机制允许在由站点管理员集中管理的站点中使用定位器首选项选项。
Shim6 provides multihoming support without forcing changes in the applications running on the host. The fact that an address has been generated according to the CGA or HBA specification does not require any specific action from the application, e.g., it can obtain remote CGA or HBA addresses as a result of a getaddrinfo() call to trigger a DNS Request. The storage of CGA or HBA addresses in DNS does not require any modification to this protocol, since they are recorded using AAAA records. Moreover, neither the ULID/locator management [RFC5533] nor the failure detection and recovery [RFC5534] functions require application awareness.
Shim6提供多宿主支持，而无需强制更改主机上运行的应用程序。根据CGA或HBA规范生成地址的事实不需要应用程序执行任何特定操作，例如，它可以通过调用getaddrinfo（）来触发DNS请求，从而获得远程CGA或HBA地址。DNS中CGA或HBA地址的存储不需要对此协议进行任何修改，因为它们是使用AAAA记录记录的。此外，ULID/定位器管理[RFC5533]和故障检测与恢复[RFC5534]功能都不需要应用程序感知。
However, a specific API [RFC6316] has been developed for those applications that might require additional capabilities in ULID/ locator management, such as the locator pair in use for a given context, or the set of local or remote locators available for it. This API can also be used to disable Shim6 operation when required.
但是，已经为那些可能需要ULID/定位器管理中的附加功能的应用程序开发了特定API[RFC6316]，例如用于给定上下文的定位器对，或可用于该上下文的本地或远程定位器集。此API还可用于在需要时禁用Shim6操作。
It is worth noting that callbacks can benefit naturally from Shim6 support. In a callback, an application in B retrieves IP_A, the IP address of a peer A, and B uses IP_A to establish a new communication with A. As long as the address exchanged, IP_A, is the ULID for the initial communication between A and B, and B uses the same address as in the initial communication, and this initial communication is alive (or the context has not been deleted), the new communication could use the locators exchanged by Shim6 for the first communication. In this case, communication could proceed even if the ULID of A is not reachable.
值得注意的是，回调可以从Shim6支持中自然受益。在回调中，B中的应用程序检索IP_a，对等方a的IP地址，B使用IP_a与a建立新的通信。只要交换的地址IP_a是a和B之间初始通信的ULID，B使用与初始通信中相同的地址，并且该初始通信是活动的（或上下文未被删除），新的通信可以使用Shim6交换的定位器进行第一次通信。在这种情况下，即使无法访问A的ULID，通信也可以继续。
However, Shim6 does not provide specific protection to current applications when they use referrals. A referral is the exchange of the IP address IP_A of a party A by party B to party C, so that party C could use IP_A to communicate with party A. In a normal case, the ULID IP_A would be the only information sent by B to C as a referral. But if IP_A is no longer valid as the locator in A, C could have trouble establishing a communication with A. Increased failure protection for referrals could be obtained if B exchanged the whole list of alternative locators of A; although, in this case the application protocol should be modified. Note that B could send to C the current locator of A, instead of the ULID of A, as a way of using the most recent reachability information about A. While in this case no modification of the application protocol is required, some concerns arise: host A may not accept one of its locators as ULID for initiating a communication, and if a CGA are used, the locator may not be a CGA so a Shim6 context among A and C could not be created.
但是，当当前应用程序使用转介时，Shim6不提供特定的保护。转介是指乙方将甲方的IP地址IP_A交换给丙方，以便丙方可以使用IP_A与甲方通信。在正常情况下，ULID IP_A将是乙方作为转介发送给丙方的唯一信息。但是，如果IP_A不再是A中的定位器，C可能无法与A建立通信。如果B交换A的整个替代定位器列表，则可以获得更高的转诊故障保护；但是，在这种情况下，应用程序协议应该修改。注意，B可以向C发送A的当前定位器，而不是A的ULID，作为使用关于A的最新可达性信息的一种方式。在这种情况下，不需要修改应用协议，但会出现一些问题：主机A可能不接受其定位器之一作为ULID来启动通信，并且如果使用CGA，定位器可能不是CGA，因此无法创建a和C之间的Shim6上下文。
In this section we discuss the interaction between Shim6 and other protocols and mechanisms. Before starting the discussion, it is worth noting that at the time of this writing, there is a lack of experience with the combination of Shim6 and these protocols and mechanisms. Therefore, the conclusions stated should be reviewed as real experience is gained in the use of Shim6.
在本节中，我们将讨论Shim6与其他协议和机制之间的交互。在开始讨论之前，值得注意的是，在撰写本文时，缺乏将Shim6与这些协议和机制相结合的经验。因此，在使用Shim6获得实际经验时，应审查所述结论。
Here, we consider some scenarios in which the Shim6 protocol and the Mobile IPv6 (MIPv6) protocol [RFC6275] might be used simultaneously.
在这里，我们考虑一些场景，其中SHIM6协议和移动IPv6（MIPv6）协议[RCF6255]可以同时使用。
In this case, the Home Network of the Mobile Node (MN) is multihomed. This implies the availability of multiple Home Network prefixes, resulting in multiple Home Addresses (HoAs) for each MN. Since the MN is a node within a multihomed site, it seems reasonable to expect that the MN should be able to benefit from the multihoming capabilities provided by the Shim6 protocol. Moreover, the MN needs to be able to obtain the multihoming benefits, even when it is roaming away from the Home Network: if the MN is away from the Home Network while the Home Network suffers a failure in a transit path, the MN should be able to continue communicating using alternate paths to reach the Home Network.
在这种情况下，移动节点（MN）的归属网络是多址的。这意味着多个家庭网络前缀的可用性，导致每个MN有多个家庭地址（HOA）。由于MN是多主站点内的节点，因此可以合理地预期MN应该能够受益于Shim6协议提供的多主功能。此外，MN需要能够获得多归属的好处，即使当它漫游离开归属网络时：如果MN离开归属网络，而归属网络在传输路径中发生故障，MN应该能够使用备用路径继续通信以到达归属网络。
The resulting scenario is the following:
由此产生的场景如下所示：
+------------------------------------+
| Internet |
+------------------------------------+
| |
+----+ +----+
|ISP1| |ISP2|
+----+ +----+
| |
+------------------------------------+
| Multihomed Home Network |
| Prefixes: P1 and P2 |
| |
| Home Agent |
| // |
+------------------//----------------+
//
//
+-----+
| MN | HoA1, HoA2
+-----+
+------------------------------------+
| Internet |
+------------------------------------+
| |
+----+ +----+
|ISP1| |ISP2|
+----+ +----+
| |
+------------------------------------+
| Multihomed Home Network |
| Prefixes: P1 and P2 |
| |
| Home Agent |
| // |
+------------------//----------------+
//
//
+-----+
| MN | HoA1, HoA2
+-----+
Figure 2
图2
So, in this configuration, the Shim6 protocol is used to provide multiple communication paths to all the nodes within the multihomed sites (including the mobile nodes), and the MIPv6 protocol is used to support mobility of the multihomed site's mobile nodes.
因此，在该配置中，使用Shim6协议向多宿站点内的所有节点（包括移动节点）提供多条通信路径，并且使用MIPv6协议支持多宿站点的移动节点的移动性。
The proposed protocol architecture would be the following:
拟议的协议架构如下：
+--------------+
| Application |
+--------------+
| Transport |
+--------------+
| IP |
| +----------+ |
| | IPSec | |
| +----------+<--ULIDs
| | Shim6 | |
| +----------+<--HoAs
| | MIPv6 | |
| +----------+<--CoAs
| |
+--------------+
Figure 3
+--------------+
| Application |
+--------------+
| Transport |
+--------------+
| IP |
| +----------+ |
| | IPSec | |
| +----------+<--ULIDs
| | Shim6 | |
| +----------+<--HoAs
| | MIPv6 | |
| +----------+<--CoAs
| |
+--------------+
Figure 3
In this architecture, the upper-layer protocols and IPSec would use ULIDs of the Shim6 protocol (see Section 16.1 in [RFC5533] for more detail on the interaction between Shim6 and IPsec). Only the HoAs will be presented by the upper layers to the Shim6 layer as potential ULIDs. Two Shim6 entities will exchange their own available HoAs as locators. Therefore, Shim6 provides failover between different HoAs and allows preservation of established communications when an outage affects the path through the ISP that has delegated the HoA used for initiating the communication (similar to the case of a host within a multihomed site). The Care-of Addresses (CoAs) are not presented to the Shim6 layer and are not included in the local locator set in this case. The CoAs are managed by the MIPv6 layer, which binds each HoA to a CoA. For example, if a single CoA, CoA1, is available for the MN in the foreign link to which it is attached, every HoA should have a bind to CoA1.
在此体系结构中，上层协议和IPSec将使用Shim6协议的ULID（有关Shim6和IPSec之间交互的更多详细信息，请参阅[RFC5533]中的第16.1节）。仅上层将HOA作为潜在ULID呈现给Shim6层。两个Shim6实体将交换自己可用的HOA作为定位器。因此，Shim6在不同HoA之间提供故障切换，并允许在中断影响通过ISP的路径时保留已建立的通信，ISP已授权用于启动通信的HoA（类似于多址站点中的主机）。在这种情况下，转交地址（COA）不提供给Shim6层，也不包括在本地定位器集中。CoA由MIPv6层管理，该层将每个HoA绑定到CoA。例如，如果单个CoA CoA1可用于其所连接的外部链路中的MN，则每个HoA都应绑定到CoA1。
So, in this case, the upper-layer protocols select a ULID pair for the communication. The Shim6 protocol translates the ULID pair to an alternative locator in case that is needed. Both the ULIDs and the alternative locators are HoAs. Next, the MIPv6 layer maps the selected HoA to the corresponding CoA, which is the actual address included in the wire.
因此，在这种情况下，上层协议为通信选择ULID对。在需要的情况下，Shim6协议将ULID对转换为替代定位器。ULID和替代定位器都是HOA。接下来，MIPv6层将所选HoA映射到相应的CoA，CoA是包括在线路中的实际地址。
The Shim6 context is established between the MN and the Correspondent Node (CN), and it would allow the communication to use all the available HoAs to provide fault tolerance. The MIPv6 protocol is used between the MN and the Home Agent (HA) in the case of the bidirectional tunnel mode, and between the MN and the CN in case of the Route Optimization (RO) mode.
在MN和对应节点（CN）之间建立Shim6上下文，它将允许通信使用所有可用HOA来提供容错。在双向隧道模式的情况下，在MN和归属代理（HA）之间使用MIPv6协议，在路由优化（RO）模式的情况下，在MN和CN之间使用MIPv6协议。
Another scenario where a Shim6-MIPv6 interaction may be useful is the case where a Shim6 context is established between the MN and the HA in order to provide fault tolerance capabilities to the bidirectional tunnel between them.
Shim6-MIPv6交互可能有用的另一个场景是在MN和HA之间建立Shim6上下文以向它们之间的双向隧道提供容错能力的情况。
Consider the case where the HA has multiple addresses (whether because the Home Network is multihomed or because the HA has multiple interfaces) and/or the MN has multiple addresses (whether because the visited network is multihomed or because the MN has multiple interfaces). In this case, if a failure affects the address pair that is being used to run the tunnel between the MN and HA, additional mechanisms need to be used to preserve the communication.
考虑HA具有多个地址（无论是家庭网络是多宿主还是因为HA具有多个接口）和/或MN具有多个地址（无论是访问的网络是多宿主的还是因为MN具有多个接口）的情况。在这种情况下，如果故障影响用于运行MN和HA之间的隧道的地址对，则需要使用其他机制来保持通信。
One possibility would be to use MIPv6 capabilities, by simply changing the CoA used as the tunnel endpoint. However, MIPv6 lacks the failure detection mechanisms that would allow the MN and/or the HA to detect the failure and trigger the usage of an alternative address. Shim6 provides such a failure detection protocol, so one possibility would be re-using the failure detection function from the Shim6 failure detection protocol in MIPv6. In this case, the Shim6 protocol wouldn't be used to create Shim6 context and provide fault tolerance, but just its failure detection functionality would be re-used.
一种可能是使用MIPv6功能，只需更改用作隧道端点的CoA即可。然而，MIPv6缺乏故障检测机制，该机制将允许MN和/或HA检测故障并触发替代地址的使用。Shim6提供了这样的故障检测协议，因此一种可能性是在MIPv6中重新使用来自Shim6故障检测协议的故障检测功能。在这种情况下，不会使用Shim6协议来创建Shim6上下文并提供容错，而只会重用其故障检测功能。
The other possibility would be to use the Shim6 protocol to create a Shim6 context between the HA and the MN, so that the Shim6 detects any failure and re-homes the communication in a transparent fashion to MIPv6. In this case, the Shim6 protocol would be associated with the tunnel interface.
另一种可能性是使用Shim6协议在HA和MN之间创建Shim6上下文，以便Shim6检测到任何故障，并以透明方式将通信重新驻留到MIPv6。在这种情况下，Shim6协议将与隧道接口相关联。
Secure Neighbor Discovery (SEND) [RFC3971] uses CGAs to prove address ownership for Neighbor Discovery [RFC4861]. The Shim6 protocol can use either CGAs or HBAs to protect locator sets included in Shim6 contexts. It is expected that some hosts will need to participate in both SEND and Shim6 simultaneously.
安全邻居发现（SEND）[RFC3971]使用CGA证明邻居发现的地址所有权[RFC4861]。Shim6协议可以使用CGA或HBA来保护Shim6上下文中包含的定位器集。预计一些主机将需要同时参与SEND和Shim6。
In the case that both the SEND and Shim6 protocols are using the CGA technique to generate addresses, there is no conflict; the host will generate addresses for both purposes as CGAs, and since it will be in control of the associated private key, the same CGA can be used for the different protocols.
在SEND和Shim6协议都使用CGA技术生成地址的情况下，不存在冲突；主机将为这两个目的生成地址作为CGA，并且由于它将控制相关的私钥，因此相同的CGA可用于不同的协议。
In the case that a Shim6-capable host is using HBAs to protect its locator sets, the host will need to generate an address that is both a valid CGA and a valid HBA, as defined in [RFC5535]. In this case, the CGA Parameter Data Structure containing a valid public key and the Multi-Prefix extension are included as inputs to the hash function.
如果支持Shim6的主机使用HBA保护其定位器集，则该主机将需要生成一个既有效CGA又有效HBA的地址，如[RFC5535]中所定义。在这种情况下，包含有效公钥和多前缀扩展的CGA参数数据结构被包括为散列函数的输入。
Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a reliable, stream-based communications channel between two hosts that provides a superset of the capabilities of TCP. One notable feature of these two protocols is that they allow the exchange of endpoint addresses between hosts in order to recover from the failure of a particular endpoint pair, or to benefit from multipath communication in the MPTCP case, in a manner that is conceptually similar to locator selection in Shim6.
SCTP[RFC4960]和MPTCP[RFC6182]协议都在两台主机之间提供了一个可靠的、基于流的通信通道，提供了TCP功能的超集。这两个协议的一个显著特征是，它们允许主机之间交换端点地址，以便从特定端点对的故障中恢复，或者在MPTCP情况下受益于多路径通信，其方式在概念上类似于Shim6中的定位器选择。
SCTP and MPTCP are transport-layer protocols, higher in the protocol stack than Shim6; hence, there is no fundamental incompatibility that would prevent a Shim6-capable host from communicating using SCTP or MPTCP.
SCTP和MPTCP是传输层协议，在协议栈中的级别高于Shim6；因此，不存在阻止支持Shim6的主机使用SCTP或MPTCP进行通信的基本不兼容性。
However, since either SCTP or MPTCP, and Shim6 aim to exchange addressing information between hosts in order to meet the same generic goal, it is possible that their simultaneous use might result in unexpected behavior, e.g., lead to race conditions.
但是，由于SCTP或MPTCP以及Shim6的目的是在主机之间交换寻址信息以达到相同的通用目标，因此它们的同时使用可能会导致意外行为，例如导致竞争条件。
The capabilities of these transport protocols with respect to path maintenance of a reliable, connection-oriented stream protocol are more extensive than the more general layer-3 locator agility provided by Shim6. Therefore, it is recommended that Shim6 not be used for SCTP or MPTCP sessions, and that path maintenance be provided solely by SCTP or MPTCP. There are at least two ways to enforce this behavior. One option is to make the stack, and in particular the Shim6 sublayer, aware of the use of SCTP or MPTCP, and in this case refrain from creating a Shim6 context. The other option is that the upper transport layer indicates, using a Shim6-capable API like the one proposed in [RFC6316], that no Shim6 context must be created for this particular communication.
这些传输协议在可靠的、面向连接的流协议的路径维护方面的能力比Shim6提供的更通用的第3层定位器灵活性更广泛。因此，建议不要将Shim6用于SCTP或MPTCP会话，路径维护仅由SCTP或MPTCP提供。至少有两种方法可以强制执行此行为。一种选择是使堆栈，特别是Shim6子层知道SCTP或MPTCP的使用，在这种情况下，避免创建Shim6上下文。另一种选择是，上层传输层使用[RFC6316]中建议的支持Shim6的API指示，不必为此特定通信创建Shim6上下文。
In general, the issues described here may also arise for protocols that handle different addresses for two communicating nodes at a higher level than the network layer to improve reliability, performance, congestion control, etc.
一般来说，对于在高于网络层的级别上处理两个通信节点的不同地址以改进可靠性、性能、拥塞控制等的协议，这里描述的问题也可能出现。
The Network Mobility (NEMO) [RFC3963] protocol extensions to MIPv6 allow a Mobile Network to communicate through a bidirectional tunnel via a Mobile Router (MR) to a NEMO-compliant HA located in a Home Network.
MIPv6的网络移动性（NEMO）[RFC3963]协议扩展允许移动网络通过双向隧道经由移动路由器（MR）与位于家庭网络中的符合NEMO的HA通信。
If either or both the MR or HA are multihomed, then an established Shim6 context preserves the integrity of the bidirectional tunnel between them in the event that a transit failure occurs in the connecting path.
如果MR或HA中的一个或两个都是多址的，那么在连接路径中发生传输故障的情况下，已建立的Shim6上下文将保持它们之间双向隧道的完整性。
Once the tunnel between MR and HA is established, hosts within the Mobile Network that are Shim6-capable can establish contexts with remote hosts in order to receive the same multihoming benefits as any host located within the Home Network.
一旦建立了MR和HA之间的隧道，移动网络中支持Shim6的主机就可以与远程主机建立上下文，以便获得与家庭网络中任何主机相同的多宿好处。
Shim6 and HIP [RFC4423] are architecturally similar in the sense that both solutions allow two hosts to use different locators to support communications between stable ULIDs. The signaling exchange to establish the demultiplexing context on the hosts is very similar for both protocols. However, there are a few key differences. First, Shim6 avoids defining a new namespace for ULIDs, preferring instead to use a routable locator as a ULID, while HIP uses public keys and hashes thereof as ULIDs. The use of a routable locator as the ULID better supports deferred context establishment, application callbacks, and application referrals, and avoids management and resolution costs of a new namespace, but requires additional security mechanisms to securely bind the ULID with the locators. Second, Shim6 uses an explicit context header on data packets for which the ULIDs differ from the locators in use (this header is only needed after a failure/re-homing event occurs), while HIP may compress this context-tag function into the Encapsulating Security Payload (ESP) Security Parameter Index (SPI) field [RFC5201]. Third, HIP as presently defined requires the use of public-key operations in its signaling exchange and ESP encryption in the data plane, while the use of Shim6 requires neither (if only HBA addresses are used). By default, HIP provides data protection, while this is a non-goal for Shim6.
Shim6和HIP[RFC4423]在架构上相似，这两种解决方案都允许两台主机使用不同的定位器来支持稳定的ULID之间的通信。这两种协议用于在主机上建立解复用上下文的信令交换非常相似。然而，有几个关键的区别。首先，Shim6避免为ULID定义新的名称空间，而是更喜欢使用可路由定位器作为ULID，而HIP使用公钥及其散列作为ULID。使用可路由定位器作为ULID更好地支持延迟上下文建立、应用程序回调和应用程序引用，避免了新命名空间的管理和解析成本，但需要额外的安全机制来安全地将ULID与定位器绑定。其次，对于ULID与使用中的定位器不同的数据包，Shim6使用显式上下文报头（仅在发生故障/重新引导事件后才需要此报头），而HIP可将此上下文标记函数压缩到封装安全有效负载（ESP）安全参数索引（SPI）字段[RFC5201]。第三，目前定义的HIP要求在其信令交换中使用公钥操作，在数据平面中使用ESP加密，而使用Shim6则两者都不需要（如果只使用HBA地址）。默认情况下，HIP提供数据保护，而这不是Shim6的目标。
Shim6 aimed to provide a solution to a specific problem, multihoming, which minimizes deployment disruption, while HIP is considered more of an experimental approach intended to solve several more general problems (mobility, multihoming, and loss of end-to-end addressing transparency) through an explicit identifier/locator split.
Shim6旨在为一个特定问题提供一个解决方案，即多归属，它将部署中断降至最低，而HIP则被认为是一种实验性方法，旨在通过显式标识符/定位器拆分来解决几个更一般的问题（移动性、多归属和端到端寻址透明度的损失）。
Communicating hosts that are willing to run HIP (perhaps extended with Shim6's failure detection protocol) likely have no reason to also run Shim6. In this sense, HIP may be viewed as a possible long-term evolution or extension of the Shim6 architecture, or one possible implementation of the Extended Shim6 Design (ESD) [SHIM6-ESD].
愿意运行HIP（可能使用Shim6的故障检测协议扩展）的通信主机可能没有理由也运行Shim6。从这个意义上讲，HIP可被视为Shim6体系结构的一种可能的长期演变或扩展，或扩展的Shim6设计（ESD）[Shim6-ESD]的一种可能实现。
The ability of Shim6 to divert the communication to different paths may be affected by certain firewall configurations. For example, consider a deployment in which one of the peers of a Shim6 session is protected by a firewall (i.e., all the paths to the locators of that peer traverse the firewall). The firewall implements the Simple Security model [RFC4864], in which incoming packets are checked against a state resulting from outgoing traffic, either associated with the locator of the internal node ('endpoint independent filtering') or to both the locators of the internal and external nodes ('address dependent filtering' or 'address and port dependent filtering'). If the external node changes the locator associated with the internal node, the packet will be discarded by the firewall. In addition, if the firewall implements 'address dependent filtering' or 'address and port dependent filtering', any change by the external node in the locator used to identify itself will also result in the packet being discarded by the firewall.
Shim6将通信转移到不同路径的能力可能会受到某些防火墙配置的影响。例如，考虑一个部署，其中SHIM6会话的一个对等点被防火墙保护（即，该对等点的定位器遍历防火墙的所有路径）。防火墙实现了简单的安全模型[RFC4864]，在该模型中，根据与内部节点的定位器（“端点独立过滤”）或内部和外部节点的定位器相关联的传出流量产生的状态检查传入数据包（“地址相关过滤”或“地址和端口相关过滤”）。如果外部节点更改与内部节点关联的定位器，则数据包将被防火墙丢弃。此外，如果防火墙实施“地址相关过滤”或“地址和端口相关过滤”，则外部节点在用于标识自身的定位器中的任何更改也将导致数据包被删除受到防火墙的攻击。
This issue could be mitigated by making the firewalls aware of the different locators that could be associated with a given communication. If the firewall is implemented in the communication node itself, the firewall could inspect the Shim6 control packet exchange to obtain this information, or the Shim6 software module could explicitly inform the firewall software module. For firewalls located outside the node, the Shim6 control packet exchange can be used to associate the alternate locators to the communication state, although it may not work for topologies in which both directions for the communication do not traverse the firewall, or in which the firewall is not traversed after a locator change. The detail of any of such mechanisms is out of the scope of this document.
通过让防火墙知道可能与给定通信相关联的不同定位器，可以缓解此问题。如果防火墙在通信节点本身中实现，则防火墙可以检查Shim6控制数据包交换以获取该信息，或者Shim6软件模块可以明确通知防火墙软件模块。对于位于节点外部的防火墙，可以使用Shim6控制数据包交换将备用定位器与通信状态相关联，尽管它可能不适用于通信的两个方向都未穿过防火墙的拓扑，或者在定位器更改后未穿过防火墙的拓扑。任何此类机制的详细信息不在本文件范围内。
However, note that a failure in using the alternative locators does not impact the communication between the nodes as long as the path between them defined by the initial locator pair remains available. In this case, data packets flow between the communicating nodes as for any non-Shim6 communication.
然而，请注意，只要由初始定位器对定义的节点之间的路径保持可用，使用替代定位器的失败不会影响节点之间的通信。在这种情况下，对于任何非Shim6通信，数据分组在通信节点之间流动。
Address translation techniques such as Network Prefix Translation (NPTv6) [RFC6296] may be used until workable solutions to avoid renumbering or facilitate multihoming are developed [RFC5902]. We now consider the impact of NPTv6 in Shim6 operation. Some of the considerations stated in this section may also be applicable to other types of IPv6 NAT.
地址转换技术，如网络前缀转换（NPTv6）[RFC6296]可以使用，直到开发出避免重新编号或促进多址的可行解决方案[RFC5902]。我们现在考虑NPTV6在SHIM6操作中的影响。本节中所述的一些注意事项也可能适用于其他类型的IPv6 NAT。
The main purpose of Shim6 is to provide locator agility below transport protocols. To prevent the risk of redirection attacks by abusing the locator exchange facilities provided by Shim6, the protocol is built upon the cryptographic properties of CGA and HBA addresses. When the CGA address of a node is used as the local ULID, the locators configured in the node can be signed with the private key associated with the CGA. A peer receiving a Shim6 message performs a hash of the CGA Parameter Data Structure information received, including a public key, to assure that this key is bound to the CGA address, and then checks the signature protecting the locators. When an HBA address of a node is used as the local ULID, the HBA address securely chains the ULID and other locators of the node by means of a hash. For both the CGA and the HBA, the locators can be exchanged at the four-way handshake used to establish the Shim6 context, or once the context has been established by means of an Update Request message.
Shim6的主要目的是提供低于传输协议的定位器灵活性。为了防止滥用Shim6提供的定位器交换设施而引发重定向攻击的风险，该协议基于CGA和HBA地址的加密属性构建。当节点的CGA地址用作本地ULID时，可以使用与CGA关联的私钥对节点中配置的定位器进行签名。接收到Shim6消息的对等方对接收到的CGA参数数据结构信息（包括公钥）执行散列，以确保该密钥绑定到CGA地址，然后检查保护定位器的签名。当节点的HBA地址用作本地ULID时，HBA地址通过哈希安全地链接该节点的ULID和其他定位器。对于CGA和HBA，定位器可以在用于建立Shim6上下文的四向握手时或通过更新请求消息建立上下文后交换。
When a node behind an NPTv6 communicates, the NAT device translates the address assigned to this internal node to an address of its address pool. This operation results in a mismatch between the address seen by external hosts and the address configured in the internal node, which is the locator that would be conveyed in a Shim6 locator exchange and is also the address for which the security defined in the CGA and HBA specifications are provided. Then, the validation processes performed by an external node may prevent the creation of the Shim6 context, or may allow the context to be created but render the alternative locator of the internal host unusable.
当NPTv6后面的节点通信时，NAT设备将分配给该内部节点的地址转换为其地址池的地址。此操作导致外部主机看到的地址与内部节点中配置的地址不匹配，内部节点是将在Shim6定位器交换中传输的定位器，也是提供CGA和HBA规范中定义的安全性的地址。然后，由外部节点执行的验证过程可以阻止创建Shim6上下文，或者可以允许创建上下文，但使内部主机的替代定位器不可用。
However, note that the failure in creating a Shim6 context, or in using the alternative locators, does not impact the communication between the nodes as long as the path between them defined by the initial locator pair remains available. Data packets flow between the communicating nodes as for any non-Shim6 communication. Not creating the Shim6 context, or not being able to convey the local locators to the peer node, affect the added value provided by Shim6, i.e., the ability to preserve the communication in case any of the locators fail. Therefore, using Shim6 with NPTv6 does not provide less functionality than using IPv6 in the same scenario.
但是，请注意，只要初始定位器对定义的节点之间的路径仍然可用，创建Shim6上下文或使用替代定位器的失败不会影响节点之间的通信。对于任何非Shim6通信，数据包在通信节点之间流动。不创建Shim6上下文，或者不能将本地定位器传送到对等节点，会影响Shim6提供的附加值，即在任何定位器发生故障时保持通信的能力。因此，在同一场景中，将Shim6与NPTv6结合使用不会比使用IPv6提供更少的功能。
We now illustrate some cases that may occur when combining Shim6 and NPTv6. The following discussion does not aim to be exhaustive in the cases that may arise, but just aims to provide some examples of possible situations. We assume a scenario in which host A is located behind a NPTv6 device for its locator IP_A1, but it is connected to the public IPv6 Internet for its locator IP_A2. Once translated, locator IP_A1 appears to external nodes as IP_T. Node A communicates with node B, with public addresses IP_B1 and IP_B2.
现在，我们将举例说明结合Shim6和NPTv6时可能出现的一些情况。以下讨论的目的并不是对可能出现的情况进行详尽的讨论，而是提供一些可能情况的例子。我们假设主机a位于NPTv6设备后面，用于定位IP_A1，但它连接到公共IPv6 Internet，用于定位IP_A2。一旦转换，定位器IP_A1在IP_T时显示给外部节点。节点A与节点B通信，公共地址为IP_B1和IP_B2。
+-----+
| A |
+-----+
IP_A1 | | IP_A2
| |
| +-----+
| |
+--------+ |
| NPTv6 | |
+--------+ |
IP_T | |
| |
+--------------------------+
| Internet |
+--------------------------+
| |
IP_B1 | | IP_B2
+-----+
| B |
+-----+
+-----+
| A |
+-----+
IP_A1 | | IP_A2
| |
| +-----+
| |
+--------+ |
| NPTv6 | |
+--------+ |
IP_T | |
| |
+--------------------------+
| Internet |
+--------------------------+
| |
IP_B1 | | IP_B2
+-----+
| B |
+-----+
Figure 4
图4
We first discuss some issues related with the four-way handshake used to establish the Shim6 context. When the locator information is included in the Shim6 exchange, either in the I2 or R2 messages, the receiver is required to validate the ULID of the peer node by performing the CGA or HBA address validation procedure. In case the validation fails, the message containing the information is silently discarded. In the scenario depicted in Figure 4, some of the cases that may occur are:
我们首先讨论与用于建立Shim6上下文的四向握手相关的一些问题。当定位器信息包含在Shim6交换中（I2或R2消息中）时，接收器需要通过执行CGA或HBA地址验证过程来验证对等节点的ULID。如果验证失败，包含该信息的消息将被自动丢弃。在图4所示的场景中，可能出现的一些情况是：
o Node A initiates the exchange, with IP_B1 as the destination address and IP_A1 as the source address, which is a CGA. Node A includes IP_A2 as an alternative locator in the I2 message. Node B sees IP_T as the ULID for A, so when it validates the CGA with the information contained in I2, the validation fails because the CGA Parameter Data Structure contains information bound to IP_A1. Therefore, B silently discards the received I2 message. Without
o 节点A发起交换，IP_B1作为目的地址，IP_A1作为源地址，这是一个CGA。节点A包括IP_A2作为I2消息中的替代定位器。节点B将IP_T视为A的ULID，因此当它使用I2中包含的信息验证CGA时，验证失败，因为CGA参数数据结构包含绑定到IP_A1的信息。因此，B会自动丢弃接收到的I2消息。没有
receiving a valid I2 message, B does not create the Shim6 context. Without receiving the R2 message, A also does not create the Shim6 context. However, data communication can proceed as long as the path between IP_A1 and IP_B1 is valid. A similar case occurs if IP_A1 and IP_A2 form an HBA, instead of using CGAs for securing the communication.
接收到有效的I2消息后，B不会创建Shim6上下文。如果没有收到R2消息，A也不会创建Shim6上下文。但是，只要IP_A1和IP_B1之间的路径有效，数据通信就可以继续进行。如果IP_A1和IP_A2形成HBA，而不是使用CGA来保护通信，则会发生类似的情况。
o Node A initiates the exchange with IP_B1 as the destination address and IP_A2 (its public address) as the source address, which is a CGA. Node A includes IP_A1 as an alternative locator in the I2 message. In this case, B can successfully validate IP_A2 as a CGA. Regarding the validation of IP_A1 as an alternative locator for A, the Shim6 specification [RFC5533] indicates that it should perform this check when the I2 message is received, but it may perform it later on, provided that the check is performed before using it as a locator. In case the validation is performed when I2 is received, the I2 message would be silently discarded, with the same result as for the previous case. In case the validation is performed later, the Shim6 context would be established in both nodes A and B, but B could not send to IP_A1, and packets sent by A from IP_A1 will not be received by B. Note that in this case both IP_B1 and IP_B2 could be used by A and B, as long as the locator for A is IP_A2, so limited locator agility may be achieved.
o 节点A以IP_B1作为目的地址，IP_A2（其公共地址）作为源地址（即CGA）发起交换。节点A包括IP_A1作为I2消息中的替代定位器。在这种情况下，B可以成功地将IP_A2验证为CGA。关于IP_A1作为A的替代定位器的验证，Shim6规范[RFC5533]指出，它应该在收到I2消息时执行该检查，但它可以在以后执行该检查，前提是在将其用作定位器之前执行该检查。如果在收到I2时执行验证，I2消息将被静默丢弃，结果与前一种情况相同。如果稍后执行验证，将在节点A和B中建立Shim6上下文，但B无法发送到IP_A1，并且A从IP_A1发送的数据包将不会被B接收。注意，在这种情况下，只要A的定位器是IP_A2，A和B都可以使用IP_B1和IP_B2，因此可以实现有限的定位器敏捷性。
o Node B initiates the exchange with IP_B1 as the source address, and IP_A2 as the destination address, which is a CGA. This case is similar to the previous one, although it is the R2 message sent by A that cannot be validated. While A can create a context with B, B cannot do the same for A. Data communication using IP_B1 and IP_A2 can proceed. However, A may try to use IP_B2 as an alternative locator, but the data packets sent carrying the Shim6 Extension Header will not be associated by B to any established context, so they will be discarded. The same occurs for packets sent by A with IP_A1 as the source address.
o 节点B以IP_B1作为源地址，IP_A2作为目标地址（即CGA）发起交换。此案例与前一个案例类似，但无法验证的是由发送的R2消息。虽然A可以与B创建上下文，但B不能对A执行相同的操作。使用IP_B1和IP_A2的数据通信可以继续。然而，A可以尝试使用IP_B2作为替代定位器，但是B不会将携带Shim6扩展报头发送的数据包与任何已建立的上下文相关联，因此它们将被丢弃。对于以IP_A1作为源地址的A发送的数据包，也会发生同样的情况。
We can also consider the case in which node A does not exchange its own locators in the Shim6 establishment exchange. For example, a Shim6 context can be established between CGA IP_A2 and IP_B1. B can convey locator IP_B2 in the four-way handshake, and validation will be correctly done by A. Later on, A may send an Update Request message to inform B about its locator IP_A1. Validation for this message will fail in B, and B will send a Shim6 Error message to A. Neither A nor B will use IP_A1 as a locator. However, IP_A2, IP_B1, and IP_B2 can still be used as valid locators for the communication.
我们也可以考虑节点A不在SHIM6建立交换机中交换自己的定位器的情况。例如，可以在CGA IP_A2和IP_B1之间建立Shim6上下文。B可以在四向握手中传递定位器IP_B2，A将正确完成验证。稍后，A可能会发送更新请求消息，通知B其定位器IP_A1。此消息的验证将在B中失败，B将向a发送一条Shim6错误消息。a和B都不会使用IP_A1作为定位器。然而，IP_A2、IP_B1和IP_B2仍然可以用作通信的有效定位器。
Finally, note that modification of the Shim6 control packets by the NPTv6 would not be able to generate a valid signature when a CGA is being used or a Parameter Data Structure binding the translated locator to the other locators of a node when an HBA is being used. Therefore, the same failure cases described before would remain.
最后，请注意，当使用CGA时，NPTv6对Shim6控制分组的修改将不能生成有效的签名，或者当使用HBA时，将转换的定位器绑定到节点的其他定位器的参数数据结构。因此，前面描述的故障情况将保持不变。
This section considers the applicability of the Shim6 protocol from a security perspective, i.e., which security features can be expected by applications and users of the Shim6 protocol.
本节从安全角度考虑了Shim6协议的适用性，即Shim6协议的应用程序和用户可以预期哪些安全特性。
First of all, it should be noted that the Shim6 protocol is not a security protocol, unlike HIP, for instance. This means that, as opposed to HIP, it is an explicit non-goal of the Shim6 protocol to provide enhanced security for the communications that use the Shim6 protocol. The goal of the Shim6 protocol design, in terms of security, is not to introduce new vulnerabilities that were not present in the current non-Shim6 enabled communications. In particular, it is an explicit non-goal of Shim6 protocol security to provide protection from on-path attackers. On-path attackers are able to sniff and spoof packets in the current Internet, and they are able to do the same in Shim6 communications (as long as the communication flows through the path on which they are located). Summarizing, the Shim6 protocol does not provide data packet protection from on-path attackers.
首先，应该注意的是，Shim6协议不是一个安全协议，例如，与HIP不同。这意味着，与HIP相反，Shim6协议的明确非目标是为使用Shim6协议的通信提供增强的安全性。就安全性而言，Shim6协议设计的目标不是引入当前未启用Shim6的通信中不存在的新漏洞。特别是，为防止路径上的攻击者提供保护是Shim6协议安全的明确非目标。路径上攻击者能够在当前Internet中嗅探和欺骗数据包，并且在Shim6通信中也可以这样做（只要通信通过其所在的路径）。总之，Shim6协议不提供数据包保护，不受路径上攻击者的攻击。
However, the Shim6 protocol does use several security techniques. The goal of these security measures is to protect the Shim6 signaling protocol from new attacks resulting from the adoption of the Shim6 protocol. In particular, the use of HBA/CGA prevents on-path and off-path attackers from injecting new locators into the locator set of a Shim6 context, thus preventing redirection attacks [RFC4218]. Moreover, the usage of probes before re-homing to a different locator as a destination address prevents flooding attacks from off-path attackers. Note that for nodes using CGA addresses, security depends on the secure handling of the private key associated with the signature and validation of locators. In particular, any address configuration method must assure that the private key remains secret, as discussed in Section 3.3.
然而，Shim6协议确实使用了几种安全技术。这些安全措施的目标是保护Shim6信令协议免受由于采用Shim6协议而产生的新攻击。特别是，使用HBA/CGA可防止路径上和路径外攻击者将新定位器注入到Shim6上下文的定位器集中，从而防止重定向攻击[RFC4218]。此外，在重新定位到另一个定位器之前使用探测器作为目标地址，可以防止非路径攻击者的洪泛攻击。注意，对于使用CGA地址的节点，安全性取决于与定位器的签名和验证相关联的私钥的安全处理。特别是，任何地址配置方法必须确保私钥保持机密，如第3.3节所述。
In addition, the usage of a 4-way handshake for establishing the Shim6 context protects against DoS attacks, so hosts implementing the Shim6 protocol should not be more vulnerable to DoS attacks than regular IPv6 hosts.
此外，使用4路握手来建立Shim6上下文可以防止DoS攻击，因此实现Shim6协议的主机不应比常规IPv6主机更容易受到DoS攻击。
Finally, many Shim6 signaling messages contain a Context Tag, meaning that only attackers that know the Context Tag can forge them. As a
最后，许多Shim6信令消息包含上下文标记，这意味着只有知道上下文标记的攻击者才能伪造它们。作为一个
consequence, only on-path attackers can generate false Shim6 signaling packets for an established context. The impact of these attacks would be limited since they would not be able to add additional locators to the locator set (because of the HBA/CGA protection). In general, the possible attacks have similar effects to the ones that an on-path attacker can launch on any regular IPv6 communication. The residual threats are described in the Security Considerations of the Shim6 protocol specification [RFC5533].
结果，只有路径上的攻击者才能为已建立的上下文生成虚假的Shim6信令包。这些攻击的影响将是有限的，因为它们无法向定位器集添加其他定位器（因为HBA/CGA保护）。一般来说，可能的攻击与路径上攻击者在任何常规IPv6通信中可能发起的攻击具有类似的效果。剩余威胁在Shim6协议规范[RFC5533]的安全注意事项中进行了描述。
The Shim6 protocol is designed to provide some basic privacy features. In particular, HBAs are generated in such a way that the different addresses assigned to a host cannot be trivially linked together as belonging to the same host, since there is nothing in common in the addresses themselves. Similar features are provided when the CGA protection is used. This means that it is not trivial to determine that a set of addresses is assigned to a single Shim6 host.
Shim6协议旨在提供一些基本的隐私功能。特别是，HBA的生成方式使得分配给主机的不同地址不能简单地链接在一起，因为它们属于同一主机，因为地址本身没有任何共同之处。使用CGA保护时，也提供类似的功能。这意味着，确定一组地址分配给单个Shim6主机并非易事。
However, the Shim6 protocol does exchange the locator set in clear text, and it also uses a fixed Context Tag when using different locators in a given context. This implies that an attacker observing the Shim6 context establishment exchange or seeing different payload packets exchanged through different locators, but with the same Context Tag, can determine the set of addresses assigned to a host. However, this requires that the attacker be located along the path and can capture the Shim6 signaling packets.
然而，Shim6协议确实以明文形式交换定位器集，并且在给定上下文中使用不同定位器时，它也使用固定的上下文标记。这意味着，观察Shim6上下文建立交换或看到通过不同定位器交换但具有相同上下文标记的不同有效负载数据包的攻击者可以确定分配给主机的地址集。但是，这要求攻击者位于路径沿线，并能够捕获Shim6信令数据包。
The analysis on the interaction between the Shim6 protocol and the other protocols presented in this note benefited from the advice of various people including Tom Henderson, Erik Nordmark, Hesham Soliman, Vijay Devarpalli, John Loughney, and Dave Thaler.
本说明中对Shim6协议与其他协议之间相互作用的分析得益于各种人士的建议，包括汤姆·亨德森、埃里克·诺德马克、赫萨姆·索利曼、维杰·德瓦帕利、约翰·洛尼和戴夫·泰勒。
Joe Abley's work was supported, in part, by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
Joe Abley的工作得到了美国国家科学基金会（研究资助SCI0414144）和DNS-OARC的支持。
Marcelo Bagnulo worked on this document while visiting Ericsson Research Laboratory Nomadiclab.
Marcelo Bagnulo在访问爱立信研究实验室Nomadiclab时编写了此文档。
Alberto Garcia-Martinez was supported, in part, by the eeCONTET project (TEC2011-29688-C02-02, granted by the Spanish Science and Innovation Ministry).
阿尔贝托·加西亚·马丁内斯（Alberto Garcia Martinez）部分得到了西班牙科学和创新部批准的eeCONTET项目（TEC2011-29688-C02-02）的支持。
Shinta Sugimoto reviewed this document and provided comments and text.
杉本信田审查了本文件，并提供了评论和文本。
Brian Carpenter, Jari Arkko, Joel Halpern, Iljitsch van Beijnum, Sam Xia, Carsten Bormann, Dan Wing, Stephen Farrell, and Stewart Bryant reviewed this document and provided comments.
Brian Carpenter、Jari Arkko、Joel Halpern、Iljitsch van Beijnum、Sam Xia、Carsten Bormann、Dan Wing、Stephen Farrell和Stewart Bryant审查了该文件并提供了意见。
[RFC2827] 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.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963]Devarapalli，V.，Wakikawa，R.，Petrescu，A.，和P.Thubert，“网络移动（NEMO）基本支持协议”，RFC 3963，2005年1月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，Ed.“流控制传输协议”，RFC 49602007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201]Moskowitz，R.，Nikander，P.，Jokela，P.，Ed.，和T.Henderson，“主机身份协议”，RFC 52012008年4月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534]Arkko，J.和I.van Beijnum，“IPv6多宿的故障检测和定位器对探测协议”，RFC 55342009年6月。
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June 2009.
[RFC5535]Bagnulo，M.，“基于哈希的地址（HBA）”，RFC5352009年6月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, March 2011.
[RFC6182]福特，A.，雷丘，C.，汉德利，M.，巴尔，S.，和J.艾扬格，“多路径TCP开发的架构指南”，RFC6182，2011年3月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., "Sockets Application Program Interface (API) for Multihoming Shim", RFC 6316, July 2011.
[RFC6316]Komu，M.，Bagnulo，M.，Slavov，K.，和S.Sugimoto，Ed.，“多归宿垫片的套接字应用程序接口（API）”，RFC 63162011年7月。
[6MAN] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, February 2012.
[6MAN]Matsumoto，A.，Fujisaki，T.，Kato，J.，和T.Chown，“使用DHCPv6分发地址选择策略”，正在进行的工作，2012年2月。
[DHCPv6-CGA] Jiang, S. and S. Shen, "Analysis of Possible DHCPv6 and CGA Interactions", Work in Progress, March 2012.
[DHCPv6 CGA]Jiang，S.和S.Shen，“DHCPv6和CGA可能相互作用的分析”，正在进行的工作，2012年3月。
[IPv6NAT] Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. Wing, "IPv6 Multihoming without Network Address Translation", Work in Progress, February 2012.
[IPv6NAT]松岛，S.，冈本，T.，特罗安，O.，迈尔斯，D.，和D.Wing，“无网络地址转换的IPv6多宿主”，正在进行的工作，2012年2月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]Huston，G.“互联网中域间路由的评论”，RFC3221，2001年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582]Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116]Abley，J.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 41162005年7月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218]Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，2005年10月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]Meyer，D.，Ed.，Zhang，L.，Ed.，和K.Fall，Ed.，“IAB路由和寻址研讨会报告”，RFC 4984，2007年9月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题”，RFC 52202008年7月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902]Thaler，D.，Zhang，L.，和G.Lebovitz，“IAB对IPv6网络地址转换的思考”，RFC 59022010年7月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011.
[RFC6418]Blanchet，M.和P.Seite，“多接口和供应域问题声明”，RFC 6418，2011年11月。
[SHIM6-ESD] Nordmark, E., "Extended Shim6 Design for ID/loc split and Traffic Engineering", Work in Progress, February 2008.
[SHIM6-ESD]Nordmark，E.“ID/loc拆分和交通工程的扩展SHIM6设计”，在建工程，2008年2月。
Authors' Addresses
作者地址
Joe Abley ICANN 12025 Waterfront Drive Suite 300 Los Angeles, CA 90094 USA
Joe Abley ICANN 12025美国加利福尼亚州洛杉矶滨水路300号套房90094
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
Phone: +1 519 670 9327
EMail: joe.abley@icann.org
Marcelo Bagnulo U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
马塞洛·巴格努洛U.卡洛斯三世马德里大道。西班牙马德里勒加内斯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/
Alberto Garcia-Martinez U. Carlos III de Madrid Av. Universidad 30 Leganes, Madrid 28911 Spain
阿尔贝托·加西亚·马丁内斯U.卡洛斯三世马德里大道。西班牙马德里勒加内斯30大学28911
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/
Phone: +34 91 6248782
EMail: alberto@it.uc3m.es
URI: http://www.it.uc3m.es/