Internet Engineering Task Force (IETF) R. Penno
Request for Comments: 6889 Cisco Systems, Inc.
Category: Informational T. Saxena
ISSN: 2070-1721 Cisco Systems
M. Boucadair
France Telecom
S. Sivakumar
Cisco Systems
April 2013
Internet Engineering Task Force (IETF) R. Penno
Request for Comments: 6889 Cisco Systems, Inc.
Category: Informational T. Saxena
ISSN: 2070-1721 Cisco Systems
M. Boucadair
France Telecom
S. Sivakumar
Cisco Systems
April 2013
Analysis of Stateful 64 Translation
有状态翻译分析
Abstract
摘要
Due to specific problems, Network Address Translation - Protocol Translation (NAT-PT) was deprecated by the IETF as a mechanism to perform IPv6-IPv4 translation. Since then, new efforts have been undertaken within IETF to standardize alternative mechanisms to perform IPv6-IPv4 translation. This document analyzes to what extent the new stateful translation mechanisms avoid the problems that caused the IETF to deprecate NAT-PT.
由于特定的问题，IETF不赞成将网络地址转换-协议转换（NAT-PT）作为执行IPv6-IPv4转换的机制。从那时起，IETF内部进行了新的努力，以标准化执行IPv6-IPv4转换的替代机制。本文分析了新的有状态转换机制在多大程度上避免了导致IETF反对NAT-PT的问题。
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/rfc6889.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6889.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of 64 Translation against Concerns of RFC 4966 . . . 4
2.1. Problems Impossible to Solve . . . . . . . . . . . . . . . 4
2.2. Problems That Can Be Solved . . . . . . . . . . . . . . . 5
2.3. Problems Solved . . . . . . . . . . . . . . . . . . . . . 7
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Analysis of 64 Translation against Concerns of RFC 4966 . . . 4
2.1. Problems Impossible to Solve . . . . . . . . . . . . . . . 4
2.2. Problems That Can Be Solved . . . . . . . . . . . . . . . 5
2.3. Problems Solved . . . . . . . . . . . . . . . . . . . . . 7
3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 13
This document uses stateful 64 (or 64 for short) to refer to the mechanisms defined in the following documents:
本文档使用stateful 64（简称64）来引用以下文档中定义的机制：
o IP/ICMP Translation Algorithm [RFC6145]
o IP/ICMP转换算法[RFC6145]
o Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [RFC6146]
o 有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换[RFC6146]
o DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [RFC6147]
o DNS64:用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展[RFC6147]
o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]
o IPv4/IPv6转换器的IPv6寻址[RFC6052]
o Framework for IPv4/IPv6 Translation [RFC6144]
o IPv4/IPv6转换框架[RFC6144]
Stateful 64 is widely seen as a major interconnection technique designed to enable communications between IPv6-only and IPv4-only networks. One of the building blocks of the stateful 64 is decoupling the DNS functionality from the protocol translation itself.
有状态64被广泛认为是一种主要的互连技术，旨在实现仅IPv6和仅IPv4网络之间的通信。有状态64的构建块之一是将DNS功能与协议转换本身分离。
This approach is pragmatic in the sense that there is no dependency on DNS implementation for the successful NAT handling. As long as there is a function (e.g., DNS64 [RFC6147] or other means) that can construct an IPv6-embedded IPv4 address with a pre-configured IPv6 prefix, an IPv4 address and a suffix (refer to [RFC6052]), NAT64 will work just fine.
这种方法是实用的，因为成功的NAT处理不依赖于DNS实现。只要有一个函数（例如DNS64[RFC6147]或其他方法）可以使用预先配置的IPv6前缀、IPv4地址和后缀（请参阅[RFC6052]）构造IPv6嵌入IPv4地址，NAT64就可以正常工作。
The focus of the stateful 64 is on the deployment and not the implementation details. As long as a NAT64 implementation conforms to the expected behavior, as desired in the deployment scenario, the details are not very important as mentioned in this excerpt from [RFC6146]:
有状态64的重点是部署，而不是实现细节。只要NAT64实现符合部署场景中所需的预期行为，细节就不会像[RFC6146]摘录中提到的那样非常重要：
A NAT64 MAY perform the steps in a different order, or MAY perform different steps, but the externally visible outcome MUST be the same as the one described in this document.
NAT64可以以不同的顺序执行步骤，也可以执行不同的步骤，但外部可见的结果必须与本文档中描述的结果相同。
This document provides an analysis of how the proposed set of documents that specify stateful IPv6-only to IPv4-only translation and replace Network Address Translation - Protocol Translation (NAT-PT) [RFC2766] address the issues raised in [RFC4966].
本文档提供了一组拟议文档的分析，这些文档指定了仅限状态IPv6到仅限IPv4的转换，并取代了网络地址转换-协议转换（NAT-PT）[RFC2766]解决了[RFC4966]中提出的问题。
As a reminder, it is worth mentioning the analysis is limited in the sense that hosts from IPv6 networks can initiate a communication to IPv4 network/Internet, but not vice versa. This corresponds to Scenarios 1 and 5 described in [RFC6144]. Hence, the scenario of servers moving to IPv6 while clients remaining IPv4 remains unaddressed. Of course, IPv6-to-IPv4 communications can also be supported if static or explicit bindings (e.g., [RFC6887]) are configured on the stateful NAT64.
值得一提的是，分析的局限性在于，来自IPv6网络的主机可以启动到IPv4网络/Internet的通信，但反之亦然。这对应于[RFC6144]中描述的场景1和场景5。因此，服务器迁移到IPv6而客户端保留IPv4的情况仍然没有得到解决。当然，如果在有状态NAT64上配置了静态或显式绑定（例如，[RFC6887]），也可以支持IPv6到IPv4的通信。
Stateful 64, just like any other technique under development, has some positives and some drawbacks. The ups and downs of the proposal must be clearly understood while going forward with its future development.
stateful64和其他正在开发的技术一样，有一些优点，也有一些缺点。在推进该提案的未来发展时，必须清楚地了解该提案的起起落落。
The scope of this document does not include stateless translation.
本文件的范围不包括无状态翻译。
Of the set of problems pointed out in [RFC4966], the stateful 64 addresses some of them, whereas it leaves others unaddressed.
在[RFC4966]中指出的一组问题中，有状态64解决了其中一些问题，而其他问题则没有得到解决。
Some issues mentioned in [RFC4966] were solved by [RFC4787], [RFC5382], and [RFC5508]. At the time when NAT-PT was published, these recommendations were not in place but they are orthogonal to the translation algorithm per se; therefore, they could be implemented with NAT-PT. On the other hand, NAT64 [RFC6146] explicitly mentions that these recommendations need to be followed and thus should be seen as a complete specification.
[RFC4966]中提到的一些问题由[RFC4787]、[RFC5382]和[RFC5508]解决。在NAT-PT发布时，这些建议尚未到位，但它们与翻译算法本身是正交的；因此，它们可以通过NAT-PT实现。另一方面，NAT64[RFC6146]明确提到需要遵循这些建议，因此应将其视为完整的规范。
It is also worth pointing out that the scope of the stateful 64 is reduced when compared to NAT-PT. Following is a point-by-point analysis of the problems. This document classifies the issues listed in [RFC4966] into three categories:
还值得指出的是，与NAT-PT相比，有状态64的范围缩小了。下面是对问题的逐点分析。本文件将[RFC4966]中列出的问题分为三类：
1. Problems impossible to solve.
1. 无法解决的问题。
2. Problems that can be solved.
2. 可以解决的问题。
3. Problems solved.
3. 问题解决了。
Problems discussed in [RFC4966] that are impossible to solve:
[RFC4966]中讨论的无法解决的问题：
1. Inability to redirect traffic for protocols that lack de-multiplexing capabilities or are not built on top of specific transport-layer protocols for transport address translations (Section 2.2 of [RFC4966]).
1. 无法为缺乏解复用功能或未构建在传输地址转换的特定传输层协议之上的协议重定向通信量（RFC4966第2.2节）。
Analysis: This issue is not specific to 64 but to all NAT-based solutions.
分析：此问题并非针对64，而是针对所有基于NAT的解决方案。
2. Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols (Section 2.4 of [RFC4966]).
2. 由于IPv4和IPv6版本的报头和协议之间的语义不兼容而导致信息丢失（RFC4966第2.4节）。
Analysis: This issue is not specific to 64 but is due to the design of IPv4 and IPv6.
分析：此问题并非特定于64，而是由于IPv4和IPv6的设计。
3. Need for the NAT64-capable device to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility (Section 2.7 of [RFC4966]).
3. 当IPv6节点移动时，需要支持NAT64的设备作为对应节点的代理，从而限制移动性（RFC4966第2.7节）。
Analysis: This is not specific to NAT64 but to all NAT flavors. Refer to [NAT64-HARMFUL] for an early analysis on mobility complications encountered when NAT64 is involved.
分析：这不是NAT64特有的，而是所有NAT口味的。参考[NAT64-HAMARY]，了解涉及NAT64时遇到的移动并发症的早期分析。
Problems discussed in [RFC4966] that can be solved:
[RFC4966]中讨论的可以解决的问题：
1. Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports) (Section 2.1 of [RFC4966]).
1. 中断在数据包有效负载中嵌入IP地址（和/或端口）或使用IP地址（和端口）应用完整性机制的所有协议（RFC4966第2.1节）。
Analysis: In the case of FTP [RFC0959], this problem can be mitigated in several ways (e.g., use a FTP64 Application Layer Gateway (ALG) [RFC6384] or in the FTP client (e.g., [FTP64])).
分析：在FTP[RFC0959]的情况下，可以通过几种方式缓解此问题（例如，使用FTP64应用层网关（ALG）[RFC6384]或在FTP客户端（例如[FTP64]）。
In the case of SIP [RFC3261], no specific issue is induced by 64; the same techniques for NAT traversal can be used when a NAT64 is involved in the path (e.g., Interactive Connectivity Establishment (ICE) [RFC5245], maintain SIP-related NAT bindings as per Section 3.4 of [RFC5853], media latching [MIDDLEBOXES], embedded SIP ALGs, etc.). [RFC6157] provides more discussion on how to establish SIP sessions between IPv4 and IPv6 SIP user agents.
在SIP[RFC3261]的情况下，64不会引发具体问题；当NAT64涉及路径时，可以使用相同的NAT遍历技术（例如，交互式连接建立（ICE）[RFC5245]，根据[RFC5853]第3.4节维护SIP相关NAT绑定，媒体锁存[Middlebox]，嵌入式SIP ALG等）。[RFC6157]提供了有关如何在IPv4和IPv6 SIP用户代理之间建立SIP会话的更多讨论。
The functioning of other protocols is left for future study. Note that the traversal of NAT64 by application embedding IP address literal is not specific to NAT64 but generic to all NAT-based solutions.
其他协议的功能留给未来研究。请注意，应用程序嵌入IP地址文字对NAT64的遍历不是NAT64特有的，而是所有基于NAT的解决方案的通用。
2. Interaction with Stream Control Transmission Protocol (SCTP) [RFC4960] and multihoming (Section 2.6 of [RFC4966]).
2. 与流控制传输协议（SCTP）[RFC4960]和多主（RFC4966]第2.6节）的交互。
Analysis: Only TCP and UDP transport protocols are within the scope of NAT64 [RFC6146]. SCTP is out of scope of this document.
分析：只有TCP和UDP传输协议在NAT64[RFC6146]的范围内。SCTP不在本文件范围内。
3. Inability to handle multicast traffic (Section 2.8 of [RFC4966]).
3. 无法处理多播通信量（RFC4966第2.8节）。
Analysis: This problem is not addressed by the current 64 specifications.
分析：当前64个规范未解决此问题。
4. Scalability concerns together with introduction of a single point of failure and a security attack nexus (Section 3.2 of [RFC4966]).
4. 可扩展性问题以及引入单点故障和安全攻击关系（RFC4966第3.2节）。
Analysis: This is not specific to NAT64 but to all stateful NAT flavors. The presence of a single point of failure is deployment-specific; some service providers may deploy state synchronization means while others may only rely on a distributed NAT64 model.
分析：这不是NAT64特有的，而是所有有状态的NAT风格。单点故障的存在是特定于部署的；一些服务提供商可能部署状态同步手段，而其他服务提供商可能仅依赖分布式NAT64模型。
5. Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it (Section 4.2 of [RFC4966]).
5. 翻译后DNS记录的有效性受限：翻译后的记录可能会转发给无法使用它的应用程序（RFC4966第4.2节）。
Analysis: If a node on the IPv4 side forwards the address of the other endpoint to a node that cannot reach the NAT box or is not covered under the endpoint-independent constraint of NAT, then the new node will not be able to initiate a successful session.
分析：如果IPv4端的一个节点将另一个端点的地址转发给一个无法到达NAT框或不受NAT的端点独立约束的节点，那么新节点将无法启动成功的会话。
Actually, this is not a limitation of 64 (or even NAT-PT) but a deployment context where IPv4 addresses managed by the NAT64 are not globally reachable. The same limitation can be encountered when referrals (even without any NAT in the path) include reachability information with limited reachability scope (see [REFERRAL] for more discussion about issues related to reachability scope).
实际上，这不是64（甚至NAT-PT）的限制，而是NAT64管理的IPv4地址无法全局访问的部署上下文。当引用（即使路径中没有任何NAT）包含可访问性范围有限的可访问性信息时，也会遇到相同的限制（有关可访问性范围相关问题的更多讨论，请参阅[引用]）。
6. IPsec traffic using AH (Authentication Header) [RFC4302] in both transport and tunnel modes cannot be carried through NAT-PT without terminating the security associations on the NAT-PT, due to the inclusion of IP header fields in the scope of AH's cryptographic integrity protection [RFC3715] (Section 2.1 of [RFC4966]). In addition, IPsec traffic using ESP (Encapsulating Security Payload) [RFC4303] in transport mode generally uses UDP encapsulation [RFC3948] for NAT traversal (including NAT-PT traversal) in order to avoid the problems described in [RFC3715] (Section 2.1 of [RFC4966]).
6. 由于AH的加密完整性保护[RFC3715]（RFC4966）的第2.1节）范围中包含了IP头字段，因此在传输和隧道模式下使用AH（认证头）[RFC4302]的IPsec通信不能通过NAT-PT进行，而不终止NAT-PT上的安全关联。此外，在传输模式下使用ESP（封装安全有效负载）[RFC4303]的IPsec通信通常使用UDP封装[RFC3948]进行NAT遍历（包括NAT-PT遍历），以避免[RFC3715]（RFC4966第2.1节）中描述的问题。
Analysis: This is not specific to NAT64 but to all NAT flavors.
分析：这不是NAT64特有的，而是所有NAT口味的。
7. Address selection issues when either the internal or external hosts implement both IPv4 and IPv6 (Section 4.1 of [RFC4966]).
7. 内部或外部主机同时实现IPv4和IPv6时的地址选择问题（RFC4966第4.1节）。
Analysis: This is out of scope of 64 since Scenarios 1 and 5 of [RFC6144] assume IPv6-only hosts.
分析：这超出了64的范围，因为[RFC6144]的场景1和5假设只有IPv6主机。
Therefore, this issue is not resolved and mitigation techniques outside the 64 need to be used (e.g., [ADDR-SELECT]). These techniques may allow one to offload NAT64 resources and prefer native communications that do not involve address family translation. Avoiding NAT devices in the path is encouraged for mobile nodes in order to save power consumption due to keepalive messages that are required to maintain NAT states ("always-on" services). An in-depth discussion can be found in [DNS64].
因此，这个问题没有得到解决，需要使用64之外的缓解技术（例如[ADDR-SELECT]）。这些技术可能允许人们卸载NAT64资源，并且更喜欢不涉及地址族转换的本机通信。建议移动节点避免路径中的NAT设备，以节省由于保持NAT状态所需的保留消息（“始终打开”服务）而产生的功耗。有关详细讨论，请参见[DNS64]。
Problems identified in [RFC4966] that have been solved:
[RFC4966]中确定的已解决问题：
1. Constraints on network topology (as it relates to DNS-ALG; see Section 3.1 of [RFC4966]).
1. 网络拓扑约束（与DNS-ALG相关；参见[RFC4966]第3.1节）。
Analysis: The severity of this issue has been mitigated by the separation of the DNS from the NAT functionality. Nevertheless, a minimal coordination may be required to ensure that the NAT64 to be crossed (the one to which the IPv4- Converted IPv6 address returned to a requesting host) must be in the path and has also sufficient resources to handle received traffic.
分析：DNS与NAT功能的分离减轻了此问题的严重性。然而，可能需要最低限度的协调，以确保要跨越的NAT64（IPv4转换的IPv6地址返回给请求主机的NAT64）必须位于路径中，并且具有足够的资源来处理接收到的流量。
2. Need for additional state and/or packet reconstruction in dealing with packet fragmentation. Otherwise, implement no support for fragments (Section 2.5 of [RFC4966]).
2. 在处理数据包碎片时需要额外的状态和/或数据包重建。否则，不支持片段（RFC4966第2.5节）。
Analysis: This issue is not specific to 64 but to all NAT-based solutions. [RFC6146] specifies how to handle fragmentation; appropriate recommendations to avoid fragmentation-related DoS (Denial-of-Service) attacks are proposed (e.g., limit resources to be dedicated to out-of-order fragments).
分析：此问题并非针对64，而是针对所有基于NAT的解决方案。[RFC6146]指定如何处理碎片；提出了避免碎片相关DoS（拒绝服务）攻击的适当建议（例如，限制用于无序碎片的资源）。
3. Inappropriate translation of responses to A queries from IPv6 nodes (Section 4.3 of [RFC4966]).
3. 对来自IPv6节点的查询的响应转换不当（RFC4966第4.3节）。
Analysis: DNS64 [RFC6147] does not alter A queries.
分析：DNS64[RFC6147]不会改变查询。
4. Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes (Section 4.4 of [RFC4966]).
4. 具有多地址节点的DNS-ALG中的地址选择问题和资源消耗（RFC4966第4.4节）。
Analysis: Since no DNS-ALG is required to be co-located with NAT64, there is no need to maintain temporary states in anticipation of connections. Note that explicit bindings (see Section 3 of [RFC6887]) are required to allow for communications initiated from an IPv4-only client to an IPv6- only server.
分析：由于不需要将DNS-ALG与NAT64放在同一位置，因此不需要在连接之前保持临时状态。请注意，需要显式绑定（请参见[RFC6887]的第3节）才能允许从仅IPv4的客户端启动到仅IPv6的服务器的通信。
5. Limitations on DNS security capabilities when using a DNS-ALG (Section 2.5 of [RFC4966]).
5. 使用DNS-ALG时对DNS安全功能的限制（RFC4966第2.5节）。
Analysis: A DNSSEC validating stub resolver behind a DNS64 in server mode is not supported. Therefore, if a host wants to do its own DNSSEC validation, and it wants to use a NAT64, the host has to also perform its own DNS64 synthesis. Refer to Section 3 of [RFC6147] for more details.
分析：不支持服务器模式下DNS64后面的DNSSEC验证存根解析器。因此，如果主机希望执行自己的DNSSEC验证，并且希望使用NAT64，则主机还必须执行自己的DNS64合成。有关更多详细信息，请参阅[RFC6147]第3节。
6. Creation of a DoS threat relating to exhaustion of memory and address/port pool resources on the translator (Section 3.4 of [RFC4966]).
6. 创建与转换器上内存和地址/端口池资源耗尽相关的DoS威胁（RFC4966第3.4节）。
Analysis: This specific DoS concern on Page 6 of [RFC4966] is under a DNS-ALG heading in that document, and refers to NAT-PT's creation of NAT mapping state when a DNS query occurred. With the new IPv6-IPv4 translation mechanisms, DNS queries do not create any mapping state in the NAT64.
分析：[RFC4966]第6页上的特定DoS问题位于该文档中的DNS-ALG标题下，并涉及发生DNS查询时NAT-PT创建的NAT映射状态。使用新的IPv6-IPv4转换机制，DNS查询不会在NAT64中创建任何映射状态。
To mitigate the exhaustion of port pool issue (Section 3.4 of [RFC4966]), 64 must enforce a port limit similar to the one defined in [RFC6888].
为缓解端口池耗尽问题（参见[RFC4966]第3.4节），64必须执行与[RFC6888]中定义的端口限制类似的端口限制。
Thus, this concern can be fully eliminated in 64.
因此，这一问题可以在64年内完全消除。
7. Requirement for applications to use keepalive mechanisms to work around connectivity issues caused by premature timeout for session table and Binding Information Base entries (Section 2.3 of [RFC4966]).
7. 要求应用程序使用keepalive机制来解决由于会话表和绑定信息库条目过早超时而导致的连接问题（RFC4966第2.3节）。
Analysis: Since NAT64 follows some of the [RFC4787], [RFC5382], and [RFC5508] requirements, there is a high lower bound for the lifetime of sessions. In NAT-PT, this was unknown and applications needed to assume the worst case. For instance, in NAT64, the lifetime for a TCP session is approximately two hours, so not much keepalive signaling overhead is needed.
分析：由于NAT64遵循了[RFC4787]、[RFC5382]和[RFC5508]的一些要求，因此会话的生存期有一个高下限。在NAT-PT中，这是未知的，应用程序需要假设最坏的情况。例如，在NAT64中，TCP会话的生存期约为两小时，因此不需要太多keepalive信令开销。
Application clients (e.g., VPN clients) are not aware of the timer configured in the NAT device. For unmanaged services, a conservative approach would be adopted by applications that issue frequent keepalive messages to be sure that an active mapping is still maintained by any involved NAT64 device even if the NAT64 complies with [RFC4787], [RFC5382], and [RFC5508].
应用程序客户端（例如VPN客户端）不知道NAT设备中配置的计时器。对于非托管服务，发出频繁keepalive消息的应用程序将采用保守的方法，以确保即使NAT64符合[RFC4787]、[RFC5382]和[RFC5508]的要求，任何相关NAT64设备仍能保持活动映射。
Note that keepalive messages may be issued by applications to ensure that an active entry is maintained by a firewall, with or without a NAT in the path, which is located in the boundaries of a local domain.
请注意，keepalive消息可能由应用程序发出，以确保活动条目由防火墙维护，无论路径中是否有NAT，该路径位于本地域的边界。
8. Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it (Section 3.3 of [RFC4966]).
8. 缺少地址映射持久性：某些应用程序需要会话之间的地址保留。如果使用不同的映射，用户通信将中断。使用DNS-ALG创建具有有限生存期的地址映射意味着应用程序必须在创建映射后不久开始使用该地址，并在开始使用该地址后保持其活动状态（RFC4966第3.3节）。
Analysis: In the following, address persistence is used to refer to the support of "IP address pooling" behavior of "Paired" [RFC4787].
分析：在下文中，地址持久性用于表示对“配对”[RFC4787]的“IP地址池”行为的支持。
In the context of 64, the external IPv4 address (representing the IPv6 host in the IPv4 network) is assigned by the NAT64 machinery and not the DNS64 function. Therefore, address persistence can be easily ensured by the NAT64 function (which complies with NAT recommendations [RFC4787] and [RFC5382]). Address persistence should be guaranteed for both dynamic and static bindings.
在64的上下文中，外部IPv4地址（表示IPv4网络中的IPv6主机）由NAT64机器分配，而不是由DNS64函数分配。因此，NAT64函数（符合NAT建议[RFC4787]和[RFC5382]）可以轻松确保地址持久性。应该保证动态和静态绑定的地址持久性。
In the IPv6 side of the NAT64, the same IPv6 address is used to represent an IPv4 host; no issue about address persistence is raised in an IPv6 network.
在NAT64的IPv6端，使用相同的IPv6地址表示IPv4主机；IPv6网络中不会出现地址持久性问题。
The above analysis of the solutions provided by the stateful 64 shows that the majority of the problems that are not directly related to the decoupling of NAT and DNS remain unaddressed. Some of these problems are not specific to 64 but are generic to all NAT-based solutions.
上述对stateful 64提供的解决方案的分析表明，大多数与NAT和DNS解耦没有直接关系的问题仍然没有得到解决。其中一些问题并非特定于64，而是所有基于NAT的解决方案的通用问题。
This points to several shortcomings of stateful 64 that must be addressed if the future network deployments have to move reliably towards 64 as a solution to IPv6-IPv4 interconnection.
这指出了有状态64的几个缺点，如果未来的网络部署必须可靠地将64作为IPv6-IPv4互连的解决方案，则必须解决这些缺点。
Some of the issues, as pointed out in [RFC4966], have possible solutions. However these solutions will require significant updates to the stateful 64, increasing its complexity.
[RFC4966]中指出的一些问题有可能解决。但是，这些解决方案将需要对有状态64进行重大更新，从而增加其复杂性。
The following table summarizes the conclusions based on the analysis of stateful 64.
下表总结了基于stateful 64分析得出的结论。
+---------------+----------+---------+----------+---------+---------+
| Issue | NAT-PT | Exists | DNS ALG | Generic | Can be |
| | Specific | in | Specific | NAT | solved? |
| | | NAT64 | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | Yes |
| embedding | | | | | |
| addresses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | No |
| without demux | | | | | |
| capability | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Binding state | No | Yes | No | Yes | Yes |
| decay | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Loss of | No | Yes | No | No | No |
| information | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Fragmentation | No | No | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| SCTP and | No | Yes | No | Yes | Yes |
| Multihoming | | | | | |
| interaction | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Proxy | No | Yes | No | No | No |
| correspondent | | | | | |
| node for | | | | | |
| MIPv6 | | | | | |
| Multicast | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| IPsec tunnel | No | Yes | No | Yes | Yes |
| mode | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Topology | Yes | No | Yes | No | Yes |
| constraints | | | | | |
| with DNS-ALG | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Issue | NAT-PT | Exists | DNS ALG | Generic | Can be |
| | Specific | in | Specific | NAT | solved? |
| | | NAT64 | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | Yes |
| embedding | | | | | |
| addresses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Protocols | No | Yes | No | Yes | No |
| without demux | | | | | |
| capability | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Binding state | No | Yes | No | Yes | Yes |
| decay | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Loss of | No | Yes | No | No | No |
| information | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Fragmentation | No | No | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| SCTP and | No | Yes | No | Yes | Yes |
| Multihoming | | | | | |
| interaction | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Proxy | No | Yes | No | No | No |
| correspondent | | | | | |
| node for | | | | | |
| MIPv6 | | | | | |
| Multicast | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| IPsec tunnel | No | Yes | No | Yes | Yes |
| mode | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Topology | Yes | No | Yes | No | Yes |
| constraints | | | | | |
| with DNS-ALG | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Scale and | No | Yes | No | Yes | Yes |
| Single point | | | | | |
| of failure | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Lack of | No | Yes | No | Yes | Yes |
| address | | | | | |
| persistence | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DoS attacks | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| Address | Yes | No | Yes | No | Yes |
| selection | | | | | |
| issues with | | | | | |
| Dual stack | | | | | |
| hosts | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Non-global | Yes | No | Yes | No | Yes |
| validity of | | | | | |
| Translated RR | | | | | |
| records | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Incorrect | Yes | No | Yes | No | Yes |
| translation | | | | | |
| of A | | | | | |
| responses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNS-ALG and | No | Yes | No | Yes | Yes |
| Multi- | | | | | |
| addressed | | | | | |
| nodes | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNSSEC | No | Yes | No | Yes | Yes |
| limitations | | | | | |
+---------------+----------+---------+----------+---------+---------+
+---------------+----------+---------+----------+---------+---------+
| Scale and | No | Yes | No | Yes | Yes |
| Single point | | | | | |
| of failure | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Lack of | No | Yes | No | Yes | Yes |
| address | | | | | |
| persistence | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DoS attacks | No | Yes | No | Yes | Yes |
+---------------+----------+---------+----------+---------+---------+
| Address | Yes | No | Yes | No | Yes |
| selection | | | | | |
| issues with | | | | | |
| Dual stack | | | | | |
| hosts | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Non-global | Yes | No | Yes | No | Yes |
| validity of | | | | | |
| Translated RR | | | | | |
| records | | | | | |
+---------------+----------+---------+----------+---------+---------+
| Incorrect | Yes | No | Yes | No | Yes |
| translation | | | | | |
| of A | | | | | |
| responses | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNS-ALG and | No | Yes | No | Yes | Yes |
| Multi- | | | | | |
| addressed | | | | | |
| nodes | | | | | |
+---------------+----------+---------+----------+---------+---------+
| DNSSEC | No | Yes | No | Yes | Yes |
| limitations | | | | | |
+---------------+----------+---------+----------+---------+---------+
Table 1: Summary of NAT64 analysis
表1:NAT64分析总结
This document does not specify any new protocol or architecture. It only analyzes how BEHAVE WG 64 documents mitigate concerns raised in [RFC4966] and which ones are still unaddressed.
本文件未规定任何新的协议或体系结构。它只分析了WG 64文档如何缓解[RFC4966]中提出的问题，以及哪些问题尚未解决。
Many thanks to M. Bagnulo, D. Wing, X. Li, D. Anipko, and S. Moonesamy for their review and comments.
非常感谢M.Bagnulo、D.Wing、X.Li、D.Anipko和S.Moonesay的评论和评论。
D. Black provided the IPsec text.
D.Black提供了IPsec文本。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[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月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[RFC4966]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[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月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP的NAT行为要求”，BCP 148，RFC 5508，2009年4月。
[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月。
[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月。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，2013年4月。
[ADDR-SELECT] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy using DHCPv6", Work in Progress, April 2013.
[ADDR-SELECT]Matsumoto，A.，Fujisaki，T.，和T.Chown，“使用DHCPv6分发地址选择策略”，正在进行的工作，2013年4月。
[DNS64] Wing, D., "IPv6-only and Dual Stack Hosts on the Same Network with DNS64", Work in Progress, February 2011.
[DNS64]Wing，D.，“与DNS64在同一网络上的仅IPv6和双栈主机”，正在进行的工作，2011年2月。
[FTP64] Liu, D., Beijnum, I., and Z. Cao, "FTP consideration for IPv4/IPv6 transition", Work in Progress, January 2012.
[FTP64]Liu，D.，Beijnum，I.，和Z.Cao，“IPv4/IPv6过渡的FTP考虑”，正在进行的工作，2012年1月。
[MIDDLEBOXES] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of Middlebox Interactions for Signaling Protocol Communication along the Media Path", Work in Progress, January 2013.
[Middlebox]Stucker，B.，Tschofenig，H.，和G.Salgueiro，“媒体路径上信令协议通信的中间盒交互分析”，正在进行的工作，2013年1月。
[NAT64-HARMFUL] Haddad, W. and C. Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Work in Progress, March 2011.
[NAT64-HAMMARY]Haddad，W.和C.Perkins，“关于NAT64与移动IPv6交互的说明”，正在进行的工作，2011年3月。
[REFERRAL] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[转介]Carpenter，B.，Boucadair，M.，Halpern，J.，Jiang，S.，和K.Moore，“互联网实体的通用转介对象”，正在进行的工作，2009年10月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[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月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853]Hautakorpi，J.，Camarillo，G.，Penfield，R.，Hawrylyshen，A.，和M.Bhatia，“会话启动协议（SIP）会话边界控制（SBC）部署的要求”，RFC 58532010年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月。
[RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013.
[RFC6888]Perreault，S.，Ed.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级NAT（CGN）的通用要求”，BCP 127，RFC 6888，2013年4月。
Authors' Addresses
作者地址
Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道170号雷纳尔多·佩诺思科系统公司，邮编：95134
EMail: repenno@cisco.com
EMail: repenno@cisco.com
Tarun Saxena Cisco Systems Cessna Business Park Bangalore 560103 India
Tarun Saxena思科系统塞斯纳商业园印度班加罗尔560103
EMail: tasaxena@cisco.com
EMail: tasaxena@cisco.com
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park, North Carolina 27709 USA
Senthil Sivakumar Cisco Systems 7100-8 Kit Creek Road Research Triangle Park，美国北卡罗来纳州27709
EMail: ssenthil@cisco.com
EMail: ssenthil@cisco.com