Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6144 Cisco Systems
Category: Informational X. Li
ISSN: 2070-1721 C. Bao
CERNET Center/Tsinghua University
K. Yin
Cisco Systems
April 2011
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 6144 Cisco Systems
Category: Informational X. Li
ISSN: 2070-1721 C. Bao
CERNET Center/Tsinghua University
K. Yin
Cisco Systems
April 2011
Framework for IPv4/IPv6 Translation
IPv4/IPv6转换框架
Abstract
摘要
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.
本说明描述了IPv4/IPv6转换的框架。这是在取代RFC 4966不推荐的网络地址转换-协议转换（NAT-PT）的背景下实现的，并使网络在过渡到IPv6网络时能够以某种合理的方式使IPv4和IPv6共存。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6144.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6144.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7
1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 9
2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 11
2.1. Scenario 1: An IPv6 Network to the IPv4 Internet . . . . . 12
2.2. Scenario 2: The IPv4 Internet to an IPv6 Network . . . . . 13
2.3. Scenario 3: The IPv6 Internet to an IPv4 Network . . . . . 14
2.4. Scenario 4: An IPv4 Network to the IPv6 Internet . . . . . 15
2.5. Scenario 5: An IPv6 Network to an IPv4 Network . . . . . . 16
2.6. Scenario 6: An IPv4 Network to an IPv6 Network . . . . . . 17
2.7. Scenario 7: The IPv6 Internet to the IPv4 Internet . . . . 18
2.8. Scenario 8: The IPv4 Internet to the IPv6 Internet . . . . 19
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Translation Components . . . . . . . . . . . . . . . . . . 19
3.1.1. Address Translation . . . . . . . . . . . . . . . . . 19
3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 21
3.1.3. Maintaining Translation State . . . . . . . . . . . . 21
3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 22
3.1.5. ALGs for Other Applications Layer Protocols . . . . . 22
3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 22
3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 23
3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 24
3.3. Layout of the Related Documents . . . . . . . . . . . . . 26
4. Translation in Operation . . . . . . . . . . . . . . . . . . . 27
5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Why Translation? . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Translation Objectives . . . . . . . . . . . . . . . . . . 7
1.4. Transition Plan . . . . . . . . . . . . . . . . . . . . . 9
2. Scenarios for IPv4/IPv6 Translation . . . . . . . . . . . . . 11
2.1. Scenario 1: An IPv6 Network to the IPv4 Internet . . . . . 12
2.2. Scenario 2: The IPv4 Internet to an IPv6 Network . . . . . 13
2.3. Scenario 3: The IPv6 Internet to an IPv4 Network . . . . . 14
2.4. Scenario 4: An IPv4 Network to the IPv6 Internet . . . . . 15
2.5. Scenario 5: An IPv6 Network to an IPv4 Network . . . . . . 16
2.6. Scenario 6: An IPv4 Network to an IPv6 Network . . . . . . 17
2.7. Scenario 7: The IPv6 Internet to the IPv4 Internet . . . . 18
2.8. Scenario 8: The IPv4 Internet to the IPv6 Internet . . . . 19
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1. Translation Components . . . . . . . . . . . . . . . . . . 19
3.1.1. Address Translation . . . . . . . . . . . . . . . . . 19
3.1.2. IP and ICMP Translation . . . . . . . . . . . . . . . 21
3.1.3. Maintaining Translation State . . . . . . . . . . . . 21
3.1.4. DNS64 and DNS46 . . . . . . . . . . . . . . . . . . . 22
3.1.5. ALGs for Other Applications Layer Protocols . . . . . 22
3.2. Operation Mode for Specific Scenarios . . . . . . . . . . 22
3.2.1. Stateless Translation . . . . . . . . . . . . . . . . 23
3.2.2. Stateful Translation . . . . . . . . . . . . . . . . . 24
3.3. Layout of the Related Documents . . . . . . . . . . . . . 26
4. Translation in Operation . . . . . . . . . . . . . . . . . . . 27
5. Unsolved Problems . . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
8.2. Informative References . . . . . . . . . . . . . . . . . . 29
This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing NAT-PT (Network Address Translation - Protocol Translation) [RFC2766], which was deprecated by [RFC4966], and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6-only network.
本说明描述了IPv4/IPv6转换的框架。这是在取代NAT-PT（网络地址转换-协议转换）[RFC2766]的背景下实现的，后者被[RFC4966]所否决，并使网络能够在过渡到仅IPv6的网络时以某种合理的方式使IPv4和IPv6共存。
NAT-PT was deprecated to inform the community that NAT-PT had operational issues and was not considered a viable medium- or long-term strategy for either coexistence or transition. It wasn't intended to say that IPv4<->IPv6 translation was bad, but the way that NAT-PT did it was bad, and in particular using NAT-PT as a general-purpose solution was bad. As with the deprecation of the RIP routing protocol [RFC1923] at the time the Internet was converting to Classless Inter-Domain Routing (CIDR), the point was to encourage network operators to actually move away from technology with known issues.
不赞成NAT-PT，因为它告诉社区NAT-PT存在运营问题，并且不被认为是共存或过渡的可行中期或长期战略。这并不是说IPv4<->IPv6转换不好，但NAT-PT的转换方式不好，尤其是将NAT-PT用作通用解决方案是不好的。当互联网正在向无类别域间路由（CIDR）转变时，RIP路由协议[RFC1923]被弃用，这一点是为了鼓励网络运营商真正远离存在已知问题的技术。
[RFC4213] describes the IETF's view of the most sensible transition model. The IETF recommends, in short, that network operators (transit providers, service providers, enterprise networks, small and medium businesses, SOHO (Small Office, Home Office) and residential customers, and any other kind of network that may currently be using IPv4) obtain an IPv6 prefix, turn on IPv6 routing within their networks and between themselves and any peer, upstream, or downstream neighbors, enable it on their computers, and use it in normal processing. This should be done while leaving IPv4 stable, until a point is reached that any communication that can be carried out could use either protocol equally well. At that point, the economic justification for running both becomes debatable, and network operators can justifiably turn IPv4 off. This process is comparable to that of [RFC4192], which describes how to renumber a network using the same address family without a flag day. While running stably with the older system, deploy the new. Use the coexistence period to work out such kinks as they arise. When the new is also running stably, shift production to it. When network and economic conditions warrant, remove the old, which is now no longer necessary.
[RFC4213]描述了IETF对最合理过渡模型的看法。简而言之，IETF建议网络运营商（运输提供商、服务提供商、企业网络、中小型企业、SOHO（小型办公室、家庭办公室）和住宅客户，以及目前可能使用IPv4的任何其他类型的网络）获得IPv6前缀，在他们的网络内以及他们与任何对等、上游或下游邻居之间启用IPv6路由，在他们的计算机上启用它，并在正常处理中使用它。这应该在保持IPv4稳定的同时完成，直到达到任何可以执行的通信都可以同样好地使用任一协议为止。在这一点上，运行两者的经济合理性变得有争议，网络运营商可以合理地关闭IPv4。此过程与[RFC4192]的过程类似，后者描述了如何使用相同的地址族对网络重新编号，而无需标记日期。在使用旧系统稳定运行的同时，部署新系统。使用共存周期计算出这些出现的扭结。当新设备稳定运行时，将生产转移到新设备上。当网络和经济条件允许时，拆除旧的，现在不再需要了。
The question arises: what if that is infeasible due to the time available to deploy or other considerations? What if the process of moving a network and its components or customers is starting too late for contract cycles to effect IPv6 turn-up on important parts at a point where it becomes uneconomical to deploy global IPv4 addresses in new services? How does one continue to deploy new services without balkanizing the network?
问题是：如果由于部署时间或其他考虑因素而不可行怎么办？如果移动网络及其组件或客户的过程开始得太晚，以至于合同周期无法在重要部分实现IPv6，而在新服务中部署全局IPv4地址变得不经济，该怎么办？如何在不使网络分裂的情况下继续部署新服务？
This document describes translation as one of the tools networks might use to facilitate coexistence and ultimate transition.
本文将翻译描述为网络可能用于促进共存和最终过渡的工具之一。
Besides dual-stack deployment, there are two fundamental approaches one could take to interworking between IPv4 and IPv6: tunneling and translation. One could -- and in the [6NET] we did -- build an overlay network that tunnels one protocol over the other. Various proposals take that model, including 6to4 [RFC3056], Teredo [RFC4380], Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], and Dual-Stack Lite [DS-LITE]. The advantage of doing so is that the new protocol is enabled to work without disturbing the old protocol, providing connectivity between users of the new protocol. There are two disadvantages to tunneling:
除了双栈部署之外，有两种基本的方法可以实现IPv4和IPv6之间的互通：隧道和转换。我们可以——在[6NET]中——构建一个覆盖网络，将一个协议传输到另一个协议上。各种方案都采用这种模式，包括6to4[RFC3056]、Teredo[RFC4380]、站点内自动隧道寻址协议（ISATAP）[RFC5214]和双栈Lite[DS-Lite]。这样做的好处是，新协议能够在不干扰旧协议的情况下工作，从而提供新协议用户之间的连接。隧道施工有两个缺点：
o Users of the new architecture are unable to use the services of the underlying infrastructure -- it is just bandwidth, and
o 新体系结构的用户无法使用底层基础设施的服务——这只是带宽，而且
o It doesn't enable new protocol users to communicate with old protocol users without dual-stack hosts.
o 它不允许新协议用户在没有双栈主机的情况下与旧协议用户通信。
As noted, in this work, we look at Internet Protocol translation as a transition strategy. [RFC4864] forcefully makes the point that people use Network Address Translators to meet various needs, many of which are met as well by routing or protocol mechanisms that preserve the end-to-end addressability of the Internet. What it did not consider is the case in which there is an ongoing requirement to communicate with IPv4 systems, but, for example, configuring IPv4 routing is not the most desirable strategy in the network operator's view, or is infeasible due to a shortage of global address space. Translation enables the client of a network, whether a transit network, an access network, or an edge network, to access the services of the network and communicate with other network users regardless of their protocol usage -- within limits. Like NAT-PT, IPv4/IPv6 translation under this rubric is not a long-term support strategy, but it is a medium-term coexistence strategy that can be used to facilitate a long-term program of transition.
如前所述，在这项工作中，我们将互联网协议翻译视为一种过渡策略。[RFC4864]有力地指出，人们使用网络地址转换器来满足各种需求，其中许多需求也通过保留互联网端到端寻址能力的路由或协议机制来满足。它没有考虑的是需要与IPv4系统进行通信的情况，但是，例如，配置IPv4路由不是网络运营商的观点中最理想的策略，或者由于全局地址空间的不足而不可行。转换使网络的客户端（无论是传输网络、接入网络还是边缘网络）能够访问网络的服务，并与其他网络用户通信，而不管他们的协议使用情况如何——在限制范围内。与NAT-PT一样，该准则下的IPv4/IPv6转换不是一种长期支持策略，而是一种中期共存策略，可用于促进长期过渡计划。
The following terminology is used in this document and other documents related to it.
本文件及其他相关文件中使用了以下术语。
An IPv4 network: A specific network that has an IPv4-only deployment. This could be an enterprise's IPv4-only network, an ISP's IPv4-only network, or even an IPv4-only host. The IPv4 Internet is the set of all interconnected IPv4 networks.
IPv4网络：具有仅IPv4部署的特定网络。这可能是企业的IPv4专用网络、ISP的IPv4专用网络，甚至是IPv4专用主机。IPv4 Internet是所有互连IPv4网络的集合。
An IPv6 network: A specific network that has an IPv6-only deployment. This could be an enterprise's IPv6-only network, an ISP's IPv6-only network, or even an IPv6-only host. The IPv6 Internet is the set of all interconnected IPv6 networks.
IPv6网络：具有仅IPv6部署的特定网络。这可能是企业的纯IPv6网络、ISP的纯IPv6网络，甚至是纯IPv6主机。IPv6 Internet是所有互连IPv6网络的集合。
DNS46: A DNS translator that translates AAAA record to A record.
DNS46：将AAAA记录转换为记录的DNS转换器。
DNS64: A DNS translator that translates A record to AAAA record.
DNS64：将记录转换为AAAA记录的DNS转换器。
Dual-Stack implementation: A dual-stack implementation, in this context, comprises an IPv4/IPv6-enabled end system stack, applications plus routing in the network. It implies that two application instances are capable of communicating using either IPv4 or IPv6 -- they have stacks, they have addresses, and they have any necessary network support including routing.
双栈实现：在此上下文中，双栈实现包括支持IPv4/IPv6的终端系统栈、应用程序以及网络中的路由。这意味着两个应用程序实例能够使用IPv4或IPv6进行通信——它们具有堆栈、地址，并且具有包括路由在内的任何必要的网络支持。
IPv4-converted addresses: IPv6 addresses used to represent IPv4 nodes in an IPv6 network. They have an explicit mapping relationship to IPv4 addresses. Both stateless and stateful translators use IPv4-converted addresses to represent IPv4 addresses.
IPv4转换地址：用于表示IPv6网络中IPv4节点的IPv6地址。它们与IPv4地址有明确的映射关系。无状态和有状态转换器都使用IPv4转换的地址来表示IPv4地址。
IPv4-only: An IPv4-only implementation, in this context, comprises an IPv4-enabled end system stack, applications directly or indirectly using that IPv4 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv4, but not IPv6 -- they have an IPv4 stack, addresses, and network support including IPv4 routing and potentially IPv4/IPv4 translation, but some element is missing that prevents communication with IPv6 hosts.
仅IPv4：在此上下文中，仅IPv4实现包括启用IPv4的终端系统堆栈、直接或间接使用该IPv4堆栈的应用程序，以及网络中的路由。这意味着两个应用程序实例能够使用IPv4进行通信，但不能使用IPv6——它们具有IPv4堆栈、地址和网络支持，包括IPv4路由和可能的IPv4/IPv4转换，但缺少阻止与IPv6主机通信的某些元素。
IPv4-translatable addresses: IPv6 addresses to be assigned to IPv6 nodes for use with stateless translation. They have an explicit mapping relationship to IPv4 addresses. A stateless translator uses the corresponding IPv4 addresses to represent the IPv6 addresses. A stateful translator does not use this kind of addresses, since IPv6 hosts are represented by the IPv4 address pool in the translator via dynamic state.
IPv4可翻译地址：分配给IPv6节点的IPv6地址，用于无状态转换。它们与IPv4地址有明确的映射关系。无状态转换器使用相应的IPv4地址来表示IPv6地址。有状态转换器不使用此类地址，因为IPv6主机通过动态状态由转换器中的IPv4地址池表示。
IPv6-only: An IPv6-only implementation, in this context, comprises an IPv6-enabled end system stack, applications directly or indirectly using that IPv6 stack, plus routing in the network. It implies that two application instances are capable of communicating using IPv6, but not IPv4 -- they have an IPv6 stack, addresses, and network support including routing in IPv6, but some element is missing that prevents communication with IPv4 hosts.
仅限IPv6：在此上下文中，仅限IPv6的实现包括启用IPv6的终端系统堆栈、直接或间接使用该IPv6堆栈的应用程序，以及网络中的路由。这意味着两个应用程序实例能够使用IPv6进行通信，但不能使用IPv4——它们具有IPv6堆栈、地址和网络支持，包括IPv6中的路由，但缺少阻止与IPv4主机通信的某些元素。
Network-Specific Prefix (NSP): From an IPv6 prefix assigned to a network operator, the operator chooses a longer prefix for use by the operator's translator(s). Hence, a given IPv4 address would have different IPv6 representations in different networks that use different network-specific prefixes. A network-specific prefix is also known as a Local Internet Registry (LIR) prefix.
网络特定前缀（NSP）：从分配给网络运营商的IPv6前缀中，运营商选择更长的前缀供运营商的翻译器使用。因此，给定的IPv4地址在使用不同网络特定前缀的不同网络中具有不同的IPv6表示。特定于网络的前缀也称为本地Internet注册表（LIR）前缀。
State: "State" refers to dynamic information that is stored in a network element. For example, if two systems are communicating using a TCP connection, each stores information about the connection, which is called "connection state". In this context, the term refers to dynamic correlations between IP addresses on either side of a translator, or {IP address, transport protocol, transport port number} tuples on either side of the translator. Of stateful algorithms, there are at least two major flavors depending on the kind of state they maintain:
状态：“状态”是指存储在网元中的动态信息。例如，如果两个系统使用TCP连接进行通信，则每个系统都存储有关连接的信息，称为“连接状态”。在此上下文中，该术语指转换器任一侧的IP地址或转换器任一侧的{IP地址、传输协议、传输端口号}元组之间的动态关联。在有状态算法中，根据它们维护的状态类型，至少有两种主要风格：
Hidden state: the existence of this state is unknown outside the network element that contains it.
隐藏状态：此状态的存在在包含它的网络元素之外是未知的。
Known state: the existence of this state is known by other network elements.
已知状态：该状态的存在为其他网络元素所知。
Stateful Translation: A translation algorithm may be said to "require state in a network element" or be "stateful" if the transmission or reception of a packet creates or modifies a data structure in the relevant network element.
有状态翻译：如果数据包的传输或接收创建或修改相关网元中的数据结构，则翻译算法可以被称为“需要网元中的状态”或“有状态”。
Stateful Translator: A translator that uses stateful translation for either the source or destination address. A stateful translator typically also uses a stateless translation algorithm for the other type of address.
有状态转换器：对源地址或目标地址使用有状态转换的转换器。有状态转换器通常还对其他类型的地址使用无状态转换算法。
Stateless Translation: A translation algorithm that is not "stateful" is "stateless". It derives its needed information algorithmically from the messages it is translating and from pre-configured information.
无状态翻译：非“有状态”的翻译算法是“无状态”的。它通过算法从正在翻译的消息和预先配置的信息中获取所需的信息。
Stateless Translator: A translator that uses only stateless translation for both destination address and source address.
无状态翻译器：只对目标地址和源地址使用无状态翻译的翻译器。
Well-Known Prefix (WKP): The IPv6 prefix defined in [RFC6052] for use in an algorithmic mapping.
众所周知的前缀（WKP）：在[RFC6052]中定义的IPv6前缀，用于算法映射。
In any translation model, there is a question of objectives. Ideally, one would like to make any system and any application running on it able to "talk with" -- exchange datagrams supporting applications with -- any other system running the same application regardless of whether they have an IPv4 stack and connectivity or IPv6 stack and connectivity. That was the model for NAT-PT, and the things it necessitated led to scaling and operational difficulties [RFC4966].
在任何翻译模式中，都存在目标问题。理想情况下，我们希望任何系统和运行在其上的任何应用程序都能够“与”进行“对话”——与支持应用程序的任何其他系统交换数据报——运行同一应用程序的任何其他系统，无论它们是否具有IPv4堆栈和连接性或IPv6堆栈和连接性。这就是NAT-PT的模型，它所需要的东西导致了扩展和操作困难[RFC4966]。
So the question comes back to what different kinds of connectivity can be easily supported, what kinds are harder, and what technologies are needed to at least pick the low-hanging fruit. We observe that applications today fall into two main categories:
因此，问题又回到了什么样的连接可以容易地得到支持，什么样的连接更难，以及至少需要什么技术才能摘下低垂的果实。我们观察到，目前的申请分为两大类：
Client/Server Application: Per whatis.com, "'Client/server' describes the relationship between two computer programs in which one program, the client, makes a service request from another program, the server, which fulfills the request." In networking, the behavior of the applications is that connections are initiated from client software and systems to server software and systems. Examples include mail handling between an end user and his mail system (POP3, IMAP, and MUA->MTA SMTP), FTP, the web, and DNS name resolution.
客户机/服务器应用程序：根据whatis.com，“客户机/服务器”描述两个计算机程序之间的关系，其中一个程序（客户机）从另一个程序（服务器）发出服务请求，服务器完成请求。”在网络中，应用程序的行为是启动从客户端软件和系统到服务器软件和系统的连接。示例包括最终用户与其邮件系统之间的邮件处理（POP3、IMAP和MUA->MTA SMTP）、FTP、web和DNS名称解析。
Peer-to-Peer (P2P) Application: A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. These in turn fall broadly into two categories:
对等（P2P）应用程序：P2P应用程序是一种应用程序，它使用相同的端点启动到对等主机的传出会话，以及接受来自对等主机的传入会话。这些又大致分为两类：
Peer-to-peer infrastructure applications: Examples of "infrastructure applications" include SMTP between MTAs, Network News, and SIP. Any MTA might open an SMTP session with any other at any time; any SIP Proxy might similarly connect with any other SIP Proxy. An important characteristic of these applications is that they use ephemeral sessions -- they open sessions when they are needed and close them when they are done.
对等基础设施应用程序：“基础设施应用程序”的示例包括MTA、网络新闻和SIP之间的SMTP。任何MTA都可能在任何时候与任何其他MTA打开SMTP会话；任何SIP代理都可以类似地与任何其他SIP代理连接。这些应用程序的一个重要特征是它们使用短暂的会话——需要时打开会话，完成时关闭会话。
Peer-to-peer file exchange applications: Examples of these include Limewire, BitTorrent, and UTorrent. These are applications that open some sessions between systems and leave them open for long periods of time, and where ephemeral sessions are important, these applications are able to learn about the reliability of peers from history or by reputation. They use the long-term sessions to map content availability.
对等文件交换应用程序：例如Limewire、BitTorrent和UTorrent。这些应用程序在系统之间打开一些会话，并让它们保持长时间的打开状态，在短暂会话很重要的情况下，这些应用程序能够从历史或声誉中了解对等点的可靠性。他们使用长期会话来映射内容可用性。
Short-term sessions are used to exchange content. They tend to prefer to ask for content from peers that they find reliable and available.
短期会议用于交换内容。他们倾向于向同行索取他们认为可靠且可用的内容。
If the goal is the ability to open connections between systems, then one must ask who opens connections.
如果目标是能够打开系统之间的连接，那么必须询问是谁打开了连接。
o We need a technology that will enable systems that act as clients to be able to open sessions with other systems that act as servers, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Ideally, this is stateless; especially in a carrier infrastructure, the preponderance of accesses will be to servers, and this optimizes access to them. However, a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed.
o 我们需要一种技术，使充当客户端的系统能够打开与充当服务器的其他系统的会话，无论是在IPv6->IPv4方向还是IPv4->IPv6方向。理想情况下，这是无状态的；特别是在运营商基础设施中，访问的优势将是服务器，这将优化对服务器的访问。然而，如果复杂性最小化，并且无法构造无状态算法，则可以接受有状态算法。
o We also need a technology that will allow peers to connect with each other, whether in the IPv6->IPv4 direction or the IPv4->IPv6 direction. Again, it would be ideal if this was stateless, but a stateful algorithm is acceptable if the complexity is minimized and a stateless algorithm cannot be constructed.
o 我们还需要一种允许对等方相互连接的技术，无论是在IPv6->IPv4方向还是IPv4->IPv6方向。同样，如果这是无状态的，这将是理想的，但是如果复杂性最小化并且无法构造无状态算法，则可以接受有状态算法。
o In some situations, hosts are purely clients. In those situations, we do not need an algorithm to enable connections to those hosts.
o 在某些情况下，主机纯粹是客户机。在这些情况下，我们不需要算法来启用到这些主机的连接。
The complexity arguments bring us in the direction of hidden state: if state must be shared between the application and the translator or between translation components, complexity and deployment issues are greatly magnified. The objective of the translators is to avoid, as much as possible, any software changes in hosts or applications necessary to support translation.
复杂性参数将我们引向隐藏状态的方向：如果状态必须在应用程序和转换器之间或在转换组件之间共享，那么复杂性和部署问题将被大大放大。翻译人员的目标是尽可能避免支持翻译所需的主机或应用程序中的任何软件更改。
NAT-PT is an example of a facility with known state -- at least two software components (the data-plane translator and the DNS Application Layer Gateway, which may be implemented in the same or different systems) share and must coordinate translation state. A typical IPv4/IPv4 NAT implements an algorithm with hidden state. Obviously, stateless translation requires less computational overhead than stateful translation, and less memory to maintain the state, because the translation tables and their associated methods and processes exist in a stateful algorithm and don't exist in a stateless one.
NAT-PT是具有已知状态的设施的一个示例——至少两个软件组件（数据平面转换器和DNS应用层网关，可以在相同或不同的系统中实现）共享并必须协调转换状态。典型的IPv4/IPv4 NAT使用隐藏状态实现算法。显然，无状态转换比有状态转换需要更少的计算开销，维护状态需要更少的内存，因为转换表及其关联的方法和过程存在于有状态算法中，而不存在于无状态算法中。
While the design of IPv4 made it impossible for IPv6 to be compatible on the wire, the designers intended that it would coexist with IPv4 during a period of transition. The primary mode of coexistence was dual-stack operation -- routers would be dual-stacked so that the network could carry both address families, and IPv6-capable hosts could be dual-stack to maintain access to IPv4-only partners. The goal was that the preponderance of hosts and routers in the Internet would be IPv6-capable long before IPv4 address space allocation was completed. At this time, it appears the exhaustion of IPv4 address space will occur before significant IPv6 adoption.
虽然IPv4的设计使得IPv6不可能在网络上兼容，但设计者希望它在过渡期间与IPv4共存。共存的主要模式是双栈操作——路由器将是双栈的，这样网络可以同时承载两个地址族，支持IPv6的主机可以是双栈的，以保持对仅IPv4的合作伙伴的访问。其目标是，在IPv4地址空间分配完成之前，互联网上主机和路由器的优势将能够支持IPv6。此时，IPv4地址空间的耗尽似乎会在IPv6被大量采用之前发生。
Curran's "A Transition Plan" [RFC5211] proposes a three-phase progression:
科伦的“过渡计划”[RFC5211]提出了三个阶段的进展：
Preparation Phase (current): characterized by pilot use of IPv6, primarily through transition mechanisms defined in [RFC4213], and planning activities.
准备阶段（当前）：主要通过[RFC4213]中定义的过渡机制和规划活动，以IPv6的试点使用为特征。
Transition Phase (2010 through 2011): characterized by general availability of IPv6 in provider networks, which should be native IPv6; organizations should provide IPv6 connectivity for their Internet-facing servers, but should still provide IPv4-based services via a separate service name.
过渡阶段（2010年至2011年）：其特点是IPv6在提供商网络中普遍可用，应为本机IPv6；组织应为其面向Internet的服务器提供IPv6连接，但仍应通过单独的服务名称提供基于IPv4的服务。
Post-Transition Phase (2012 and beyond): characterized by a preponderance of IPv6-based services and diminishing support for IPv4-based services.
过渡后阶段（2012年及以后）：以基于IPv6的服务占优势和对基于IPv4的服务的支持减少为特征。
Various timelines have been discussed, but most will agree with the pattern of the above three transition phases, also known as an "S" curve transition pattern.
已经讨论了各种时间线，但大多数都同意上述三个过渡阶段的模式，也被称为“S”曲线过渡模式。
In each of these phases, the coexistence problem and solution space have a different focus:
在每一个阶段中，共存问题和解决方案空间都有不同的重点：
Preparation Phase: Coexistence tools are needed to facilitate early adopters by removing impediments to IPv6 deployment and to assure that nothing is lost by adopting IPv6 -- in particular, that the IPv6 adopter has unfettered access to the global IPv4 Internet regardless of whether they have a global IPv4 address (or any IPv4 address or stack at all). While it might appear reasonable for the cost and operational burden to be borne by the early adopter, the shared goal of promoting IPv6 adoption would argue against that model. Additionally, current IPv4 users should not be forced
准备阶段：需要共存工具，通过消除IPv6部署的障碍来帮助早期采用者，并确保采用IPv6不会造成任何损失——特别是，IPv6采用者可以不受限制地访问全局IPv4 Internet，而不管他们是否具有全局IPv4地址（或任何IPv4地址或协议栈）。虽然早期采用者承担的成本和运营负担似乎是合理的，但促进IPv6采用的共同目标将与该模式相矛盾。此外，不应强迫当前IPv4用户
to retire or upgrade their equipment, and the burden remains on service providers to carry and route native IPv4. This is known as the early stage of the "S" curve.
使其设备退役或升级，而承载和路由本机IPv4的负担仍由服务提供商承担。这被称为“S”曲线的早期阶段。
Transition Phase: During the middle stage of the "S" curve, while IPv6 adoption can be expected to accelerate, there will still be a significant portion of the Internet operating IPv4-only or preferring IPv4. During this phase, the norm shifts from IPv4 to IPv6, and coexistence tools evolve to ensure interoperability between domains that may be restricted to IPv4 or IPv6.
过渡阶段：在“S”曲线的中间阶段，虽然IPv6的采用有望加快，但仍有很大一部分互联网只运行IPv4或更倾向于使用IPv4。在此阶段，规范从IPv4转移到IPv6，共存工具不断发展，以确保可能仅限于IPv4或IPv6的域之间的互操作性。
Post-Transition Phase: This is the last stage of the "S" curve. In this phase, IPv6 is ubiquitous and the burden of maintaining interoperability shifts to those who choose to maintain IPv4-only systems. While these systems should be allowed to live out their economic life cycles, the IPv4-only legacy users at the edges should bear the cost of coexistence tools, and at some point service provider networks should not be expected to carry and route native IPv4 traffic.
过渡后阶段：这是“S”曲线的最后阶段。在这个阶段，IPv6无处不在，维护互操作性的负担转移到那些选择只维护IPv4系统的人身上。虽然应该允许这些系统度过其经济生命周期，但边缘仅IPv4的遗留用户应该承担共存工具的成本，并且在某些情况下，服务提供商网络不应该承载和路由本机IPv4流量。
The choice between the terms "transition" versus "coexistence" has engendered long philosophical debate. "Transition" carries the sense that one is going somewhere, while "coexistence" seems more like one is sitting somewhere. Historically with the IETF, "transition" has been the term of choice [RFC4213] [RFC5211], and the tools for interoperability have been called "transition mechanisms". There is some perception or conventional wisdom that adoption of IPv6 is being impeded by the deficiency of tools to facilitate interoperability of nodes or networks that are constrained (in some way, fully or partially) from full operation in one of the address families. In addition, it is apparent that transition will involve a period of coexistence; the only real question is how long that will last.
“过渡”与“共存”这两个术语之间的选择引发了长期的哲学争论。“过渡”意味着一个人要去某个地方，而“共存”更像是坐在某个地方。从历史上看，在IETF中，“过渡”一直是首选术语[RFC4213][RFC5211]，互操作性工具被称为“过渡机制”。有一种看法或传统观点认为，IPv6的采用正受到阻碍，原因是缺乏促进节点或网络互操作性的工具，而这些节点或网络在某个地址系列中（以某种方式，完全或部分）无法完全运行。此外，很明显，过渡将涉及一段共存时期；唯一真正的问题是这将持续多久。
Thus, coexistence is an integral part of the transition plan, not in conflict with it, but there will be a balancing act. It starts out being a way for early IPv6 adopters to easily exploit the bigger IPv4 Internet, and ends up being a way for late/never adopters to hang on with IPv4 (at their own expense, with minimal impact or visibility to the Internet). One way to look at solutions is that cost incentives (both monetary cost and the operational overhead for the end user) should encourage IPv6 and discourage IPv4. That way natural market forces will keep the transition moving -- especially as the legacy IPv4-only stuff ages out of use. The end goal should not be to eliminate IPv4 by fiat, but rather render it redundant through ubiquitous IPv6 deployment. IPv4 may never go away completely, but rational plans should move the costs of maintaining IPv4 to those who insist on using it after wide adoption of IPv6.
因此，共存是过渡计划不可分割的一部分，与过渡计划没有冲突，但会有一种平衡行动。它一开始是早期IPv6采用者轻松利用更大的IPv4互联网的一种方式，最后是后来/从未采用IPv4的人继续使用IPv4的一种方式（自费，对互联网的影响或可见性最小）。一种看待解决方案的方法是，成本激励（包括最终用户的货币成本和运营开销）应该鼓励IPv6，而不鼓励IPv4。这样，自然的市场力量将继续推动这一转变——特别是在传统的只支持IPv4的东西已经过时的情况下。最终目标不应该是通过菲亚特消除IPv4，而是通过无处不在的IPv6部署使其成为冗余。IPv4可能永远不会完全消失，但理性的计划应该将维护IPv4的成本转移到那些在IPv6广泛采用后坚持使用IPv4的人身上。
It is important to note that the choice of translation solution and the assumptions about the network where they are used impact the consequences. A translator for the general case has a number of issues that a translator for a more specific situation may not have at all.
需要注意的是，翻译解决方案的选择和对使用网络的假设会影响结果。一般情况下的翻译人员有许多问题，而更具体情况下的翻译人员可能根本没有这些问题。
The intention of this document is to focus on translation solutions under all kinds of situations. All IPv4/IPv6 translation cases can be easily described in terms of "interoperation between a set of systems (applications) that only communicate using IPv4 and a set of systems that only communicate using IPv6", but the differences at a detailed level make them interesting.
本文件的目的是关注各种情况下的翻译解决方案。所有IPv4/IPv6转换案例都可以用“仅使用IPv4进行通信的一组系统（应用程序）与仅使用IPv6进行通信的一组系统（应用程序）之间的互操作”来轻松描述，但详细程度上的差异使它们变得有趣。
Based on the transition plan described in Section 1.4, there are four types of IPv4/IPv6 translation cases:
根据第1.4节中描述的过渡计划，有四种类型的IPv4/IPv6转换案例：
a. Interoperation between an IPv6 network and the IPv4 Internet
a. IPv6网络和IPv4 Internet之间的互操作
b. Interoperation between an IPv4 network and the IPv6 Internet
b. IPv4网络和IPv6 Internet之间的互操作
c. Interoperation between an IPv6 network and an IPv4 network
c. IPv6网络和IPv4网络之间的互操作
d. Interoperation between the IPv6 Internet and the IPv4 Internet
d. IPv6 Internet和IPv4 Internet之间的互操作
Each one of the above can be divided into two scenarios, depending on whether the IPv6 side or the IPv4 side initiates communication, so there are a total of eight scenarios.
根据IPv6端还是IPv4端发起通信，上述每种情况可分为两种情况，因此总共有八种情况。
Scenario 1: an IPv6 network to the IPv4 Internet
场景1：连接到IPv4 Internet的IPv6网络
Scenario 2: the IPv4 Internet to an IPv6 network
场景2：将IPv4 Internet连接到IPv6网络
Scenario 3: the IPv6 Internet to an IPv4 network
场景3：将IPv6 Internet连接到IPv4网络
Scenario 4: an IPv4 network to the IPv6 Internet
场景4：将IPv4网络连接到IPv6 Internet
Scenario 5: an IPv6 network to an IPv4 network
场景5：IPv6网络到IPv4网络
Scenario 6: an IPv4 network to an IPv6 network
场景6：IPv4网络到IPv6网络
Scenario 7: the IPv6 Internet to the IPv4 Internet
场景7：IPv6互联网到IPv4互联网
Scenario 8: the IPv4 Internet to the IPv6 Internet
场景8：IPv4互联网到IPv6互联网
We will discuss each scenario in detail in the next section.
我们将在下一节详细讨论每个场景。
Due to the lack of IPv4 addresses or due to other technical or economical constraints, the network is IPv6-only, but the hosts in the network require communicating with the global IPv4 Internet.
由于缺少IPv4地址或其他技术或经济限制，网络仅为IPv6，但网络中的主机需要与全局IPv4 Internet通信。
This is the typical scenario for what we sometimes call "green-field" deployments. One example is an enterprise network that wishes to operate only IPv6 for operational simplicity, but still wishes to reach the content in the IPv4 Internet. The green-field enterprise scenario is different from an ISP's network in the sense that there is only one place that the enterprise can easily modify: the border between its network and the IPv4 Internet. Obviously, the IPv4 Internet operates the way it already does. But, in addition, the hosts in the enterprise network are commercially available devices, personal computers with existing operating systems. This restriction drives us to a "one box" type of solution, where IPv6 can be translated into IPv4 to reach the public Internet.
这是我们有时称之为“绿地”部署的典型场景。一个例子是一个企业网络，它希望只运行IPv6以简化操作，但仍然希望访问IPv4 Internet中的内容。绿地企业场景不同于ISP的网络，因为只有一个地方企业可以轻松修改：其网络和IPv4 Internet之间的边界。显然，IPv4互联网的运行方式与以往相同。但是，除此之外，企业网络中的主机是商用设备，即具有现有操作系统的个人计算机。这一限制促使我们采用“一箱式”解决方案，在这种解决方案中，IPv6可以转换为IPv4以到达公共互联网。
Other cases that have been mentioned include wireless ISP networks and sensor networks. These bear a striking resemblance to this scenario as well, if one considers the ISP network to simply be a very special kind of enterprise network.
提到的其他案例包括无线ISP网络和传感器网络。如果你认为ISP网络仅仅是一种非常特殊的企业网络，那么它们也与这种情况有着惊人的相似性。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 1: Scenario 1
图1：场景1
Both stateless and stateful solutions can support Scenario 1.
无状态和有状态解决方案都可以支持场景1。
When the enterprise networks or ISP networks adopt Scenario 1, the IPv6-only users will not only want to access servers on the IPv4 Internet but also will want to setup their own servers in the network that are accessible by the users on the IPv4 Internet, since the majority of the Internet users are still in the IPv4 Internet. Thus, with a translation solution for this scenario, the benefits would be clear. Not only could servers move directly to IPv6 without trudging through a difficult transition period, but they could do so without risk of losing connectivity with the IPv4-only Internet.
当企业网络或ISP网络采用场景1时，仅限IPv6的用户不仅希望访问IPv4 Internet上的服务器，还希望在IPv4 Internet上的用户可以访问的网络中设置自己的服务器，因为大多数Internet用户仍在IPv4 Internet上。因此，在这种情况下使用翻译解决方案，好处是显而易见的。服务器不仅可以直接迁移到IPv6，而不必艰难地度过一个艰难的过渡期，而且还可以避免失去与仅IPv4的互联网的连接。
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
--------
// \\ ----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \\ //
\\ // ----------
--------
====>
Figure 2: Scenario 2
图2：场景2
In general, this scenario presents a hard case for translation. Stateful translation such as NAT-PT [RFC2766] can be used in this scenario, but it requires a tightly coupled DNS Application Level Gateway (ALG) in the translator, and this technique was deprecated by the IETF [RFC4966].
一般来说，这种情况下很难进行翻译。这种情况下可以使用NAT-PT[RFC2766]等有状态转换，但它需要在转换器中使用紧密耦合的DNS应用程序级网关（ALG），IETF[RFC4966]不赞成这种技术。
The stateless translation solution in Scenario 1 can also work in Scenario 2, since it can support IPv4-initiated communications with a subset of the IPv6 addresses (IPv4-translatable addresses) in an IPv6 network.
场景1中的无状态转换解决方案也可以在场景2中工作，因为它可以支持与IPv6网络中的IPv6地址子集（IPv4可翻译地址）进行IPv4启动的通信。
There is a requirement for a legacy IPv4 network to provide services to IPv6 hosts.
传统IPv4网络需要向IPv6主机提供服务。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 3: Scenario 3
图3：场景3
Stateless translation will not work for this scenario, because an IPv4 network needs to communicate with all of the IPv6 Internet, not just a small subset, and stateless can only support a subset of the IPv6 addresses. However, IPv6-initiated communication can be achieved through stateful translation. In this case, a Network Specific Prefix assigned to the translator will give the hosts unique IPv4-converted IPv6 addresses, no matter whether the legacy IPv4 network uses public IPv4 addresses or [RFC1918] addresses. Also there is no need to synthesize AAAA from A records, since static AAAA records can be put in the regular DNS to represent these IPv4-only hosts as discussed in Section 7.3 of [RFC6147].
无状态转换在这种情况下不起作用，因为IPv4网络需要与所有IPv6 Internet通信，而不仅仅是一个小子集，无状态转换只能支持IPv6地址的一个子集。然而，IPv6发起的通信可以通过有状态转换来实现。在这种情况下，分配给转换器的特定于网络的前缀将为主机提供唯一的IPv4转换IPv6地址，无论传统IPv4网络使用公共IPv4地址还是[RFC1918]地址。此外，无需从记录合成AAAA，因为静态AAAA记录可以放在常规DNS中，以表示这些仅IPv4主机，如[RFC6147]第7.3节所述。
Due to technical or economical constraints, the network is IPv4-only, and IPv4-only hosts (applications) may require communicating with the global IPv6 Internet.
由于技术或经济上的限制，网络仅限于IPv4，并且仅限于IPv4的主机（应用程序）可能需要与全球IPv6 Internet通信。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 | XLAT: IPv4/IPv6
| Network +----+ Internet | Translator
| |DNS | | DNS: DNS46
\ +----+ /
\\ // \ /
--------- \\ //
----------
=====>
Figure 4: Scenario 4
图4：场景4
In general, this scenario presents a hard case for translation. Stateful translation such as NAT-PT [RFC2766] can be used in this scenario, but it requires a tightly coupled DNS ALG in the translator, and this technique was deprecated by the IETF [RFC4966].
一般来说，这种情况下很难进行翻译。这种情况下可以使用NAT-PT[RFC2766]等有状态转换，但它需要在转换器中使用紧密耦合的DNS ALG，IETF[RFC4966]不赞成这种技术。
From the transition phase discussion in Section 1.4, this scenario will probably only occur when we are well past the early stage of the "S" curve, and the IPv4/IPv6 transition has already moved to the right direction. Therefore, in-network translation is not considered viable for this scenario, and other techniques should be considered.
从第1.4节中的过渡阶段讨论来看，只有当我们远远超过“S”曲线的早期阶段，并且IPv4/IPv6过渡已经朝着正确的方向发展时，这种情况才可能发生。因此，在这种情况下，网络翻译是不可行的，应该考虑其他技术。
In this scenario, both an IPv4 network and an IPv6 network are within the same organization.
在此场景中，IPv4网络和IPv6网络都位于同一组织内。
The IPv4 addresses used are either public IPv4 addresses or [RFC1918] addresses. The IPv6 addresses used are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193].
使用的IPv4地址为公共IPv4地址或[RFC1918]地址。使用的IPv6地址是公共IPv6地址或ULA（唯一本地地址）[RFC4193]。
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
--------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 5: Scenario 5
图5：场景5
The translation requirement from this scenario has no significant difference from Scenario 1, so both the stateful and stateless translation schemes discussed in Section 2.1 apply here.
此场景的翻译需求与场景1没有显著差异，因此第2.1节中讨论的有状态和无状态翻译方案都适用于此。
This is another scenario when both an IPv4 network and an IPv6 network are within the same organization.
当IPv4网络和IPv6网络位于同一组织内时，这是另一种情况。
The IPv4 addresses used are either public IPv4 addresses or [RFC1918] addresses. The IPv6 addresses used are either public IPv6 addresses or ULAs (Unique Local Addresses) [RFC4193].
使用的IPv4地址为公共IPv4地址或[RFC1918]地址。使用的IPv6地址是公共IPv6地址或ULA（唯一本地地址）[RFC4193]。
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\\ // \\ //
-------- ---------
====>
Figure 6: Scenario 6
图6：场景6
The translation requirement from this scenario has no significant difference from Scenario 2, so the translation scheme discussed in Section 2.2 applies here.
该场景的翻译需求与场景2没有显著差异，因此第2.2节中讨论的翻译方案适用于此处。
This seems the ideal case for in-network translation technology, where any IPv6-only host or application on the global Internet can initiate communication with any IPv4-only host or application on the global Internet.
这似乎是网络内转换技术的理想情况，全球互联网上的任何纯IPv6主机或应用程序都可以启动与全球互联网上任何纯IPv4主机或应用程序的通信。
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \ /
\\ // \\ //
-------- ---------
<====
Figure 7: Scenario 7
图7：场景7
Due to the huge difference in size between the address spaces of the IPv4 Internet and the IPv6 Internet, there is no viable translation technique to handle unlimited IPv6 address translation.
由于IPv4 Internet和IPv6 Internet的地址空间在大小上存在巨大差异，因此没有可行的转换技术来处理无限的IPv6地址转换。
If we ever run into this scenario, fortunately, the IPv4/IPv6 transition has already passed the early stage of the "S" curve. Therefore, there is no obvious business reason to demand a translation solution as the only transition strategy.
如果我们遇到这种情况，幸运的是，IPv4/IPv6过渡已经过了“S”曲线的早期阶段。因此，没有明显的商业理由要求将翻译解决方案作为唯一的过渡策略。
This case is very similar to Scenario 7. The analysis and conclusions for Scenario 7 also apply for this scenario.
这种情况与场景7非常相似。场景7的分析和结论也适用于该场景。
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
-------- ---------
// \\ // \\
/ \ / \
/ +----+ \
| |XLAT| |
| The IPv4 +----+ The IPv6 |
| Internet +----+ Internet | XLAT: IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS46
\ / \ /
\\ // \\ //
-------- ---------
====>
Figure 8: Scenario 8
图8：场景8
Having laid out the preferred transition model and the options for implementing it (Section 1.1), defined terms (Section 1.2), considered the requirements (Section 1.3), considered the transition model (Section 1.4), and considered the kinds of scenarios the facility would support (Section 2), we now turn to a framework for IPv4/IPv6 translation. The framework contains the following components:
在列出了首选转换模型和实现该模型的选项（第1.1节）、定义术语（第1.2节）、考虑了需求（第1.3节）、考虑了转换模型（第1.4节）以及设施将支持的场景类型（第2节）之后，我们现在转向IPv4/IPv6转换框架。该框架包含以下组件：
o Address translation
o 地址转换
o IP and ICMP translation
o IP和ICMP翻译
o Maintaining translation state
o 保持翻译状态
o DNS64 and DNS46
o DNS64和DNS46
o ALGs for other application-layer protocols (e.g., FTP)
o 其他应用层协议（如FTP）的ALG
When IPv6/IPv4 translation is performed, we should specify how an individual IPv6 address is translated to a corresponding IPv4 address, and vice versa, in cases where an algorithmic mapping is
在执行IPv6/IPv4转换时，我们应该指定如何将单个IPv6地址转换为相应的IPv4地址，反之亦然，如果需要算法映射
used. This includes the choice of IPv6 prefix and the choice of method by which the remainder of the IPv6 address is derived from an IPv4 address [RFC6052]. The usages of the IPv6 addresses are shown in the following figures.
习惯于这包括IPv6前缀的选择以及IPv6地址剩余部分从IPv4地址派生的方法的选择[RFC6052]。IPv6地址的用法如下图所示。
------------
H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4-
(IPv4 ------------ translatable address
address) \
--------------
|Stateless XLAT|
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4-
----------- translatable address)
------------
H4 - (IPv4 network) - IPv4 address corresponding to H6's IPv4-
(IPv4 ------------ translatable address
address) \
--------------
|Stateless XLAT|
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (IPv4-
----------- translatable address)
Figure 9: IPv6 Address Representation for Stateless Translation
图9：无状态转换的IPv6地址表示
------------
H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool
(IPv4 ------------
address) \
--------------
|Stateful XLAT |
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address)
-----------
------------
H4 - (IPv4 network) - IPv4 address in the translator's IPv4 pool
(IPv4 ------------
address) \
--------------
|Stateful XLAT |
--------------
\
-----------
IPv4-converted address of H4 - (IPv6 network) - H6 (any IPv6 address)
-----------
Figure 10: IPv6 Address Representation for Stateful Translation
图10：有状态转换的IPv6地址表示
For both stateless and stateful translation, an algorithmic mapping table is used to translate IPv6 destination addresses (IPv4-converted addresses) to IPv4 destination addresses in the IPv6-to-IPv4 direction and translate IPv4 source addresses to IPv6 source addresses (IPv4-converted addresses) in the IPv4-to-IPv6 direction. Note that translating IPv6 source addresses to IPv4 source addresses in the IPv6-to-IPv4 direction and translating IPv4 destination addresses to IPv6 destination addresses in the IPv4-to-IPv6 direction will be different for stateless translation and stateful translation.
对于无状态和有状态转换，算法映射表用于将IPv6目标地址（IPv4转换地址）转换为IPv6到IPv4方向的IPv4目标地址，并将IPv4源地址转换为IPv4到IPv6方向的IPv6源地址（IPv4转换地址）。请注意，对于无状态转换和有状态转换，将IPv6源地址转换为IPv6到IPv4方向的IPv4源地址和将IPv4目标地址转换为IPv4到IPv6方向的IPv6目标地址是不同的。
o For stateless translation, the same algorithmic mapping table is used to translate IPv6 source addresses (IPv4-translatable addresses) to IPv4 source addresses in the IPv6-to-IPv4 direction and translate IPv4 destination addresses to IPv6 destination
o 对于无状态转换，使用相同的算法映射表将IPv6源地址（IPv4可翻译地址）转换为IPv6到IPv4方向的IPv4源地址，并将IPv4目标地址转换为IPv6目标地址
addresses (IPv4-translatable addresses) in the IPv4-to-IPv6 direction. In this case, blocks of the service provider's IPv4 addresses are mapped into IPv6 and used by physical IPv6 nodes. The original IPv4 form of these blocks of the service provider's IPv4 addresses are used to represent the physical IPv6 nodes in IPv4. Note that stateless translation supports both IPv6 initiated as well as IPv4 initiated communications.
IPv4到IPv6方向的地址（IPv4可翻译地址）。在这种情况下，服务提供商的IPv4地址块映射到IPv6，并由物理IPv6节点使用。这些服务提供商IPv4地址块的原始IPv4形式用于表示IPv4中的物理IPv6节点。请注意，无状态转换既支持IPv6启动的通信，也支持IPv4启动的通信。
o For stateful translation, the algorithmic mapping table is not used to translate source addresses in the IPv6-to-IPv4 direction and destination addresses in the IPv4-to-IPv6 direction. Instead, a state table is used to translate IPv6 source addresses to IPv4 source addresses in the IPv6-to-IPv4 direction and translate IPv4 destination addresses to IPv6 destination addresses in the IPv4- to-IPv6 direction. In this case, blocks of the service provider's IPv4 addresses are maintained in the translator as the IPv4 address pools and are dynamically bound to specific IPv6 addresses. The original IPv4 form of these blocks of the service provider's IPv4 addresses is used to represent the IPv6 address in IPv4. However, due to the dynamic binding, stateful translation in general only supports IPv6-initiated communication.
o 对于有状态转换，算法映射表不用于转换IPv6到IPv4方向的源地址和IPv4到IPv6方向的目标地址。相反，状态表用于将IPv6源地址转换为IPv6到IPv4方向上的IPv4源地址，并将IPv4目标地址转换为IPv4到IPv6方向上的IPv6目标地址。在这种情况下，服务提供商的IPv4地址块作为IPv4地址池保存在转换器中，并动态绑定到特定的IPv6地址。这些服务提供商IPv4地址块的原始IPv4形式用于表示IPv4中的IPv6地址。但是，由于动态绑定，有状态转换通常只支持IPv6发起的通信。
The IPv4/IPv6 translator is based on the update to the Stateless IP/ ICMP Translation Algorithm (SIIT) described in [RFC2765]. The algorithm translates between IPv4 and IPv6 packet headers (including ICMP headers).
IPv4/IPv6转换器基于[RFC2765]中描述的无状态IP/ICMP转换算法（SIIT）的更新。该算法在IPv4和IPv6数据包报头（包括ICMP报头）之间进行转换。
The IP and ICMP translation document [RFC6145] discusses header translation for both stateless and stateful modes, but does not cover maintaining state in the stateful mode. In the stateless mode, translation is performed using a combination of information carried in the address and information configured in the translator. This permits both IPv4->IPv6 and IPv6->IPv4 session establishment. In the stateful mode, translation state is maintained between IPv4 address/ transport port tuples and IPv6 address/transport port tuples, enabling IPv6 systems to open sessions with IPv4 systems. The choice of operational mode is made by the operator deploying the network and is critical to the operation of the applications using it.
IP和ICMP翻译文档[RFC6145]讨论了无状态和有状态模式下的头翻译，但不包括在有状态模式下维护状态。在无状态模式下，使用地址中携带的信息和转换器中配置的信息的组合来执行翻译。这允许IPv4->IPv6和IPv6->IPv4会话建立。在有状态模式下，IPv4地址/传输端口元组和IPv6地址/传输端口元组之间保持转换状态，使IPv6系统能够打开与IPv4系统的会话。操作模式的选择由部署网络的运营商决定，对于使用网络的应用程序的操作至关重要。
For the stateful translator, besides IP and ICMP translation, special action must be taken to maintain the translation states. [RFC6146] describes a mechanism for maintaining state.
对于有状态翻译器，除了IP和ICMP翻译外，还必须采取特殊措施来维护翻译状态。[RFC6146]描述了一种维护状态的机制。
DNS64 [RFC6147] and possible future DNS46 documents describe the mechanisms by which a DNS translator is intended to operate. It is designed to operate on the basis of known address translation algorithms defined in [RFC6052].
DNS64[RFC6147]和未来可能的DNS46文档描述了DNS转换器操作的机制。它设计为基于[RFC6052]中定义的已知地址转换算法进行操作。
There are at least two possible implementations of a DNS64 and DNS46:
DNS64和DNS46至少有两种可能的实现方式：
Static records: One could literally populate DNS with corresponding A and AAAA records. This mechanism works for scenarios 2, 3, 5, and 6.
静态记录：可以用相应的A和AAAA记录来填充DNS。此机制适用于场景2、3、5和6。
Dynamic Translation of static records: In more general operation, the preferred behavior is an A record to be (retrieved and) translated to a AAAA record by the DNS64 if and only if no reachable AAAA record exists, or for a AAAA record to be (retrieved and) translated to an A record by the DNS46 if and only if no reachable A record exists.
静态记录的动态转换：在更一般的操作中，首选行为是当且仅当不存在可访问的AAAA记录时，由DNS64将A记录（检索并）转换为AAAA记录，或者当且仅当不存在可访问的记录时，由DNS46将AAAA记录（检索并）转换为A记录。
In addition, some applications require special support. An example is FTP. FTP's active mode doesn't work well across NATs without extra support such as SOCKS [RFC1928] [RFC3089]. Across NATs, it generally uses passive mode. However, the designers of FTP wrote different and incompatible passive-mode implementations for IPv4 and IPv6 networks. Hence, either they need to fix FTP, or a translator must be written for the application. Other applications may be similarly broken.
此外，有些应用程序需要特殊支持。FTP就是一个例子。如果没有SOCKS[RFC1928][RFC3089]等额外支持，FTP的活动模式在NAT中无法正常工作。在NAT中，它通常使用被动模式。然而，FTP的设计者为IPv4和IPv6网络编写了不同且不兼容的被动模式实现。因此，要么他们需要修复FTP，要么必须为应用程序编写转换器。其他应用程序也可能出现类似的问题。
As a general rule, a simple operational recommendation will work around many application issues: there should be a server in each domain, or an instance of the server should have an interface in each domain. For example, an SMTP MTA may be confused by finding an IPv6 address in its HELO when it is connected to using IPv4 (or vice versa), but would work perfectly well if it had an interface in both the IPv4 and IPv6 domains and was used as an application-layer bridge between them.
一般来说，一个简单的操作建议可以解决许多应用程序问题：每个域中都应该有一个服务器，或者服务器的一个实例在每个域中都应该有一个接口。例如，SMTP MTA在使用IPv4连接到其HELO时（或反之亦然），可能会因在其HELO中查找IPv6地址而感到困惑，但如果它在IPv4和IPv6域中都有接口，并用作它们之间的应用层网桥，则它将工作得非常好。
Currently, the proposed solutions for IPv6/IPv4 translation are classified into stateless translation and stateful translation.
目前，建议的IPv6/IPv4转换解决方案分为无状态转换和有状态转换。
For stateless translation, the translation information is carried in the address itself plus configuration in the translators, permitting both IPv4->IPv6 and IPv6->IPv4 session initiation. Stateless translation supports end-to-end address transparency and has better scalability compared with stateful translation [RFC6145].
对于无状态转换，转换信息包含在地址本身以及转换器中的配置中，允许IPv4->IPv6和IPv6->IPv4会话启动。无状态转换支持端到端地址透明性，与有状态转换相比具有更好的可扩展性[RFC6145]。
The stateless translation mechanisms typically put constraints on what IPv6 addresses can be assigned to IPv6 nodes that want to communicate with IPv4 destinations using an algorithmic mapping. For Scenario 1 ("an IPv6 network to the IPv4 Internet"), it is not a serious drawback, since the address assignment policy can be applied to satisfy this requirement for the IPv6 nodes that need to communicate with the IPv4 Internet. In addition, stateless translation supports Scenario 2 ("the IPv4 Internet to an IPv6 network"), which means that not only could servers move directly to IPv6 without trudging through a difficult transition period, but also they could do so without risk of losing connectivity with the IPv4- only Internet.
无状态转换机制通常会限制哪些IPv6地址可以分配给希望使用算法映射与IPv4目的地通信的IPv6节点。对于场景1（“到IPv4 Internet的IPv6网络”），这不是一个严重的缺点，因为可以应用地址分配策略来满足需要与IPv4 Internet通信的IPv6节点的这一要求。此外，无状态转换支持场景2（“IPv4互联网到IPv6网络”），这意味着服务器不仅可以直接移动到IPv6，而无需艰难地度过过渡期，而且还可以避免失去与仅IPv4互联网的连接的风险。
Stateless translation can be used for Scenarios 1, 2, 5, and 6, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv4 Internet to an IPv6 network", "an IPv6 network to an IPv4 network", and "an IPv4 network to an IPv6 network".
无状态转换可用于场景1、2、5和6，即支持“IPv6网络到IPv4互联网”、“IPv4互联网到IPv6网络”、“IPv6网络到IPv4网络”和“IPv4网络到IPv6网络”。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\ / \\ //
\\ // ----------
--------
<====>
Figure 11: Stateless Translation for Scenarios 1 and 2
图11：场景1和场景2的无状态转换
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateless IPv4/IPv6
| |DNS | (address | Translator
\ +----+ subset) / DNS: DNS64/DNS46
\\ // \\ //
-------- ---------
<====>
Figure 12: Stateless Translation for Scenarios 5 and 6
图12：场景5和6的无状态转换
The implementation of the stateless translator needs to refer to [RFC6145] and [RFC6052].
无状态转换器的实现需要参考[RFC6145]和[RFC6052]。
For stateful translation, the translation state is maintained between IPv4 address/port pairs and IPv6 address/port pairs, enabling IPv6 systems to open sessions with IPv4 systems [RFC6145] [RFC6146].
对于有状态转换，转换状态在IPv4地址/端口对和IPv6地址/端口对之间保持，使IPv6系统能够打开与IPv4系统的会话[RFC6145][RFC6146]。
Stateful translation can be used for Scenarios 1, 3, and 5, i.e., it supports "an IPv6 network to the IPv4 Internet", "the IPv6 Internet to an IPv4 network", and "an IPv6 network to an IPv4 network".
有状态转换可用于场景1、3和5，即支持“IPv6网络到IPv4互联网”、“IPv6互联网到IPv4网络”和“IPv6网络到IPv4网络”。
For Scenario 1, any IPv6 addresses in an IPv6 network can use stateful translation; however, it typically only supports initiation from the IPv6 side. In addition, it does not result in stable addresses of IPv6 nodes that can be used in DNS, which may cause
对于场景1，IPv6网络中的任何IPv6地址都可以使用有状态转换；但是，它通常只支持从IPv6端发起。此外，它不会导致可以在DNS中使用的IPv6节点的稳定地址，这可能会导致
problems for the protocols and applications that do not deal well with highly dynamic addresses.
协议和应用程序无法很好地处理高度动态地址的问题。
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
--------
// \\ -----------
/ \ // \\
/ +----+ \
| |XLAT| |
| The IPv4 +----+ An IPv6 |
| Internet +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\ / \\ //
\\ // -----------
--------
<====
Figure 13: Stateful Translation for Scenario 1
图13：场景1的状态转换
Scenario 3 handles servers using IPv4 private addresses [RFC1918] and being reached from the IPv6 Internet. This includes cases of servers that for some reason cannot be upgraded to IPv6 and don't have public IPv4 addresses, and yet need to be reached by IPv6 nodes in the IPv6 Internet.
场景3处理使用IPv4专用地址[RFC1918]并通过IPv6 Internet访问的服务器。这包括由于某种原因无法升级到IPv6且没有公共IPv4地址，但需要IPv6 Internet中的IPv6节点访问的服务器。
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
-----------
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv4 +----+ The IPv6 |
| Network +----+ Internet | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
<====
Figure 14: Stateful Translation for Scenario 3
图14：场景3的状态转换
Similarly, stateful translation can also be used for Scenario 5.
类似地，有状态转换也可用于场景5。
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
-------- ---------
// \\ // \\
/ +----+ \
| |XLAT| |
| An IPv4 +----+ An IPv6 |
| Network +----+ Network | XLAT: Stateful IPv4/IPv6
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \\ //
-------- ---------
<====
Figure 15: Stateful Translation for Scenario 5
图15：场景5的状态转换
The implementation of the stateful translator needs to refer to [RFC6145], [RFC6146], and [RFC6052].
有状态转换器的实现需要参考[RFC6145]、[RFC6146]和[RFC6052]。
Based on the above analysis, the IPv4/IPv6 translation series consists of the following documents.
基于上述分析，IPv4/IPv6翻译系列包括以下文档。
o Framework for IPv4/IPv6 Translation (this document).
o IPv4/IPv6转换框架（本文档）。
o Address translation (the choice of IPv6 prefix and the choice of method by which the remainder of the IPv6 address is derived from an IPv4 address, part of the SIIT update) [RFC6052].
o 地址转换（IPv6前缀的选择和IPv6地址剩余部分从IPv4地址派生的方法的选择，SIIT更新的一部分）[RFC6052]。
o IP and ICMP Translation (header translation and ICMP handling, part of the SIIT update) [RFC6145].
o IP和ICMP转换（头转换和ICMP处理，SIIT更新的一部分）[RFC6145]。
o Table maintenance (stateful translation including session database and mapping table handling) [RFC6146].
o 表维护（有状态转换，包括会话数据库和映射表处理）[RFC6146]。
o DNS64 (DNS64: A to AAAA mapping and DNSSEC discussion) [RFC6147].
o DNS64（DNS64:A到AAAA的映射和DNSSEC讨论）[RFC6147]。
o FTP ALG [FTP64].
o FTP ALG[FTP64]。
o Others (DNS46, Multicast, etc.).
o 其他（DNS46、多播等）。
The relationship among these documents is shown in the following figure.
这些文档之间的关系如下图所示。
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
-----------------------------------------
| Framework for IPv4/IPv6 Translation |
-----------------------------------------
|| ||
-------------------------------------------------------------------
| || stateless and stateful || |
| -------------------- --------------------- |
| |Address Translation | <======== | IP/ICMP Translation | |
| -------------------- --------------------- |
| /\ /\ |
| || ------------------||------------ |
| || | stateful \/ |
| ----------------- | --------------------- |
| | DNS64/DNS46 | | | Table Maintenance | |
| ----------------- | --------------------- |
-------------------------------------------------------------------
/\ /\
|| ||
----------------- --------------------
| FTP ALG | | Others |
----------------- --------------------
Figure 16: Document Layout
图16：文档布局
In the document layout, the IP/ICMP Translation and DNS64/DNS46 normatively refer to Address Translation. The Table Maintenance and IP/ICMP Translation normatively refer to each other.
在文档布局中，IP/ICMP翻译和DNS64/DNS46通常指地址翻译。表维护和IP/ICMP转换规范地相互参照。
The FTP ALG and other documents normatively refer to the Address Format, IP/ICMP Translation, and Table Maintenance documents.
FTP ALG和其他文档通常指地址格式、IP/ICMP翻译和表维护文档。
Operationally, there are two ways that translation could be used -- as a permanent solution thereby making transition "the other guy's problem", and as a temporary solution for a new part of one's network while bringing up IPv6 services in the remaining parts of one's network. We obviously recommend the latter at the present stage. For the IPv4 parts of the network, [RFC4213]'s recommendation holds. Bring IPv6 up in those domains, move production to it, and then take down the now-unnecessary IPv4 service when economics warrant. This approach to transition entails the least risk.
在操作上，有两种方式可以使用翻译——作为永久解决方案，从而使转换成为“另一个人的问题”，以及作为网络新部分的临时解决方案，同时在网络的其余部分提供IPv6服务。在现阶段，我们显然建议采用后者。对于网络的IPv4部分，[RFC4213]的建议适用。在这些域中启动IPv6，将生产转移到它，然后在经济许可的情况下关闭现在不必要的IPv4服务。这种过渡方法的风险最小。
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\----+----+-+-----+ +----+-/////
|XLAT|-|DNS64|-|FTP |
| |-|DNS46|-|ALG |
/////----+----+ +-----+ +----+-\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
----------------------
////// \\\\\\
/// IPv4 or Dual Stack \\\
|| +----+ Routing +-----+ ||
| |IPv4| |IPv4+| |
| |Host| |IPv6 | |
|| +----+ |Host | ||
\\\ +-----+ ///
\\\\\----+----+-+-----+ +----+-/////
|XLAT|-|DNS64|-|FTP |
| |-|DNS46|-|ALG |
/////----+----+ +-----+ +----+-\\\\\
/// \\\
|| +-----+ +----+ ||
| |IPv4+| |IPv6| |
| |IPv6 | |Host| |
|| |Host | +----+ ||
\\\ +-----+ IPv6-only Routing ///
\\\\\\ //////
----------------------
Figure 17: Translation Operational Model
图17：翻译运作模式
Figure 17 shows that, during the coexistence phase, one expects a combination of hosts, applications, and networks. Hosts might include IPv6-only gaming devices and handsets, older computer operating systems that are IPv4-only, and modern mainline operating systems that support both. Applications might include ones that are IPv4-only and modern applications that support both IPv4 and IPv6. Networks might include dual-stack devices operating in single-stack networks (whether that stack is IPv4 or IPv6) and fully functional dual-stack networks.
图17显示，在共存阶段，需要主机、应用程序和网络的组合。主机可能包括仅限IPv6的游戏设备和手机、仅限IPv4的旧计算机操作系统以及同时支持这两种设备的现代主线操作系统。应用程序可能包括仅支持IPv4的应用程序和同时支持IPv4和IPv6的现代应用程序。网络可能包括在单堆栈网络（无论该堆栈是IPv4还是IPv6）中运行的双堆栈设备和功能齐全的双堆栈网络。
The framework does not cover all possible scenarios, and it may be extended in the future to address them.
该框架并没有涵盖所有可能的场景，将来可能会加以扩展以解决这些场景。
This document is the framework of IPv4/IPv6 translation. The security issues are addressed in individual IPv4/IPv6 translation documents, i.e., [RFC6052], [RFC6145], [RFC6146], [RFC6147], and [FTP64].
本文档是IPv4/IPv6转换的框架。安全问题在单独的IPv4/IPv6翻译文档中解决，即[RFC6052]、[RFC6145]、[RFC6146]、[RFC6147]和[FTP64]。
This is under development by a large group of people. Those who have posted to the list during the discussion include Andrew Sullivan, Andrew Yourtchenko, Bo Zhou, Brian Carpenter, Dan Wing, Dave Thaler, David Harrington, Ed Jankiewicz, Gang Chen, Hui Deng, Hiroshi Miyata, Iljitsch van Beijnum, John Schnizlein, Magnus Westerlund, Marcelo Bagnulo Braun, Margaret Wasserman, Masahito Endo, Phil Roberts, Philip Matthews, Remi Denis-Courmont, and Remi Despres.
这是由一大群人开发的。在讨论过程中公布名单的人包括安德鲁·沙利文、安德鲁·尤琴科、周波、布赖恩·卡彭特、丹·荣、戴夫·泰勒、大卫·哈灵顿、埃德·扬基维茨、陈刚、邓惠东、宫田浩史、伊尔吉茨基·范·贝伊南、约翰·施尼兹林、马塞洛·巴格鲁·布劳恩、玛格丽特·瓦瑟曼、马萨希托·恩多、菲尔·罗伯茨、，菲利普·马修斯、雷米·丹尼斯·库尔蒙和雷米·德斯普雷斯。
Ed Jankiewicz described the transition plan.
Ed Jankiewicz描述了过渡计划。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[6NET] 6NET Consortium, "6NET", <http://www.6net.org/>.
[6NET]6NET联合体，“6NET”<http://www.6net.org/>.
[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, March 2011.
[DS-LITE]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈LITE宽带部署”，正在进行的工作，2011年3月。
[FTP64] Beijnum, I., "An FTP ALG for IPv6-to-IPv4 translation", Work in Progress, March 2011.
[FTP64]北京，I.，“用于IPv6到IPv4转换的FTP ALG”，正在进行的工作，2011年3月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1923] Halpern, J. and S. Bradner, "RIPv1 Applicability Statement for Historic Status", RFC 1923, March 1996.
[RFC1923]Halpern，J.和S.Bradner，“RIPv1历史地位适用性声明”，RFC 1923，1996年3月。
[RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[RFC1928]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.，和L.Jones，“SOCKS协议版本5”，RFC 19281996年3月。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3089] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[RFC3089]北村，H.，“基于SOCKS的IPv6/IPv4网关机制”，RFC3089，2001年4月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211, July 2008.
[RFC5211]Curran，J.，“互联网转型计划”，RFC 52112008年7月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
Authors' Addresses
作者地址
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
中国北京清华大学主楼225室兴利赛尔网中心/清华大学，100084
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 China
丛晓宝CERNET中心/清华大学主楼225室，北京，100084
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Kevin Yin Cisco Systems No. 2 Jianguomenwai Ave, Chaoyang District Beijing, 100022 China
Kevin Yin思科系统中国北京朝阳区建国门外大街2号，邮编100022
Phone: +86-10-8515-5094
EMail: kyin@cisco.com
Phone: +86-10-8515-5094
EMail: kyin@cisco.com