Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7755 Redpill Linpro
Category: Informational February 2016
ISSN: 2070-1721
Internet Engineering Task Force (IETF) T. Anderson
Request for Comments: 7755 Redpill Linpro
Category: Informational February 2016
ISSN: 2070-1721
SIIT-DC: Stateless IP/ICMP Translation for IPv6 Data Center Environments
SIIT-DC：IPv6数据中心环境的无状态IP/ICMP转换
Abstract
摘要
This document describes the use of the Stateless IP/ICMP Translation Algorithm (SIIT) in an IPv6 Internet Data Center (IDC). In this deployment model, traffic from legacy IPv4-only clients on the Internet is translated to IPv6 upon reaching the IDC operator's network infrastructure. From that point on, it may be treated the same as traffic from native IPv6 end users. The IPv6 endpoints may be numbered using arbitrary (non-IPv4-translatable) IPv6 addresses. This facilitates a single-stack IPv6-only network infrastructure, as well as efficient utilization of public IPv4 addresses.
本文档描述了无状态IP/ICMP转换算法（SIIT）在IPv6互联网数据中心（IDC）中的使用。在此部署模型中，来自Internet上传统的仅IPv4客户端的流量在到达IDC运营商的网络基础设施时转换为IPv6。从那时起，它可能被视为来自本机IPv6最终用户的流量。IPv6端点可以使用任意（非IPv4可翻译）IPv6地址进行编号。这有助于实现单栈纯IPv6网络基础设施，以及高效利用公共IPv4地址。
The primary audience is IDC operators who are deploying IPv6, running out of available IPv4 addresses, and/or feeling that dual stack causes undesirable operational complexity.
主要受众是IDC运营商，他们正在部署IPv6，可用IPv4地址即将用尽，和/或感觉双堆栈会导致不必要的操作复杂性。
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/rfc7755.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7755.
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
1.1. Single-Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13
4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13
4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13
4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14
4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14
4.9.3. Minimum Path MTU Difference between IPv4 and IPv6 . . 15
4.10. IPv4-Translatable IPv6 Service Addresses . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Mistaking the Translation Prefix for a Trusted Network . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Complete SIIT-DC IDC Topology Example . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Single-Stack IPv6 Operation . . . . . . . . . . . . . . . 3
1.2. Stateless Operation . . . . . . . . . . . . . . . . . . . 4
1.3. IPv4 Address Conservation . . . . . . . . . . . . . . . . 4
1.4. Clients' IPv4 Source Addresses Visible to Applications . 5
1.5. Compatible with Standard IPv4 and IPv6 Stacks . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 8
3.1. Packet Flow . . . . . . . . . . . . . . . . . . . . . . . 9
4. Deployment Considerations and Guidelines . . . . . . . . . . 10
4.1. Application/Device Support for IPv6 . . . . . . . . . . . 10
4.2. Application Support for NAT . . . . . . . . . . . . . . . 10
4.3. Application Communication Pattern . . . . . . . . . . . . 10
4.4. Choice of Translation Prefix . . . . . . . . . . . . . . 11
4.5. Routing Considerations . . . . . . . . . . . . . . . . . 12
4.6. Location of the SIIT-DC Border Relays . . . . . . . . . . 12
4.7. Migration from Dual Stack . . . . . . . . . . . . . . . . 13
4.8. Translation of ICMPv6 Errors to IPv4 . . . . . . . . . . 13
4.9. MTU and Fragmentation . . . . . . . . . . . . . . . . . . 13
4.9.1. IPv4/IPv6 Header Size Difference . . . . . . . . . . 14
4.9.2. IPv6 Atomic Fragments . . . . . . . . . . . . . . . . 14
4.9.3. Minimum Path MTU Difference between IPv4 and IPv6 . . 15
4.10. IPv4-Translatable IPv6 Service Addresses . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Mistaking the Translation Prefix for a Trusted Network . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Complete SIIT-DC IDC Topology Example . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
Historically, dual stack [RFC4213] [RFC6883] has been the recommended way to transition from a legacy IPv4-only environment to one capable of serving IPv6 users. However, for IDC operators, dual-stack operation has a number of disadvantages compared to single-stack operation. In particular, running two protocols rather than one results in increased complexity and operational overhead with little return on investment for as long as large parts of the public Internet remains predominantly IPv4 only. Furthermore, the dual-stack approach does not in any way help with the depletion of the IPv4 address space, which at the time of writing is a pressing concern in most parts of the world.
从历史上看，双栈[RFC4213][RFC6883]一直是从传统的仅IPv4环境过渡到能够为IPv6用户服务的环境的推荐方式。然而，对于IDC运营商来说，与单栈运营相比，双栈运营有许多缺点。特别是，运行两个协议而不是一个协议会增加复杂性和操作开销，只要大部分公共互联网仍然主要是IPv4，投资回报就很小。此外，双栈方法在任何方面都无助于IPv4地址空间的耗尽，在撰写本文时，这是世界上大多数地区迫切关注的问题。
Therefore, some IDC operators may instead prefer an approach in which they only need to operate one protocol in the data center as they prepare for the future. Stateless IP/ICMP Translation for IPv6 Data Center Environments (SIIT-DC) is one such approach. Its design goals include:
因此，一些IDC运营商可能更喜欢一种方法，在为未来做准备时，他们只需要在数据中心运行一种协议。IPv6数据中心环境的无状态IP/ICMP转换（SIIT-DC）就是这样一种方法。其设计目标包括：
o Promote the deployment of native IPv6 services (cf. [RFC6540]).
o 促进本机IPv6服务的部署（参见[RFC6540]）。
o Provide IPv4 service availability for legacy users with no loss of performance or functionality.
o 为旧式用户提供IPv4服务可用性，而不会损失性能或功能。
o Ensure that the legacy users' IPv4 addresses remain visible to the nodes and applications located in the IPv6 network.
o 确保旧式用户的IPv4地址对位于IPv6网络中的节点和应用程序保持可见。
o Conserve and maximize the utilization of the operator's public IPv4 addresses.
o 保存并最大限度地利用运营商的公共IPv4地址。
o Avoid introducing more complexity than absolutely necessary, especially on the nodes and applications.
o 避免引入超过绝对必要的复杂性，尤其是在节点和应用程序上。
o Easy to scale and deploy in a fault-tolerant manner.
o 易于以容错方式扩展和部署。
The following subsections elaborate on how SIIT-DC meets these goals.
以下小节详细介绍了SIIT-DC如何实现这些目标。
SIIT-DC allows IDC operators to build their infrastructure and applications on an IPv6-only foundation. IPv4 end-user connectivity becomes a service provided by the network, which systems administration and application development staff do not need to concern themselves with. This promotes universal IPv6 deployment for the IDC operator's services and applications.
SIIT-DC允许IDC运营商在IPv6基础上构建其基础设施和应用程序。IPv4最终用户连接成为网络提供的一项服务，系统管理和应用程序开发人员无需关心这项服务。这促进了IDC运营商服务和应用程序的通用IPv6部署。
SIIT-DC requires no special support or change from the underlying IPv6 infrastructure; it is compatible with all standard IPv6 networks. Traffic between IPv6-enabled end users and IPv6-enabled services will always be transported native end to end; SIIT-DC does not intercept or handle native IPv6 traffic at all.
SIIT-DC不需要底层IPv6基础设施的特殊支持或更改；它与所有标准IPv6网络兼容。启用IPv6的最终用户和启用IPv6的服务之间的流量将始终以本机端到端传输；SIIT-DC根本不拦截或处理本机IPv6流量。
When the day comes to discontinue all support for IPv4, no change needs to be made to the overall architecture -- it's only a matter of shutting off the SIIT-DC Border Relays (BRs). Operators who deploy native IPv6 along with SIIT-DC will thus avoid requiring any future migration or deployment projects relating to IPv6 deployment and/or IPv4 sunsetting.
当有一天要停止对IPv4的所有支持时，不需要对整个体系结构进行任何更改——只需关闭SIIT-DC边界中继（BRs）。因此，与SIIT-DC一起部署本机IPv6的运营商将避免需要任何与IPv6部署和/或IPv4部署相关的未来迁移或部署项目。
Unlike other solutions that provide either dual-stack availability to single-stack services (e.g., Stateful Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146] and Layer 4/7 proxies) or conservation of IPv4 addresses (e.g., IPv4 address translation (NAPT44) [RFC3022]), SIIT-DC does not maintain any state associated with individual connections or flows. In this sense, it operates exactly like a regular IP router and has similar scaling properties -- the limiting factors are packets per second and bandwidth. The number of concurrent flows and flow initiation rates are irrelevant for performance.
与为单栈服务提供双栈可用性（例如，从IPv6客户端到IPv4服务器（NAT64）[RFC6146]和第4/7层代理）或IPv4地址保护（例如，IPv4地址转换（NAPT44）[RFC3022]）的其他解决方案不同，SIIT-DC不维护与单个连接或流相关的任何状态。从这个意义上讲，它的运行方式与普通IP路由器完全相同，并且具有类似的扩展特性——限制因素是每秒数据包数和带宽。并发流的数量和流启动速率与性能无关。
This not only allows individual BRs to easily attain "line-rate" performance, but it also allows for per-packet load balancing between multiple BRs using Equal-Cost Multipath Routing [RFC2991]. Asymmetric routing is also acceptable, which makes it easy to avoid suboptimal traffic patterns; the prefixes involved may be anycasted from all the BRs in the provider's network, thus ensuring that the most optimal path through the network is used, even where the optimal path in one direction differs from the optimal path in the opposite direction.
这不仅允许单个BRs轻松获得“线路速率”性能，还允许使用等成本多路径路由在多个BRs之间实现每包负载平衡[RFC2991]。非对称路由也是可以接受的，这使得它很容易避免次优的流量模式；所涉及的前缀可以从提供商网络中的所有br中进行任意广播，从而确保使用通过网络的最佳路径，即使在一个方向上的最佳路径与相反方向上的最佳路径不同的情况下也是如此。
Finally, stateless operation means that high availability is easily achieved. If a BR should fail, its traffic can be rerouted onto another BR using a standard IP routing protocol. This does not impact existing flows any more than what any other IP rerouting event would.
最后，无状态操作意味着很容易实现高可用性。如果某个BR失败，则可以使用标准IP路由协议将其流量重新路由到另一个BR。这不会比任何其他IP重新路由事件对现有流的影响更大。
In most parts of the world, it is difficult or even impossible to obtain generously sized IPv4 delegations from the Internet Numbers Registry System [RFC7020]. The resulting scarcity in turn impacts individual end users and operators, whom might be forced to purchase
在世界大部分地区，很难甚至不可能从互联网号码注册系统[RFC7020]获得规模庞大的IPv4授权。由此产生的稀缺性反过来影响个人最终用户和运营商，他们可能被迫购买
IPv4 addresses from other operators in order to cover their needs. This process can be risky to business continuity, in the case where no suitable block for sale can be located, and/or turn out to be prohibitively expensive. In spite of this, an IDC operator will find that providing IPv4 service remains essential, as a large share of the Internet end users still do not have IPv6 connectivity.
来自其他运营商的IPv4地址，以满足其需求。如果找不到合适的销售区块和/或成本过高，此流程可能会对业务连续性造成风险。尽管如此，IDC运营商会发现，提供IPv4服务仍然至关重要，因为大部分互联网终端用户仍然没有IPv6连接。
A key goal of SIIT-DC is to help reduce a data center operator's IPv4 address requirement to the absolute minimum by allowing the operator to remove them entirely from nodes and applications that do not need to communicate with endpoints in the IPv4 Internet. One example would be servers that are operating in a supporting/backend role and only communicating with other servers (database servers, file servers, and so on). Another example would be the network infrastructure itself (router-to-router links, loopback addresses, and so on). Furthermore, as LAN prefix sizes must always be rounded up to the nearest power of two (or larger if one reserves space for future growth), even more IPv4 addresses will often end up being wasted without even being used.
SIIT-DC的一个关键目标是帮助数据中心运营商将IPv4地址要求降至绝对最低，允许运营商将其从不需要与IPv4 Internet中的端点通信的节点和应用程序中完全删除。例如，以支持/后端角色运行且仅与其他服务器（数据库服务器、文件服务器等）通信的服务器。另一个例子是网络基础设施本身（路由器到路由器的链接、环回地址等）。此外，由于LAN前缀大小必须始终四舍五入到最接近的二次方（如果有一个为未来的增长预留空间，则更大），甚至更多的IPv4地址往往会在没有使用的情况下被浪费。
With SIIT-DC, the operator can remove these valuable IPv4 addresses from his backend servers and network infrastructure and reassign them to the SIIT-DC service as IPv4 Service Addresses. There exists no requirement that IPv4 Service Addresses are to be assigned in an aggregated manner, so there is nothing lost due to infrastructure overhead; every single IPv4 address assigned to SIIT-DC can be used as an IPv4 Service Address.
通过SIIT-DC，运营商可以从其后端服务器和网络基础设施中删除这些有价值的IPv4地址，并将其作为IPv4服务地址重新分配给SIIT-DC服务。不存在以聚合方式分配IPv4服务地址的要求，因此不会因基础设施开销而丢失任何内容；分配给SIIT-DC的每个IPv4地址都可以用作IPv4服务地址。
SIIT-DC uses the [RFC6052] algorithm to map the entire end-user's IPv4 source address into a predefined IPv6 translation prefix. This ensures that there is no loss of information; the end-user's IPv4 source address remains available to the application located in the IPv6 network, allowing it to perform tasks like geolocation, logging, abuse handling, and so forth.
SIIT-DC使用[RFC6052]算法将整个最终用户的IPv4源地址映射为预定义的IPv6转换前缀。这确保了信息不会丢失；最终用户的IPv4源地址对位于IPv6网络中的应用程序仍然可用，允许其执行地理定位、日志记录、滥用处理等任务。
Except for the introduction of the BRs themselves, no change to the network, nodes, applications, or anything else is required in order to support SIIT-DC. SIIT-DC is practically invisible from the point of view of the IPv4 clients, the IPv6 nodes, the IPv6 data center network, and the IPv4 Internet. SIIT-DC interoperates with all standards-compliant IPv4 or IPv6 stacks.
除了BRs本身的引入，支持SIIT-DC不需要对网络、节点、应用程序或任何其他方面进行任何更改。从IPv4客户端、IPv6节点、IPv6数据中心网络和IPv4 Internet的角度来看，SIIT-DC实际上是不可见的。SIIT-DC可与所有符合标准的IPv4或IPv6协议栈进行互操作。
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 IDC's outer network border. The ER is an optional component of SIIT-DC. It is discussed in more detail in [RFC7756].
SIIT-DC边缘中继（ER）：一种设备或逻辑功能，为仅IPv4设备或应用软件提供“本机”IPv4连接。它在功能上与BR非常相似，但通常位于其支持的仅IPv4组件附近，而不是IDC的外部网络边界上。ER是SIIT-DC的可选组件。[RFC7756]对其进行了更详细的讨论。
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。
IPv4 Service Address Pool: One or more IPv4 prefixes routed to the BR's IPv4 interface. IPv4 Service Addresses are allocated from this pool. This does not necessarily have to be a "pool" per se, as it could also be one or more host routes (whose prefix lengths are equal to /32). The purpose of using a pool rather than host routes is to facilitate IPv4 route aggregation and ease provisioning of new IPv4 Service Addresses.
IPv4服务地址池：路由到BR的IPv4接口的一个或多个IPv4前缀。IPv4服务地址是从此池分配的。这本身不一定是“池”，因为它也可以是一个或多个主机路由（其前缀长度等于/32）。使用池而不是主机路由的目的是促进IPv4路由聚合并简化新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-Translatable 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]中所述进行解释。
This section describes the basic SIIT-DC architecture.
本节介绍基本的SIIT-DC体系结构。
IPv6-capable user IPv4-only user
<2001:db8::ab:cd> <203.0.113.50>
| |
(the IPv6 Internet) (the IPv4 Internet)
| |
| +-[BR]---------<192.0.2.0/24>--------------+
| | |
| | EAM #1: 192.0.2.1,2001:db8:12:34::1 |
| | EAM #2..#n: [...] |
| | XLAT Prefix: 2001:db8:46::/96 |
| | |
| +------------<2001:db8:46::/96>------------+
| |
(the IPv6-only data center network)
|
+--<2001:db8:12:34::1>--[v6-only server]-+
| | |
| +-[2001:db8:12:34::1]--[v6-only app]-+ |
| | AF_INET6 socket | |
| +------------------------------------+ |
+----------------------------------------+
IPv6-capable user IPv4-only user
<2001:db8::ab:cd> <203.0.113.50>
| |
(the IPv6 Internet) (the IPv4 Internet)
| |
| +-[BR]---------<192.0.2.0/24>--------------+
| | |
| | EAM #1: 192.0.2.1,2001:db8:12:34::1 |
| | EAM #2..#n: [...] |
| | XLAT Prefix: 2001:db8:46::/96 |
| | |
| +------------<2001:db8:46::/96>------------+
| |
(the IPv6-only data center network)
|
+--<2001:db8:12:34::1>--[v6-only server]-+
| | |
| +-[2001:db8:12:34::1]--[v6-only app]-+ |
| | AF_INET6 socket | |
| +------------------------------------+ |
+----------------------------------------+
Figure 1: SIIT-DC Architecture
图1:SIIT-DC体系结构
In Figure 1, 192.0.2.0/24 is the IPv4 Service Address Pool. Individual IPv4 Service Addresses are assigned from this prefix, and traffic destined for it is routed to the BR's IPv4-facing network interface. There are no restrictions on how many IPv4 Service Address Pools are used or their prefix length, as long as they are all routed to the BR's IPv4-facing network interface.
在图1中，192.0.2.0/24是IPv4服务地址池。从该前缀分配单个IPv4服务地址，并将发送给该地址的流量路由到BR的面向IPv4的网络接口。对使用多少IPv4服务地址池或其前缀长度没有限制，只要它们都路由到BR的面向IPv4的网络接口。
When translating packets between IPv4 and IPv6, the BR uses EAM #1 to replace any occurrence of the IPv4 Service Address (192.0.2.1) with its corresponding IPv6 Service Address (2001:db8:12:34::1). Addresses that do not match any EAM configured in the BR are translated by inserting or removing the translation prefix (2001:db8:46::/96); cf. Section 2.2 of [RFC6052].
在IPv4和IPv6之间转换数据包时，BR使用EAM#1将IPv4服务地址（192.0.2.1）替换为其相应的IPv6服务地址（2001:db8:12:34:：1）。通过插入或删除转换前缀（2001:db8:46:：/96），可以转换与BR中配置的任何EAM不匹配的地址；参见[RFC6052]第2.2节。
The BR can be deployed as a separate device or as a logical function in another multipurpose device, such as an IP router. Any number of BRs may exist simultaneously in the IDC's network infrastructure, as long as they are all configured with the same translation prefix and an identical EAM Table.
BR可以作为单独的设备部署，也可以作为另一个多用途设备（如IP路由器）中的逻辑功能部署。IDC的网络基础设施中可能同时存在任意数量的BR，只要它们都配置了相同的翻译前缀和相同的EAM表。
The IPv6 Service Address should be registered in DNS using an "IN AAAA" record, while its corresponding IPv4 Service Address should be registered using an "IN A" record. This ensures that IPv6-capable clients access the application/service directly using native IPv6 end to end, while IP4-only clients will access it through SIIT-DC.
IPv6服务地址应使用“in AAAA”记录在DNS中注册，而其相应的IPv4服务地址应使用“in A”记录注册。这确保支持IPv6的客户端直接使用本机IPv6端到端访问应用程序/服务，而只有IP4的客户端将通过SIIT-DC访问应用程序/服务。
In this example, the "IPv4-only user" from Figure 1 initiates a connection to the application running on the IPv6-only server. After first having looked up the "IN A" record in DNS, the user starts by transmitting a TCP SYN packet to the IPv4 Service Address. This IPv4 packet is routed to the BR and is there translated to IPv6 as follows:
在本例中，图1中的“仅IPv4用户”启动到仅IPv6服务器上运行的应用程序的连接。首先在DNS中查找“IN A”记录后，用户开始向IPv4服务地址发送TCP SYN数据包。此IPv4数据包路由到BR，并在那里转换为IPv6，如下所示：
+--[IPv4]----------+ +--[IPv6]-----------------------+
| SRC 203.0.113.50 | | SRC 2001:db8:46::203.0.113.50 |
| DST 192.0.2.1 | --> | DST 2001:db8:12:34::1 |
| TCP SYN [..] | | TCP SYN [..] |
+------------------+ +-------------------------------+
+--[IPv4]----------+ +--[IPv6]-----------------------+
| SRC 203.0.113.50 | | SRC 2001:db8:46::203.0.113.50 |
| DST 192.0.2.1 | --> | DST 2001:db8:12:34::1 |
| TCP SYN [..] | | TCP SYN [..] |
+------------------+ +-------------------------------+
Figure 2: IPv4-to-IPv6 Translation
图2:IPv4到IPv6的转换
The resulting IPv6 packet is routed to the IPv6-only server, which processes and responds to it as if it had been a native IPv6 packet all along. The server's IPv6 response packet is then routed back to the BR, where it is translated back to IPv4 as follows:
生成的IPv6数据包被路由到仅限IPv6的服务器，该服务器处理并响应该数据包，就像它一直都是本机IPv6数据包一样。然后，服务器的IPv6响应数据包被路由回BR，在BR中它被转换回IPv4，如下所示：
+--[IPv6]-----------------------+ +--[IPv4]----------+
| SRC 2001:db8:12:34::1 | | SRC 192.0.2.1 |
| DST 2001:db8:46::203.0.113.50 | --> | DST 203.0.113.50 |
| TCP SYN/ACK [..] | | TCP SYN/ACK [..] |
+-------------------------------+ +------------------+
+--[IPv6]-----------------------+ +--[IPv4]----------+
| SRC 2001:db8:12:34::1 | | SRC 192.0.2.1 |
| DST 2001:db8:46::203.0.113.50 | --> | DST 203.0.113.50 |
| TCP SYN/ACK [..] | | TCP SYN/ACK [..] |
+-------------------------------+ +------------------+
Figure 3: IPv6-to-IPv4 Translation
图3:IPv6到IPv4的转换
It is important to note that neither the IPv4 client nor the IPv6 server/application need any special support to participate in SIIT-DC. However, the application may optionally be taught to extract the embedded IPv4 source address from incoming IPv6 packets with source addresses within the translation prefix. This will allow it to perform IPv4-specific tasks such as geolocation, logging, abuse handling, and so on.
需要注意的是，IPv4客户端和IPv6服务器/应用程序都不需要任何特殊支持才能参与SIIT-DC。然而，可以任选地教导应用程序从具有翻译前缀内的源地址的传入IPv6分组中提取嵌入的IPv4源地址。这将允许它执行特定于IPv4的任务，如地理定位、日志记录、滥用处理等。
SIIT-DC as described in this document requires that the application (and/or the node the application is located on) supports IPv6 networking and that it has no dependency on local IPv4 network connectivity.
本文档中描述的SIIT-DC要求应用程序（和/或应用程序所在的节点）支持IPv6网络，并且不依赖于本地IPv4网络连接。
SIIT-DC can, however, support legacy IPv4-dependent applications and nodes through the introduction of an ER. The ER provides the legacy application or node with seemingly native IPv4 Internet connectivity, so that it may operate correctly in an otherwise IPv6-only network environment. This approach is described in more detail in [RFC7756].
然而，SIIT-DC可以通过引入ER来支持传统的依赖IPv4的应用程序和节点。ER为遗留应用程序或节点提供了看似本机的IPv4 Internet连接，因此它可以在仅限IPv6的网络环境中正常运行。[RFC7756]中更详细地描述了这种方法。
The operator should carefully examine whether or not the application protocols he would like to use SIIT-DC with are able to operate in a network environment where rewriting of IP addresses occurs. In general, if an application-layer protocol works correctly through standard NAT44 (see [RFC3235]), it will most likely work correctly through SIIT-DC as well.
操作员应仔细检查其希望使用的SIIT-DC应用协议是否能够在IP地址重写的网络环境中运行。一般来说，如果应用层协议通过标准NAT44正常工作（请参见[RFC3235]），那么它也很可能通过SIIT-DC正常工作。
Higher-level protocols that embed IP addresses as part of their payload are particularly problematic [RFC2663] [RFC2993] [RFC3022]. One well-known example of such a protocol is FTP [RFC959]. Such protocols can be made to work with SIIT-DC through the introduction of an ER, which provides end-to-end IPv4 address transparency by reversing the translations performed by the BR before passing the packets to the NAT-incompatible application. This approach is described in more detail in [RFC7756].
嵌入IP地址作为其有效负载一部分的高级协议尤其有问题[RFC2663][RFC2993][RFC3022]。这种协议的一个众所周知的例子是FTP[RFC959]。可以通过引入ER使此类协议与SIIT-DC协同工作，ER通过在将数据包传递给NAT不兼容的应用程序之前反转BR执行的转换来提供端到端IPv4地址透明性。[RFC7756]中更详细地描述了这种方法。
SIIT-DC is best suited for traditional client/server applications where IPv4-only clients on the Internet initiate traffic towards an IPv6-only service, which in turn is passively listening for inbound traffic and responding as necessary. In this case, an IPv4 client looks exactly like a native IPv6 client from the IPv6 service's point of view and thus does not require any special treatment. One particularly common application protocol that follows this client/ server communication pattern, and thus is ideally suited for use with SIIT-DC, is HTTP [RFC7230].
SIIT-DC最适合于传统的客户机/服务器应用程序，在这些应用程序中，Internet上仅IPv4的客户机向仅IPv6的服务发起流量，后者反过来被动地侦听入站流量并根据需要进行响应。在本例中，从IPv6服务的角度来看，IPv4客户端与本机IPv6客户端完全相同，因此不需要任何特殊处理。遵循这种客户机/服务器通信模式的一种特别常见的应用程序协议是HTTP[RFC7230]，因此非常适合与SIIT-DC一起使用。
It is also possible to combine SIIT-DC with DNS64 [RFC6147] in order to allow an IPv6-only application to initiate communication with IPv4-only nodes through SIIT-DC. However, in this case, care must be taken so that all outgoing communication is sourced from an IPv6 Service Address that is found in an EAM configured in the BR. If another address is used, the BR will most likely be unable to translate it to IPv4, causing the packet to be discarded. This could be prevented by altering the Default Address Selection Policy Table [RFC6724] on the IPv6 node.
还可以将SIIT-DC与DNS64[RFC6147]结合，以允许仅IPv6应用程序通过SIIT-DC启动与仅IPv4节点的通信。但是，在这种情况下，必须小心，以便所有传出通信都来自在BR中配置的EAM中找到的IPv6服务地址。如果使用了另一个地址，BR很可能无法将其转换为IPv4，从而导致数据包被丢弃。这可以通过更改IPv6节点上的默认地址选择策略表[RFC6724]来防止。
An alternative approach to the above would be to place an ER in front of the application in question, as described in [RFC7756]. This provides the application with seemingly native IPv4 connectivity, which it may use freely for bidirectional communication with the IPv4 Internet. An application or node located behind an ER does not need to worry about selecting a specific source address, as it will only have valid options available.
上述的另一种方法是将ER放在相关应用程序前面，如[RFC7756]所述。这为应用程序提供了看似本机的IPv4连接，它可以自由地使用该连接与IPv4 Internet进行双向通信。位于ER后面的应用程序或节点不需要担心选择特定的源地址，因为它只有可用的有效选项。
Either a Network-Specific Prefix (NSP) from the provider's own IPv6 address space or the IANA-allocated Well-Known Prefix (WKP) 64:ff9b::/96 may be used. From a technical point of view, both work equally well. However, only a single WKP exists, so if a provider would like to deploy more than one instance of SIIT-DC in his network, or another translation technology such as Stateful NAT64 [RFC6146], the operator will be forced to use an NSP for all but one of those deployments.
可以使用提供商自己的IPv6地址空间中的网络特定前缀（NSP）或IANA分配的已知前缀（WKP）64:ff9b:：/96。从技术角度来看，这两种方法都同样有效。但是，只有一个WKP存在，因此如果提供商希望在其网络中部署多个SIIT-DC实例，或其他转换技术，如有状态NAT64[RFC6146]，则运营商将被迫对所有这些部署（其中一个除外）使用NSP。
Another consideration is that the WKP cannot be used in inter-domain routing. By using an NSP instead, SIIT-DC will support a deployment where the BR and the IPv6 Service Address are located in different Autonomous Systems.
另一个考虑因素是WKP不能用于域间路由。通过使用NSP，SIIT-DC将支持BR和IPv6服务地址位于不同自治系统中的部署。
The translation prefix may use any of the lengths described in Section 2.2 of [RFC6052], but /96 has two distinct advantages over the others. First, converting it to IPv4 can be done in a single operation by simply stripping off the first 96 bits; second, it allows for IPv4 addresses to be embedded directly into the text representation of an IPv6 address using the familiar dotted quad notation, e.g., "2001:db8::198.51.100.10" (cf. Section 2.4 of [RFC6052]), instead of being converted to hexadecimal notation. This makes it easier to write literal IPv6 addresses (e.g., in ACLs) that correspond to translated endpoints in the IPv4 Internet.
翻译前缀可以使用[RFC6052]第2.2节中描述的任何长度，但是/96与其他长度相比有两个明显的优势。首先，只需剥离前96位，就可以在一次操作中将其转换为IPv4；其次，它允许IPv4地址直接嵌入到IPv6地址的文本表示中，使用熟悉的虚线四元表示法，例如，“2001:db8:：198.51.100.10”（参见[RFC6052]第2.4节），而不是转换为十六进制表示法。这使得编写与IPv4 Internet中转换的端点相对应的文字IPv6地址（例如，在ACL中）变得更容易。
For the reasons discussed above, this document recommends that an NSP with a prefix length of /96 be used. Section 3.3 of [RFC6052] discusses the choice of the translation prefix in more detail.
出于上述原因，本文件建议使用前缀长度为/96的NSP。[RFC6052]第3.3节更详细地讨论了翻译前缀的选择。
The prefixes that constitute the IPv4 Service Address Pool and the IPv6 translation prefix may be routed to the BRs like any other IPv4 or IPv6 route in the provider's network. If more than one BR is being deployed, it is recommended that a routing protocol (IGP) be used to advertise the routes within the provider's network. This will ensure that the traffic that is to be translated will reach the closest BR, reducing or eliminating suboptimal traffic patterns as well as providing high availability: should one BR fail, the IGP will automatically redirect the traffic to the closest alternate BR.
与提供商网络中的任何其他IPv4或IPv6路由一样，构成IPv4服务地址池和IPv6转换前缀的前缀可以路由到BRs。如果部署了多个BR，建议使用路由协议（IGP）在提供商的网络中公布路由。这将确保要转换的流量将到达最近的BR，减少或消除次优流量模式，并提供高可用性：如果一个BR失败，IGP将自动将流量重定向到最近的备用BR。
The goal of SIIT-DC is to facilitate a true IPv6-only application and network architecture, with the sole exception being the IPv4 interfaces of the BRs and the network infrastructure required to connect the BRs to the IPv4 Internet. Therefore, the BRs must be located somewhere between the IPv4 Internet and the application delivery stack, which includes all servers, load balancers, firewalls, intrusion detection systems, and similar devices that are processing traffic to a greater extent than merely forwarding it.
SIIT-DC的目标是促进真正的纯IPv6应用程序和网络体系结构，唯一的例外是BRs的IPv4接口以及将BRs连接到IPv4 Internet所需的网络基础设施。因此，BRs必须位于IPv4 Internet和应用程序交付堆栈之间的某个位置，该堆栈包括所有服务器、负载平衡器、防火墙、入侵检测系统以及处理流量的类似设备，而不仅仅是转发流量。
It is optimal to place the BRs as close as possible to the direct path between the location of the IPv6 Service Address and the end users. If the closest BR was located a long way from the direct path, all packets in both directions must make a detour in order to traverse the BR. This would increase the RTT between the service and the end user by two times the extra latency incurred by the detour, as well as cause unnecessary load on the network links on the detour path.
最好将BRs尽可能靠近IPv6服务地址位置和最终用户之间的直接路径。如果最近的BR距离直接路径很远，则两个方向上的所有数据包都必须绕道才能穿过BR。这将使服务和最终用户之间的RTT增加两倍于绕行引起的额外延迟，并在绕行路径上的网络链路上造成不必要的负载。
Where possible, it is beneficial to implement the BRs as a logical function within the routers that also handle the native IPv6 traffic between the IPv6 Service Address and the IPv6 Internet. This way, an SIIT-DC deployment does not require separate networks ports (which might become saturated and impact the service quality) nor will it require extra rack space and energy. Some particularly good choices for the location could be within the IDC's access routers or within the Autonomous System's border routers.
在可能的情况下，将BRs实现为路由器内的逻辑功能是有益的，路由器还处理IPv6服务地址和IPv6 Internet之间的本机IPv6流量。这样，SIIT-DC部署不需要单独的网络端口（可能会饱和并影响服务质量），也不需要额外的机架空间和能量。一些特别好的位置选择可能在IDC的接入路由器内或自治系统的边界路由器内。
Finally, another possibility is that the IDC operator outsources the SIIT-DC service to another entity, for example, his upstream ISP. Doing so allows the IDC operator to build a true IPv6-only infrastructure.
最后，另一种可能性是IDC运营商将SIIT-DC服务外包给另一个实体，例如其上游ISP。这样做可以让IDC运营商构建真正的纯IPv6基础设施。
While this document mainly discusses the use of IPv6-only nodes and applications, it is important to note that SIIT-DC is fully compatible with dual-stack infrastructures, including dual-stack nodes and applications.
虽然本文档主要讨论仅限IPv6的节点和应用程序的使用，但需要注意的是，SIIT-DC完全兼容双栈基础设施，包括双栈节点和应用程序。
Thus, migrating a dual-stacked service to an IPv6-only one where SIIT-DC provides the IPv4 Internet connectivity is easy. The operator would start out by designating the service's current native IPv6 address as the IPv6 Service Address and assigning it a corresponding IPv4 Service Address. At this point, the service will respond on both its old (native) IPv4 address and the SIIT-DC IPv4 Service Address. The operator may now move traffic from the former to the latter by changing the service's "IN A" DNS record. Once all IPv4 traffic has been successfully moved to SIIT-DC, the old IPv4 address may be reclaimed.
因此，将双堆叠服务迁移到只有IPv6的服务（其中SIIT-DC提供IPv4互联网连接）是很容易的。运营商首先将服务的当前本机IPv6地址指定为IPv6服务地址，并为其分配相应的IPv4服务地址。此时，服务将在其旧（本机）IPv4地址和SIIT-DC IPv4服务地址上响应。运营商现在可以通过更改服务的“IN A”DNS记录将流量从前者移动到后者。一旦所有IPv4流量成功移动到SIIT-DC，就可以回收旧的IPv4地址。
In response to an IPv4 packet subsequently translated to IPv6 by the BR, an IPv6 router in the IDC network may need to transmit an ICMPv6 error back to the origin IPv4 node. By default, such an ICMPv6 error will most likely be discarded by the BR, unless the source address of the ICMPv6 error happens to be an IPv4-translatable IPv6 address or covered by an EAM.
为了响应随后由BR转换为IPv6的IPv4数据包，IDC网络中的IPv6路由器可能需要将ICMPv6错误发送回原始IPv4节点。默认情况下，除非ICMPv6错误的源地址恰好是IPv4可翻译IPv6地址或由EAM覆盖，否则BR很可能会丢弃此类ICMPv6错误。
To facilitate reliable delivery of such ICMPv6 errors, an SIIT-DC operator SHOULD implement the recommendations in [RFC6791] in the BRs.
为促进此类ICMPv6错误的可靠交付，SIIT-DC运营商应在BRs中实施[RFC6791]中的建议。
There are some key differences between IPv4 and IPv6 relating to packet sizes and fragmentation that one MUST consider when deploying SIIT-DC. They result in a few problematic corner cases, which can be dealt with in a few different ways. The following subsections will discuss these in detail and provide operational guidance.
IPv4和IPv6之间的一些关键差异与部署SIIT-DC时必须考虑的数据包大小和碎片有关。它们导致了一些有问题的角落案例，可以用几种不同的方式来处理。以下小节将详细讨论这些问题，并提供操作指南。
In particular, the operator may find that relying on fragmentation in the IPv6 domain is undesired or even operationally impossible [FRAGMENTS]. For this reason, the recommendations in this section seek to minimize the use of IPv6 fragmentation.
尤其是，运营商可能会发现，依赖IPv6域中的碎片是不希望的，甚至在操作上是不可能的[碎片]。因此，本节中的建议旨在尽量减少IPv6分段的使用。
Unless otherwise stated, the following subsections assume that the MTUs in both the IPv4 and IPv6 domains are 1500 bytes.
除非另有说明，否则以下小节假设IPv4和IPv6域中的MTU均为1500字节。
The IPv6 header is up to 20 bytes larger than the IPv4 header. This means that a full-size 1500 bytes large IPv4 packet cannot be translated to IPv6 without being fragmented, otherwise it would likely have resulted in a 1520 bytes large IPv6 packet.
IPv6标头最多比IPv4标头大20个字节。这意味着一个全尺寸的1500字节大的IPv4数据包不能在不分段的情况下转换为IPv6，否则它可能会导致一个1520字节大的IPv6数据包。
If the transport protocol used is TCP, this is generally not a problem; the IPv6 node will advertise a TCP Maximum Segment Size (MSS) of 1440 bytes during the initial TCP handshake. This causes the IPv4 clients to never send larger packets than what can be translated to a single full-size IPv6 packet, eliminating any need for fragmentation.
如果使用的传输协议是TCP，这通常不是问题；在初始TCP握手期间，IPv6节点将公布1440字节的TCP最大段大小（MSS）。这使得IPv4客户端发送的数据包永远不会超过可以转换为单个完整大小IPv6数据包的数据包，从而消除了任何碎片化的需要。
For other transport protocols, full-size IPv4 packets with the Don't Fragment (DF) flag cleared will need to be fragmented by the BR. This may be avoided by increasing the Path MTU between the BR and the IPv6 nodes to 1520 bytes or greater. If this is done, the MTU on the IPv6 nodes themselves SHOULD NOT be increased accordingly, as doing so would cause them to undergo Path MTU Discovery for all destinations on the IPv6 Internet. The nodes MUST, however, be able to accept and process incoming packets larger than their own MTU. If the nodes' IPv6 implementation allows the initial Path MTU to be set differently for specific destinations, it MAY be increased to 1520 for destinations within the translation prefix specifically.
对于其他传输协议，清除了不分段（DF）标志的全尺寸IPv4数据包需要由BR分段。这可以通过将BR和IPv6节点之间的路径MTU增加到1520字节或更大来避免。如果这样做，IPv6节点本身上的MTU不应相应增加，因为这样做会导致它们在IPv6 Internet上的所有目的地上进行路径MTU发现。然而，节点必须能够接受和处理比其自身MTU大的传入数据包。如果节点的IPv6实现允许针对特定目的地以不同的方式设置初始路径MTU，则对于特定翻译前缀内的目的地，可以将其增加到1520。
In keeping with the fifth paragraph of Section 4 of [RFC6145], a stateless translator like a BR will by default add an IPv6 Fragmentation header to the resulting IPv6 packet when translating an IPv4 packet with the DF flag set to 0. This happens even though the resulting IPv6 packet isn't actually fragmented into several pieces, resulting in an IPv6 Atomic Fragment [RFC6946]. These Atomic Fragments are generally not useful in an IDC environment, and it is therefore recommended that this behavior be disabled in the BRs. To this end, Section 4 of [RFC6145] notes that the "translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets."
根据[RFC6145]第4节第五段的规定，在翻译DF标志设置为0的IPv4数据包时，类似BR的无状态转换器在默认情况下将向生成的IPv6数据包添加IPv6分段头。即使生成的IPv6数据包实际上没有分割成多个片段，也会发生这种情况，从而生成IPv6原子片段[RFC6946]。这些原子片段在IDC环境中通常不有用，因此建议在BRs中禁用此行为。为此，[RFC6145]第4节指出，“转换器可以提供一个配置功能，允许转换器不包括非分段IPv6数据包的分段头。”
Note that work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. As a result, a BR that conforms to that document is required to behave as recommended above.
请注意，（在[RFC6145bis]中）目前正在进行弃用IPv6原子片段的工作。因此，符合该文件的BR需要按照上述建议进行操作。
In IPv6, the Identification value is located inside the Fragmentation header. That means that if the generation of IPv6 Atomic Fragments
在IPv6中，标识值位于分段标头内。这意味着如果IPv6原子片段的生成
is disabled, the IPv4 Identification value will be lost during translation to IPv6. This could potentially confuse some diagnostic tools.
如果禁用，则IPv4标识值将在转换为IPv6期间丢失。这可能会混淆某些诊断工具。
Section 5 of [RFC2460] specifies that the minimum IPv6 link MTU is 1280 bytes. Therefore, an IPv6 node can reasonably assume that if it transmits an IPv6 packet that is 1280 bytes or smaller, it is guaranteed to reach its destination without requiring fragmentation or invoking the Path MTU Discovery algorithm [RFC1981]. However, this assumption might prove false if the destination is an IPv4 node reached through a protocol translator such as a BR, as the minimum IPv4 link MTU is 68 bytes. See Section 3.2 of [RFC791].
[RFC2460]的第5节规定，最小IPv6链路MTU为1280字节。因此，IPv6节点可以合理地假设，如果它传输1280字节或更小的IPv6数据包，则可以保证在不需要分段或调用路径MTU发现算法[RFC1981]的情况下到达其目的地。但是，如果目标是通过协议转换器（如BR）到达的IPv4节点，则此假设可能是错误的，因为IPv4链路MTU的最小值为68字节。见[RFC791]第3.2节。
Section 5.1 of [RFC6145] specifies that a stateless translator should set the IPv4 Don't Fragment flag to 1 when it translates a non-fragmented IPv6 packet to IPv4. This means that when the path to the destination IPv4 node contains an IPv4 link with an MTU smaller than 1260 bytes (which corresponds to an IPv6 MTU smaller than 1280 bytes; cf. Section 4.9.1), the Path MTU Discovery algorithm will be invoked, even if the original IPv6 packet was only 1280 bytes large. This happens as a result of the IPv4 router connecting to the IPv4 link with the small MTU returning an ICMPv4 Need To Fragment error with an MTU value smaller than 1260, which in turn is translated by the BR to an ICMPv6 Packet Too Big error with an MTU value smaller than 1280, which is then transmitted to the origin IPv6 node.
[RFC6145]的第5.1节规定，无状态转换器在将未分段的IPv6数据包转换为IPv4时，应将IPv4不分段标志设置为1。这意味着，当目标IPv4节点的路径包含MTU小于1260字节（对应于小于1280字节的IPv6 MTU；参见第4.9.1节）的IPv4链路时，将调用路径MTU发现算法，即使原始IPv6数据包仅为1280字节。这是由于IPv4路由器连接到IPv4链路，而小MTU返回一个ICMPv4需要将MTU值小于1260的错误分段，然后BR将其转换为MTU值小于1280的ICMPv6数据包太大错误，然后将其传输到源IPv6节点。
When an IPv6 node receives an ICMPv6 Packet Too Big error indicating an MTU value smaller than 1280, it is not allowed to reduce its Path MTU estimation to the indicated value. It must instead include a Fragmentation header in subsequent packets sent on that path [RFC1981]. In other words, the IPv6 node will start emitting Atomic Fragments. The Fragmentation header signals to the BR that the Don't Fragment flag should be set to 0 in the resulting IPv4 packet, and it also provides the Identification value.
当IPv6节点收到指示MTU值小于1280的ICMPv6数据包太大错误时，不允许将其路径MTU估计值减少到指示值。相反，它必须在该路径[RFC1981]上发送的后续数据包中包含碎片标头。换句话说，IPv6节点将开始发射原子碎片。分段标头向BR发出信号，表示在生成的IPv4数据包中，不分段标志应设置为0，并且还提供标识值。
If the use of the IPv6 Fragmentation header is problematic, the operator should consider enabling the functionality described as the "second approach" in Section 6 of [RFC6145]. This functionality changes the BR's behavior as follows:
如果IPv6碎片报头的使用是有问题的，操作员应该考虑启用描述为[FC665]第6节中的“第二种方法”的功能。此功能将更改BR的行为，如下所示：
o When translating ICMPv4 Need To Fragment to ICMPv6 Packet Too Big, the resulting packet will never contain an MTU value lower than 1280. This prevents the IPv6 nodes from generating Atomic Fragments.
o 当将ICMPv4翻译成过大的ICMPv6数据包时，生成的数据包将永远不会包含低于1280的MTU值。这将防止IPv6节点生成原子片段。
o When translating IPv6 packets smaller than or equal to 1280 bytes, the Don't Fragment flag in the resulting IPv4 packet will be set to 0. This ensures that in the eventuality that the path contains an IPv4 link with an MTU smaller than 1260, the IPv4 router connected to that link will have the responsibility to fragment the packet before forwarding it towards its destination.
o 翻译小于或等于1280字节的IPv6数据包时，生成的IPv4数据包中的“不分段”标志将设置为0。这确保在路径包含MTU小于1260的IPv4链路的情况下，连接到该链路的IPv4路由器将负责在将数据包转发到其目的地之前对其进行分段。
In summary, this approach could be seen as prompting the IPv4 protocol itself to provide the "link-specific fragmentation and reassembly at a layer below IPv6" required for links that "cannot convey a 1280-octet packet in one piece", to paraphrase Section 5 of [RFC2460].
总之，这种方法可以被视为促使IPv4协议本身提供“无法在一块中传输1280个八位字节数据包”的链路所需的“IPv6下一层的链路特定碎片化和重组”，如[RFC2460]第5节所述。
Note that work is currently in progress (in [RFC6145bis]) to deprecate IPv6 Atomic Fragments. As a result, a BR that conforms to that document is required to behave as suggested above.
请注意，（在[RFC6145bis]中）目前正在进行弃用IPv6原子片段的工作。因此，符合该文档的BR需要按照上述建议进行操作。
SIIT-DC is designed so that the IPv6 Service Addresses are not required to be IPv4-translatable IPv6 addresses. Section 2 of [RFC7757] discusses why it is desirable to avoid requiring the use of IPv4-translatable IPv6 addresses.
SIIT-DC的设计使得IPv6服务地址不需要是IPv4可翻译IPv6地址。[RFC7757]第2节讨论了为什么需要避免使用IPv4可翻译IPv6地址。
It is, however, quite possible to deploy SIIT-DC in combination with IPv4-translatable IPv6 Service Addresses. The primary benefits in doing so are:
然而，将SIIT-DC与IPv4可翻译IPv6服务地址结合部署是完全可能的。这样做的主要好处是：
o The operator is not required to provision EAMs for IPv4-translatable IPv6 Service Addresses onto the BR/ERs.
o 运营商无需在BR/ERs上为IPv4可翻译IPv6服务地址提供EAMs。
o [RFC6145] translation can be performed in a checksum-neutral manner; cf. Section 4.1 of [RFC6052].
o [RFC6145]可以以校验和中性方式执行转换；参见[RFC6052]第4.1节。
The trade-off is that the IPv4-translatable IPv6 Service Addresses must be configured on the IPv6 nodes, and the applications must be set up to use them -- likely in addition to their primary (non-IPv4-translatable) IPv6 addresses. The IPv4-translatable IPv6 Service Addresses must also be routed from the BR through the IDC's IPv6 network infrastructure to the nodes on which they are assigned. This essentially requires the entire IPv6 infrastructure to be made aware of and handle translated IPv4 traffic as a special case, which significantly increases complexity. As previously described in Section 1.1, avoiding such drawbacks is a design goal of SIIT-DC. The use of IPv4-translatable IPv6 Service Addresses is therefore discouraged.
折衷的办法是，必须在IPv6节点上配置IPv4可翻译IPv6服务地址，并且必须设置应用程序以使用它们——很可能除了它们的主（非IPv4可翻译）IPv6地址之外。IPv4可翻译IPv6服务地址还必须通过IDC的IPv6网络基础设施从BR路由到分配它们的节点。这本质上要求整个IPv6基础设施了解并作为特例处理转换后的IPv4流量，这会显著增加复杂性。如前所述，避免此类缺陷是SIIT-DC的设计目标。因此，不鼓励使用IPv4可翻译IPv6服务地址。
If a Network-Specific Prefix from the provider's own address space is chosen for the translation prefix, as recommended in Section 4.4, care MUST be taken if the translation service is used in front of services that have application-level ACLs that distinguish between the operator's own networks and the Internet at large, as traffic from translated IPv4 end users on the Internet might appear to be originating from the provider's own network. It is therefore important that the translation prefix be treated the same as the Internet at large rather than as a trusted network.
如果按照第4.4节的建议，为翻译前缀选择了提供商自己地址空间中的网络特定前缀，则在具有应用级ACL的服务前面使用翻译服务时必须小心，这些ACL区分运营商自己的网络和整个互联网，因为来自互联网上已翻译IPv4最终用户的流量可能来自提供商自己的网络。因此，重要的是翻译前缀应被视为与整个互联网相同，而不是被视为可信网络。
In order to alleviate this problem, the operator may opt to use a translation prefix that is distinct from and not a subset of the IPv6 prefixes used elsewhere in the network infrastructure.
为了缓解此问题，运营商可以选择使用不同于网络基础设施中其他地方使用的IPv6前缀的子集的翻译前缀。
[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>.
[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>.
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, <http://www.rfc-editor.org/info/rfc6791>.
[RFC6791]Li，X.，Bao，C.，Wing，D.，Vaitianathan，R.，和G.Huston，“ICMPv6数据包的无状态源地址映射”，RFC 6791，DOI 10.17487/RFC6791192012年11月<http://www.rfc-editor.org/info/rfc6791>.
[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>.
[FRAGMENTS] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, M., and T. Taylor, "Why Operators Filter Fragments and What It Implies", Work in Progress, draft-taylor-v6ops-fragdrop-02, December 2013.
[片段]Jaeggli，J.，Colitti，L.，Kumari，W.，Vyncke，E.，Kaeo，M.，和T.Taylor，“为什么操作员过滤片段及其含义”，正在进行的工作，草稿-Taylor-v6ops-fragdrop-022013年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <http://www.rfc-editor.org/info/rfc959>.
[RFC959]Postel，J.和J.Reynolds，“文件传输协议”，STD 9，RFC 959，DOI 10.17487/RFC0959，1985年10月<http://www.rfc-editor.org/info/rfc959>.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，DOI 10.17487/RFC19811996年8月<http://www.rfc-editor.org/info/rfc1981>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，DOI 10.17487/RFC2663，1999年8月<http://www.rfc-editor.org/info/rfc2663>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <http://www.rfc-editor.org/info/rfc2991>.
[RFC2991]Thaler，D.和C.Hopps，“单播和多播下一跳选择中的多路径问题”，RFC 2991，DOI 10.17487/RFC2991，2000年11月<http://www.rfc-editor.org/info/rfc2991>.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, DOI 10.17487/RFC2993, November 2000, <http://www.rfc-editor.org/info/rfc2993>.
[RFC2993]Hain，T，“NAT的建筑含义”，RFC 2993，DOI 10.17487/RFC2993，2000年11月<http://www.rfc-editor.org/info/rfc2993>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<http://www.rfc-editor.org/info/rfc3022>.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, DOI 10.17487/RFC3235, January 2002, <http://www.rfc-editor.org/info/rfc3235>.
[RFC3235]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 3235，DOI 10.17487/RFC3235，2002年1月<http://www.rfc-editor.org/info/rfc3235>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005, <http://www.rfc-editor.org/info/rfc4213>.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，DOI 10.17487/RFC4213，2005年10月<http://www.rfc-editor.org/info/rfc4213>.
[RFC6145bis] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, "IP/ICMP Translation Algorithm (rfc6145bis)", Work in Progress, draft-bao-v6ops-rfc6145bis-05, January 2016.
[RFC6145bis]Bao，C.，Li，X.，Baker，F.，Anderson，T.，和F.Gont，“IP/ICMP翻译算法（RFC6145bis）”，正在进行的工作，草稿-Bao-v6ops-RFC6145bis-05，2016年1月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<http://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <http://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<http://www.rfc-editor.org/info/rfc6147>.
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, DOI 10.17487/RFC6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540]George，W.，Donley，C.，Liljenstolpe，C.，和L.Howard，“所有具有IP能力的节点都需要IPv6支持”，BCP 177，RFC 6540，DOI 10.17487/RFC6540，2012年4月<http://www.rfc-editor.org/info/rfc6540>.
[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>.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, DOI 10.17487/RFC6883, March 2013, <http://www.rfc-editor.org/info/rfc6883>.
[RFC6883]Carpenter，B.和S.Jiang，“互联网内容提供商和应用服务提供商的IPv6指南”，RFC 6883，DOI 10.17487/RFC6883，2013年3月<http://www.rfc-editor.org/info/rfc6883>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013, <http://www.rfc-editor.org/info/rfc6946>.
[RFC6946]Gont，F.，“IPv6原子片段的处理”，RFC 6946，DOI 10.17487/RFC6946，2013年5月<http://www.rfc-editor.org/info/rfc6946>.
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <http://www.rfc-editor.org/info/rfc7020>.
[RFC7020]Housley，R.，Curran，J.，Huston，G.，和D.Conrad，“互联网号码注册系统”，RFC 7020，DOI 10.17487/RFC7020，2013年8月<http://www.rfc-editor.org/info/rfc7020>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7756] Anderson, T. and S. Steffann, "Stateless IP/ICMP Translation for IPv6 Internet Data Center Environments (SIIT-DC): Dual Translation Mode", RFC 7756, DOI 10.17487/RFC7756, February 2016, <http://www.rfc-editor.org/info/rfc7756>.
[RFC7756]Anderson，T.和S.Steffann，“IPv6互联网数据中心环境（SIIT-DC）的无状态IP/ICMP转换：双转换模式”，RFC 7756，DOI 10.17487/RFC7756，2016年2月<http://www.rfc-editor.org/info/rfc7756>.
Figure 4 attempts to "tie it all together" and show a more complete SIIT-DC topology, in order to better demonstrate its advantageous properties discussed in Section 1. These are discussed in more detail below.
图4试图“将其连接在一起”，并展示更完整的SIIT-DC拓扑，以便更好地展示第1节中讨论的优势特性。下文将更详细地讨论这些问题。
/--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | [BGP]
| | |
+-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+ |
| BR #1 | | BR #2 | |
| EAM Table: | | | |
| ========== | | | |
| 192.0.2.1,2001:db8:12:34::1 | | | |
| 192.0.2.2,2001:db8:12:34::2 | | Exactly the same | |
| 192.0.2.3,2001:db8:fe:dc::1 | | configuration as | |
| 192.0.2.4,2001:db8:12:34::4 | | BR #1 | |
| 192.0.2.5,2001:db8:fe:dc::e | | | |
| | | | |
| XLAT Prefix 2001:db8:46::/96 | | | |
| | | | |
+--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+ |
| | |
| <------[ECMP]------> | |
| | |
/-----------------+----------------------+--\ |
| IPv6 IDC network w/ OSPFv3 +------------/
\-+--------------------------------+--------/
| |
| Tenant A's server LAN | Tenant B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www-lb ::1 (IPv6+SIIT-DC)
| |
+-- mta ::2 (IPv6+SIIT-DC) +-- web ::80:01 (IPv6 only)
| | [...]
+-- ftp ::3 (IPv6) +-- web ::80:99 (IPv6 only)
| ::4 (IPv4, via ER) |
| | +----+
+-- app01 ::a:01 (IPv6 only) \---- ::e | ER | --\
| [...] +----+ |
+- app99 ::a:99 (IPv6 only) |
| ftp 192.0.2.5 ---/
+-- db01 ::d:01 (IPv6 only)
| [..]
\-- db99 ::d:99 (IPv6 only)
/--------------------------------\ /---------------\
| IPv4 Internet | | IPv6 Internet |
\-+----------------------------+-/ \--------+------/
| | |
| <----------[BGP]---------> | [BGP]
| | |
+-------<192.0.2.0/24>---------+ +---<192.0.2.0/24>---+ |
| BR #1 | | BR #2 | |
| EAM Table: | | | |
| ========== | | | |
| 192.0.2.1,2001:db8:12:34::1 | | | |
| 192.0.2.2,2001:db8:12:34::2 | | Exactly the same | |
| 192.0.2.3,2001:db8:fe:dc::1 | | configuration as | |
| 192.0.2.4,2001:db8:12:34::4 | | BR #1 | |
| 192.0.2.5,2001:db8:fe:dc::e | | | |
| | | | |
| XLAT Prefix 2001:db8:46::/96 | | | |
| | | | |
+--------<2001:db8:46::/96>----+ +-<2001:db8:46::/96>-+ |
| | |
| <------[ECMP]------> | |
| | |
/-----------------+----------------------+--\ |
| IPv6 IDC network w/ OSPFv3 +------------/
\-+--------------------------------+--------/
| |
| Tenant A's server LAN | Tenant B's server LAN
| 2001:db8:12:34::/64 | 2001:db8:fe:dc::/64
| |
+-- www ::1 (IPv6+SIIT-DC) +-- www-lb ::1 (IPv6+SIIT-DC)
| |
+-- mta ::2 (IPv6+SIIT-DC) +-- web ::80:01 (IPv6 only)
| | [...]
+-- ftp ::3 (IPv6) +-- web ::80:99 (IPv6 only)
| ::4 (IPv4, via ER) |
| | +----+
+-- app01 ::a:01 (IPv6 only) \---- ::e | ER | --\
| [...] +----+ |
+- app99 ::a:99 (IPv6 only) |
| ftp 192.0.2.5 ---/
+-- db01 ::d:01 (IPv6 only)
| [..]
\-- db99 ::d:99 (IPv6 only)
Figure 4: Example SIIT-DC IDC Topology
图4:SIIT-DC IDC拓扑示例
Single-Stack IPv6 Operation: As discussed in Section 1.1, SIIT-DC facilitates an IPv6-only IDC network infrastructure. The only places where IPv4 is absolutely required are between the BRs and the IPv4 Internet and between any ERs and the IPv4-only applications or devices they are serving (illustrated here as the two tenants' FTP servers). The figure also illustrates how SIIT-DC does not interfere with native IPv6; when there is no longer a need to support IPv4 clients, the BRs may be decommissioned without causing any impact to native IPv6 traffic.
单栈IPv6操作：如第1.1节所述，SIIT-DC有助于实现仅限IPv6的IDC网络基础设施。唯一绝对需要IPv4的地方是BRs和IPv4 Internet之间，以及任何ER和它们所服务的仅IPv4的应用程序或设备之间（此处显示为两个租户的FTP服务器）。该图还说明了SIIT-DC如何不干扰本机IPv6；当不再需要支持IPv4客户端时，BRs可能会停用，而不会对本机IPv6流量造成任何影响。
Stateless Operation: As discussed in Section 1.2, SIIT-DC operates in a stateless fashion. In the illustration, both BRs are simultaneously advertising (i.e., anycasting) the IPv4 Service Address Pool and the IPv6 translation prefix, so incoming traffic from the IPv4 Internet may arrive at either of the BRs, while outgoing IPv6 traffic destined for IPv4 endpoints are load balanced between them using Equal-Cost Multipath Routing. No continuous state synchronization between the two BRs occurs. Should one of the BRs fail, the BGP and OSPF protocols will ensure that traffic converges on the remaining BR. Existing sessions will not be disrupted beyond any disruption caused by the BGP/OSPF convergence process itself.
无状态运行：如第1.2节所述，SIIT-DC以无状态方式运行。在图示中，两个br同时播发（即任意广播）IPv4服务地址池和IPv6转换前缀，因此来自IPv4互联网的传入流量可能到达任一br，而发送到IPv4端点的传出IPv6流量使用等成本多路径路由在它们之间进行负载平衡。两个BRs之间不会发生连续状态同步。如果其中一个BR出现故障，BGP和OSPF协议将确保流量在剩余BR上聚合。除了BGP/OSPF融合过程本身造成的任何中断外，现有会话将不会中断。
IPv4 Address Conservation: As discussed in Section 1.3, SIIT-DC conserves the IDC operator's IPv4 address space. Even though the two customers in the example above have several hundred servers, the majority of the servers are not used for running services made available directly from the Internet and therefore do not need to consume IPv4 addresses. The IDC network infrastructure consumes no IPv4 addresses, either. Finally, the IPv4 addresses that are assigned to the SIIT-DC function as IPv4 Service Address Pools may be assigned with 100% efficiency, one address at a time; there is no requirement to assign multiple addresses to a single customer in a contiguous block.
IPv4地址保护：如第1.3节所述，SIIT-DC保护IDC运营商的IPv4地址空间。尽管上面示例中的两个客户拥有数百台服务器，但大多数服务器并不用于运行直接从Internet提供的服务，因此不需要使用IPv4地址。IDC网络基础设施也不使用IPv4地址。最后，分配给SIIT-DC功能作为IPv4服务地址池的IPv4地址可以100%的效率分配，一次分配一个地址；不需要在连续块中为单个客户分配多个地址。
Application Support: As discussed in Section 1.5, as long as the application protocol is translation friendly (illustrated here with HTTP and SMTP), it will work with SIIT-DC without requiring any special adaptation. Furthermore, translation-unfriendly applications (illustrated here with FTP) will also work when located behind an ER [RFC7756]. Tenant A's FTP server illustrates how an ER may be located in the networking stack of a node, while Tenant B's FTP server
应用程序支持：如第1.5节所述，只要应用程序协议是翻译友好的（这里用HTTP和SMTP说明），它将与SIIT-DC一起工作，而不需要任何特殊的修改。此外，当位于ER[RFC7756]后面时，不利于翻译的应用程序（这里用FTP说明）也可以工作。租户A的FTP服务器说明了ER如何位于节点的网络堆栈中，而租户B的FTP服务器
illustrates how the ER may be deployed as a network service. The latter approach enables SIIT-DC to support IPv4-only nodes/devices.
说明了如何将ER部署为网络服务。后一种方法使SIIT-DC能够支持仅IPv4的节点/设备。
Acknowledgements
致谢
The author would like to thank the following individuals for their contributions, suggestions, corrections, and criticisms: Fred Baker, Cameron Byrne, Brian E. Carpenter, Ross Chandler, Tobias Gondrom, Christer Holmberg, Dagfinn Ilmari Mannsaaker, Lars Olafsen, Stig Sandbeck Mathisen, Knut A. Syed, Qin Wu, and Andrew Yourtchenko.
作者要感谢以下个人的贡献、建议、更正和批评：弗雷德·贝克、卡梅隆·伯恩、布赖恩·卡彭特、罗斯·钱德勒、托比亚斯·冈德罗姆、克里斯特·霍姆伯格、达芬·伊尔马里·曼萨克、拉尔斯·奥拉夫森、斯蒂格·桑德贝克·马蒂森、克努特·赛义德、秦武和安德鲁·尤琴科。
Author's Address
作者地址
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