Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6264 D. Guo
Category: Informational Huawei
ISSN: 2070-1721 B. Carpenter
University of Auckland
June 2011
Internet Engineering Task Force (IETF) S. Jiang
Request for Comments: 6264 D. Guo
Category: Informational Huawei
ISSN: 2070-1721 B. Carpenter
University of Auckland
June 2011
An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition
一种用于IPv6过渡的增量载波级NAT（CGN）
Abstract
摘要
Global IPv6 deployment was slower than originally expected. As IPv4 address exhaustion approaches, IPv4 to IPv6 transition issues become more critical and less tractable. Host-based transition mechanisms used in dual-stack environments cannot meet all transition requirements. Most end users are not sufficiently expert to configure or maintain host-based transition mechanisms. Carrier-Grade NAT (CGN) devices with integrated transition mechanisms can reduce the operational changes required during the IPv4 to IPv6 migration or coexistence period.
全局IPv6部署比最初预期的慢。随着IPv4地址耗尽的临近，IPv4到IPv6的转换问题变得更为关键，也更不易处理。双堆栈环境中使用的基于主机的转换机制无法满足所有转换要求。大多数最终用户没有足够的专家来配置或维护基于主机的转换机制。具有集成转换机制的运营商级NAT（CGN）设备可以减少IPv4到IPv6迁移或共存期间所需的操作更改。
This document proposes an incremental CGN approach for IPv6 transition. It can provide IPv6 access services for IPv6 hosts and IPv4 access services for IPv4 hosts while leaving much of a legacy ISP network unchanged during the initial stage of IPv4 to IPv6 migration. Unlike CGN alone, incremental CGN also supports and encourages smooth transition towards dual-stack or IPv6-only ISP networks. An integrated configurable CGN device and an adaptive home gateway (HG) device are described. Both are reusable during different transition phases, avoiding multiple upgrades. This enables IPv6 migration to be incrementally achieved according to real user requirements.
本文档提出了一种用于IPv6过渡的增量CGN方法。它可以为IPv6主机提供IPv6访问服务，并为IPv4主机提供IPv4访问服务，同时在IPv4到IPv6迁移的初始阶段保持大部分传统ISP网络不变。与仅CGN不同，增量CGN还支持并鼓励向双栈或仅限IPv6的ISP网络平滑过渡。描述了一种集成的可配置CGN设备和一种自适应家庭网关（HG）设备。两者在不同的过渡阶段都是可重用的，避免了多次升级。这使得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/rfc6264.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6264.
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 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 ....................................................2
2. An Incremental CGN Approach .....................................4
2.1. Incremental CGN Approach Overview ..........................4
2.2. Choice of Tunneling Technology .............................5
2.3. Behavior of Dual-Stack Home Gateway ........................6
2.4. Behavior of Dual-Stack CGN .................................6
2.5. Impact for Existing Hosts and Unchanged Networks ...........7
2.6. IPv4/IPv6 Intercommunication ...............................7
2.7. Discussion .................................................8
3. Smooth Transition towards IPv6 Infrastructure ...................8
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
1. Introduction ....................................................2
2. An Incremental CGN Approach .....................................4
2.1. Incremental CGN Approach Overview ..........................4
2.2. Choice of Tunneling Technology .............................5
2.3. Behavior of Dual-Stack Home Gateway ........................6
2.4. Behavior of Dual-Stack CGN .................................6
2.5. Impact for Existing Hosts and Unchanged Networks ...........7
2.6. IPv4/IPv6 Intercommunication ...............................7
2.7. Discussion .................................................8
3. Smooth Transition towards IPv6 Infrastructure ...................8
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................11
Global IPv6 deployment did not happen as was forecast 10 years ago. Network providers were hesitant to make the first move while IPv4 was and is still working well. However, IPv4 address exhaustion is imminent. The dynamically updated IPv4 Address Report [IPUSAGE] has analyzed this issue. IANA unallocated address pool exhaustion occurred in February 2011, and at the time of publication, the site predicts imminent exhaustion for Regional Internet Registry (RIR)
全球IPv6部署并不像10年前预测的那样发生。在IPv4过去和现在都运行良好的情况下，网络提供商对采取第一步行动犹豫不决。然而，IPv4地址耗尽迫在眉睫。动态更新的IPv4地址报告[IPUSAGE]已分析此问题。IANA未分配地址池耗尽发生在2011年2月，发布时，该网站预测区域互联网注册（RIR）即将耗尽
unallocated address pools. Based on this fact, the Internet industry appears to have reached consensus that global IPv6 deployment is inevitable and has to be done expeditiously.
未分配的地址池。基于这一事实，互联网行业似乎已经达成共识，即全球IPv6部署是不可避免的，必须尽快完成。
IPv4 to IPv6 transition issues therefore become more critical and complicated for the approaching global IPv6 deployment. Host-based transition mechanisms alone are not able to meet the requirements in all cases. Therefore, network-based supporting functions and/or new transition mechanisms with simple user-side operation are needed.
因此，对于即将到来的全球IPv6部署，IPv4到IPv6的过渡问题变得更加关键和复杂。仅基于主机的转换机制无法在所有情况下满足要求。因此，需要基于网络的支持功能和/或具有简单用户端操作的新转换机制。
Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large Scale NAT, compounds IPv4 operational problems when used alone but does nothing to encourage IPv4 to IPv6 transition. Deployment of NAT444 CGN allows ISPs to delay the transition and therefore causes double transition costs (once to add CGN and again to support IPv6).
载波级NAT（CGN）[CGN-REQS]，也称为NAT444 CGN或大规模NAT，单独使用时会加剧IPv4运行问题，但不会鼓励IPv4向IPv6过渡。NAT444 CGN的部署允许ISP延迟过渡，因此导致双重过渡成本（一次添加CGN，另一次支持IPv6）。
CGN deployments that integrate multiple transition mechanisms can simplify the operation of end-user services during the IPv4 to IPv6 migration and coexistence periods. CGNs are deployed on the network side and managed/maintained by professionals. On the user side, new home gateway (HG) devices may be needed too. They may be provided by network providers, depending on the specific business model. Dual-stack lite [DS-LITE], also called DS-Lite, is a CGN-based solution that supports transition, but it requires the ISP to upgrade its network to IPv6 immediately. Many ISPs hesitate to do this as the first step. Theoretically, DS-Lite can be used with double encapsulation (IPv4-in-IPv6-in-IPv4), but this seems even less likely to be accepted by an ISP and is not discussed in this document.
集成多种转换机制的CGN部署可以简化IPv4到IPv6迁移和共存期间最终用户服务的操作。CGN部署在网络端，由专业人员管理/维护。在用户端，可能还需要新的家庭网关（HG）设备。它们可能由网络提供商提供，具体取决于具体的商业模式。双栈lite[DS-lite]，也称为DS-lite，是一种基于CGN的解决方案，支持转换，但它要求ISP立即将其网络升级到IPv6。许多ISP在第一步做这件事时犹豫不决。从理论上讲，DS-Lite可以与双封装（IPv4-in-IPv6-in-IPv4）一起使用，但ISP似乎更不可能接受这一点，本文档中没有讨论这一点。
This document proposes an incremental CGN approach for IPv6 transition. It does not define any new protocols or mechanisms but describes how to combine existing proposals in an incremental deployment. The approach is similar to DS-Lite but the other way around. It mainly combines v4-v4 NAT with v6-over-v4 tunneling functions. It can provide IPv6 access services for IPv6-enabled hosts and IPv4 access services for IPv4 hosts while leaving most of legacy IPv4 ISP networks unchanged. The deployment of this technology does not affect legacy IPv4 hosts with global IPv4 addresses at all. It is suitable for the initial stage of IPv4 to IPv6 migration. It also supports transition towards dual-stack or IPv6-only ISP networks.
本文档提出了一种用于IPv6过渡的增量CGN方法。它没有定义任何新的协议或机制，但描述了如何在增量部署中组合现有的建议。该方法类似于DS Lite，但与之相反。它主要将v4-v4 NAT与v6-over-v4隧道功能相结合。它可以为支持IPv6的主机提供IPv6访问服务，并为IPv4主机提供IPv4访问服务，同时保持大多数传统IPv4 ISP网络不变。此技术的部署根本不会影响具有全局IPv4地址的旧式IPv4主机。它适用于IPv4到IPv6迁移的初始阶段。它还支持向双栈或仅限IPv6的ISP网络过渡。
A smooth transition mechanism is also described in this document. It introduces an integrated configurable CGN device and an adaptive HG device. Both CGN and HG are reusable devices during different transition periods, so they do not need to be replaced as the transition proceeds. This enables IPv6 migration to be incrementally achieved according to the real user requirements.
本文还描述了平滑过渡机制。它引入了一个集成的可配置CGN设备和一个自适应HG设备。CGN和HG在不同的过渡期都是可重用的设备，因此在过渡过程中不需要更换它们。这使得IPv6迁移能够根据实际用户需求逐步实现。
Today, most consumers primarily use IPv4. Network providers are starting to provide IPv6 access services for end users. At the initial stage of IPv4 to IPv6 migration, IPv4 connectivity and traffic would continue to represent the majority of traffic for most ISP networks. ISPs would like to minimize the changes to their IPv4 networks. Switching the whole ISP network into IPv6-only would be considered a radical strategy. Switching the whole ISP network to dual-stack is less radical but introduces operational costs and complications. Although some ISPs have successfully deployed dual-stack networks, others prefer not to do this as their first step in IPv6. However, they currently face two urgent pressures -- to compensate for an immediate shortage of IPv4 addresses by deploying some method of address sharing and to prepare actively for the use of deployment of IPv6 address space and services. ISPs facing only one pressure out of two could adopt either CGN (for shortage of IPv4 addresses) or 6rd (to provide IPv6 connectivity services). The approach described in this document is intended to address both of these pressures at the same time by combining v4-v4 CGN with v6-over-v4 tunneling technologies.
如今，大多数消费者主要使用IPv4。网络提供商开始为最终用户提供IPv6访问服务。在IPv4到IPv6迁移的初始阶段，IPv4连接和流量将继续代表大多数ISP网络的大部分流量。ISP希望尽量减少对其IPv4网络的更改。将整个ISP网络切换到IPv6将被认为是一种激进的策略。将整个ISP网络切换到双协议栈不那么激进，但会带来运营成本和复杂性。尽管一些ISP已成功部署了双栈网络，但其他ISP不愿意将此作为IPv6的第一步。然而，他们目前面临两个紧迫的压力——通过部署某种地址共享方法来弥补IPv4地址的短缺，并积极准备部署IPv6地址空间和服务。面临两个压力中只有一个压力的ISP可以采用CGN（用于IPv4地址不足）或6rd（用于提供IPv6连接服务）。本文档中描述的方法旨在通过将v4-v4 CGN与v6-over-v4隧道技术相结合，同时解决这两种压力。
The incremental CGN approach we propose is illustrated in the following figure.
我们提出的增量CGN方法如下图所示。
+-------------+
|IPv6 Internet|
+-------------+
|
+---------------+----------+
+-----+ +--+ | IPv4 ISP +--+--+ | +--------+
|v4/v6|---|DS|=======+============| CGN |-------+---| IPv4 |
|Host | |HG| | Network +-----+ | | |Internet|
+-----+ +--+ +----------------------+---+ +--------+
_ _ _ _ _ _ _ _ _ _ _ |
()_6_over_4_ _t_u_n_n_e_l_() +---------------------+
| Existing IPv4 hosts |
+---------------------+
+-------------+
|IPv6 Internet|
+-------------+
|
+---------------+----------+
+-----+ +--+ | IPv4 ISP +--+--+ | +--------+
|v4/v6|---|DS|=======+============| CGN |-------+---| IPv4 |
|Host | |HG| | Network +-----+ | | |Internet|
+-----+ +--+ +----------------------+---+ +--------+
_ _ _ _ _ _ _ _ _ _ _ |
()_6_over_4_ _t_u_n_n_e_l_() +---------------------+
| Existing IPv4 hosts |
+---------------------+
Figure 1: Incremental CGN Approach with IPv4 ISP Network
图1：IPv4 ISP网络的增量CGN方法
DS HG = Dual-Stack Home Gateway (CPE - Customer Premises Equipment).
DS HG=双栈家庭网关（CPE-客户场所设备）。
As shown in the figure above, the ISP has not significantly changed its IPv4 network. This approach enables IPv4 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 Internet. A dual-
如上图所示，ISP并未显著改变其IPv4网络。此方法使IPv4主机能够访问IPv4 Internet，IPv6主机能够访问IPv6 Internet。双重身份-
stack host is treated as an IPv4 host when it uses IPv4 access service and as an IPv6 host when it uses an IPv6 access service. In order to enable IPv4 hosts to access the IPv6 Internet and IPv6 hosts to access IPv4 Internet, NAT64 can be integrated with the CGN; see Section 2.6 for details regarding IPv4/IPv6 intercommunication. The integration of such mechanisms is out of scope for this document.
堆栈主机在使用IPv4访问服务时被视为IPv4主机，在使用IPv6访问服务时被视为IPv6主机。为了使IPv4主机能够访问IPv6互联网，IPv6主机能够访问IPv4互联网，可以将NAT64与CGN集成；有关IPv4/IPv6内部通信的详细信息，请参见第2.6节。此类机制的整合超出了本文件的范围。
Two types of devices need to be deployed in this approach: a dual-stack home gateway (HG) and a dual-stack CGN. The dual-stack home gateway integrates both IPv6 and IPv4 forwarding and v6-over-v4 tunneling functions. It should follow the requirements of [RFC6204], including IPv6 prefix delegation. It may also integrate v4-v4 NAT functionality. The dual-stack CGN integrates v6-over-v4 tunneling and v4-v4 CGN functions as well as standard IPv6 and IPv4 routing.
这种方法需要部署两种类型的设备：双栈家庭网关（HG）和双栈CGN。双栈家庭网关集成了IPv6和IPv4转发以及v6-over-v4隧道功能。它应该遵循[RFC6204]的要求，包括IPv6前缀委派。它还可以集成v4-v4 NAT功能。双栈CGN集成了v6-over-v4隧道和v4-v4 CGN功能以及标准IPv6和IPv4路由。
The approach does not require any new mechanisms for IP packet forwarding or encapsulation or decapsulation at tunnel endpoints. The following sections describe how the HG and the incremental CGN interact.
该方法不需要任何新的机制在隧道端点进行IP数据包转发或封装或解封。以下各节描述了HG和增量CGN是如何相互作用的。
In principle, this model will work with any form of tunnel between the dual-stack HG and the dual-stack CGN. However, tunnels that require individual configuration are clearly undesirable because of their operational cost. Configured tunnels based directly on [RFC4213] are therefore not suitable. A tunnel broker according to [RFC3053] would also have high operational costs and be unsuitable for home users.
原则上，该模型适用于双堆栈HG和双堆栈CGN之间的任何形式的隧道。然而，由于运营成本的原因，需要单独配置的隧道显然是不可取的。因此，直接基于[RFC4213]配置的隧道不适用。根据[RFC3053]的规定，隧道经纪人的运营成本也很高，不适合家庭用户。
6rd [RFC5569, RFC5969] technology appears suitable to support v6-over-v4 tunneling with low operational cost. Generic Routing Encapsulation (GRE) [RFC2784] with an additional auto-configuration mechanism is also able to support v6-over-v4 tunneling. Other tunneling mechanisms such as 6over4 [RFC2529], 6to4 [RFC3056], the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214], or Virtual Enterprise Traversal (VET) [RFC5558] could be considered. If the ISP has an entirely MPLS infrastructure between the HG and the dual-stack CGN, it would also be possible to use a IPv6 Provider Edge (6PE) [RFC4798] tunnel directly over MPLS. This would, however, only be suitable for an advanced HG that is unlikely to be found as a consumer device and is not further discussed here. To simplify the discussion, we assume the use of 6rd.
第6rd[RFC5569，RFC5969]技术似乎适合以较低的运营成本支持v6-over-v4隧道。具有附加自动配置机制的通用路由封装（GRE）[RFC2784]也能够支持v6-over-v4隧道。可以考虑其他隧道机制，如6over4[RFC2529]、6to4[RFC3056]、站点内自动隧道寻址协议（ISATAP）[RFC5214]或虚拟企业遍历（VET）[RFC5558]。如果ISP在HG和双栈CGN之间有一个完整的MPLS基础设施，那么也可以直接在MPLS上使用IPv6提供商边缘（6PE）[RFC4798]隧道。然而，这只适用于不太可能作为消费设备找到的高级汞，此处不再进一步讨论。为了简化讨论，我们假设使用6rd。
When a dual-stack home gateway receives a data packet from a host, it will determine whether the packet is an IPv4 or IPv6 packet. The packet will be handled by an IPv4 or IPv6 stack as appropriate. For IPv4, and in the absence of v4-v4 NAT on the HG, the stack will simply forward the packet to the CGN, which will normally be the IPv4 default router. If v4-v4 NAT is enabled, the HG translates the packet source address from an HG-scope private IPv4 address into a CGN-scope IPv4 address, performs port mapping if needed, and then forwards the packet towards the CGN. The HG records the v4-v4 address and port mapping information for inbound packets, like any other NAT.
当双栈家庭网关从主机接收到数据包时，它将确定该数据包是IPv4还是IPv6数据包。数据包将由IPv4或IPv6堆栈（视情况而定）处理。对于IPv4，在HG上没有v4-v4 NAT的情况下，堆栈将简单地将数据包转发到CGN，CGN通常是IPv4默认路由器。如果启用了v4-v4 NAT，HG将数据包源地址从HG作用域专用IPv4地址转换为CGN作用域IPv4地址，根据需要执行端口映射，然后将数据包转发到CGN。HG记录入站数据包的v4-v4地址和端口映射信息，就像任何其他NAT一样。
For IPv6, the HG needs to encapsulate the data into an IPv4 tunnel packet, which has the dual-stack CGN as the IPv4 destination. The HG sends the new IPv4 packet towards the CGN, for example, using 6rd.
对于IPv6，HG需要将数据封装到IPv4隧道数据包中，该数据包具有双堆栈CGN作为IPv4目标。HG向CGN发送新的IPv4数据包，例如，使用6rd。
If the HG is linked to more than one CGN, it will record the mapping information between the tunnel and the source IPv6 address for inbound packets. Detailed considerations for the use of multiple CGNs by one HG are for further study.
如果HG链接到多个CGN，它将记录隧道和入站数据包的源IPv6地址之间的映射信息。一个汞柱使用多个CGN的详细考虑因素有待进一步研究。
IPv4 packets from the CGN and encapsulated IPv6 packets from the CGN will be translated or decapsulated according to the stored mapping information and forwarded to the customer side of the HG.
来自CGN的IPv4数据包和来自CGN的封装IPv6数据包将根据存储的映射信息进行转换或解封，并转发到HG的客户端。
When a dual-stack CGN receives an IPv4 data packet from a dual-stack home gateway, it will determine whether the packet is a normal IPv4 packet, which is non-encapsulated, or a v6-over-v4 tunnel packet addressed to a tunnel endpoint within the CGN. For a normal IPv4 packet, the CGN translates the packet source address from a CGN-scope IPv4 address into a public IPv4 address, performs port mapping if necessary, and then forwards it normally to the IPv4 Internet. The CGN records the v4-v4 address and port mapping information for inbound packets, just like a normal NAT does. For a v6-over-v4 tunnel packet, the tunnel endpoint within the CGN will decapsulate it into the original IPv6 packet and then forward it to the IPv6 Internet. The CGN records the mapping information between the tunnel and the source IPv6 address for inbound packets.
当双栈CGN从双栈家庭网关接收到IPv4数据包时，它将确定该数据包是非封装的正常IPv4数据包，还是寻址到CGN内隧道端点的v6-over-v4隧道数据包。对于普通IPv4数据包，CGN将数据包源地址从CGN作用域IPv4地址转换为公共IPv4地址，必要时执行端口映射，然后将其正常转发到IPv4 Internet。CGN记录入站数据包的v4-v4地址和端口映射信息，就像普通NAT一样。对于v6-over-v4隧道数据包，CGN内的隧道端点将其解压缩为原始IPv6数据包，然后将其转发到IPv6 Internet。CGN记录隧道和入站数据包的源IPv6地址之间的映射信息。
Depending on the deployed location of the CGN, it may use a further v6-over-v4 tunnel to connect to the IPv6 Internet.
根据CGN的部署位置，它可能会使用另一个v6-over-v4隧道连接到IPv6 Internet。
Packets from the IPv4 Internet will be appropriately translated by the CGN and forwarded to the HG, and packets from the IPv6 Internet will be tunneled to the appropriate HG, using the stored mapping information as necessary.
来自IPv4互联网的数据包将由CGN进行适当转换并转发到HG，来自IPv6互联网的数据包将通过隧道传输到适当的HG，必要时使用存储的映射信息。
This approach does not affect the unchanged parts of ISP networks at all. Legacy IPv4 ISP networks and their IPv4 devices remain in use. The existing IPv4 hosts, shown as the lower right box in Figure 1, having either global IPv4 addresses or behind v4-v4 NAT, can connect to the IPv4 Internet as it is now. These hosts, if they are upgraded to become dual-stack hosts, can access the IPv6 Internet through the IPv4 ISP network by using IPv6-over-IPv4 tunnel technologies. (See Section 2.7 for a comment on MTU size.)
这种方法根本不会影响ISP网络中不变的部分。传统IPv4 ISP网络及其IPv4设备仍在使用中。现有IPv4主机（如图1右下框所示）具有全局IPv4地址或位于v4-v4 NAT之后，可以像现在一样连接到IPv4 Internet。如果这些主机升级为双栈主机，则可以使用IPv6-over-IPv4隧道技术通过IPv4 ISP网络访问IPv6 Internet。（有关MTU尺寸的注释，请参见第2.7节。）
For obvious commercial reasons, IPv6-only public services are not expected as long as there is a significant IPv4-only customer base in the world. However, IPv4/IPv6 intercommunication may become an issue in many scenarios.
出于明显的商业原因，只要世界上有大量只使用IPv4的客户群，就不需要使用只使用IPv6的公共服务。然而，在许多情况下，IPv4/IPv6互通可能会成为一个问题。
The IETF is expected to standardize a recommended IPv4/IPv6 translation algorithm, sometimes referred to as NAT64. It is specified in the following:
预计IETF将标准化推荐的IPv4/IPv6转换算法，有时称为NAT64。具体规定如下：
o "Framework for IPv4/IPv6 Translation" [RFC6144]
o "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052]
o "DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers" [RFC6147]
o "IP/ICMP Translation Algorithm" [RFC6145]
o "Stateful NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers" [RFC6146]
o "An FTP ALG for IPv6-to-IPv4 Translation" [FTP-ALG]
o "Framework for IPv4/IPv6 Translation" [RFC6144]
o "IPv6 Addressing of IPv4/IPv6 Translators" [RFC6052]
o "DNS64: DNS Extensions for Network Address Translation from IPv6
Clients to IPv4 Servers" [RFC6147]
o "IP/ICMP Translation Algorithm" [RFC6145]
o "Stateful NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers" [RFC6146]
o "An FTP ALG for IPv6-to-IPv4 Translation" [FTP-ALG]
The service, as described in the IETF's "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment" [RFC6180], provides for stateless translation between hosts in an IPv4-only domain or hosts that offer an IPv4-only service and hosts with an IPv4-embedded IPv6 address in an IPv6-only domain. It additionally provides access from IPv6 hosts with general format addresses to hosts in an IPv4-only domain or hosts that offer an IPv4-only service. It does not provide any-to-any translation. One result is that client-only hosts in the IPv6 domain gain access to IPv4 services through stateful translation. Another result is that the IPv6 network operator has
如IETF的“IPv6部署期间使用IPv6转换机制的指南”[RFC6180]中所述，该服务提供仅IPv4域中的主机或提供仅IPv4服务的主机与仅IPv6域中具有IPv4嵌入IPv6地址的主机之间的无状态转换。它还提供了从具有通用格式地址的IPv6主机到仅IPv4域中的主机或提供仅IPv4服务的主机的访问。它不提供任何对任何翻译。一个结果是IPv6域中的客户端主机通过有状态转换获得对IPv4服务的访问。另一个结果是IPv6网络运营商
the option of moving servers into the IPv6-only domain while retaining accessibility for IPv4-only clients through stateless translation of an IPv4-embedded IPv6 address.
通过IPv4嵌入IPv6地址的无状态转换，将服务器移动到仅IPv6域，同时保留仅IPv4客户端的可访问性的选项。
Also, "Architectural Implications of NAT" [RFC2993] applies across the service just as in IPv4/IPv4 translation: apart from the fact that a system with an IPv4-embedded IPv6 address is reachable across the NAT, which is unlike IPv4, any assumption on the application's part that a local address is meaningful to a remote peer and any use of an IP address literal in the application payload is a source of service issues. In general, the recommended mitigation for this is as follows:
此外，“NAT的体系结构含义”[RFC2993]适用于整个服务，就像在IPv4/IPv4转换中一样：除了具有IPv4嵌入IPv6地址的系统可以通过NAT访问之外，NAT与IPv4不同，应用程序方面的任何假设，即本地地址对远程对等方有意义，并且在应用程序有效负载中使用IP地址文字，都是服务问题的根源。一般而言，建议的缓解措施如下：
o Ideally, applications should use DNS names rather than IP address literals in URLs, URIs, and referrals, and in general be network layer agnostic.
o 理想情况下，应用程序应该在URL、URI和引用中使用DNS名称，而不是IP地址文本，并且通常是网络层不可知的。
o If they do not, the network may provide a relay or proxy that straddles the domains. For example, an SMTP Mail Transfer Agent (MTA) with both IPv4 and IPv6 connectivity handles IPv4/IPv6 translation cleanly at the application layer.
o 如果没有，网络可能会提供跨域的中继或代理。例如，同时具有IPv4和IPv6连接的SMTP邮件传输代理（MTA）可以在应用程序层干净地处理IPv4/IPv6转换。
For IPv4 traffic, the incremental CGN approach inherits all the problems of CGN address-sharing techniques [ADDR-ISSUES] (e.g., scaling and the difficulty of supporting well-known ports for inbound traffic). Application-layer problems created by double NAT are beyond the scope of this document.
对于IPv4流量，增量CGN方法继承了CGN地址共享技术的所有问题[ADDR-ISSUES]（例如，扩展和为入站流量支持知名端口的困难）。双NAT造成的应用层问题超出了本文档的范围。
For IPv6 traffic, a user behind the DS HG will see normal IPv6 service. We observe that an IPv6 tunnel MTU of at least 1500 bytes would ensure that the mechanism does not cause excessive fragmentation of IPv6 traffic or excessive IPv6 path MTU discovery interactions. This, and the absence of NAT problems for IPv6, will create an incentive for users and application service providers to prefer IPv6.
对于IPv6流量，DS HG后面的用户将看到正常的IPv6服务。我们观察到，至少1500字节的IPv6隧道MTU将确保该机制不会导致IPv6流量的过度碎片化或过度IPv6路径MTU发现交互。这以及IPv6不存在NAT问题，将激励用户和应用程序服务提供商选择IPv6。
ICMP filtering [RFC4890] may be included as part of CGN functions.
ICMP过滤[RFC4890]可作为CGN功能的一部分。
Transition from pure NAT444 CGN or 6rd to the incremental CGN approach is straightforward. The HG and CGN devices and their locations do not have to be changed; only software upgrading may be needed. In the ideal model, described below, even software upgrading is not necessary; reconfiguration of the devices is enough. NAT444 CGN solves the public address shortage issues in the current IPv4
从纯NAT444 CGN或6rd到增量CGN方法的过渡非常简单。HG和CGN设备及其位置无需更改；可能只需要软件升级。在下面描述的理想模型中，甚至软件升级都是不必要的；设备的重新配置就足够了。NAT444 CGN解决了当前IPv4中公共地址不足的问题
infrastructure. However, it does not contribute towards IPv6 deployment at all. The incremental CGN approach can inherit NAT444 CGN functions while providing overlay IPv6 services. 6rd mechanisms can also transform smoothly into this incremental CGN model. However, the home gateways need to be upgraded correspondingly to perform the steps described below
基础设施但是，它对IPv6部署毫无帮助。增量CGN方法可以继承NAT444 CGN函数，同时提供覆盖IPv6服务。第六种机制也可以顺利转换为这种增量CGN模型。然而，家庭网关需要相应地升级以执行下面描述的步骤
The incremental CGN can also easily be transitioned to an IPv6- enabled infrastructure, in which the ISP network is either dual-stack or IPv6-only.
增量CGN还可以很容易地过渡到支持IPv6的基础设施，其中ISP网络可以是双栈网络，也可以是仅支持IPv6的网络。
If the ISP prefers to move to dual-stack routing, the HG should simply switch off its v6-over-v4 function when it observes native IPv6 Router Advertisement (RA) or DHCPv6 traffic and then forward both IPv6 and IPv4 traffic directly while the dual-stack CGN keeps only its v4-v4 NAT function.
如果ISP倾向于采用双栈路由，HG应在观察本机IPv6路由器广告（RA）或DHCPv6流量时简单地关闭其v6-over-v4功能，然后直接转发IPv6和IPv4流量，而双栈CGN仅保留其v4-v4 NAT功能。
However, we expect ISPs to choose the approach described as incremental CGN here because they intend to avoid dual-stack routing and to move incrementally from IPv4-only routing to IPv6-only routing. In this case, the ideal model for the incremental CGN approach is that of an integrated configurable CGN device and an adaptive HG device. The integrated CGN device will be able to support multiple functions, including NAT444 CGN, 6rd router (or an alternative tunneling mechanism), DS-Lite, and dual-stack forwarding.
但是，我们希望ISP选择此处描述为增量CGN的方法，因为他们打算避免双堆栈路由，并从仅IPv4路由逐渐过渡到仅IPv6路由。在这种情况下，增量CGN方法的理想模型是集成可配置CGN设备和自适应HG设备。集成的CGN设备将能够支持多种功能，包括NAT444 CGN、6rd路由器（或替代隧道机制）、DS Lite和双堆栈转发。
The HG has to integrate the corresponding functions and be able to detect relevant incremental changes on the CGN side. Typically, the HG will occasionally poll the CGN to discover which features are operational. For example, starting from a pure IPv4-only scenario (in which the HG treats the CGN only as an IPv4 default router), the HG would discover (by infrequent polling) when 6rd became available. The home user would then acquire an IPv6 prefix. At a later stage, the HG would observe the appearance of native IPv6 Route Advertisement messages or DHCPv6 messages to discover the availability of an IPv6 service including DS-Lite. Thus, when an ISP decides to switch from incremental CGN to DS-Lite CGN, only a configuration change or a minor software update is needed on the CGNs. The home gateway would detect this change and switch automatically to DS-Lite mode. The only impact on the home user will be to receive a different IPv6 prefix.
HG必须集成相应的功能，并能够检测CGN侧的相关增量变化。通常，HG会偶尔轮询CGN，以发现哪些功能是可操作的。例如，从纯IPv4场景开始（HG仅将CGN视为IPv4默认路由器），HG将在第6条可用时发现（通过不频繁的轮询）。然后，家庭用户将获得IPv6前缀。在稍后阶段，HG将观察本机IPv6路由广告消息或DHCPv6消息的外观，以发现包括DS Lite在内的IPv6服务的可用性。因此，当ISP决定从增量CGN切换到DS Lite CGN时，CGN上只需要配置更改或少量软件更新。家庭网关将检测到此变化并自动切换到DS Lite模式。对家庭用户的唯一影响是接收不同的IPv6前缀。
In the smooth transition model, both CGN and HG are reusable devices during different transition periods. This avoids potential multiple upgrades. Different regions of the same ISP network may be at different stages of the incremental process, using identical
在平滑过渡模型中，CGN和HG在不同的过渡期都是可重用的设备。这避免了潜在的多次升级。同一ISP网络的不同区域可能处于增量过程的不同阶段，使用相同的
equipment but with different configurations of the incremental CGN devices in each region. Thus, IPv6 migration may be incrementally achieved according to the real ISP and customer requirements.
但在每个区域具有不同配置的增量CGN设备。因此，IPv6迁移可以根据实际ISP和客户需求逐步实现。
Security issues associated with NAT have been documented in [RFC2663] and [RFC2993]. Security issues for large-scale address sharing, including CGN, are discussed in [ADDR-ISSUES]. The present specification does not introduce any new features to CGN itself and hence no new security considerations. Security issues for 6rd are documented in [RFC5569] and [RFC5969], and those for DS-Lite are discussed in [DS-LITE].
[RFC2663]和[RFC2993]中记录了与NAT相关的安全问题。大规模地址共享（包括CGN）的安全问题在[ADDR-issues]中讨论。本规范没有向CGN本身引入任何新特性，因此没有新的安全考虑。[RFC5569]和[RFC5969]中记录了6rd的安全问题，而[DS-Lite]中讨论了DS-Lite的安全问题。
Since the tunnels proposed here exist entirely within a single ISP network between the HG/CPE and the CGN, the threat model is relatively simple. [RFC4891] describes how to protect tunnels using IPsec, but an ISP could reasonably deem its infrastructure to provide adequate security without the additional protection and overhead of IPsec. The intrinsic risks of tunnels are described in [RFC6169], which recommends that tunneled traffic should not cross border routers. The incremental CGN approach respects this recommendation. To avoid other risks caused by tunnels, it is important that any security mechanisms based on packet inspection and any implementation of ingress filtering are applied to IPv6 packets after they have been decapsulated by the CGN. The dual-stack home gateway will need to provide basic security functionality for IPv6 [RFC6092]. Other aspects are described in [RFC4864].
由于此处提出的隧道完全存在于HG/CPE和CGN之间的单一ISP网络中，因此威胁模型相对简单。[RFC4891]描述了如何使用IPsec保护隧道，但ISP可以合理地认为其基础设施能够提供足够的安全性，而无需IPsec的额外保护和开销。[RFC6169]中描述了隧道的内在风险，其中建议隧道流量不应跨越边界路由器。增量CGN方法尊重这一建议。为了避免隧道引起的其他风险，重要的是，在IPv6数据包被CGN解封后，应将任何基于数据包检查和任何入口过滤实现的安全机制应用于IPv6数据包。双栈家庭网关需要为IPv6提供基本的安全功能[RFC6092]。[RFC4864]中描述了其他方面。
Useful comments were made by Fred Baker, Dan Wing, Fred Templin, Seiichi Kawamura, Remi Despres, Janos Mohacsi, Mohamed Boucadair, Shin Miyakawa, Joel Jaeggli, Jari Arkko, Tim Polk, Sean Turner, and other members of the IETF V6OPS working group.
弗雷德·贝克、丹·荣格、弗雷德·坦普林、川村圣一、雷米·德斯普雷斯、雅诺斯·莫哈西、穆罕默德·布卡达尔、三川信孝、乔尔·杰格利、贾里·阿克科、蒂姆·波尔克、肖恩·特纳以及IETF V6OPS工作组的其他成员发表了有益的评论。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529]Carpenter，B.和C.Jung，“在没有明确隧道的IPv4域上传输IPv6”，RFC 2529，1999年3月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[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月。
[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月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798]De Clercq，J.，Ooms，D.，Prevost，S.，和F.Le Faucheur，“使用IPv6提供商边缘路由器（6PE）通过IPv4 MPLS连接IPv6孤岛”，RFC 4798，2007年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月。
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
[RFC4890]Davies，E.和J.Mohacsi，“防火墙中过滤ICMPv6消息的建议”，RFC 48902007年5月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[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月。
[RFC5558] Templin, F., Ed., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558]Templin，F.，Ed.，“虚拟企业遍历（VET）”，RFC55558，2010年2月。
[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月。
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[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. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[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, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RFC6180]Arkko，J.和F.Baker，“IPv6部署期间使用IPv6转换机制的指南”，RFC 6180，2011年5月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，Ed.，“IPv6客户边缘路由器的基本要求”，RFC 62042011年4月。
[IPUSAGE] G. Huston, IPv4 Address Report, June 2011, http://www.potaroo.net/tools/ipv4/index.html.
[IPUSAGE]G.Huston，IPv4地址报告，2011年6月，http://www.potaroo.net/tools/ipv4/index.html.
[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DS-LITE]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈LITE宽带部署”，正在进行的工作，2011年5月。
[ADDR-ISSUES] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2011.
[ADDR-ISSUES]福特，M.，布卡代尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，正在进行的工作，2011年3月。
[CGN-REQS] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, March 2011.
[CGN-REQS]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“IP地址共享方案的通用要求”，正在进行的工作，2011年3月。
[FTP-ALG] van Beijnum, I., "An FTP ALG for IPv6-to-IPv4 Translation", Work in Progress, May 2011.
[FTP-ALG]van Beijnum，I.，“用于IPv6到IPv4转换的FTP ALG”，正在进行的工作，2011年5月。
Authors' Addresses
作者地址
Sheng Jiang Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R. China EMail: jiangsheng@huawei.com
盛江华为技术有限公司中国北京市海淀区上地信息产业基地新西路3号华为大厦邮编：100085电子邮件：jiangsheng@huawei.com
Dayong Guo Huawei Technologies Co., Ltd Huawei Building, No.3 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District Beijing 100085 P.R. China EMail: guoseu@huawei.com
中国北京市海淀区上地信息产业基地新西路3号华为大厦大用国华为技术有限公司邮编100085电子邮件：guoseu@huawei.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: brian.e.carpenter@gmail.com
Brian Carpenter奥克兰大学计算机系PB 92019奥克兰，1142新西兰电子邮件：布瑞恩。E。carpenter@gmail.com