Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7269 Z. Cao
Category: Informational China Mobile
ISSN: 2070-1721 C. Xie
China Telecom
D. Binet
France Telecom-Orange
June 2014
Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7269 Z. Cao
Category: Informational China Mobile
ISSN: 2070-1721 C. Xie
China Telecom
D. Binet
France Telecom-Orange
June 2014
NAT64 Deployment Options and Experience
NAT64部署选项和经验
Abstract
摘要
This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document.
本文档总结了NAT64功能部署场景和操作经验。本文档中同时考虑了NAT64载波级NAT（NAT64-CGN）和NAT64服务器前端（NAT64-FE）。
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/rfc7269.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7269.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source-Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Test Results for Application Behavior . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source-Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Test Results for Application Behavior . . . . . . . 21
IPv6 is the only sustainable solution for numbering nodes on the Internet due to the IPv4 depletion. Network operators have to deploy IPv6-only networks in order to meet the needs of the expanding Internet without available IPv4 addresses.
由于IPv4耗尽，IPv6是唯一可持续的互联网节点编号解决方案。网络运营商必须部署仅限IPv6的网络，以满足在没有可用IPv4地址的情况下不断扩大的互联网的需求。
Single-stack IPv6 network deployment can simplify network provisioning; some justification was provided in 464XLAT [RFC6877]. IPv6-only connectivity confers some benefits to mobile operators as an example. In the mobile context, IPv6-only usage enables the use of a single IPv6 Packet Data Protocol (PDP) context or Evolved Packet System (EPS) bearer on Long Term Evolution (LTE) networks. This eliminates significant network costs (caused by employing two PDP contexts in some cases) and the need for IPv4 addresses to be assigned to customers. In broadband networks overall, it can allow for the scaling of edge-network growth to be decoupled from IPv4 numbering limitations.
单栈IPv6网络部署可以简化网络配置；464XLAT[RFC6877]中提供了一些理由。例如，仅IPv6连接为移动运营商带来了一些好处。在移动环境中，仅使用IPv6允许在长期演进（LTE）网络上使用单个IPv6分组数据协议（PDP）环境或演进分组系统（EPS）承载。这消除了巨大的网络成本（在某些情况下由于使用两个PDP上下文而导致）以及将IPv4地址分配给客户的需要。在整个宽带网络中，它可以允许边缘网络增长的扩展与IPv4编号限制分离。
In transition scenarios, some existing networks are likely to be IPv4 only for quite a long time. IPv6 networks and IPv6-only hosts will need to coexist with IPv4 numbered resources. Widespread dual-stack deployments have not materialized at the anticipated rate over the last 10 years, one possible conclusion being that legacy networks will not make the jump quickly. The Internet will include nodes that are dual stack, nodes that remain IPv4 only, and nodes that can be deployed as IPv6-only nodes. A translation mechanism based on a NAT64 function [RFC6145] [RFC6146] is likely to be a key element of Internet connectivity for IPv6-IPv4 interoperability.
在过渡场景中，一些现有网络可能只在相当长的一段时间内使用IPv4。IPv6网络和仅IPv6主机将需要与IPv4编号的资源共存。在过去10年中，广泛的双栈部署并没有以预期的速度实现，一个可能的结论是传统网络不会很快实现跳跃。Internet将包括双栈节点、仅保留IPv4的节点以及可部署为仅IPv6节点的节点。基于NAT64函数[RFC6145][RFC6146]的转换机制可能是实现IPv6-IPv4互操作性的互联网连接的关键要素。
[RFC6036] reports at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). Advice on NAT64 deployment and operations are therefore of some importance. [RFC6586] documents the implications for IPv6-only networks. This document intends to be specific to NAT64 network planning.
[RFC6036]报告至少有30%的操作员计划运行某种转换器（可能是NAT64/DNS64）。因此，有关NAT64部署和操作的建议具有一定的重要性。[RFC6586]记录了仅IPv6网络的含义。本文件旨在专门针对NAT64网络规划。
Regarding IPv4/IPv6 translation, [RFC6144] has described a framework for enabling networks to make interworking possible between IPv4 and IPv6 networks. Two operation modes (i.e., stateful translation and stateless translation) have been described in Section 3.2 of [RFC6144]. This document describes the usage of those two operation modes and has further categorized different NAT64 functions, locations, and use cases. The principal distinction of location is whether the NAT64 is located in a Carrier-Grade NAT or server Front End. The terms "NAT-CGN" and "NAT-FE" are understood to be a topological distinction indicating different features employed in a NAT64 deployment.
关于IPv4/IPv6转换，[RFC6144]描述了一个使网络能够在IPv4和IPv6网络之间实现互通的框架。[RFC6144]第3.2节描述了两种操作模式（即有状态转换和无状态转换）。本文档描述了这两种操作模式的用法，并对不同的NAT64功能、位置和用例进行了进一步分类。位置的主要区别在于NAT64是位于运营商级NAT还是服务器前端。术语“NAT-CGN”和“NAT-FE”被理解为表示NAT64部署中采用的不同特性的拓扑区别。
NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP network. IPv6-enabled subscribers leverage the NAT64-CGN to access existing IPv4 Internet services. The ISP as an administrative entity takes full control of the IPv6 side, but it has limited or no control on the IPv4 Internet side. NAT64-CGN deployments may have to consider the IPv4 Internet environment and services, and make appropriate configuration choices accordingly.
NAT64载波级NAT（NAT64-CGN）：将NAT64-CGN置于ISP网络中。支持IPv6的订户利用NAT64-CGN访问现有的IPv4 Internet服务。ISP作为管理实体完全控制IPv6端，但对IPv4 Internet端的控制有限或没有控制权。NAT64-CGN部署可能需要考虑IPv4 Internet环境和服务，并相应地做出适当的配置选择。
NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device with NAT64 functionality in a content provider or data center network. It could be, for example, a traffic load balancer or a firewall. The operator of the NAT64-FE has full control over the IPv4 network within the data center but only limited influence or control over the external Internet IPv6 network.
NAT64服务器前端（NAT64-FE）：NAT64-FE通常是在内容提供商或数据中心网络中具有NAT64功能的设备。例如，它可以是流量负载均衡器或防火墙。NAT64-FE的运营商完全控制数据中心内的IPv4网络，但对外部互联网IPv6网络的影响或控制有限。
Fixed network operators and mobile operators may locate NAT64 translators in access networks or in mobile core networks. NAT64 can be built into various devices, including routers, gateways, or firewalls, in order to connect IPv6 users to the IPv4 Internet. With regard to the numbers of users and the shortage of public IPv4 addresses, stateful NAT64 [RFC6146] is more suited to maximize sharing of public IPv4 addresses. The usage of stateless NAT64 can provide better transparency features [MOTIVATION], but it has to be coordinated with Address plus Port (A+P) processes [RFC6346] as specified in [MAP-T] in order to deal with an IPv4 address shortage.
固定网络运营商和移动运营商可以在接入网络或移动核心网络中定位NAT64转换器。NAT64可以内置到各种设备中，包括路由器、网关或防火墙，以便将IPv6用户连接到IPv4 Internet。考虑到用户数量和公共IPv4地址的短缺，有状态NAT64[RFC6146]更适合最大限度地共享公共IPv4地址。无状态NAT64的使用可以提供更好的透明特性[MOTIVATION]，但它必须与[MAP-T]中指定的地址加端口（A+P）进程[RFC6346]相协调，以解决IPv4地址短缺问题。
DNS64 [RFC6147] is recommended for use in combination with stateful NAT64, and it will likely be an essential part of an IPv6 single-stack network that couples to the IPv4 Internet. 464XLAT [RFC6877] can enable access of IPv4-only applications or applications that call IPv4 literal addresses. Using DNS64 will help 464XLAT to automatically discover NAT64 prefixes through [RFC7050]. Berkeley Internet Name Daemon (BIND) software supports that function. It's important to note that DNS64 generates the synthetic AAAA reply when services only provide A records. Operators should not expect to access IPv4 parts of a dual-stack server using NAT64/DNS64. The traffic is forwarded on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may be routed around rather than going through NAT64. Only the traffic going to IPv4-only services would traverse the NAT64 translator. In some sense, it encourages IPv6 usage and limits NAT translation compared to employing NAT44, where all traffic flows have to be translated. In some cases, NAT64-CGNs may serve double roles, i.e., as a translator and IPv6 forwarder. In mobile networks, NAT64 may be deployed as the default gateway serving all the IPv6 traffic. The traffic heading to a dual-stack server is only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested to be configured on the Internet-facing interfaces of NAT64. We tested on the top 100 websites (referring to [Alexa] statistics). 43% of websites are connected and forwarded on NAT64 since those websites have both AAAA and A records. With expansion of IPv6 support, the translation process on NAT64 will likely become less important over time. It should be noted that the DNS64-DNSSEC interaction [RFC6147] may impact validation of Resource Records retrieved from the DNS64 process. In particular, DNSSEC validation
建议将DNS64[RFC6147]与有状态NAT64结合使用，它很可能是连接到IPv4 Internet的IPv6单堆栈网络的重要组成部分。464XLAT[RFC6877]可以启用仅IPv4应用程序或调用IPv4文本地址的应用程序的访问。使用DNS64将有助于464XLAT通过[RFC7050]自动发现NAT64前缀。伯克利互联网名称守护程序（BIND）软件支持该功能。需要注意的是，DNS64在服务仅提供记录时生成合成AAAA应答。操作员不应期望使用NAT64/DNS64访问双堆栈服务器的IPv4部分。如果以双堆栈服务器为目标，则流量将在IPv6路径上转发。IPv6流量可能会在周围路由，而不是通过NAT64。只有流向仅IPv4服务的流量才会通过NAT64转换器。从某种意义上说，与使用NAT44相比，它鼓励使用IPv6并限制NAT转换，而NAT44需要转换所有流量。在某些情况下，NAT64 CGN可能扮演双重角色，即作为转换器和IPv6转发器。在移动网络中，NAT64可以部署为默认网关，为所有IPv6流量提供服务。流向双堆栈服务器的流量仅在NAT64上转发。因此，建议在NAT64面向互联网的接口上同时配置IPv6和IPv4。我们在前100名网站上进行了测试（参考[Alexa]统计数据）。43%的网站通过NAT64进行连接和转发，因为这些网站同时拥有AAAA和A记录。随着IPv6支持的扩展，NAT64上的翻译过程可能会随着时间的推移变得不那么重要。应该注意的是，DNS64-DNSSEC交互[RFC6147]可能会影响从DNS64进程检索的资源记录的验证。尤其是DNSSEC验证
will fail when DNS64 synthesizes AAAA records where there is a DNS query received with the "DNSSEC OK" (DO) bit set and the "Checking Disabled" (CD) bit set.
当DNS64合成AAAA记录时将失败，其中接收到带有“DNSSEC OK”（DO）位集和“Checking Disabled”（CD）位集的DNS查询。
All connections to IPv4 services from IPv6-only clients must traverse the NAT64-CGN. It can be advantageous from the viewpoint of troubleshooting and traffic engineering to carry the IPv6 traffic natively for as long as possible within an access network and translate packets only at or near the network egress. NAT64 may be a feature of the Autonomous System (AS) border in fixed networks. It may be deployed in an IP node beyond the Gateway GPRS Support Node (GGSN) or Packet Data Network Gateway (PDN-GW) in mobile networks or directly as part of the gateway itself in some situations. This allows consistent attribution and traceability within the service provider network. It has been observed that the process of correlating log information is problematic from multiple vendors' equipment due to inconsistent formats of log records. Placing NAT64 in a centralized location may reduce diversity of log format and simplify the network provisioning. Moreover, since NAT64 is only targeted at serving traffic flows from IPv6 to IPv4-only services, the user traffic volume should not be as high as in a NAT44 scenario, and therefore, the gateway's capacity in such a location may be less of a concern or a hurdle to deployment. On the other hand, placement in a centralized fashion would require more strict high-availability (HA) design. It would also make geolocation based on IPv4 addresses rather inaccurate as is currently the case for NAT44 CGNs already deployed in ISP networks. More considerations or workarounds on HA and traceability can be found in Sections 4 and 5.
从仅限IPv6的客户端到IPv4服务的所有连接都必须通过NAT64-CGN。从故障排除和流量工程的角度来看，在接入网络内尽可能长时间地以本机方式承载IPv6流量并且仅在网络出口处或其附近翻译分组是有利的。NAT64可以是固定网络中自治系统（AS）边界的特征。它可以部署在移动网络中网关GPRS支持节点（GGSN）或分组数据网络网关（PDN-GW）之外的IP节点中，或者在某些情况下直接作为网关本身的一部分。这允许服务提供商网络内的一致归属和可追溯性。据观察，由于日志记录的格式不一致，多个供应商设备的日志信息关联过程存在问题。将NAT64放置在一个集中的位置可以减少日志格式的多样性，并简化网络配置。此外，由于NAT64仅用于服务从IPv6到仅IPv4服务的流量，因此用户流量不应像NAT44场景中那样高，因此，网关在该位置的容量对部署来说可能不那么重要或困难。另一方面，以集中方式放置需要更严格的高可用性（HA）设计。它还将使基于IPv4地址的地理定位变得相当不准确，就像目前ISP网络中已经部署的NAT44 CGN一样。关于HA和可追溯性的更多注意事项或解决方法，请参见第4节和第5节。
NAT64 will likely coexist with NAT44 in a dual-stack network where IPv4 private addresses are allocated to customers. The coexistence has already been observed in mobile networks, in which dual-stack mobile phones normally initiate some dual-stack PDN/PDP Type [RFC6459] to query both IPv4/IPv6 addresses and IPv4-allocated addresses (which are very often private ones). [RFC6724] always prioritizes IPv6 connections regardless of whether the end-to-end path is native IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, a "Happy Eyeballs" [RFC6555] algorithm will direct some IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may depend on particular implementation choices or settings on a host-by-host basis, and it may differ from an operator's deterministic scheme. Our tests verified that hosts may find themselves switching between IPv4 and IPv6 paths as they access identical services, but at different times [COEXIST]. Since the topology on each path is
NAT64可能与NAT44共存于双栈网络中，在该网络中，IPv4专用地址分配给客户。在移动网络中已经观察到这种共存现象，其中双栈移动电话通常会启动一些双栈PDN/PDP类型[RFC6459]，以查询IPv4/IPv6地址和IPv4分配的地址（通常是专用地址）。[RFC6724]始终优先考虑IPv6连接，无论端到端路径是本机IPv6还是通过NAT64/DNS64转换为IPv4的IPv6。相反，“快乐眼球”[RFC6555]算法将引导一些IP流通过IPv4路径。IPv4/IPv6路径的选择可能取决于主机对主机的特定实现选择或设置，并且可能不同于运营商的确定性方案。我们的测试验证了主机在访问相同的服务时可能会发现自己在IPv4和IPv6路径之间切换，但在不同的时间[共存]。因为每个路径上的拓扑都是
potentially different, it may cause unstable user experience and some degradation of Quality of Experience (QoE) when falling back to the other protocol. It's also difficult for operators to find a solution to make a stable network with optimal resource utilization. In general, it's desirable to figure out the solution that will introduce IPv6/IPv4 translation service to IPv6-only hosts connecting to IPv4 servers, while making sure dual-stack hosts have at least one address family accessible via native service if possible. With the end-to-end native IPv6 environment available, hosts should be upgraded aggressively to migrate in favor of IPv6 only. There are ongoing efforts to detect host connectivity and propose a new DHCPv6 option [CONN-STATUS] to convey appropriate configuration information to the hosts.
可能不同的是，当退回到其他协议时，它可能会导致不稳定的用户体验和体验质量（QoE）的某些降低。运营商也很难找到一个解决方案，使网络稳定，资源利用率最佳。通常，我们希望找到一种解决方案，将IPv6/IPv4转换服务引入到只连接到IPv4服务器的IPv6主机，同时尽可能确保双堆栈主机至少有一个地址族可通过本机服务访问。有了端到端的本机IPv6环境，主机应该积极升级，以便只迁移到IPv6。目前正在努力检测主机连接，并提出一个新的DHCPv6选项[CONN-STATUS]，以向主机传递适当的配置信息。
Some Internet Content Providers (ICPs) may locate NAT64 in front of an Internet Data Center (IDC), for example, co-located with a load-balancing function. Load balancers are employed to connect different IP family domains and distribute workloads across multiple domains or internal servers. In some cases, IPv4 address exhaustion may not be a problem in an IDC's internal network. IPv6 support for some applications may require increased investment and workload, so IPv6 support may not be a priority. NAT64 can be used to support widespread IPv6 adoption on the Internet while maintaining access to IPv4-only applications.
一些互联网内容提供商（ICP）可能将NAT64定位在互联网数据中心（IDC）前面，例如，与负载平衡功能位于同一位置。负载平衡器用于连接不同的IP系列域，并跨多个域或内部服务器分配工作负载。在某些情况下，IPv4地址耗尽可能不是IDC内部网络的问题。对某些应用程序的IPv6支持可能需要增加投资和工作量，因此IPv6支持可能不是重点。NAT64可用于支持Internet上广泛采用IPv6，同时保持对仅IPv4应用程序的访问。
Different strategies have been described in [RFC6883]; they are referred to as "inside out" and "outside in". An IDC operator may implement the following practices in the NAT64-FE networking scenario.
[RFC6883]中描述了不同的策略；它们被称为“由内而外”和“由外而内”。IDC运营商可在NAT64-FE网络场景中实施以下实践。
o Some ICPs who already have satisfactory operational experience might adopt single-stack IPv6 operation in building data center networks, servers, and applications, as it allows new services to be delivered without having to consider IPv4 NAT or the address limitations of IPv4 networks. Stateless NAT64 [RFC6145] can used to provide services for IPv4-only customers. [SIIT] has provided further descriptions and guidelines.
o 一些已经拥有满意操作经验的ICP可以采用单栈IPv6操作来构建数据中心网络、服务器和应用程序，因为它允许在不考虑IPv4 NAT或IPv4网络地址限制的情况下交付新服务。无状态NAT64[RFC6145]可用于为仅IPv4的客户提供服务。[SIIT]提供了进一步的说明和指南。
o ICPs who attempt to offer customers IPv6 support in their application farms at an early stage will likely run proxies, load balancers, or translators that are configured to handle incoming IPv6 flows and proxy them to IPv4 back-end systems. Many load balancers integrate proxy functionality. IPv4 addresses configured in the proxy may be multiplexed like a stateful NAT64 translator. A similar challenge exists as more users with IPv6 connectivity access IPv4 networks. High loads on load balancers
o 在早期阶段尝试在其应用程序场中为客户提供IPv6支持的ICP可能会运行代理、负载平衡器或转换器，这些代理、负载平衡器或转换器配置为处理传入的IPv6流并将其代理到IPv4后端系统。许多负载平衡器集成了代理功能。在代理中配置的IPv4地址可以像有状态NAT64转换器一样进行多路复用。随着更多具有IPv6连接的用户访问IPv4网络，也存在类似的挑战。负载平衡器上的高负载
may be apt to cause additional latency, IPv4 pool exhaustion, etc. Therefore, this approach is only reasonable at an early stage. ICPs may employ dual stack or IPv6 single stack in a further stage, since native IPv6 is frequently more desirable than any of the transition solutions.
可能会导致额外的延迟、IPv4池耗尽等。因此，此方法仅在早期阶段合理。ICP可在下一阶段采用双栈或IPv6单栈，因为本机IPv6通常比任何过渡解决方案都更理想。
[RFC6144] recommends that AAAA records of load balancers or application servers can be directly registered in the authoritative DNS servers. In this case, there is no need to deploy DNS64 name servers. Those AAAA records can point to natively assigned IPv6 addresses or IPv4-converted IPv6 addresses [RFC6052]. Hosts are not aware of the NAT64 translator on the communication path. For testing purposes, operators could employ an independent subdomain, e.g., ipv6exp.example.com, to identify experimental IPv6 services to users. How to design the Fully Qualified Domain Name (FQDN) for the IPv6 service is outside the scope of this document.
[RFC6144]建议可以直接在权威DNS服务器中注册负载平衡器或应用程序服务器的AAAA记录。在这种情况下，不需要部署DNS64名称服务器。这些AAAA记录可以指向本机分配的IPv6地址或IPv4转换的IPv6地址[RFC6052]。主机不知道通信路径上的NAT64转换器。出于测试目的，运营商可以使用一个独立的子域（例如ipv6exp.example.com）来识别向用户提供的实验性IPv6服务。如何为IPv6服务设计完全限定域名（FQDN）超出了本文档的范围。
High Availability (HA) is a major requirement for every service and network service. Deploying redundancy mechanisms is essential to avoiding failure and significantly increasing the network reliability. It's useful not only to stateful NAT64 cases but also to stateless NAT64 gateways.
高可用性（HA）是每个服务和网络服务的主要要求。部署冗余机制对于避免故障和显著提高网络可靠性至关重要。它不仅适用于有状态NAT64情况，而且也适用于无状态NAT64网关。
Three redundancy modes are mainly used: Cold Standby, Warm Standby, and Hot Standby.
主要采用三种冗余方式：冷备、温备、热备。
o Cold Standby HA devices do not replicate the NAT64 states from the primary equipment to the backup. Administrators switch on the backup NAT64 only if the primary NAT64 fails. As a result, all existing established sessions through a failed translator will be disconnected. The translated flows will need to be recreated by end systems. Since the backup NAT64 is manually configured to switch over to active NAT64, it may have unpredictable impacts to the ongoing services.
o 冷备用HA设备不会将NAT64状态从主设备复制到备份设备。只有在主NAT64出现故障时，管理员才会打开备份NAT64。因此，通过故障转换器建立的所有现有会话都将断开连接。转换后的流需要由终端系统重新创建。由于备份NAT64被手动配置为切换到活动NAT64，因此它可能会对正在进行的服务产生不可预测的影响。
o Warm Standby is a flavor of the Cold Standby mode. Backup NAT64 would keep running once the primary NAT64 is working. This makes Warm Standby less time-consuming during the traffic failover. The Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a solution to enable automatic handover during Warm Standby. During testing, the handover took a maximum of 1 minute if the backup NAT64 had to take over routing and reconstruct the Binding
o 热备用是冷备用模式的一种。主NAT64工作后，备份NAT64将继续运行。这使得热备用在流量故障切换期间花费的时间更少。虚拟路由器冗余协议（VRRP）[RFC5798]是一种解决方案，可在热备用期间实现自动切换。在测试期间，如果备份NAT64必须接管路由并重建绑定，则切换最长需要1分钟
Information Bases (BIBs) for 30 million sessions. In the deployment phase, operators could balance loads on distinct NAT64 devices. Those NAT64 devices make a warm backup of each other.
3000万次会议的信息库（BIB）。在部署阶段，运营商可以平衡不同NAT64设备上的负载。这些NAT64设备彼此进行热备份。
o Hot Standby must synchronize the BIBs between the primary NAT64 and backup. When the primary NAT64 fails, the backup NAT64 takes over and maintains the state of all existing sessions. The internal hosts don't have to reconnect the external hosts. The handover time is extremely reduced. During testing that employed Bidirectional Forwarding Detection (BFD) [RFC5880] combined with VRRP, a handover time of only 35 ms for 30 million sessions was observed. Under ideal conditions, Hot Standby deployments could guarantee the session continuity for every service. In order to transmit session states in a timely manner, operators may have to deploy extra transport links between the primary NAT64 and the distant backup. The scale of synchronization of the data instance depends on the particular deployment. For example, if a NAT64-CGN serves 200,000 users, an average amount of 800,000 sessions per second is a rough estimate of the newly created and expired sessions. A physical 10 Gbit/s transport link may have to be deployed for the sync data transmission considering the amount of sync sessions at the peak and the capacity redundancy.
o 热备用必须在主NAT64和备份之间同步BIB。当主NAT64失败时，备份NAT64将接管并维护所有现有会话的状态。内部主机不必重新连接外部主机。切换时间大大缩短。在采用双向转发检测（BFD）[RFC5880]与VRRP相结合的测试期间，观察到3000万个会话的切换时间仅为35毫秒。在理想情况下，热备部署可以保证每个服务的会话连续性。为了及时传输会话状态，运营商可能必须在主NAT64和远程备份之间部署额外的传输链路。数据实例的同步规模取决于特定的部署。例如，如果一个NAT64-CGN服务200000个用户，平均每秒800000个会话是对新创建和过期会话的粗略估计。考虑到峰值的同步会话量和容量冗余，可能必须为同步数据传输部署10 Gbit/s的物理传输链路。
In general, Cold Standby and Warm Standby are simpler and less resource intensive, but they require clients to re-establish sessions when a failover occurs. Hot Standby increases resource consumption in order to synchronize state, but it potentially achieves seamless handover. For stateless NAT64, considerations are simple because state synchronization is unnecessary. Regarding stateful NAT64, it may be useful to investigate the performance tolerance of applications and the traffic characteristics in a particular network. Some test results are shown in the Appendix A.
一般来说，冷备份和热备份更简单，资源消耗更少，但它们要求客户端在发生故障切换时重新建立会话。热备用增加了资源消耗以同步状态，但它可能实现无缝切换。对于无状态NAT64，考虑事项很简单，因为不需要状态同步。关于有状态NAT64，研究应用程序的性能容差和特定网络中的流量特性可能是有用的。一些测试结果如附录A所示。
Our statistics in a mobile network shown that almost 91.21% of traffic is accounted by HTTP/HTTPS services. These services generally don't require session continuity. Hot Standby does not offer much benefit for those sessions on this point. In fixed networks, HTTP streaming, P2P, and online games would be the major traffic beneficiaries of Hot Standby replication [Cisco-VNI]. Consideration should be given to the importance of maintaining bindings for those sessions across failover. Operators may also consider the Average Revenue Per User (ARPU) when deploying a suitable redundancy mode. Warm Standby may still be adopted to cover most services, while Hot Standby could be used to upgrade the Quality of Experience (QoE) and using DNS64 to generate different synthetic responses for limited traffic or destinations. Further considerations are discussed at Section 6.
我们在移动网络中的统计数据显示，HTTP/HTTPS服务占据了几乎91.21%的流量。这些服务通常不需要会话连续性。在这一点上，热备用对这些会话没有多大好处。在固定网络中，HTTP流媒体、P2P和在线游戏将是热备份复制[Cisco VNI]的主要流量受益者。应考虑在故障切换过程中为这些会话维护绑定的重要性。当部署合适的冗余模式时，运营商也可以考虑每个用户的平均收入（ARPU）。热备用仍可用于覆盖大多数服务，而热备用可用于升级体验质量（QoE），并使用DNS64为有限的流量或目的地生成不同的合成响应。第6节讨论了进一步的考虑。
Load balancing is used to accompany redundancy design so that better scalability and resiliency can be achieved. Stateless NAT64s allow asymmetric routing, while anycast-based solutions are recommended in [MAP-DEPLOY]. The deployment of load balancing may make more sense to stateful NAT64s for the sake of avoiding single-point failures. Since the NAT64-CGN and NAT64-FE have distinct facilities, the following lists the considerations for each case.
负载平衡用于伴随冗余设计，以便实现更好的可伸缩性和弹性。无状态NAT64允许非对称路由，而[MAP-DEPLOY]中建议使用基于选播的解决方案。为了避免单点故障，负载平衡的部署对有状态NAT64更有意义。由于NAT64-CGN和NAT64-FE具有不同的设施，以下列出了每种情况下的注意事项。
o NAT64-CGN normally doesn't implement load-balancing functions; they may be implemented in other dedicated equipment. Therefore, the gateways have to resort to DNS64 or an internal host's behavior. Once DNS64 is deployed, the load balancing can be performed by synthesizing the AAAA response with different IPv6 prefixes. For the applications not requiring a DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in [RFC7050] and then select one based on a given prefix selection policy.
o NAT64-CGN通常不实现负载平衡功能；它们可以在其他专用设备中实现。因此，网关必须求助于DNS64或内部主机的行为。一旦部署了DNS64，就可以通过合成具有不同IPv6前缀的AAAA响应来执行负载平衡。对于不需要DNS解析器的应用程序，内部主机可以通过[RFC7050]中定义的方法学习多个IPv6前缀，然后根据给定的前缀选择策略选择一个前缀。
o A dedicated load balancer could be deployed at the front of a NAT64-FE farm. The load balancer could use proxy mode to redirect the flows to the appropriate NAT64 instance. Stateful NAT64s require a deterministic pattern to arrange the traffic in order to ensure outbound/inbound flows traverse the identical NAT64. Therefore, static scheduling algorithms, for example, a source-address-based policy, is preferred. A dynamic algorithm, for example, Round-Robin, may have impacts on applications seeking session continuity, which are described in Table 1.
o 可以在NAT64-FE场的前端部署专用负载平衡器。负载平衡器可以使用代理模式将流重定向到适当的NAT64实例。有状态NAT64需要确定的模式来安排流量，以确保出站/入站流通过相同的NAT64。因此，首选静态调度算法，例如基于源地址的策略。动态算法（例如循环）可能会对寻求会话连续性的应用程序产生影响，如表1所述。
Traceability is required in many cases, such as meeting accounting requirements and identifying the sources of malicious attacks. Operators are asked to record the NAT64 log information for specific periods of time. In our lab testing, the log information from 200,000 subscribers was collected from a stateful NAT64 gateway for 60 days. Syslog [RFC5424] has been adopted to transmit log messages from NAT64 to a log station. Each log message contains the transport protocol, source IPv6 address:port, translated IPv4 address:port, and timestamp. It takes almost 125 bytes in ASCII format. It has been verified that the rate of traffic flow is around 72,000 flows per second, and the volume of recorded information reaches up to 42.5 terabytes in the raw format. The volume is 29.07 terabytes in a
在许多情况下都需要可追溯性，例如满足会计要求和识别恶意攻击的来源。要求操作员记录特定时间段的NAT64日志信息。在我们的实验室测试中，来自200000个订阅者的日志信息从有状态NAT64网关收集了60天。采用Syslog[RFC5424]将日志消息从NAT64传输到日志站。每个日志消息都包含传输协议、源IPv6地址：端口、转换后的IPv4地址：端口和时间戳。ASCII格式几乎需要125个字节。经验证，流量约为每秒72000次，原始格式记录的信息量高达42.5 TB。该卷的容量为29.07 TB
compact format. At scale, operators have to build up dedicated transport links, storage systems, and servers for the purpose of managing such logging.
紧凑格式。在规模上，运营商必须建立专用的传输链路、存储系统和服务器来管理此类日志记录。
There are also several improvements that can be made to mitigate the issue. For example, stateful NAT64 could be configured with the bulk port allocation method. Once a subscriber creates the first session, a number of ports are pre-allocated. A bulk allocation message is logged indicating this allocation. Subsequent session creations will use one of the pre-allocated ports and hence do not require logging. The log volume in this case may be only one thousandth of that of dynamic port allocation. Some implementations may adopt static port-range allocations [DET-CGN] that eliminate the need for per-subscriber logging. As a side effect of those methods, the IPv4 multiplexing efficiency is decreased. For example, the utilization ratio of public IPv4 addresses drops to approximately 75% when the NAT64 gateway is configured with bulk port allocation. (The lab testing allocates each subscriber with 400 ports.) In addition, port-range-based allocation should consider port randomization as described in [RFC6056]. The trade-off among address multiplexing efficiency, logging storage compression, and port allocation complexity should be considered. More discussions can be found in [PORT-ALLOC]. The decision can balance usable IPv4 resources against investments in log systems.
为了缓解这个问题，还可以进行一些改进。例如，可以使用大容量端口分配方法配置有状态NAT64。一旦订户创建第一个会话，就会预先分配多个端口。将记录一条批量分配消息，指示此分配。后续会话创建将使用一个预先分配的端口，因此不需要日志记录。在这种情况下，日志容量可能只有动态端口分配的千分之一。一些实现可能采用静态端口范围分配[DET-CGN]，从而消除了对每个订户日志记录的需要。作为这些方法的副作用，IPv4多路复用效率降低。例如，当NAT64网关配置了大容量端口分配时，公共IPv4地址的利用率下降到大约75%。（实验室测试分配每个用户有400个端口）。此外，基于端口范围的分配应该考虑到端口随机化，如[RCF6056]中所描述的。应该考虑地址复用效率、日志存储压缩和端口分配复杂性之间的权衡。更多讨论请参见[PORT-ALLOC]。该决策可以平衡可用IPv4资源与日志系统投资。
IP addresses are usually used as inputs to geolocation services. The use of address sharing prevents these systems from resolving the location of a host based on IP address alone. Applications that assume such geographic information may not work as intended. The possible solutions listed in [RFC6967] are intended to bridge the gap. However, those solutions can only provide a suboptimal substitution to solve the problem of host identification; in particular, it may not solve today's problems with source identification through translation. The following lists current practices to mitigate the issue.
IP地址通常用作地理定位服务的输入。使用地址共享可防止这些系统仅基于IP地址解析主机位置。假定此类地理信息的应用程序可能无法按预期工作。[RFC6967]中列出的可能解决方案旨在弥补这一差距。然而，这些解决方案只能提供次优替代来解决宿主识别问题；特别是，它可能无法解决当今通过翻译识别源代码的问题。以下列出了缓解此问题的当前做法。
o Operators who adopt NAT64-FE may leverage the application-layer proxies, e.g., X-Forwarded-For (XFF) [RFC7239], to convey the IPv6 source address in HTTP headers. Those messages would be passed on to web servers. The log parsing tools are required to be able to support IPv6 and may lookup RADIUS servers for the target subscribers based on IPv6 addresses included in XFF HTTP headers. XFF is the de facto standard that has been integrated in most load balancers. Therefore, it may be superior to use in a NAT-FE environment. On the downside, XFF is specific to HTTP. It
o 采用NAT64-FE的运营商可以利用应用层代理，例如X-Forwarded-For（XFF）[RFC7239]，在HTTP头中传输IPv6源地址。这些消息将被传递到web服务器。日志解析工具需要能够支持IPv6，并且可以根据XFF HTTP头中包含的IPv6地址查找目标订阅者的RADIUS服务器。XFF是事实上的标准，已集成在大多数负载平衡器中。因此，它可能优于在NAT-FE环境中使用。另一方面，XFF特定于HTTP。信息技术
restricts usage so that the solution can't be applied to requests made over HTTPS. This makes geolocation problematic for HTTPS-based services.
限制使用，使解决方案无法应用于通过HTTPS发出的请求。这使得基于HTTPS的服务的地理定位问题重重。
o The NAT64-CGN equipment may not implement XFF. Geolocation based on shared IPv4 addresses is rather inaccurate in that case. Operators could subdivide the outside IPv4 address pool so an IPv6 address can be translated depending on the IPv6 subscriber's geographical locations. As a consequence, location information can be identified from a certain IPv4 address range. [RFC6967] also enumerates several options to reveal the host identifier. Each solution likely has its own specific usage. For the geolocation systems relying on a RADIUS database [RFC5580], we have investigated delivering NAT64 BIBs and Session Table Entries (STEs) to a RADIUS server [NAT64-RADIUS]. This method could provide a geolocation system with an internal IPv6 address to identify each user. It can be paired with [RFC5580] to convey the original source address through the same message bus.
o NAT64-CGN设备可能无法实现XFF。在这种情况下，基于共享IPv4地址的地理定位是相当不准确的。运营商可以细分外部IPv4地址池，以便根据IPv6订户的地理位置转换IPv6地址。因此，可以从某个IPv4地址范围识别位置信息。[RFC6967]还列举了几个选项以显示主机标识符。每个解决方案可能都有自己的特定用途。对于依赖RADIUS数据库[RFC5580]的地理定位系统，我们研究了向RADIUS服务器[NAT64-RADIUS]交付NAT64 BIB和会话表条目（STE）。这种方法可以为地理定位系统提供一个内部IPv6地址来识别每个用户。它可以与[RFC5580]配对，通过相同的消息总线传送原始源地址。
NAT64 is providing a translation capability between IPv6 and IPv4 end nodes. In order to provide reachability between two IP address families, NAT64-CGN has to implement appropriate application-aware functions, i.e., Application Layer Gateways (ALGs), where address translation is not sufficient and security mechanisms do not render the functions infeasible. Most NAT64-CGNs mainly provide FTP-ALG [RFC6384]. NAT64-FEs may have functional richness on the load balancer; for example, HTTP-ALG, HTTPS-ALG, RTSP-ALG, and SMTP-ALG have been supported. Those application protocols exchange IP address and port parameters within a control session, for example, using the "Via" field in a HTTP header, "Transport" field in an RTSP SETUP message, or "Received:" header in a SMTP message. ALG functions will detect those fields and make IP address translations. It should be noted that ALGs may impact the performance on a NAT64 box to some extent. ISPs as well as content providers might choose to avoid situations where the imposition of an ALG might be required. At the same time, it is also important to remind customers and application developers that IPv6 end-to-end usage does not require ALG imposition and therefore results in a better overall user experience.
NAT64提供了IPv6和IPv4终端节点之间的转换功能。为了提供两个IP地址族之间的可达性，NAT64-CGN必须实现适当的应用程序感知功能，即应用层网关（ALG），其中地址转换不充分，安全机制不会导致功能不可行。大多数NAT64 CGN主要提供FTP-ALG[RFC6384]。NAT64 FEs可能在负载平衡器上具有丰富的功能；例如，支持HTTP-ALG、HTTPS-ALG、RTSP-ALG和SMTP-ALG。这些应用程序协议在控制会话中交换IP地址和端口参数，例如，使用HTTP头中的“Via”字段、RTSP设置消息中的“Transport”字段或SMTP消息中的“Received:”头。ALG函数将检测这些字段并进行IP地址转换。需要注意的是，ALGs可能会在一定程度上影响NAT64机箱的性能。ISP和内容提供商可能会选择避免可能需要强制实施ALG的情况。同时，提醒客户和应用程序开发人员IPv6端到端使用不需要ALG强制，因此可以带来更好的总体用户体验，这一点也很重要。
The service reachability is also subject to the IPv6 support in the client side. We tested several kinds of applications as shown in the below table to verify the IPv6 support. The experiences of some applications are still aligned with [RFC6586]. For example, we tested P2P file sharing and streaming applications including eMule
服务的可访问性还取决于客户端对IPv6的支持。我们测试了下表所示的几种应用程序，以验证IPv6支持。一些应用程序的经验仍然与[RFC6586]保持一致。例如，我们测试了P2P文件共享和流媒体应用程序，包括eMule
v0.50a, Thunder v7.9, and PPS TV v3.2.0. It has been found there are some software issues with the support of IPv6 at this time. The application software would benefit from 464XLAT [RFC6877] until the software adds IPv6 support. A SIP-based voice call has been tested in the LTE mobile environment as specified in [IR.92]. The voice call failed due to the lack of NAT64 traversal when an IPv6 SIP user agent communicates with an IPv4 SIP user agent. In order to address the failure, Interactive Connectivity Establishment (ICE) as described in [RFC5245] is recommended to be supported for the SIP IPv6 transition. [RFC6157] describes both signaling and the media-layer process, which should be followed. In addition, it is worth noting that ICE is not only useful for NAT traversal, but also for firewall [RFC6092] traversal in a native IPv6 deployment.
v0.50a、Thunder v7.9和PPS TV v3.2.0。目前已经发现在支持IPv6的情况下存在一些软件问题。应用软件将受益于464XLAT[RFC6877]，直到该软件添加IPv6支持。根据[IR.92]中的规定，已经在LTE移动环境中测试了基于SIP的语音呼叫。由于IPv6 SIP用户代理与IPv4 SIP用户代理通信时缺少NAT64遍历，语音呼叫失败。为了解决故障，建议SIP IPv6转换支持[RFC5245]中所述的交互式连接建立（ICE）。[RFC6157]描述了应遵循的信令和媒体层过程。此外，值得注意的是，ICE不仅对NAT遍历有用，而且对本机IPv6部署中的防火墙[RFC6092]遍历也有用。
Different IPsec modes for VPN services have been tested, including IPsec Authentication Header (AH) and IPsec Encapsulating Security Payload (ESP). It has been shown that IPsec AH fails because the destination host detects the IP header changes and invalidates the packets. IPsec ESP failed in our testing because the NAT64 does not translate IPsec ESP (i.e., protocol 50) packets. It has been suggested that IPsec ESP would succeed if the IPsec client supports NAT traversal in the Internet Key Exchange Protocol (IKE) [RFC3947] and uses IPsec ESP over UDP [RFC3948].
VPN服务的不同IPsec模式已经过测试，包括IPsec身份验证头（AH）和IPsec封装安全负载（ESP）。已经表明，IPsec AH失败是因为目标主机检测到IP报头更改并使数据包无效。IPsec ESP在我们的测试中失败，因为NAT64不转换IPsec ESP（即协议50）数据包。有人建议，如果IPsec客户端支持Internet密钥交换协议（IKE）[RFC3947]中的NAT遍历，并通过UDP[RFC3948]使用IPsec ESP，则IPsec ESP将成功。
Table 1: The Tested Applications
表1：测试的应用程序
+----------------+----------------------------------------------------+
| Application | Results and Issues Found |
+----------------+----------------------------------------------------+
| Web service | Mostly pass; some failures due to IPv4 literals |
+----------------+----------------------------------------------------+
|Instant Message | Mostly fail; software can't support IPv6 |
+----------------+----------------------------------------------------+
| Games | Mostly pass for web-based games; mostly fail for |
| | standalone games due to the lack of IPv6 support |
| | in software |
+----------------+----------------------------------------------------+
| SIP VoIP | Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+
| IPsec VPN | Fail; the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+
|P2P file sharing| Mostly fail; software can't support IPv6, |
|and streaming | e.g., eMule, Thunder, and PPS TV |
+----------------+----------------------------------------------------+
| FTP | Pass |
+----------------+----------------------------------------------------+
| Email | Pass |
+----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+
| Application | Results and Issues Found |
+----------------+----------------------------------------------------+
| Web service | Mostly pass; some failures due to IPv4 literals |
+----------------+----------------------------------------------------+
|Instant Message | Mostly fail; software can't support IPv6 |
+----------------+----------------------------------------------------+
| Games | Mostly pass for web-based games; mostly fail for |
| | standalone games due to the lack of IPv6 support |
| | in software |
+----------------+----------------------------------------------------+
| SIP VoIP | Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+
| IPsec VPN | Fail; the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+
|P2P file sharing| Mostly fail; software can't support IPv6, |
|and streaming | e.g., eMule, Thunder, and PPS TV |
+----------------+----------------------------------------------------+
| FTP | Pass |
+----------------+----------------------------------------------------+
| Email | Pass |
+----------------+----------------------------------------------------+
Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" must not be less than 2 hours 4 minutes [RFC5382] for TCP sessions and 5 minutes for UDP sessions [RFC4787]. In some cases, NAT resources may be significantly consumed by largely inactive users. The NAT and other customers would suffer from service degradation due to port consumption by other subscribers using the same NAT64 device. A flexible NAT session control is desirable to resolve these issues. The Port Control Protocol (PCP) [RFC6887] could be a candidate to provide such capability. A NAT64-CGN should integrate with a PCP server to allocate available IPv4 address/port resources. Resources could be assigned to PCP clients through PCP MAP/PEER mode. Doing so might improve user experiences, for example, by assigning different sizes of port ranges for different subscribers. Those mechanisms are also helpful to minimize terminal battery consumption and reduce the number of keep-alive messages sent by mobile terminal devices.
会话状态通常由静态计时器管理。例如，“已建立连接空闲超时”的值对于TCP会话不得小于2小时4分钟[RFC5382]，对于UDP会话不得小于5分钟[RFC4787]。在某些情况下，NAT资源可能会被大部分不活跃的用户大量消耗。由于使用相同NAT64设备的其他用户使用端口，NAT和其他客户将遭受服务降级的影响。灵活的NAT会话控制有助于解决这些问题。端口控制协议（PCP）[RFC6887]可以作为提供这种能力的候选协议。NAT64-CGN应与PCP服务器集成，以分配可用的IPv4地址/端口资源。资源可以通过PCP映射/对等模式分配给PCP客户端。这样做可能会改善用户体验，例如，通过为不同的订阅者分配不同大小的端口范围。这些机制也有助于最大限度地减少终端电池消耗，减少移动终端设备发送的保持活动消息的数量。
Subscribers can also benefit from network reliability. It has been discussed that Hot Standby offers a satisfactory experience after outage of the primary NAT64 has occurred. Operators may rightly be concerned about the considerable investment required for NAT64 equipment relative to low ARPU. For example, transport links may be expensive, because the primary NAT64 and the backup are normally located at different locations, separated by a relatively large distance. Additional cost would be incurred to ensure the connectivity quality. However, that may be necessary to applications that are delay-sensitive and seek session continuity, for example, online games and live streaming. Operators may be able to get added value from those services by offering first-class services. The service sessions can be pre-configured on the gateway to Hot Standby mode depending on the subscriber's profile. The rest of the sessions can be covered by Cold or Warm Standby.
用户还可以从网络可靠性中受益。据讨论，在主NAT64发生停机后，热备用提供了令人满意的体验。相对于较低的ARPU，运营商可能会担心NAT64设备所需的大量投资。例如，传输链路可能很昂贵，因为主NAT64和备份通常位于不同的位置，彼此之间的距离相对较远。为确保连接质量，将产生额外费用。但是，对于延迟敏感并寻求会话连续性的应用程序，例如在线游戏和实时流媒体，这可能是必要的。运营商可以通过提供一流的服务从这些服务中获得附加值。服务会话可以在网关上预先配置为热备用模式，具体取决于订户的配置文件。其余的会话可以通过冷备或热备来覆盖。
IPv6 requires that every link in the Internet have a Maximum Transmission Unit (MTU) of 1280 octets or greater [RFC2460]. However, if NAT64 translation is deployed, some IPv4 MTU constrained link will be used in a communication path and the originating IPv6 nodes may therefore receive an ICMP Packet Too Big (PTB) message, reporting a Next-Hop MTU less than 1280 bytes. The result would be that IPv6 allows packets to contain a fragmentation header, without the packet being fragmented into multiple pieces. A NAT64 would receive IPv6 packets with a fragmentation header in which the "M" flag is set to 0 and the "Fragment Offset" is set to 0. Those packets likely impact other fragments already queued with the same
IPv6要求互联网中的每条链路的最大传输单元（MTU）为1280个八位字节或更大[RFC2460]。但是，如果部署了NAT64转换，则在通信路径中将使用一些受IPv4 MTU约束的链路，并且发起IPv6节点可能因此接收ICMP数据包过大（PTB）消息，报告下一跳MTU小于1280字节。结果将是IPv6允许数据包包含一个分段报头，而不会将数据包分段为多个片段。NAT64将接收具有分段标头的IPv6数据包，其中“M”标志设置为0，“分段偏移量”设置为0。这些数据包可能会影响已经使用相同数据包排队的其他片段
set of {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. If the NAT64 box is compliant with [RFC5722], there is a risk that all the fragments will have to be dropped.
{IPv6源地址、IPv6目标地址、片段标识}的集合。如果NAT64盒符合[RFC5722]，则存在必须丢弃所有碎片的风险。
[RFC6946] discusses how this situation could be exploited by an attacker to perform fragmentation-based attacks and also proposes improved handling of such packets. It requires enhancements on NAT64 gateway implementations to isolate the processing of packets. NAT64 devices should follow the recommendations and take steps to prevent the risks of fragmentation.
[RFC6946]讨论了攻击者如何利用这种情况执行基于碎片的攻击，并建议改进此类数据包的处理。它需要对NAT64网关实现进行增强，以隔离数据包的处理。NAT64设备应遵循建议并采取措施防止碎片风险。
Another approach that potentially avoids this issue is to configure the IPv4 MTU to more than 1260 bytes. This would prevent getting a PTB message for an MTU smaller than 1280 bytes. Such an operational consideration is hard to universally apply to the legacy "IPv4 Internet" that is bridged by NAT64-CGNs. However, it's a feasible approach in NAT64-FE cases, since an IPv4 network NAT64-FE is rather well-organized and operated by an IDC operator or content provider. Therefore, the MTU of an IPv4 network in NAT64-FE case is strongly recommended to be set to more than 1260 bytes.
另一种可能避免此问题的方法是将IPv4 MTU配置为超过1260字节。这将防止为小于1280字节的MTU获取PTB消息。这样的操作考虑很难普遍应用于由NAT64 CGN桥接的传统“IPv4 Internet”。然而，在NAT64-FE的情况下，这是一种可行的方法，因为IPv4网络NAT64-FE是由IDC运营商或内容提供商精心组织和运营的。因此，强烈建议将NAT64-FE情况下IPv4网络的MTU设置为大于1260字节。
Unique Local Addresses (ULAs) are defined in [RFC4193] to be renumbered within a network site for local communications. Operators may use ULAs as NAT64 prefixes to provide site-local IPv6 connectivity. Those ULA prefixes are stripped when the packets go to the IPv4 Internet; therefore, ULAs are only valid in the IPv6 site. The use of ULAs could help in identifying the translation traffic. [ULA-USAGE] provides further guidance on using ULAs.
唯一本地地址（ULA）在[RFC4193]中定义，在网络站点内重新编号，用于本地通信。运营商可以使用ULAs作为NAT64前缀来提供站点本地IPv6连接。当数据包进入IPv4互联网时，这些前缀被剥离；因此，ULA仅在IPv6站点中有效。使用ULAs有助于识别翻译流量。[ULA-USAGE]提供有关使用ULA的进一步指导。
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is assigned with only an IPv6 address and connected to a NAT64-CGN, when it connects to an IPv4 service, it would receive a AAAA record generated by the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will be selected as the source address to the ULA destination address. When the host has both IPv4 and IPv6 addresses, it would initiate both A and AAAA record lookup, then both the original A record and DNS64-generated AAAA record would be received. A host that is compliant with [RFC6724] will never prefer a ULA over an IPv4 address. An IPv4 path will always be selected. It may be undesirable because the NAT64-CGN will never be used. Operators may consider adding additional site-specific rows into the default policy table for host address selection in order to steer traffic flows through the NAT64-CGN. However, it involves significant costs to change a terminal's behavior. Therefore, it is not suggested that operators configure ULAs on a NAT64-CGN.
我们将ULAs配置为NAT64-CGN上的NAT64前缀。如果主机仅分配了IPv6地址并连接到NAT64-CGN，则当主机连接到IPv4服务时，它将收到DNS64生成的带有ULA前缀的AAAA记录。将选择一个全局单播地址（GUA）作为ULA目标地址的源地址。当主机同时具有IPv4和IPv6地址时，它将启动A和AAAA记录查找，然后将同时接收原始A记录和DNS64生成的AAAA记录。与[RFC6724]兼容的主机永远不会选择ULA而不是IPv4地址。将始终选择IPv4路径。这可能是不可取的，因为NAT64-CGN将永远不会被使用。运营商可以考虑将额外的站点特定行添加到默认策略表中，以用于主机地址选择，以引导通过NAT64-CGN的业务流。然而，改变终端的行为需要付出巨大的成本。因此，不建议操作员在NAT64-CGN上配置ULA。
ULAs can't work when hosts transit the Internet to connect with NAT64. Therefore, ULAs are not applicable to the case of NAT64-FE.
当主机通过Internet连接NAT64时，ULAs无法工作。因此，ULA不适用于NAT64-FE的情况。
This document presents the deployment experiences of NAT64 in CGN and FE scenarios. In general, RFC 6146 [RFC6146] provides TCP-tracking, address-dependent filtering mechanisms to protect NAT64 from Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators could also adopt unicast Reverse Path Forwarding (uRPF) [RFC3704] and blacklisting and whitelisting to enhance security by specifying access policies. For example, NAT64-CGN should forbid establishing NAT64 BIB for incoming IPv6 packets if they do not pass the uRPF check in Strict or Loose mode or if their source IPv6 address is blacklisted.
本文档介绍了NAT64在CGN和FE场景中的部署经验。通常，RFC 6146[RFC6146]提供TCP跟踪、地址相关过滤机制，以保护NAT64免受分布式拒绝服务（DDoS）的攻击。在NAT64-CGN情况下，运营商还可以采用单播反向路径转发（uRPF）[RFC3704]和黑名单和白名单，通过指定访问策略来增强安全性。例如，如果传入IPv6数据包在严格或松散模式下未通过uRPF检查，或者其源IPv6地址被列入黑名单，则NAT64-CGN应禁止为其建立NAT64 BIB。
Stateful NAT64-FE creates state and maps that connection to an internally facing IPv4 address and port. An attacker can consume the resources of the NAT64-FE device by sending an excessive number of connection attempts. Without a DDoS limitation mechanism, the NAT64-FE is exposed to attacks. The load balancer is recommended to enable the capabilities for line-rate DDOS defense, such as the employment of SYN proxy/cookie. In this case, division of the security domain is necessary as well. Therefore, load balancers could not only optimize the traffic distribution but also prevent service from quality deterioration due to security attacks.
有状态NAT64-FE创建状态并将该连接映射到内部面向IPv4的地址和端口。攻击者可以通过发送过多的连接尝试来消耗NAT64-FE设备的资源。如果没有DDoS限制机制，NAT64-FE将面临攻击。建议使用负载平衡器来启用线速率DDOS防御功能，例如使用SYN proxy/cookie。在这种情况下，还需要划分安全域。因此，负载均衡器不仅可以优化流量分配，还可以防止由于安全攻击而导致的服务质量下降。
The DNS64 process will potentially interfere with the DNSSEC functions [RFC4035], since the DNS response is modified and DNSSEC intends to prevent such changes. More detailed discussions can be found in [RFC6147].
DNS64进程可能会干扰DNSSEC功能[RFC4035]，因为DNS响应已修改，DNSSEC打算阻止此类更改。更详细的讨论见[RFC6147]。
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Tim Chown, Gert Doering, and Simon Perreault for their helpful comments.
作者要感谢贾里·阿尔科、丹·荣、雷米·德斯普雷斯、弗雷德·贝克、惠登、伊尔吉茨·范·贝伊纳姆、菲利普·马修斯、兰迪·布什、米凯尔·亚伯拉罕松、洛伦佐·科利蒂、盛江、尼克·希特利、蒂姆·周恩、格特·多林和西蒙·佩雷尔特的有益评论。
Many thanks to Wesley George, Lee Howard, and Satoru Matsushima for their detailed reviews.
非常感谢韦斯利·乔治、李·霍华德和松岛佐藤的详细评论。
The authors especially thank Joel Jaeggli and Ray Hunter for their efforts and contributions on editing, which substantially improved the readability of the document.
作者特别感谢Joel Jaeggli和Ray Hunter在编辑方面的努力和贡献，这大大提高了文档的可读性。
Thanks to Cameron Byrne who was an active coauthor of some earlier draft versions of this document.
感谢Cameron Byrne，他是本文件早期草稿的积极合著者。
The following individuals contributed extensively to the effort:
以下个人对这项工作作出了广泛贡献：
Qiong Sun China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 P.R. China Phone: +86-10-58552936 EMail: sunqiong@ctbri.com.cn
琼孙中国电信北京西直门内大街118号708室100035中国电话：+86-10-58552936电子邮件：sunqiong@ctbri.com.cn
QiBo Niu ZTE 50 RuanJian Road YuHua District, Nan Jing 210012 P.R. China EMail: niu.qibo@zte.com.cn
齐波牛中兴通讯中国南京雨花区阮建路50号邮编：210012电子邮件：牛。qibo@zte.com.cn
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[RFC3948]Huttunen，A.，Swander，B.，Volpe，V.，DiBurro，L.，和M.Stenberg，“IPsec ESP数据包的UDP封装”，RFC 3948，2005年1月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[RFC5382]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 54242009年3月。
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009.
[RFC5580]Tschofenig，H.，Adrangi，F.，Jones，M.，Lior，A.，和B.Aboba，“以半径和直径携带定位物体”，RFC 55802009年8月。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009.
[RFC5722]Krishnan，S.，“重叠IPv6片段的处理”，RFC 5722，2009年12月。
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[RFC5798]Nadas，S.，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，2010年3月。
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010.
[RFC5880]Katz，D.和D.Ward，“双向转发检测（BFD）”，RFC 58802010年6月。
[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. 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月。
[RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 Transition in the Session Initiation Protocol (SIP)", RFC 6157, April 2011.
[RFC6157]Camarillo，G.，El Malki，K.，和V.Gurbani，“会话启动协议（SIP）中的IPv6转换”，RFC 6157，2011年4月。
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
[RFC6384]van Beijnum，I.“用于IPv6到IPv4转换的FTP应用层网关（ALG）”，RFC 6384，2011年10月。
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6555]Wing，D.和A.Yourtchenko，“快乐眼球：双堆栈主机的成功”，RFC 6555，2012年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]南柴郡Wing，D.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, May 2013.
[RFC6946]Gont，F.，“IPv6原子碎片的处理”，RFC 69462013年5月。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 70502013年11月。
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", RFC 7239, June 2014.
[RFC7239]Peterson，A.和M.Nilsson，“转发HTTP扩展”，RFC 72392014年6月。
[Alexa] Alexa, "Top 500 Global Sites", April 2013, <http://www.alexa.com/topsites>.
[Alexa]Alexa，“全球500强网站”，2013年4月<http://www.alexa.com/topsites>.
[COEXIST] Kaliwoda, A. and D. Binet, "Co-existence of both dual-stack and IPv6-only hosts", Work in Progress, October 2012.
[共存]Kaliwoda，A.和D.Binet，“双栈和仅IPv6主机的共存”，正在进行的工作，2012年10月。
[CONN-STATUS] Patil, P., Boucadair, M., Wing, D., and T. Reddy, "IP Connectivity Status Notifications for DHCPv6", Work in Progress, February 2014.
[CONN-STATUS]Patil，P.，Boucadair，M.，Wing，D.，和T.Reddy，“DHCPv6的IP连接状态通知”，正在进行的工作，2014年2月。
[Cisco-VNI] Cisco, "Cisco VNI Global Mobile Data Traffic Forecast, 2012-2018", February 2014, <http://ciscovni.com/forecast-widget/index.html>.
[Cisco VNI]Cisco，“2012-2018年Cisco VNI全球移动数据流量预测”，2014年2月<http://ciscovni.com/forecast-widget/index.html>.
[DET-CGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", Work in Progress, January 2014.
[DET-CGN]Donley，C.，Grundemann，C.，Sarawat，V.，Sundaresan，K.，和O.Vautrin，“确定性地址映射以减少运营商级NAT部署中的日志记录”，正在进行的工作，2014年1月。
[IR.92] Global System for Mobile Communications Association (GSMA), "IMS Profile for Voice and SMS Version 7.0", March 2013.
[IR.92]全球移动通信系统协会（GSMA），“语音和短信7.0版IMS配置文件”，2013年3月。
[MAP-DEPLOY] Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment Considerations", Work in Progress, April 2014.
[MAP-DEPLOY]琼，Q.，陈，M.，陈，G.，邹，T.，和S.佩雷尔特，“地址和港口映射（MAP）-部署注意事项”，正在进行的工作，2014年4月。
[MAP-T] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", Work in Progress, February 2014.
[MAP-T]Li，X.，Bao，C.，Dec，W.，Troan，O.，Matsushima，S.，和T.Murakami，“地址和端口映射使用翻译（MAP-T）”，正在进行的工作，2014年2月。
[MOTIVATION] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, November 2012.
[动机]Boucadair，M.，Matsushima，S.，Lee，Y.，Bonness，O.，Borges，I.，和G.Chen，“运营商端无状态IPv4 over IPv6迁移解决方案的动机”，正在进行的工作，2012年11月。
[NAT64-RADIUS] Chen, G. and D. Binet, "Radius Attributes for Stateful NAT64", Work in Progress, July 2013.
[NAT64-RADIUS]Chen，G.和D.Binet，“有状态NAT64的RADIUS属性”，正在进行的工作，2013年7月。
[PORT-ALLOC] Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses", Work in Progress, April 2014.
[PORT-ALLOC]Chen，G.，Tsou，T.，Donley，C.，和T.Taylor，“共享IPv4地址的NAT64端口分配方法分析”，正在进行的工作，2014年4月。
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010.
[RFC6036]Carpenter，B.和S.Jiang，“IPv6部署的新兴服务提供商场景”，RFC 6036，2010年10月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，“提供住宅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月。
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6346]Bush，R.，“IPv4地址短缺的地址加端口（A+P）方法”，RFC 6346，2011年8月。
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012.
[RFC6459]Korhonen，J.，Soininen，J.，Patil，B.，Savolainen，T.，Bajko，G.，和K.Iisakkila，“第三代合作伙伴关系项目（3GPP）中的IPv6演进包系统（EPS）”，RFC 6459，2012年1月。
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012.
[RFC6586]Arkko，J.和A.Keranen，“纯IPv6网络的体验”，RFC 6586，2012年4月。
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，2013年4月。
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013.
[RFC6883]Carpenter，B.和S.Jiang，“互联网内容提供商和应用程序服务提供商的IPv6指南”，RFC 6883，2013年3月。
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, June 2013.
[RFC6967]Boucadair，M.，Touch，J.，Levis，P.，和R.Penno，“在共享地址部署中显示主机标识符（主机ID）的潜在解决方案分析”，RFC 6967，2013年6月。
[SIIT] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", Work in Progress, November 2012.
[SIIT]Anderson，T.，“IPv6数据中心环境中的无状态IP/ICMP转换”，正在进行的工作，2012年11月。
[ULA-USAGE] Liu, B. and S. Jiang, "Recommendations of Using Unique Local Addresses", Work in Progress, February 2014.
[ULA-USAGE]Liu，B.和S.Jiang，“使用唯一本地地址的建议”，正在进行的工作，2014年2月。
We tested several application behaviors in a lab environment to evaluate the impact when a primary NAT64 is out of service. In this testing, participants were asked to connect an IPv6-only WiFi network using laptops, tablets, or mobile phones. NAT64 was deployed as the gateway to provide Internet service. The tested applications are shown in the table below. Cold Standby, Warm Standby, and Hot Standby were each tested. The participants may have experienced service interruption due to the NAT64 handover. Different interruption intervals were tested to gauge application behaviors. The results are shown below.
我们在实验室环境中测试了几个应用程序行为，以评估主NAT64停止服务时的影响。在这项测试中，参与者被要求使用笔记本电脑、平板电脑或手机连接一个仅限IPv6的WiFi网络。NAT64被部署为提供互联网服务的网关。测试的应用程序如下表所示。分别测试冷备用、热备用和热备用。参与者可能由于NAT64切换而经历了服务中断。测试不同的中断间隔，以评估应用行为。结果如下所示。
Table 2: The Acceptable Delay of Applications
表2：可接受的申请延期
+----------------+------------------------+-------------------------+
| Application | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web browsing | Maximum of 6 s | No |
+----------------+------------------------+-------------------------+
| HTTP streaming | Maximum of 10 s (cache)| Yes |
+----------------+------------------------+-------------------------+
| Games | 200-400 ms | Yes |
+----------------+------------------------+-------------------------+
|P2P file sharing| 10-16 s | Yes |
|and streaming | | |
+----------------+------------------------+-------------------------+
| Instant Message| 1 minute | Yes |
+----------------+------------------------+-------------------------+
| Email | 30 s | No |
+----------------+------------------------+-------------------------+
| Downloading | 1 minute | No |
+----------------+------------------------+-------------------------+
+----------------+------------------------+-------------------------+
| Application | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web browsing | Maximum of 6 s | No |
+----------------+------------------------+-------------------------+
| HTTP streaming | Maximum of 10 s (cache)| Yes |
+----------------+------------------------+-------------------------+
| Games | 200-400 ms | Yes |
+----------------+------------------------+-------------------------+
|P2P file sharing| 10-16 s | Yes |
|and streaming | | |
+----------------+------------------------+-------------------------+
| Instant Message| 1 minute | Yes |
+----------------+------------------------+-------------------------+
| Email | 30 s | No |
+----------------+------------------------+-------------------------+
| Downloading | 1 minute | No |
+----------------+------------------------+-------------------------+
Authors' Addresses
作者地址
Gang Chen China Mobile Xuanwumenxi Ave. No. 32 Xuanwu District Beijing 100053 P.R. China
陈刚中国移动北京市宣武区宣武门西路32号，邮编100053
EMail: chengang@chinamobile.com, phdgang@gmail.com
EMail: chengang@chinamobile.com, phdgang@gmail.com
Zhen Cao China Mobile Xuanwumenxi Ave. No. 32 Xuanwu District Beijing 100053 P.R. China
中国北京市宣武区宣武门西大街32号中国移动真曹100053
EMail: caozhen@chinamobile.com, zehn.cao@gmail.com
EMail: caozhen@chinamobile.com, zehn.cao@gmail.com
Chongfeng Xie China Telecom Room 708, No. 118, Xizhimennei Street Beijing 100035 P.R. China
中国北京西直门内大街118号崇丰谢中国电信708室，邮编100035
EMail: xiechf@ctbri.com.cn
EMail: xiechf@ctbri.com.cn
David Binet France Telecom-Orange Rennes 35000 France
David Binet法国电信橙色雷恩35000法国
EMail: david.binet@orange.com
EMail: david.binet@orange.com