Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7756 Redpill Linpro
Category: Informational S. Steffann
ISSN: 2070-1721 S.J.M. Steffann Consultancy
February 2016
Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7756 Redpill Linpro
Category: Informational S. Steffann
ISSN: 2070-1721 S.J.M. Steffann Consultancy
February 2016
Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode
IPv6 Internet数据中心环境的无状态IP/ICMP转换（SIIT-DC）：双转换模式
Abstract
摘要
This document describes an extension of the Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC) architecture, which allows applications, protocols, or nodes that are incompatible with IPv6 and/or Network Address Translation to operate correctly with SIIT-DC. This is accomplished by introducing a new component called an SIIT-DC Edge Relay, which reverses the translations made by an SIIT-DC Border Relay. The application and/or node is thus provided with seemingly native IPv4 connectivity that provides end-to-end address transparency.
本文档描述了IPv6 Internet数据中心环境无状态IP/ICMP转换（SIIT-DC）体系结构的扩展，该体系结构允许与IPv6和/或网络地址转换不兼容的应用程序、协议或节点使用SIIT-DC正确运行。这是通过引入一种称为SIIT-DC边缘继电器的新组件来实现的，该组件可反转由SIIT-DC边界继电器进行的转换。因此，应用程序和/或节点具有看似本机的IPv4连接，提供端到端地址透明性。
The reader is expected to be familiar with the SIIT-DC architecture described in RFC 7755.
读者应熟悉RFC 7755中描述的SIIT-DC体系结构。
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/rfc7756.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7756.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 5
3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 6
3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
3.2.1. Edge Relay "on a Stick" . . . . . . . . . . . . . . . 8
3.2.2. Edge Relay That Bridges IPv6 Packets . . . . . . . . 9
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 11
5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 16
A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Edge Relay Description . . . . . . . . . . . . . . . . . . . 5
3.1. Node-Based Edge Relay . . . . . . . . . . . . . . . . . . 6
3.2. Network-Based Edge Relay . . . . . . . . . . . . . . . . 7
3.2.1. Edge Relay "on a Stick" . . . . . . . . . . . . . . . 8
3.2.2. Edge Relay That Bridges IPv6 Packets . . . . . . . . 9
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 9
4.1. IPv6 Path MTU . . . . . . . . . . . . . . . . . . . . . . 9
4.2. IPv4 MTU . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. IPv4 Identification Header . . . . . . . . . . . . . . . 10
5. Intra-IDC IPv4 Communication . . . . . . . . . . . . . . . . 10
5.1. Hairpinning by the SIIT-DC Border Relay . . . . . . . . . 11
5.2. Additional EAMs Configured in Edge Relay . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Examples: Network-Based IPv4 Connectivity . . . . . 16
A.1. Subnet with IPv4 Service Addresses . . . . . . . . . . . 16
A.2. Subnet with Unrouted IPv4 Addresses . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
SIIT-DC [RFC7755] describes an architecture where IPv4-only users can access IPv6-only services through a stateless translator called an SIIT-DC Border Relay (BR). This approach has certain limitations, however. In particular, the following cases will work poorly or not at all:
SIIT-DC[RFC7755]描述了一种体系结构，在这种体系结构中，只有IPv4的用户可以通过称为SIIT-DC边界中继（BR）的无状态转换器访问只有IPv6的服务。然而，这种方法有一定的局限性。特别是，以下情况将效果不佳或根本不起作用：
o Application protocols that do not support NAT (i.e., the lack of end-to-end transparency of IP addresses).
o 不支持NAT的应用程序协议（即，IP地址缺乏端到端的透明度）。
o Nodes that cannot connect to IPv6 networks at all or that can only connect such networks if they also provide IPv4 connectivity (i.e., dual-stacked networks).
o 完全无法连接到IPv6网络或仅在同时提供IPv4连接的情况下才能连接此类网络的节点（即双堆叠网络）。
o Application software that makes use of legacy IPv4-only APIs or otherwise makes assumptions that IPv4 connectivity is available.
o 使用传统的仅IPv4 API或以其他方式假设IPv4连接可用的应用程序软件。
By extending the SIIT-DC architecture with a new component called an Edge Relay (ER), all of the above can be made to work correctly in an otherwise IPv6-only network environment using SIIT-DC.
通过使用称为边缘中继（ER）的新组件扩展SIIT-DC体系结构，上述所有功能都可以在使用SIIT-DC的仅限IPv6的网络环境中正常工作。
The purpose of the ER is to reverse the IPv4-to-IPv6 packet translations previously done by the BR for traffic arriving from IPv4 clients and forward this as "native" IPv4 to the node or application. In the reverse direction, IPv4 packets transmitted by the node or application are intercepted by the ER, which translates them to IPv6 before they are forwarded to the BR, which in turn will reverse the translations and forward them to the IPv4 client. The node or application is thus provided with "virtual" IPv4 Internet connectivity that retains end-to-end transparency for the IPv4 addresses.
ER的目的是反转BR以前对来自IPv4客户端的流量所做的IPv4到IPv6数据包转换，并将其作为“本机”IPv4转发到节点或应用程序。在相反的方向上，由节点或应用程序传输的IPv4数据包被ER截获，ER在将其转发到BR之前将其转换为IPv6，BR反过来将反转转换并将其转发到IPv4客户端。因此，为节点或应用程序提供了“虚拟”IPv4 Internet连接，该连接保留了IPv4地址的端到端透明性。
This document makes use of the following terms:
本文件使用了以下术语：
SIIT-DC Border Relay (BR): A device or a logical function that performs stateless protocol translation between IPv4 and IPv6. It MUST do so in accordance with [RFC6145] and [RFC7757].
SIIT-DC边界中继（BR）：在IPv4和IPv6之间执行无状态协议转换的设备或逻辑功能。必须按照[RFC6145]和[RFC7757]的规定进行。
SIIT-DC Edge Relay (ER): A device or logical function that provides "native" IPv4 connectivity to IPv4-only devices or application software. It is very similar in function to a BR but is typically located close to the IPv4-only component(s) it is supporting rather than on the outer network border of the Internet Data Center (IDC). An ER may be either node based (Section 3.1) or network based (Section 3.2).
SIIT-DC边缘中继（ER）：一种设备或逻辑功能，为仅IPv4设备或应用软件提供“本机”IPv4连接。它在功能上与BR非常相似，但通常位于其支持的仅IPv4组件附近，而不是位于Internet数据中心（IDC）的外部网络边界上。ER可以是基于节点的（第3.1节）或基于网络的（第3.2节）。
IPv4 Service Address: An IPv4 address representing a node or service located in an IPv6 network. It is coupled with an IPv6 Service Address using an Explicit Address Mapping (EAM). Packets sent to this address are translated to IPv6 by the BR, and possibly back to IPv4 by an ER, before reaching the node or service.
IPv4服务地址：表示位于IPv6网络中的节点或服务的IPv4地址。它使用显式地址映射（EAM）与IPv6服务地址耦合。发送到此地址的数据包在到达节点或服务之前由BR转换为IPv6，可能由ER转换回IPv4。
IPv6 Service Address: An IPv6 address assigned to an application, node, or service either directly or indirectly (through an ER). It is coupled with an IPv4 Service Address using an EAM. IPv4-only clients communicate with the IPv6 Service Address through SIIT-DC.
IPv6服务地址：直接或间接（通过ER）分配给应用程序、节点或服务的IPv6地址。它使用EAM与IPv4服务地址耦合。仅IPv4客户端通过SIIT-DC与IPv6服务地址通信。
Explicit Address Mapping (EAM): A bidirectional coupling between an IPv4 Service Address and an IPv6 Service Address configured in a BR or ER. When translating between IPv4 and IPv6, the BR/ER changes the address fields in the translated packet's IP header according to any matching EAM. The EAM algorithm is specified in [RFC7757].
显式地址映射（EAM）：在BR或ER中配置的IPv4服务地址和IPv6服务地址之间的双向耦合。在IPv4和IPv6之间转换时，BR/ER根据任何匹配的EAM更改转换数据包IP报头中的地址字段。[RFC7757]中规定了EAM算法。
Translation Prefix: An IPv6 prefix into which the entire IPv4 address space is mapped, according to the algorithm in [RFC6052]. The translation prefix is routed to the BR's IPv6 interface. When translating between IPv4 and IPv6, a BR/ER will insert/remove the translation prefix into/from the address fields in the translated packet's IP header, unless an EAM exists for the IP address that is being translated.
转换前缀：根据[RFC6052]中的算法，整个IPv4地址空间映射到的IPv6前缀。翻译前缀被路由到BR的IPv6接口。在IPv4和IPv6之间转换时，BR/ER将在转换数据包的IP报头中的地址字段中插入/删除转换前缀，除非正在转换的IP地址存在EAM。
IPv4-Converted IPv6 Addresses: As defined in Section 1.3 of [RFC6052].
IPv4转换的IPv6地址：如[RFC6052]第1.3节所定义。
IDC: Short for "Internet Data Center"; a data center whose main purpose is to deliver services to the public Internet. SIIT-DC is primarily targeted at being deployed in an IDC. An IDC is typically operated by an Internet Content Provider or a Managed Services Provider.
IDC：互联网数据中心的简称；主要目的是向公共互联网提供服务的数据中心。SIIT-DC的主要目标是部署在IDC中。IDC通常由互联网内容提供商或托管服务提供商运营。
SIIT: The Stateless IP/ICMP Translation Algorithm, as specified in [RFC6145].
SIIT：无状态IP/ICMP转换算法，如[RFC6145]所述。
XLAT: Short for "Translation". Used in figures to indicate where a BR/ ER uses SIIT [RFC6145] to translate IPv4 packets to IPv6 and vice versa.
XLAT：翻译的缩写。在图中用于指示BR/ER使用SIIT[RFC6145]将IPv4数据包转换为IPv6的位置，反之亦然。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An ER is at its core an implementation of the Stateless IP/ICMP Translation Algorithm [RFC6145] that supports Explicit Address Mappings [RFC7757]. It provides virtual IPv4 connectivity for nodes or applications that require this to operate correctly with SIIT-DC.
ER的核心是支持显式地址映射的无状态IP/ICMP转换算法[RFC6145]的实现[RFC7757]。它为需要通过SIIT-DC正确运行的节点或应用程序提供虚拟IPv4连接。
Packets from the IPv4 Internet destined for an IPv4 Service Address are first translated to IPv6 by a BR. The resulting IPv6 packets are subsequently forwarded to the ER that owns the IPv6 Service Address the translated packets are addressed to. The ER then translates them back to IPv4 before forwarding them to the IPv4 application or node. In the other direction, the exact same translations happen, only in reverse. This process provides end-to-end transparency of IPv4 addresses.
从IPv4 Internet发送到IPv4服务地址的数据包首先由BR转换为IPv6。生成的IPv6数据包随后被转发到拥有转换后的数据包所寻址的IPv6服务地址的ER。ER然后将它们转换回IPv4，然后再将它们转发到IPv4应用程序或节点。在另一个方向，完全相同的翻译发生，只是相反。此过程提供IPv4地址的端到端透明性。
An ER may handle an arbitrary number of IPv4/IPv6 Service Addresses. All the EAMs configured in the BR that involve the IPv4/IPv6 Service Addresses handled by an ER MUST also be present in the ER's configuration.
ER可以处理任意数量的IPv4/IPv6服务地址。BR中配置的所有涉及由ER处理的IPv4/IPv6服务地址的EAM也必须存在于ER的配置中。
An ER may be implemented in two distinct ways: as a software-based service residing inside an otherwise IPv6-only node or as a network-based service that provides an isolated IPv4 network segment to which nodes that require IPv4 can connect. In both cases, native IPv6 connectivity may be provided simultaneously with the virtual IPv4 connectivity. Thus, dual-stack connectivity is facilitated in case the node or application supports it.
ER可以以两种不同的方式实现：作为驻留在仅限IPv6的节点内的基于软件的服务，或者作为提供需要IPv4的节点可以连接到的隔离IPv4网段的基于网络的服务。在这两种情况下，本机IPv6连接可以与虚拟IPv4连接同时提供。因此，在节点或应用程序支持双栈连接的情况下，双栈连接变得更加容易。
The choice between a node- or network-based ER is made on a per-service or per-node basis. An arbitrary number of each type of ER may co-exist in an SIIT-DC architecture.
在基于节点或基于网络的ER之间进行选择是基于每个服务还是基于每个节点。在SIIT-DC体系结构中，任意数量的每种类型的ER可以共存。
This section describes the different approaches and discusses which approach fits best for the various use cases.
本节描述了不同的方法，并讨论了哪种方法最适合各种用例。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| | +-----<IPv6-only node/server>----------+
[IPv6-only IDC network] | +----------------+|
| | /--(ER/XLAT)--AF_INET Dual-stack ||
\-------------------------+ | application ||
| \------------AF_INET6 software ||
| +----------------+|
+--------------------------------------+
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| | +-----<IPv6-only node/server>----------+
[IPv6-only IDC network] | +----------------+|
| | /--(ER/XLAT)--AF_INET Dual-stack ||
\-------------------------+ | application ||
| \------------AF_INET6 software ||
| +----------------+|
+--------------------------------------+
Figure 1: A Node-Based Edge Relay
图1：基于节点的边缘中继
A node-based ER is typically implemented as a logical software function that runs inside the operating system of an IPv6 node. It provides applications running on the same node with IPv4 connectivity. Its IPv4 Service Address SHOULD be considered a regular local address that allows applications running on the same node to use it with IPv4-only API calls, e.g., to create AF_INET sockets that listen for and accept incoming connections to its IPv4 Service Address. An ER may accomplish this by creating a virtual network adapter to which it assigns the IPv4 Service Address and points a default IPv4 route. This approach is similar to the "Bump-in-the-Stack" approach discussed in [RFC6535]; however, it does not include an Extension Name Resolver.
基于节点的ER通常实现为在IPv6节点的操作系统内运行的逻辑软件功能。它为在同一节点上运行的应用程序提供IPv4连接。其IPv4服务地址应视为常规本地地址，允许在同一节点上运行的应用程序将其用于仅IPv4的API调用，例如，创建用于侦听和接受到其IPv4服务地址的传入连接的AF_INET套接字。ER可以通过创建一个虚拟网络适配器来实现这一点，向该虚拟网络适配器分配IPv4服务地址并指向默认IPv4路由。该方法类似于[RFC6535]中讨论的“堆栈中的凹凸”方法；但是，它不包括扩展名解析程序。
As shown in Figure 1, if the application supports dual-stack operation, IPv6 clients will be able to communicate with it directly using native IPv6. Neither the BR nor the ER will intercept this communication. Support for IPv6 in the application is, however, not a requirement; the application may opt not to establish any IPv6 sockets. Foregoing IPv6 in this manner will simply preclude connectivity to the service from IPv6-only clients; connectivity to the service from IPv4 clients (through the BR) will continue work in the same way.
如图1所示，如果应用程序支持双堆栈操作，IPv6客户端将能够使用本机IPv6直接与其通信。BR和ER都不会拦截此通信。然而，应用程序中对IPv6的支持不是一项要求；应用程序可能选择不建立任何IPv6套接字。以这种方式前述IPv6将简单地排除从仅IPv6客户端到服务的连接；从IPv4客户端（通过BR）到服务的连接将以相同的方式继续工作。
The ER requires a dedicated IPv6 Service Address for each IPv4 Service Address it has configured. The IPv6 network MUST forward traffic to these IPv6 Service Addresses to the node, whose operating system MUST in turn forward them to the ER. This document does not attempt to fully explore the multitude of ways this could be accomplished; however, considering that the IPv6 protocol is designed for having multiple addresses assigned to a single node, one particularly straight-forward way would be to assign the ER's IPv6
ER需要为其配置的每个IPv4服务地址提供专用的IPv6服务地址。IPv6网络必须将到这些IPv6服务地址的流量转发给节点，节点的操作系统必须反过来将这些流量转发给ER。本文件并未试图充分探讨实现这一目标的多种方式；然而，考虑到IPv6协议被设计为将多个地址分配给单个节点，一种特别直接的方法是分配ER的IPv6
Service Addresses as secondary IPv6 addresses on the node itself so that the upstream router learns of their location using the IPv6 Neighbor Discovery Protocol [RFC4861].
服务地址作为节点本身上的辅助IPv6地址，以便上游路由器使用IPv6邻居发现协议[RFC4861]了解其位置。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network] +--<IPv4-only node/server>--+
| | +----------------+|
+-----|-----+ [v4-only] | | IPv4-only ||
| (ER/XLAT)-----[network]--------AF_INET application ||
+-----------+ [segment] | | software ||
| +----------------+|
+---------------------------+
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network] +--<IPv4-only node/server>--+
| | +----------------+|
+-----|-----+ [v4-only] | | IPv4-only ||
| (ER/XLAT)-----[network]--------AF_INET application ||
+-----------+ [segment] | | software ||
| +----------------+|
+---------------------------+
Figure 2: A Basic Network-Based Edge Relay
图2：基于基本网络的边缘中继
A network-based ER functions the exact same way as a node-based ER does, only that instead of assigning the IPv4 Service Addresses to an internal-only virtual network adapter, traffic destined for them are forwarded onto a network segment to which nodes that require IPv4 connectivity connect to. The ER also functions as the default IPv4 router for the nodes on this network segment.
基于网络的ER的工作方式与基于节点的ER完全相同，只是没有将IPv4服务地址分配给仅内部的虚拟网络适配器，而是将发送给它们的流量转发到需要IPv4连接的节点所连接的网段上。ER还充当此网段上节点的默认IPv4路由器。
Each node on the IPv4 network segment MUST acquire and assign an IPv4 Service Address to a local network interface. While this document does not attempt to explore all the various methods by which this could be accomplished, some examples are provided in Appendix A.
IPv4网段上的每个节点都必须获取IPv4服务地址并将其分配给本地网络接口。虽然本文件并未试图探讨实现这一点的所有各种方法，但附录A中提供了一些示例。
The basic ER illustrated in Figure 2 establishes an IPv4-only network segment between itself and the IPv4-only nodes it serves. This is fine if the nodes it provides IPv4 access to have no support for IPv6 whatsoever; however, if they are dual-stack capable, it would not be ideal to take away their IPv6 connectivity in this manner. While it is RECOMMENDED to use a node-based ER in this case, appropriate implementations of a node-based ER might not be available for every node. If the application protocol in question does not work correctly in a NAT environment, standard SIIT-DC cannot be used either, which leaves a network-based ER as the only remaining solution. The following subsections contain examples on how the ER could be implemented in a way that provides IPv6 connectivity for dual-stack capable nodes.
图2所示的基本ER在其自身和其服务的仅IPv4节点之间建立了仅IPv4的网段。如果它提供IPv4访问的节点不支持IPv6，这是可以接受的；但是，如果它们具有双栈功能，那么以这种方式取消它们的IPv6连接就不太理想了。虽然在这种情况下建议使用基于节点的ER，但基于节点的ER的适当实现可能并不适用于每个节点。如果所讨论的应用程序协议在NAT环境中不能正常工作，则也不能使用标准SIIT-DC，这使得基于网络的ER成为唯一剩下的解决方案。以下小节包含了ER如何以为支持双栈的节点提供IPv6连接的方式实现的示例。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
| +-------------+
| | _IPv6_ |
| | / \ |
+==== (ER/XLAT) |
| | \_ _/ |
| | IPv4 | +--<Dual-stack node/server>--+
| +-------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
| +-------------+
| | _IPv6_ |
| | / \ |
+==== (ER/XLAT) |
| | \_ _/ |
| | IPv4 | +--<Dual-stack node/server>--+
| +-------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
Figure 3: A Network-Based Edge Relay "on a Stick"
图3：基于网络的“棒上”边缘中继
The ER "on a stick" approach illustrated in Figure 3 ensures that the dual-stack capable node retains native IPv6 connectivity by connecting the ER's IPv4 and IPv6 interfaces to the same network segment, alternatively by using a single dual-stacked interface. Native IPv6 traffic between the IDC network and the node bypasses the ER entirely, while IPv4 traffic from the node will be routed directly to the ER (because it acts as its default IPv4 router), where it is translated to IPv6 before being transmitted to the upstream default IPv6 router. The ER could attract inbound traffic to the IPv6 Service Addresses by responding to the upstream router's IPv6 Neighbor Discovery [RFC4861] messages for them.
图3所示的ER“在一根棍子上”方法通过将ER的IPv4和IPv6接口连接到同一网段，或者通过使用单个双堆叠接口，确保支持双堆栈的节点保持本机IPv6连接。IDC网络和节点之间的本机IPv6流量完全绕过ER，而来自节点的IPv4流量将直接路由到ER（因为它充当其默认IPv4路由器），在ER中，在传输到上游默认IPv6路由器之前，将其转换为IPv6。ER可以通过响应上游路由器的IPv6邻居发现[RFC4861]消息将入站流量吸引到IPv6服务地址。
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
+-----------|--------------+
| ____/ \_IPv6_ |
| / \ |
| (IPv6 Bridge) (ER/XLAT) |
| \____ _ _/ |
| \ / IPv4 | +--<Dual-stack node/server>--+
+-----------|--------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
[IPv4 Internet] [IPv6 Internet]
| |
+-----|-----+ |
| (BR/XLAT) | |
+-----|-----+ |
| |
[IPv6-only IDC network]
|
+-----------|--------------+
| ____/ \_IPv6_ |
| / \ |
| (IPv6 Bridge) (ER/XLAT) |
| \____ _ _/ |
| \ / IPv4 | +--<Dual-stack node/server>--+
+-----------|--------------+ | +----------------+|
| | /---AF_INET Dual-stack ||
[Dual-stack network segment]----< | application ||
| \--AF_INET6 software ||
| +----------------+|
+----------------------------+
Figure 4: A Network-Based Edge Relay Containing an IPv6 Bridge
图4：包含IPv6网桥的基于网络的边缘中继
The ER illustrated in Figure 4 will transparently bridge IPv6 frames between its upstream and downstream interfaces. IPv6 packets sent from the upstream IDC network to an IPv6 Service Address are intercepted by the ER (e.g., by responding to IPv6 Neighbor Discovery [RFC4861] messages for them) and routed through the translation function before being forwarded out the ER's downstream interface as IPv4 packets. The downstream network segment thus becomes dual stacked.
图4所示的ER将在其上游和下游接口之间透明地桥接IPv6帧。从上游IDC网络发送到IPv6服务地址的IPv6数据包被ER截获（例如，通过响应IPv6邻居发现[RFC4861]消息），并通过转换功能路由，然后作为IPv4数据包转发出ER的下游接口。因此，下游网段变为双重堆叠。
The IPv6 Path MTU between the ER and the BR will typically be larger than the default value defined in Section 4 of [RFC6145] (1280 bytes), as it will typically be contained within a single administrative domain. Therefore, it is RECOMMENDED that the IPv6 Path MTU configured in the ER be raised accordingly. It is RECOMMENDED that the ER and the BR use identical configured IPv6 Path MTU values.
ER和BR之间的IPv6路径MTU通常将大于[RFC6145]（1280字节）第4节中定义的默认值，因为它通常包含在单个管理域中。因此，建议相应提升ER中配置的IPv6路径MTU。建议ER和BR使用相同的配置IPv6路径MTU值。
In order to avoid IPv6 fragmentation, an ER SHOULD ensure that the IPv4 MTU used by applications or nodes is equal to the configured IPv6 Path MTU - 20 so that a maximum-sized IPv4 packet can fit in an unfragmented IPv6 packet. This ensures that the application may do its part in avoiding IP-level fragmentation from occurring, e.g., by segmenting/fragmenting outbound packets at the application layer, and advertising the maximum size its peer may use for inbound packets (e.g., through the use of the TCP Maximum Segment Size (MSS) option).
为了避免IPv6碎片化，ER应确保应用程序或节点使用的IPv4 MTU等于配置的IPv6路径MTU-20，以便最大大小的IPv4数据包可以容纳在未碎片化的IPv6数据包中。这确保了应用程序可以尽其所能避免IP级碎片的发生，例如，通过在应用层对出站数据包进行分段/碎片化，并公布其对等方可用于入站数据包的最大大小（例如，通过使用TCP最大段大小（MSS）选项）。
A node-based ER could accomplish this by configuring this MTU value on the virtual network adapter, while a network-based ER could do so by advertising the MTU to its downstream nodes using the DHCPv4 Interface MTU option [RFC2132].
基于节点的ER可以通过在虚拟网络适配器上配置此MTU值来实现这一点，而基于网络的ER可以通过使用DHCPv4接口MTU选项[RFC2132]向其下游节点公布MTU来实现这一点。
If the generation of IPv6 Atomic Fragments is disabled, the value of the IPv4 Identification header will be lost during the translation. Conversely, enabling the generation of IPv6 Atomic Fragments will ensure that the IPv4 Identification header will be carried end to end. Note that for this to work bidirectionally, IPv6 Atomic Fragment generation MUST be enabled on both the BR and the ER.
如果禁用IPv6原子片段的生成，则IPv4标识标头的值将在转换过程中丢失。相反，启用IPv6原子片段的生成将确保IPv4标识头端到端地传输。请注意，为了双向工作，必须在BR和ER上同时启用IPv6原子片段生成。
Apart from certain diagnostic tools, there are few (if any) application protocols that make use of the IPv4 Identification header. Therefore, the loss of the IPv4 Identification value will generally not cause any problems.
除了某些诊断工具外，很少有（如果有的话）应用程序协议使用IPv4标识头。因此，IPv4标识值的丢失通常不会导致任何问题。
IPv6 Atomic Fragments and their impact on the IPv4 Identification header is further discussed in Section 4.9.2 of [RFC7755].
[RFC7755]的第4.9.2节进一步讨论了IPv6原子片段及其对IPv4标识标头的影响。
Although SIIT-DC is primarily intended to facilitate communication between IPv4-only nodes on the Internet and services located in an IPv6-only IDC network, an IPv4-only node or application located behind an ER might need to communicate with other nodes or services in the IDC. The IPv4-only node or application will need to go through the ER, as it will typically be incapable of contacting IPv6 destinations directly. The following subsections discuss various methods on how to facilitate such communication.
尽管SIIT-DC主要用于促进Internet上仅IPv4节点与位于仅IPv6 IDC网络中的服务之间的通信，但位于ER后面的仅IPv4节点或应用程序可能需要与IDC中的其他节点或服务通信。仅IPv4的节点或应用程序将需要通过ER，因为它通常无法直接联系IPv6目的地。以下各小节讨论如何促进此类沟通的各种方法。
If the BR supports hairpinning as described in Section 4.2 of [RFC7757], the easiest solution is to make the target service available through SIIT-DC in the normal way; that is, by provisioning an EAM to the BR that assigns an IPv4 Service Address with the target service's IPv6 Service Address.
如果BR支持[RFC7757]第4.2节所述的发夹，最简单的解决方案是通过SIIT-DC以正常方式提供目标服务；也就是说，通过向BR提供EAM，BR将IPv4服务地址分配给目标服务的IPv6服务地址。
This allows the IPv4-only node or application to transmit packets destined for the target service's IPv4 Service Address, which the ER will then translate to a corresponding IPv4-converted IPv6 address by inserting the translation prefix [RFC6052]. When this IPv6 packet reaches the BR, it will be hairpinned and transmitted back to the target service's IPv6 Service Address (where it could possibly pass through another ER before reaching the target service). Return traffic from the target service will be hairpinned in the same fashion.
这允许仅IPv4的节点或应用程序传输目的地为目标服务的IPv4服务地址的数据包，然后ER将通过插入转换前缀[RFC6052]将其转换为相应的IPv4转换IPv6地址。当此IPv6数据包到达BR时，它将被发夹并传输回目标服务的IPv6服务地址（在到达目标服务之前，它可能通过另一个ER）。来自目标服务的返回流量将以相同的方式被发夹。
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
+---------------+ +----------------------------+ |
(XLAT#2)
+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )
| SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | |
| DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/
+---------------+ +----------------------------+
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]-------------+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:46::192.0.2.2 |---\
+---------------+ +----------------------------+ |
(XLAT#2)
+-[Pkt#4: IPv4]-+ +--[Pkt#3: IPv6]-------------+ ( @ BR )
| SRC 192.0.2.1 | (XLAT#3) | SRC 2001:db8:46::192.0.2.1 | |
| DST 192.0.2.2 |<--(@ ER B)--| DST 2001:db8:b:: |<--/
+---------------+ +----------------------------+
Figure 5: Hairpinned IPv4-IPv4 Packet Flow
图5：发夹式IPv4-IPv4数据包流
Figure 5 illustrates the flow of a hairpinned packet sent from the IPv4-only node/app behind ER A towards an IPv6-only node/app behind ER B. ER A is configured with the EAM {192.0.2.1,2001:db8:a::} and ER B with {192.0.2.2,2001:db8:b::}. The BR is configured with both EAMs and supports hairpinning. Note that if the target service had not been located behind an ER, the third and final translation (XLAT#3) would not have happened, i.e., the target service/node would have received and responded to packet #3 directly.
图5说明了从ER a后面的仅IPv4的节点/应用发送到ER B后面的仅IPv6的节点/应用的发夹数据包的流程。ER a配置有EAM{192.0.2.12001:db8:a:}，ER B配置有{192.0.2.22001:db8:B:}。BR配置有EAMs并支持发夹。请注意，如果目标服务未位于ER后面，则不会发生第三次也是最后一次转换（XLAT#3），即目标服务/节点将直接接收并响应数据包#3。
If the IPv4-only nodes/services do not need connectivity with the public IPv4 Internet, private IPv4 addresses [RFC1918] could be used as their IPv4 Service Addresses in order to conserve the IDC operator's pool of public IPv4 addresses.
如果仅IPv4的节点/服务不需要与公共IPv4 Internet连接，则可以使用专用IPv4地址[RFC1918]作为其IPv4服务地址，以保留IDC运营商的公共IPv4地址池。
If the BR does not support hairpinning, or if the hairpinning solution is not desired for some other reason, intra-IDC IPv4 traffic may be facilitated by configuring additional EAMs on the ER for each service the IPv4-only node or application needs to communicate with. This makes the IPv6 traffic between the ER and the target service's IPv6 Service Address follow the direct path through the IPv6 network. The traffic does not pass the BR, which means that this solution might yield better latency than the hairpinning approach.
如果BR不支持发夹，或者由于某些其他原因不需要发夹解决方案，则可以通过在ER上为仅IPv4节点或应用程序需要与之通信的每个服务配置额外的EAM来促进IDC内部IPv4流量。这使得ER和目标服务的IPv6服务地址之间的IPv6通信遵循通过IPv6网络的直接路径。流量没有通过BR，这意味着此解决方案可能比发夹方法产生更好的延迟。
The additional EAM configured in the ER consists of the target's IPv6 Service Address and an IPv4 Service Address. The IPv4-only node or application will contact the target's assigned IPv4 Service Address using its own IPv4 Service Address as the source. The ER will then proceed to translate the original IPv4 packet to an IPv6 packet. The source address of the resulting IPv6 packet will be the IPv6 Service Address of the local node or application, while the destination address will be the IPv6 Service Address of the target. Any replies from the target will undergo identical translation, only in reverse.
ER中配置的附加EAM由目标的IPv6服务地址和IPv4服务地址组成。仅IPv4节点或应用程序将使用其自己的IPv4服务地址作为源来联系目标的分配IPv4服务地址。ER随后将继续将原始IPv4数据包转换为IPv6数据包。生成的IPv6数据包的源地址将是本地节点或应用程序的IPv6服务地址，而目标地址将是目标的IPv6服务地址。目标公司的任何回复都将进行相同的翻译，只有相反的翻译。
If the target service is located behind another ER, that other ER MUST also be provisioned with an additional EAM that contains the IPv4 and IPv6 Service Addresses of the origin IPv4-only node or application. Otherwise, the target service's ER will be unable to translate the source address of the incoming packets.
如果目标服务位于另一个ER后面，则还必须为该另一个ER提供一个额外的EAM，该EAM包含源仅IPv4节点或应用程序的IPv4和IPv6服务地址。否则，目标服务的ER将无法转换传入数据包的源地址。
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
+---------------+ +------------------+
|
+-[Pkt#3: IPv4]-+ |
| SRC 192.0.2.1 | (XLAT#2) |
| DST 192.0.2.2 |<-------(@ ER B)------/
+---------------+
+-[Pkt#1: IPv4]-+ +--[Pkt#2: IPv6]---+
| SRC 192.0.2.1 | (XLAT#1) | SRC 2001:db8:a:: |
| DST 192.0.2.2 |--(@ ER A)-->| DST 2001:db8:b:: |
+---------------+ +------------------+
|
+-[Pkt#3: IPv4]-+ |
| SRC 192.0.2.1 | (XLAT#2) |
| DST 192.0.2.2 |<-------(@ ER B)------/
+---------------+
Figure 6: Non-hairpinned IPv4-IPv4 Packet Flow
图6：非发夹式IPv4-IPv4数据包流
Figure 6 illustrates the flow of a packet carrying intra-IDC IPv4 traffic between two IPv4-only nodes/applications that are both located behind ERs. Both ER A and ER B are configured with two EAMs: {192.0.2.1,2001:db8:a::} and {192.0.2.2,2001:db8:b::}. The packet will follow the regular routing path through the IPv6 IDC network; the BR is not involved, and the packet will not be hairpinned.
图6说明了在两个仅IPv4的节点/应用程序之间承载IDC内部IPv4流量的数据包流，这两个节点/应用程序都位于ERs后面。ERA和ERB都配置了两个EAM:{192.0.2.12001:db8:A:}和{192.0.2.22001:db8:B:}。数据包将通过IPv6 IDC网络遵循常规路由路径；不涉及BR，并且数据包不会被发夹。
The above approach is not mutually exclusive with the hairpinning approach described in Section 5.1: If both EAMs above are also configured on the BR, both 192.0.2.1 and 192.0.2.2 would be reachable from other IPv4-only services/nodes using the hairpinning approach. They would also be reachable from the IPv4 Internet.
上述方法与第5.1节中描述的发夹方法并不相互排斥：如果上述两个EAM也在BR上配置，则可以使用发夹方法从其他仅IPv4的服务/节点访问192.0.2.1和192.0.2.2。它们也可以从IPv4互联网上访问。
Note that if the target service in this example was not located behind an ER, but instead was a native IPv6 service listening on 2001:db8:b::, the second translation step in Figure 6 would not occur; the target service would receive and respond to packet #2 directly.
请注意，如果本例中的目标服务不位于ER后面，而是侦听2001:db8:b:：的本机IPv6服务，则不会发生图6中的第二个转换步骤；目标服务将直接接收和响应数据包#2。
As with the hairpinning approach, if the IPv4-only nodes/services do not need connectivity to/from the public IPv4 Internet, private IPv4 addresses [RFC1918] could be used as their IPv4 Service Addresses. Alternatively, in the case where the target service is on native IPv6, the target's assigned IPv4 Service Address has only local significance behind the ER. It could therefore be assigned from the IPv4 Service Continuity Prefix [RFC7335].
与发夹方法一样，如果仅IPv4的节点/服务不需要与公共IPv4 Internet连接，则可以使用专用IPv4地址[RFC1918]作为其IPv4服务地址。或者，在目标服务位于本机IPv6上的情况下，目标分配的IPv4服务地址仅在ER后面具有本地意义。因此，可以从IPv4服务连续性前缀[RFC7335]进行分配。
This section discusses security considerations specific to the use of an ER. See the Security Considerations section in [RFC7755] for security considerations applicable to the SIIT-DC architecture in general.
本节讨论特定于ER使用的安全注意事项。有关一般适用于SIIT-DC体系结构的安全注意事项，请参阅[RFC7755]中的安全注意事项部分。
If the ER receives an IPv4 packet from the application/node from a source address it does not have an EAM for, both the source and destination addresses will be rewritten according to [RFC6052]. After undergoing the reverse translation in the BR, the resulting IPv4 packet routed to the IPv4 network will have a spoofed IPv4 source address. The ER SHOULD therefore ensure that ingress filtering [RFC2827] is used on the ER's IPv4 interface so that such packets are immediately discarded.
如果ER从没有EAM的源地址接收到来自应用程序/节点的IPv4数据包，则源地址和目标地址都将根据[RFC6052]重写。在BR中进行反向转换后，路由到IPv4网络的IPv4数据包将具有伪造的IPv4源地址。因此，ER应确保在ER的IPv4接口上使用入口过滤[RFC2827]，以便立即丢弃此类数据包。
If the ER receives an IPv6 packet with both the source and destination address equal to one of its local IPv6 Service Addresses, the resulting packet would appear to the IPv4-only application/node as locally generated, as both the source address and the destination address will be the same address. This could trick the application into believing the packet came from a trusted source (itself). To prevent this, the ER SHOULD discard any received IPv6 packets that have a source address that is either 1) equal to any of its local IPv6 Service Addresses or 2) after translation from IPv6 to IPv4, equal to any of its local IPv4 Service Addresses.
如果ER接收到源地址和目标地址均等于其本地IPv6服务地址之一的IPv6数据包，则生成的数据包将在仅IPv4的应用程序/节点上显示为本地生成的，因为源地址和目标地址都是相同的地址。这可能会欺骗应用程序，使其相信数据包来自可信来源（自身）。为防止出现这种情况，ER应丢弃任何接收到的IPv6数据包，这些数据包的源地址1）等于其任何本地IPv6服务地址，或2）从IPv6转换为IPv4后等于其任何本地IPv4服务地址。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC7755] Anderson, T., "SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments", RFC 7755, DOI 10.17487/RFC7755, February 2016, <http://www.rfc-editor.org/info/rfc7755>.
[RFC7755]Anderson，T.，“SIIT-DC：IPv6数据中心环境的无状态IP/ICMP转换”，RFC 7755，DOI 10.17487/RFC7755，2016年2月<http://www.rfc-editor.org/info/rfc7755>.
[RFC7757] Anderson, T. and A. Leiva, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc-editor.org/info/rfc7757>.
[RFC7757]Anderson，T.和A.Leiva，“无状态IP/ICMP转换的显式地址映射”，RFC 7757，DOI 10.17487/RFC7757，2016年2月<http://www.rfc-editor.org/info/rfc7757>.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<http://www.rfc-editor.org/info/rfc1918>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 2132，DOI 10.17487/RFC2132，1997年3月<http://www.rfc-editor.org/info/rfc2132>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052，DOI 10.17487/RFC6052，2010年10月<http://www.rfc-editor.org/info/rfc6052>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 6145DOI 10.17487/RFC6145，2011年4月<http://www.rfc-editor.org/info/rfc6145>.
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535]Huang，B.，Deng，H.，和T.Savolainen，“使用“主机中的凹凸”（BIH）的双堆栈主机”，RFC 6535，DOI 10.17487/RFC65352012年2月<http://www.rfc-editor.org/info/rfc6535>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<http://www.rfc-editor.org/info/rfc6724>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <http://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<http://www.rfc-editor.org/info/rfc6877>.
[RFC7335] Byrne, C., "IPv4 Service Continuity Prefix", RFC 7335, DOI 10.17487/RFC7335, August 2014, <http://www.rfc-editor.org/info/rfc7335>.
[RFC7335]Byrne，C.，“IPv4服务连续性前缀”，RFC 7335，DOI 10.17487/RFC7335，2014年8月<http://www.rfc-editor.org/info/rfc7335>.
Appendix A. Examples: Network-Based IPv4 Connectivity
附录A.示例：基于网络的IPv4连接
One relatively straight-forward way to provide IPv4 connectivity between a network-based ER and the IPv4 node(s) it serves is to ensure the IPv4 Service Address(es) can be enclosed within a larger IPv4 prefix. The ER may then claim one address in this prefix for itself and use it to provide an IPv4 default router address and assign the IPv4 Service Address(es) to its downstream node(s) using DHCPv4 [RFC2131]. For example, if the IPv4 Service Addresses are 192.0.2.26 and 192.0.2.27, the ER would configure the address 192.0.2.25/29 on its IPv4-facing interface and would add the two IPv4 Service Addresses to its DHCPv4 pool.
在基于网络的ER和其服务的IPv4节点之间提供IPv4连接的一种相对简单的方法是确保IPv4服务地址可以包含在较大的IPv4前缀中。然后，ER可以在该前缀中为自己声明一个地址，并使用它来提供IPv4默认路由器地址，并使用DHCPv4[RFC2131]将IPv4服务地址分配给其下游节点。例如，如果IPv4服务地址为192.0.2.26和192.0.2.27，ER将在其面向IPv4的接口上配置地址192.0.2.25/29，并将两个IPv4服务地址添加到其DHCPv4池中。
One disadvantage of this method is that IPv4 communication between the IPv4 node(s) behind the ER and other services made available through SIIT-DC becomes impossible, if those other services are assigned IPv4 Service Addresses that also are covered by the same IPv4 prefix (e.g., 192.0.2.28). This happens because the IPv4 nodes will mistakenly believe they have an on-link route to the entire prefix and attempt to resolve the addresses using ARP [RFC826], instead of sending them to the ER for translation to IPv6. This problem could, however, be overcome by avoiding assigning IPv4 Service Addresses that overlap with an IPv4 prefix handled by an ER (at the expense of wasting some potential IPv4 Service Addresses) or by ensuring that the overlapping IPv4 Service Addresses are only assigned to services that do not need to communicate with the IPv4 node(s) behind the ER. A third way to avoid this problem is discussed in Appendix A.2.
此方法的一个缺点是，如果为其他服务分配了同样由相同IPv4前缀覆盖的IPv4服务地址（例如192.0.2.28），则ER后面的IPv4节点与通过SIIT-DC提供的其他服务之间的IPv4通信将变得不可能。发生这种情况是因为IPv4节点会错误地认为它们有一条到整个前缀的链路路由，并尝试使用ARP[RFC826]解析地址，而不是将地址发送到ER以转换为IPv6。但是，可以通过避免分配与ER处理的IPv4前缀重叠的IPv4服务地址（以浪费一些潜在IPv4服务地址为代价）或通过确保仅将重叠的IPv4服务地址分配给不需要与IPv4节点通信的服务来克服此问题在急诊室后面。附录A.2讨论了避免此问题的第三种方法。
In order to avoid the problem discussed in Appendix A.1, a private unrouted IPv4 network that does not encompass the IPv4 Service Address(es) could be used to provide connectivity between the ER and the IPv4-only node(s) it serves. An IPv4-only node must then assign its IPv4 Service Address as a secondary local address, while the ER routes each of the IPv4 Service Addresses to its assigned node using that node's private on-link IPv4 address as the next hop. This approach would ensure there are no overlaps with IPv4 Service Addresses elsewhere in the infrastructure, but on the other hand, it would preclude the use of DHCPv4 [RFC2131] for assigning the IPv4 Service Addresses.
为了避免附录A.1中讨论的问题，可以使用不包含IPv4服务地址的专用未路由IPv4网络来提供ER与其服务的仅IPv4节点之间的连接。然后，仅IPv4的节点必须将其IPv4服务地址分配为辅助本地地址，而ER将每个IPv4服务地址路由到其分配的节点，并使用该节点的专用链路IPv4地址作为下一跳。这种方法将确保与基础设施中其他位置的IPv4服务地址没有重叠，但另一方面，它将阻止使用DHCPv4[RFC2131]来分配IPv4服务地址。
This approach creates a need to ensure that the IPv4 application is selecting the IPv4 Service Address (as opposed to its private on-link IPv4 address) as its source address when initiating outbound connections. This could be accomplished by altering the Default Address Selection Policy Table [RFC6724] on the IPv4 node.
这种方法需要确保IPv4应用程序在启动出站连接时选择IPv4服务地址（与其专用链路IPv4地址相反）作为其源地址。这可以通过更改IPv4节点上的默认地址选择策略表[RFC6724]来实现。
Acknowledgements
致谢
The authors would like to especially thank the authors of 464XLAT [RFC6877]: Masataka Mawatari, Masanobu Kawashima, and Cameron Byrne. The architecture described by this document is merely an adaptation of their work to a data center environment and could not have happened without them.
作者特别感谢464XLAT[RFC6877]的作者：Masataka Mawatari、Masanobu Kawashima和Cameron Byrne。本文档描述的体系结构仅仅是他们的工作适应了数据中心环境，没有他们是不可能实现的。
The authors would like also to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Tobias Brox, Olafur Gudmundsson, Christer Holmberg, Ray Hunter, Shucheng LIU (Will), and Andrew Yourtchenko.
作者还要感谢以下个人的贡献、建议、更正和批评：弗雷德·贝克、托比亚斯·布罗克斯、奥拉弗尔·古德蒙德森、克里斯特·霍姆伯格、雷·亨特、刘淑成（威尔）和安德鲁·尤琴科。
Authors' Addresses
作者地址
Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway
挪威奥斯陆Tore Anderson Redpill Linpro Vitaminveien 1A 0485
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com
Phone: +47 959 31 212
Email: tore@redpill-linpro.com
URI: http://www.redpill-linpro.com
Sander Steffann S.J.M. Steffann Consultancy Tienwoningenweg 46 Apeldoorn, Gelderland 7312 DN The Netherlands
Sander Steffann S.J.M.Steffann咨询公司Tienwoningenweg 46 Apeldoorn，Gelderland 7312 DN荷兰
Email: sander@steffann.nl
Email: sander@steffann.nl