Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6146 UC3M
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
Internet Engineering Task Force (IETF) M. Bagnulo
Request for Comments: 6146 UC3M
Category: Standards Track P. Matthews
ISSN: 2070-1721 Alcatel-Lucent
I. van Beijnum
IMDEA Networks
April 2011
Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换
Abstract
摘要
This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server.
本文档介绍有状态NAT64转换，它允许仅限IPv6的客户端使用单播UDP、TCP或ICMP与IPv4服务器联系。分配给NAT64转换器的一个或多个公共IPv4地址在几个仅限IPv6的客户端之间共享。当有状态NAT64与DNS64结合使用时，通常不需要在IPv6客户端或IPv4服务器中进行任何更改。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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/rfc6146.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6146.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Features of Stateful NAT64 . . . . . . . . . . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . . 6
1.2.2. Stateful NAT64 Behavior Walk-Through . . . . . . . . . 8
1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 14
3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14
3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 17
3.4. Determining the Incoming Tuple . . . . . . . . . . . . . . 18
3.5. Filtering and Updating Binding and Session Information . . 20
3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 21
3.5.1.1. Rules for Allocation of IPv4 Transport
Addresses for UDP . . . . . . . . . . . . . . . . 23
3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 24
3.5.2.1. State Definition . . . . . . . . . . . . . . . . . 24
3.5.2.2. State Machine for TCP Processing in the NAT64 . . 25
3.5.2.3. Rules for Allocation of IPv4 Transport
Addresses for TCP . . . . . . . . . . . . . . . . 33
3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 33
3.5.4. Generation of the IPv6 Representations of IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 36
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and
for ICMP Error Messages Containing a TCP or UDP
Packets . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query
Messages and for ICMP Error Messages Containing an
ICMP Query . . . . . . . . . . . . . . . . . . . . . . 38
3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 38
3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 39
4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Implications on End-to-End Security . . . . . . . . . . . 40
5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 41
5.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . . 42
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Features of Stateful NAT64 . . . . . . . . . . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . . 6
1.2.2. Stateful NAT64 Behavior Walk-Through . . . . . . . . . 8
1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 10
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Stateful NAT64 Normative Specification . . . . . . . . . . . . 14
3.1. Binding Information Bases . . . . . . . . . . . . . . . . 14
3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Packet Processing Overview . . . . . . . . . . . . . . . . 17
3.4. Determining the Incoming Tuple . . . . . . . . . . . . . . 18
3.5. Filtering and Updating Binding and Session Information . . 20
3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . . 21
3.5.1.1. Rules for Allocation of IPv4 Transport
Addresses for UDP . . . . . . . . . . . . . . . . 23
3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . . 24
3.5.2.1. State Definition . . . . . . . . . . . . . . . . . 24
3.5.2.2. State Machine for TCP Processing in the NAT64 . . 25
3.5.2.3. Rules for Allocation of IPv4 Transport
Addresses for TCP . . . . . . . . . . . . . . . . 33
3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 33
3.5.4. Generation of the IPv6 Representations of IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . 36
3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . . 36
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and
for ICMP Error Messages Containing a TCP or UDP
Packets . . . . . . . . . . . . . . . . . . . . . . . 37
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query
Messages and for ICMP Error Messages Containing an
ICMP Query . . . . . . . . . . . . . . . . . . . . . . 38
3.7. Translating the Packet . . . . . . . . . . . . . . . . . . 38
3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . . 39
4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
5.1. Implications on End-to-End Security . . . . . . . . . . . 40
5.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3. Attacks on NAT64 . . . . . . . . . . . . . . . . . . . . . 41
5.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . . 42
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. Normative References . . . . . . . . . . . . . . . . . . . 43
8.2. Informative References . . . . . . . . . . . . . . . . . . 44
This document specifies stateful NAT64, a mechanism for IPv4-IPv6 transition and IPv4-IPv6 coexistence. Together with DNS64 [RFC6147], these two mechanisms allow an IPv6-only client to initiate communications to an IPv4-only server. They also enable peer-to-peer communication between an IPv4 and an IPv6 node, where the communication can be initiated when either end uses existing, NAT-traversal, peer-to-peer communication techniques, such as Interactive Connectivity Establishment (ICE) [RFC5245]. Stateful NAT64 also supports IPv4-initiated communications to a subset of the IPv6 hosts through statically configured bindings in the stateful NAT64.
本文档指定了有状态NAT64，这是IPv4-IPv6转换和IPv4-IPv6共存的机制。与DNS64[RFC6147]一起，这两种机制允许仅限IPv6的客户端启动与仅限IPv4的服务器的通信。它们还支持IPv4和IPv6节点之间的点对点通信，其中当任一端使用现有的NAT穿越点对点通信技术（如交互式连接建立（ICE））时，可以启动通信[RFC5245]。有状态NAT64还支持通过有状态NAT64中静态配置的绑定与IPv6主机子集进行IPv4发起的通信。
Stateful NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and vice versa. The translation is done by translating the packet headers according to the IP/ICMP Translation Algorithm defined in [RFC6145]. The IPv4 addresses of IPv4 hosts are algorithmically translated to and from IPv6 addresses by using the algorithm defined in [RFC6052] and an IPv6 prefix assigned to the stateful NAT64 for this specific purpose. The IPv6 addresses of IPv6 hosts are translated to and from IPv4 addresses by installing mappings in the normal Network Address Port Translation (NAPT) manner [RFC3022]. The current specification only defines how stateful NAT64 translates unicast packets carrying TCP, UDP, and ICMP traffic. Multicast packets and other protocols, including the Stream Control Transmission Protocol (SCTP), the Datagram Congestion Control Protocol (DCCP), and IPsec, are out of the scope of this specification.
有状态NAT64是一种将IPv6数据包转换为IPv4数据包的机制，反之亦然。转换是通过根据[RFC6145]中定义的IP/ICMP转换算法转换数据包头来完成的。IPv4主机的IPv4地址通过使用[RFC6052]中定义的算法和为此指定给有状态NAT64的IPv6前缀从算法上转换为IPv6地址。通过以正常网络地址端口转换（NAPT）方式安装映射，IPv6主机的IPv6地址可转换为IPv4地址或从IPv4地址转换为IPv6地址[RFC3022]。当前规范仅定义有状态NAT64如何转换承载TCP、UDP和ICMP流量的单播数据包。多播数据包和其他协议，包括流控制传输协议（SCTP）、数据报拥塞控制协议（DCCP）和IPsec，不在本规范的范围内。
DNS64 is a mechanism for synthesizing AAAA resource records (RRs) from A RRs. The IPv6 address contained in the synthetic AAAA RR is algorithmically generated from the IPv4 address and the IPv6 prefix assigned to a NAT64 device by using the same algorithm defined in [RFC6052].
DNS64是从RRs合成AAAA资源记录（RRs）的机制。合成AAAA RR中包含的IPv6地址是通过使用[RFC6052]中定义的相同算法，从分配给NAT64设备的IPv4地址和IPv6前缀算法生成的。
Together, these two mechanisms allow an IPv6-only client (i.e., a host with a networking stack that only implements IPv6, a host with a networking stack that implements both protocols but with only IPv6 connectivity, or a host running an IPv6-only application) to initiate communications to an IPv4-only server (which is analogous to the IPv6-only host above).
这两种机制一起允许仅限IPv6的客户端（即，具有仅实现IPv6的网络堆栈的主机、具有同时实现两种协议但仅具有IPv6连接的网络堆栈的主机或运行仅限IPv6应用程序的主机）启动与仅限IPv4服务器的通信（类似于上面的IPv6唯一主机）。
These mechanisms are expected to play a critical role in IPv4-IPv6 transition and IPv4-IPv6 coexistence. Due to IPv4 address depletion, it is likely that in the future, the new clients will be IPv6-only and they will want to connect to the existing IPv4-only servers. The stateful NAT64 and DNS64 mechanisms are easily deployable, since they do not require changes to either the IPv6 client or the IPv4 server.
这些机制有望在IPv4-IPv6过渡和IPv4-IPv6共存中发挥关键作用。由于IPv4地址耗尽，很可能在将来，新的客户端将仅限于IPv6，并且它们将希望连接到现有的仅限于IPv4的服务器。有状态NAT64和DNS64机制易于部署，因为它们不需要更改IPv6客户端或IPv4服务器。
For basic functionality, the approach only requires the deployment of the stateful NAT64 function in the devices connecting an IPv6-only network to the IPv4-only network, along with the deployment of a few DNS64-enabled name servers accessible to the IPv6-only hosts. An analysis of the application scenarios can be found in [RFC6144].
对于基本功能，该方法只需要在将仅IPv6网络连接到仅IPv4网络的设备中部署有状态NAT64功能，同时部署一些仅IPv6主机可访问的启用DNS64的名称服务器。有关应用场景的分析，请参见[RFC6144]。
For brevity, in the rest of the document, we will refer to the stateful NAT64 either as stateful NAT64 or simply as NAT64.
为简洁起见，在文档的其余部分中，我们将有状态NAT64称为有状态NAT64或简称为NAT64。
The features of NAT64 are:
NAT64的特点是：
o NAT64 is compliant with the recommendations for how NATs should handle UDP [RFC4787], TCP [RFC5382], and ICMP [RFC5508]. As such, NAT64 only supports Endpoint-Independent Mappings and supports both Endpoint-Independent and Address-Dependent Filtering. Because of the compliance with the aforementioned requirements, NAT64 is compatible with current NAT traversal techniques, such as ICE [RFC5245], and with other NAT traversal techniques.
o NAT64符合NAT应如何处理UDP[RFC4787]、TCP[RFC5382]和ICMP[RFC5508]的建议。因此，NAT64仅支持端点无关映射，并支持端点无关和地址相关过滤。由于符合上述要求，NAT64与当前的NAT穿越技术（如ICE[RFC5245]）以及其他NAT穿越技术兼容。
o In the absence of preexisting state in a NAT64, only IPv6 nodes can initiate sessions to IPv4 nodes. This works for roughly the same class of applications that work through IPv4-to-IPv4 NATs.
o 在NAT64中没有预先存在的状态的情况下，只有IPv6节点可以启动到IPv4节点的会话。这适用于通过IPv4到IPv4 NAT工作的大致相同类型的应用程序。
o Depending on the filtering policy used (Endpoint-Independent, or Address-Dependent), IPv4-nodes might be able to initiate sessions to a given IPv6 node, if the NAT64 somehow has an appropriate mapping (i.e., state) for an IPv6 node, via one of the following mechanisms:
o 根据所使用的过滤策略（独立于端点或依赖于地址），如果NAT64通过以下机制之一具有IPv6节点的适当映射（即状态），IPv4节点可能能够启动到给定IPv6节点的会话：
* The IPv6 node has recently initiated a session to the same or another IPv4 node. This is also the case if the IPv6 node has used a NAT-traversal technique (such as ICE).
* IPv6节点最近启动了与同一个或另一个IPv4节点的会话。如果IPv6节点使用了NAT穿越技术（如ICE），也会出现这种情况。
* A statically configured mapping exists for the IPv6 node.
* IPv6节点存在静态配置的映射。
o IPv4 address sharing: NAT64 allows multiple IPv6-only nodes to share an IPv4 address to access the IPv4 Internet. This helps with the forthcoming IPv4 exhaustion.
o IPv4地址共享：NAT64允许多个仅限IPv6的节点共享IPv4地址以访问IPv4 Internet。这有助于解决即将到来的IPv4耗尽问题。
o As currently defined in this NAT64 specification, only TCP, UDP, and ICMP are supported. Support for other protocols (such as other transport protocols and IPsec) is to be defined in separate documents.
o 按照NAT64规范的当前定义，仅支持TCP、UDP和ICMP。对其他协议（如其他传输协议和IPsec）的支持将在单独的文档中定义。
This section provides a non-normative introduction to NAT64. This is achieved by describing the NAT64 behavior involving a simple setup that involves a single NAT64 device, a single DNS64, and a simple network topology. The goal of this description is to provide the reader with a general view of NAT64. It is not the goal of this section to describe all possible configurations nor to provide a normative specification of the NAT64 behavior. So, for the sake of clarity, only TCP and UDP are described in this overview; the details of ICMP, fragmentation, and other aspects of translation are purposefully avoided in this overview. The normative specification of NAT64 is provided in Section 3.
本节对NAT64进行了非规范性介绍。这是通过描述NAT64行为实现的，该行为涉及一个简单的设置，该设置涉及一个NAT64设备、一个DNS64和一个简单的网络拓扑。本说明的目的是为读者提供NAT64的一般视图。本节的目的不是描述所有可能的配置，也不是提供NAT64行为的规范性规范。因此，为了清楚起见，本概述中仅描述TCP和UDP；本概述有意避免涉及ICMP、碎片和翻译的其他方面的细节。NAT64的规范性规范见第3节。
The NAT64 mechanism is implemented in a device that has (at least) two interfaces, an IPv4 interface connected to the IPv4 network, and an IPv6 interface connected to the IPv6 network. Packets generated in the IPv6 network for a receiver located in the IPv4 network will be routed within the IPv6 network towards the NAT64 device. The NAT64 will translate them and forward them as IPv4 packets through the IPv4 network to the IPv4 receiver. The reverse takes place for packets generated by hosts connected to the IPv4 network for an IPv6 receiver. NAT64, however, is not symmetric. In order to be able to perform IPv6-IPv4 translation, NAT64 requires state. The state contains the binding of an IPv6 address and TCP/UDP port (hereafter called an IPv6 transport address) to an IPv4 address and TCP/UDP port (hereafter called an IPv4 transport address).
NAT64机制在具有（至少）两个接口的设备中实现，一个是连接到IPv4网络的IPv4接口，另一个是连接到IPv6网络的IPv6接口。在IPv6网络中为位于IPv4网络中的接收器生成的数据包将在IPv6网络中路由到NAT64设备。NAT64将转换它们，并通过IPv4网络将它们作为IPv4数据包转发给IPv4接收器。对于连接到IPv6接收器的IPv4网络的主机生成的数据包，情况正好相反。然而，NAT64不是对称的。为了能够执行IPv6-IPv4转换，NAT64需要状态。该状态包含IPv6地址和TCP/UDP端口（以下称为IPv6传输地址）与IPv4地址和TCP/UDP端口（以下称为IPv4传输地址）的绑定。
Such binding state is either statically configured in the NAT64 or it is created when the first packet flowing from the IPv6 network to the IPv4 network is translated. After the binding state has been created, packets flowing in both directions on that particular flow are translated. The result is that, in the general case, NAT64 only supports communications initiated by the IPv6-only node towards an IPv4-only node. Some additional mechanisms (like ICE) or static binding configuration can be used to provide support for communications initiated by an IPv4-only node to an IPv6-only node.
这种绑定状态要么在NAT64中静态配置，要么在从IPv6网络传输到IPv4网络的第一个数据包被转换时创建。创建绑定状态后，将转换在该特定流上双向流动的数据包。结果是，在一般情况下，NAT64仅支持由仅IPv6节点向仅IPv4节点发起的通信。可以使用一些附加机制（如ICE）或静态绑定配置来支持由仅IPv4节点启动到仅IPv6节点的通信。
In this section, we describe the different elements involved in the NAT64 approach.
在本节中，我们将描述NAT64方法中涉及的不同元素。
The main component of the proposed solution is the translator itself. The translator has essentially two main parts, the address translation mechanism and the protocol translation mechanism.
提出的解决方案的主要组成部分是翻译器本身。翻译器基本上有两个主要部分，地址转换机制和协议转换机制。
Protocol translation from an IPv4 packet header to an IPv6 packet header and vice versa is performed according to the IP/ICMP Translation Algorithm [RFC6145].
根据IP/ICMP转换算法[RFC6145]执行从IPv4数据包头到IPv6数据包头的协议转换，反之亦然。
Address translation maps IPv6 transport addresses to IPv4 transport addresses and vice versa. In order to create these mappings, the NAT64 has two pools of addresses: an IPv6 address pool (to represent IPv4 addresses in the IPv6 network) and an IPv4 address pool (to represent IPv6 addresses in the IPv4 network).
地址转换将IPv6传输地址映射到IPv4传输地址，反之亦然。为了创建这些映射，NAT64有两个地址池：IPv6地址池（表示IPv6网络中的IPv4地址）和IPv4地址池（表示IPv4网络中的IPv6地址）。
The IPv6 address pool is one or more IPv6 prefixes assigned to the translator itself. Hereafter, we will call the IPv6 address pool Pref64::/n; in the case there is more than one prefix assigned to the NAT64, the comments made about Pref64::/n apply to each of them. Pref64::/n will be used by the NAT64 to construct IPv4-Converted IPv6 addresses as defined in [RFC6052]. Due to the abundance of IPv6 address space, it is possible to assign one or more Pref64::/n, each of them being equal to or even bigger than the size of the whole IPv4 address space. This allows each IPv4 address to be mapped into a different IPv6 address by simply concatenating a Pref64::/n with the IPv4 address being mapped and a suffix. The provisioning of the Pref64::/n as well as the address format are defined in [RFC6052].
IPv6地址池是分配给转换器本身的一个或多个IPv6前缀。此后，我们将调用IPv6地址池Pref64:：/n；如果为NAT64分配了多个前缀，则有关Pref64:：/n的注释适用于每个前缀。Pref64:：/n将由NAT64用于构造[RFC6052]中定义的IPv4转换IPv6地址。由于IPv6地址空间丰富，可以分配一个或多个Pref64:：/n，每个Pref64:：/n等于或甚至大于整个IPv4地址空间的大小。这允许通过简单地将Pref64:：/n与要映射的IPv4地址和后缀连接起来，将每个IPv4地址映射到不同的IPv6地址。Pref64:：/n的设置以及地址格式在[RFC6052]中定义。
The IPv4 address pool is a set of IPv4 addresses, normally a prefix assigned by the local administrator. Since IPv4 address space is a scarce resource, the IPv4 address pool is small and typically not sufficient to establish permanent one-to-one mappings with IPv6 addresses. So, except for the static/manually created ones, mappings using the IPv4 address pool will be created and released dynamically. Moreover, because of the IPv4 address scarcity, the usual practice for NAT64 is likely to be the binding of IPv6 transport addresses into IPv4 transport addresses, instead of IPv6 addresses into IPv4 addresses directly, enabling a higher utilization of the limited IPv4 address pool. This implies that NAT64 performs both address and port translation.
IPv4地址池是一组IPv4地址，通常是本地管理员分配的前缀。由于IPv4地址空间是一种稀缺资源，IPv4地址池很小，通常不足以与IPv6地址建立永久的一对一映射。因此，除了静态/手动创建的映射之外，使用IPv4地址池的映射将被动态创建和释放。此外，由于IPv4地址稀缺，NAT64的通常做法可能是将IPv6传输地址绑定到IPv4传输地址，而不是将IPv6地址直接绑定到IPv4地址，从而提高有限IPv4地址池的利用率。这意味着NAT64同时执行地址和端口转换。
Because of the dynamic nature of the IPv6-to-IPv4 address mapping and the static nature of the IPv4-to-IPv6 address mapping, it is far simpler to allow communications initiated from the IPv6 side toward an IPv4 node, whose address is algorithmically mapped into an IPv6 address, than communications initiated from IPv4-only nodes to an IPv6 node. In that case, an IPv4 address needs to be associated with the IPv6 node's address dynamically.
由于IPv6-to-IPv4地址映射的动态性质和IPv4-to-IPv6地址映射的静态性质，允许从IPv6端发起到IPv4节点的通信（其地址通过算法映射到IPv6地址）比从仅IPv4节点发起到IPv6节点的通信简单得多。在这种情况下，IPv4地址需要与IPv6节点的地址动态关联。
Using a mechanism such as DNS64, an IPv6 client obtains an IPv6 address that embeds the IPv4 address of the IPv4 server and sends a packet to that IPv6 address. The packets are intercepted by the NAT64 device, which associates an IPv4 transport address out of its
使用DNS64等机制，IPv6客户端获取嵌入IPv4服务器IPv4地址的IPv6地址，并向该IPv6地址发送数据包。这些数据包被NAT64设备截获，NAT64设备将IPv4传输地址与它的IP地址相关联
IPv4 pool to the IPv6 transport address of the initiator, creating binding state, so that reply packets can be translated and forwarded back to the initiator. The binding state is kept while packets are flowing. Once the flow stops, and based on a timer, the IPv4 transport address is returned to the IPv4 address pool so that it can be reused for other communications.
IPv4池到启动器的IPv6传输地址，创建绑定状态，以便可以转换回复数据包并将其转发回启动器。当数据包流动时，绑定状态保持不变。一旦流停止，基于计时器，IPv4传输地址将返回到IPv4地址池，以便可以将其重新用于其他通信。
To allow an IPv6 initiator to do a DNS lookup to learn the address of the responder, DNS64 [RFC6147] is used to synthesize AAAA RRs from the A RRs. The IPv6 addresses contained in the synthetic AAAA RRs contain a Pref64::/n assigned to the NAT64 and the IPv4 address of the responder. The synthetic AAAA RRs are passed back to the IPv6 initiator, which will initiate an IPv6 communication with an IPv6 address associated to the IPv4 receiver. The packet will be routed to the NAT64 device, which will create the IPv6-to-IPv4 address mapping as described before.
为了允许IPv6启动器执行DNS查找以了解响应者的地址，使用DNS64[RFC6147]从a RRs合成AAAA RRs。合成AAAA RRs中包含的IPv6地址包含分配给NAT64的Pref64:：/n和响应程序的IPv4地址。合成AAAA rr被传回IPv6启动器，该启动器将使用与IPv4接收器关联的IPv6地址启动IPv6通信。数据包将被路由到NAT64设备，该设备将创建IPv6到IPv4的地址映射，如前所述。
In this section, we provide a simple example of the NAT64 behavior. We consider an IPv6 node that is located in an IPv6-only site and that initiates a TCP connection to an IPv4-only node located in the IPv4 network.
在本节中，我们提供一个NAT64行为的简单示例。我们考虑IPv6节点位于IPv6唯一站点，并发起到IPv4网络中的IPv4节点的TCP连接。
The scenario for this case is depicted in the following figure:
下图描述了这种情况的场景：
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | network |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +-------+ | 192.0.2.1 |
|2001:db8::1|------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+
+---------------------+ +---------------+
|IPv6 network | | IPv4 |
| | +-------------+ | network |
| |--| Name server |--| |
| | | with DNS64 | | +----+ |
| +----+ | +-------------+ | | H2 | |
| | H1 |---| | | +----+ |
| +----+ | +-------+ | 192.0.2.1 |
|2001:db8::1|------| NAT64 |----| |
| | +-------+ | |
| | | | |
+---------------------+ +---------------+
The figure above shows an IPv6 node H1 with an IPv6 address 2001:db8::1 and an IPv4 node H2 with IPv4 address 192.0.2.1. H2 has h2.example.com as its Fully Qualified Domain Name (FQDN).
上图显示了IPv6地址为2001:db8:：1的IPv6节点H1和IPv4地址为192.0.2.1的IPv4节点H2。H2将H2.example.com作为其完全限定域名（FQDN）。
A NAT64 connects the IPv6 network to the IPv4 network. This NAT64 uses the Well-Known Prefix 64:ff9b::/96 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address space and a single IPv4 address 203.0.113.1 assigned to its IPv4 interface. The routing is
NAT64将IPv6网络连接到IPv4网络。此NAT64使用[RFC6052]中定义的众所周知的前缀64:ff9b:：/96表示IPv6地址空间中的IPv4地址以及分配给其IPv4接口的单个IPv4地址203.0.113.1。路由是
configured in such a way that the IPv6 packets addressed to a destination address in 64:ff9b::/96 are routed to the IPv6 interface of the NAT64 device.
以这样的方式配置，即寻址到64:ff9b:：/96中的目标地址的IPv6数据包被路由到NAT64设备的IPv6接口。
Also shown is a local name server with DNS64 functionality. The local name server uses the Well-Known Prefix 64:ff9b::/96 to create the IPv6 addresses in the synthetic RRs.
还显示了具有DNS64功能的本地名称服务器。本地名称服务器使用众所周知的前缀64:ff9b:：/96在合成RRs中创建IPv6地址。
For this example, assume the typical DNS situation where IPv6 hosts have only stub resolvers, and the local name server does the recursive lookups.
对于本例，假设典型的DNS情况，其中IPv6主机只有存根解析程序，而本地名称服务器执行递归查找。
The steps by which H1 establishes communication with H2 are:
H1与H2建立通信的步骤如下：
1. H1 performs a DNS query for h2.example.com and receives the synthetic AAAA RR from the local name server that implements the DNS64 functionality. The AAAA record contains an IPv6 address formed by the Well-Known Prefix and the IPv4 address of H2 (i.e., 64:ff9b::192.0.2.1).
1. H1对h2.example.com执行DNS查询，并从实现DNS64功能的本地名称服务器接收合成AAAA RR。AAAA记录包含由众所周知的前缀和IPv4地址H2（即64:ff9b:：192.0.2.1）组成的IPv6地址。
2. H1 sends a TCP SYN packet to H2. The packet is sent from a source transport address of (2001:db8::1,1500) to a destination transport address of (64:ff9b::192.0.2.1,80), where the ports are set by H1.
2. H1向H2发送TCP SYN数据包。数据包从源传输地址（2001:db8:：11500）发送到目标传输地址（64:ff9b:：192.0.2.1,80），其中端口由H1设置。
3. The packet is routed to the IPv6 interface of the NAT64 (since IPv6 routing is configured that way).
3. 数据包被路由到NAT64的IPv6接口（因为IPv6路由是以这种方式配置的）。
4. The NAT64 receives the packet and performs the following actions:
4. NAT64接收数据包并执行以下操作：
* The NAT64 selects an unused port (e.g., 2000) on its IPv4 address 203.0.113.1 and creates the mapping entry (2001:db8::1,1500) <--> (203.0.113.1,2000)
* NAT64在其IPv4地址203.0.113.1上选择一个未使用的端口（如2000），并创建映射条目（2001:db8:：11500）<-->（203.0.113.12000）
* The NAT64 translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm [RFC6145].
* NAT64使用IP/ICMP转换算法[RFC6145]将IPv6报头转换为IPv4报头。
* The NAT64 includes (203.0.113.1,2000) as the source transport address in the packet and (192.0.2.1,80) as the destination transport address in the packet. Note that 192.0.2.1 is extracted directly from the destination IPv6 address of the received IPv6 packet that is being translated. The destination port 80 of the translated packet is the same as the destination port of the received IPv6 packet.
* NAT64包括（203.0.113.12000）作为包中的源传输地址和（192.0.2.1,80）作为包中的目标传输地址。请注意，192.0.2.1直接从正在翻译的接收到的IPv6数据包的目标IPv6地址提取。翻译后的分组的目的地端口80与接收到的IPv6分组的目的地端口相同。
5. The NAT64 sends the translated packet out of its IPv4 interface and the packet arrives at H2.
5. NAT64从其IPv4接口发送转换后的数据包，数据包到达H2。
6. H2 node responds by sending a TCP SYN+ACK packet with the destination transport address (203.0.113.1,2000) and source transport address (192.0.2.1,80).
6. H2节点通过发送带有目标传输地址（203.0.113.12000）和源传输地址（192.0.2.1,80）的TCP SYN+ACK数据包进行响应。
7. Since the IPv4 address 203.0.113.1 is assigned to the IPv4 interface of the NAT64 device, the packet is routed to the NAT64 device, which will look for an existing mapping containing (203.0.113.1,2000). Since the mapping (2001:db8::1,1500) <--> (203.0.113.1,2000) exists, the NAT64 performs the following operations:
7. 由于IPv4地址203.0.113.1分配给NAT64设备的IPv4接口，因此数据包被路由到NAT64设备，该设备将查找包含（203.0.113.12000）的现有映射。由于映射（2001:db8:：11500）<-->（203.0.113.12000）存在，NAT64执行以下操作：
* The NAT64 translates the IPv4 header into an IPv6 header using the IP/ICMP Translation Algorithm [RFC6145].
* NAT64使用IP/ICMP转换算法[RFC6145]将IPv4报头转换为IPv6报头。
* The NAT64 includes (2001:db8::1,1500) as the destination transport address in the packet and (64:ff9b::192.0.2.1,80) as the source transport address in the packet. Note that 192.0.2.1 is extracted directly from the source IPv4 address of the received IPv4 packet that is being translated. The source port 80 of the translated packet is the same as the source port of the received IPv4 packet.
* NAT64包括（2001:db8:：11500）作为包中的目标传输地址和（64:ff9b:：192.0.2.1,80）作为包中的源传输地址。请注意，192.0.2.1直接从正在翻译的接收到的IPv4数据包的源IPv4地址提取。翻译后的分组的源端口80与接收到的IPv4分组的源端口相同。
8. The translated packet is sent out of the IPv6 interface to H1.
8. 翻译后的数据包从IPv6接口发送到H1。
The packet exchange between H1 and H2 continues, and packets are translated in the different directions as previously described.
H1和H2之间的分组交换继续，并且分组按照前面描述的不同方向被转换。
It is important to note that the translation still works if the IPv6 initiator H1 learns the IPv6 representation of H2's IPv4 address (i.e., 64:ff9b::192.0.2.1) through some scheme other than a DNS lookup. This is because the DNS64 processing does NOT result in any state being installed in the NAT64 and because the mapping of the IPv4 address into an IPv6 address is the result of concatenating the Well-Known Prefix to the original IPv4 address.
需要注意的是，如果IPv6启动器H1通过DNS查找以外的方案学习H2 IPv4地址（即64:ff9b:：192.0.2.1）的IPv6表示，则转换仍然有效。这是因为DNS64处理不会导致NAT64中安装任何状态，并且IPv4地址到IPv6地址的映射是将已知前缀连接到原始IPv4地址的结果。
NAT64 may do filtering, which means that it only allows a packet in through an interface under certain circumstances. The NAT64 can filter IPv6 packets based on the administrative rules to create entries in the binding and session tables. The filtering can be flexible and general, but the idea of the filtering is to provide the administrators necessary control to avoid denial-of-service (DoS) attacks that would result in exhaustion of the NAT64's IPv4 address, port, memory, and CPU resources. Filtering techniques of incoming IPv6 packets are not specific to the NAT64 and therefore are not described in this specification.
NAT64可以进行过滤，这意味着在某些情况下，它只允许数据包通过接口进入。NAT64可以根据管理规则过滤IPv6数据包，以在绑定表和会话表中创建条目。过滤可以是灵活和通用的，但过滤的思想是为管理员提供必要的控制，以避免拒绝服务（DoS）攻击，这将导致NAT64的IPv4地址、端口、内存和CPU资源耗尽。传入IPv6数据包的过滤技术不特定于NAT64，因此本规范中不进行描述。
Filtering of IPv4 packets, on the other hand, is tightly coupled to the NAT64 state and therefore is described in this specification. In this document, we consider that the NAT64 may do no filtering, or it may filter incoming IPv4 packets.
另一方面，IPv4数据包的过滤与NAT64状态紧密耦合，因此在本规范中进行了描述。在本文档中，我们认为NAT64不进行过滤，或者它可以过滤传入的IPv4包。
NAT64 filtering of incoming IPv4 packets is consistent with the recommendations of [RFC4787] and [RFC5382]. Because of that, the NAT64 as specified in this document supports both Endpoint-Independent Filtering and Address-Dependent Filtering, both for TCP and UDP as well as filtering of ICMP packets.
传入IPv4数据包的NAT64过滤符合[RFC4787]和[RFC5382]的建议。因此，本文档中指定的NAT64支持端点独立过滤和地址相关过滤，包括TCP和UDP过滤以及ICMP数据包过滤。
If a NAT64 performs Endpoint-Independent Filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state for the destination transport address of the incoming IPv4 packet.
如果NAT64对传入IPv4数据包执行与端点无关的过滤，则会丢弃传入IPv4数据包，除非NAT64具有传入IPv4数据包的目标传输地址的状态。
If a NAT64 performs Address-Dependent Filtering of incoming IPv4 packets, then an incoming IPv4 packet is dropped unless the NAT64 has state involving the destination transport address of the IPv4 incoming packet and the particular source IP address of the incoming IPv4 packet.
如果NAT64对传入IPv4数据包执行地址相关过滤，则传入IPv4数据包将被丢弃，除非NAT64的状态涉及IPv4传入数据包的目标传输地址和传入IPv4数据包的特定源IP地址。
This section provides a definitive reference for all the terms used in this document.
本节为本文件中使用的所有术语提供了明确的参考。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The following additional terms are used in this document:
本文件中使用了以下附加术语：
3-Tuple: The tuple (source IP address, destination IP address, ICMP Identifier). A 3-tuple uniquely identifies an ICMP Query session. When an ICMP Query session flows through a NAT64, each session has two different 3-tuples: one with IPv4 addresses and one with IPv6 addresses.
3-元组：元组（源IP地址、目标IP地址、ICMP标识符）。三元组唯一标识ICMP查询会话。当ICMP查询会话流经NAT64时，每个会话都有两个不同的3元组：一个具有IPv4地址，另一个具有IPv6地址。
5-Tuple: The tuple (source IP address, source port, destination IP address, destination port, transport protocol). A 5-tuple uniquely identifies a UDP/TCP session. When a UDP/TCP session flows through a NAT64, each session has two different 5-tuples: one with IPv4 addresses and one with IPv6 addresses.
5-元组：元组（源IP地址、源端口、目标IP地址、目标端口、传输协议）。5元组唯一标识UDP/TCP会话。当UDP/TCP会话流经NAT64时，每个会话都有两个不同的5元组：一个具有IPv4地址，另一个具有IPv6地址。
BIB: Binding Information Base. A table of bindings kept by a NAT64. Each NAT64 has a BIB for each translated protocol. An implementation compliant to this document would have a BIB for TCP, one for UDP, and one for ICMP Queries. Additional BIBs would be added to support other protocols, such as SCTP.
BIB：绑定信息库。NAT64保存的绑定表。每个NAT64都有一个用于每个已翻译协议的BIB。符合本文档的实现将有一个用于TCP的BIB、一个用于UDP的BIB和一个用于ICMP查询的BIB。将添加额外的BIB以支持其他协议，如SCTP。
Endpoint-Independent Mapping: In NAT64, using the same mapping for all the sessions involving a given IPv6 transport address of an IPv6 host (irrespectively of the transport address of the IPv4 host involved in the communication). Endpoint-Independent Mapping is important for peer-to-peer communication. See [RFC4787] for the definition of the different types of mappings in IPv4-to-IPv4 NATs.
端点独立映射：在NAT64中，对涉及IPv6主机的给定IPv6传输地址的所有会话使用相同的映射（不考虑通信中涉及的IPv4主机的传输地址）。端点无关映射对于对等通信非常重要。有关IPv4到IPv4 NAT中不同类型映射的定义，请参见[RFC4787]。
Filtering, Endpoint-Independent: The NAT64 only filters incoming IPv4 packets destined to a transport address for which there is no state in the NAT64, regardless of the source IPv4 transport address. The NAT forwards any packets destined to any transport address for which it has state. In other words, having state for a given transport address is sufficient to allow any packets back to the internal endpoint. See [RFC4787] for the definition of the different types of filtering in IPv4-to-IPv4 NATs.
过滤，端点独立：NAT64仅过滤发送到NAT64中没有状态的传输地址的传入IPv4数据包，而不管源IPv4传输地址如何。NAT将任何数据包转发到其具有状态的任何传输地址。换句话说，拥有给定传输地址的状态足以允许任何数据包返回内部端点。有关IPv4到IPv4 NAT中不同类型过滤的定义，请参见[RFC4787]。
Filtering, Address-Dependent: The NAT64 filters incoming IPv4 packets destined to a transport address for which there is no state (similar to the Endpoint-Independent Filtering). Additionally, the NAT64 will filter out incoming IPv4 packets coming from a given IPv4 address X and destined for a transport address for which it has state if the NAT64 has not sent packets to X previously (independently of the port used by X). In other words, for receiving packets from a specific IPv4 endpoint, it is necessary for the IPv6 endpoint to send packets first to that specific IPv4 endpoint's IP address.
过滤，地址相关：NAT64过滤发送到没有状态的传输地址的传入IPv4数据包（类似于端点独立过滤）。此外，如果NAT64之前没有向X发送数据包（与X使用的端口无关），则NAT64将过滤掉来自给定IPv4地址X且目的地为其具有状态的传输地址的传入IPv4数据包。换句话说，要从特定IPv4端点接收数据包，IPv6端点必须首先将数据包发送到该特定IPv4端点的IP地址。
Hairpinning: Having a packet do a "U-turn" inside a NAT and come back out the same side as it arrived on. If the destination IPv6 address and its embedded IPv4 address are both assigned to the NAT64 itself, then the packet is being sent to another IPv6 host connected to the same NAT64. Such a packet is called a 'hairpin packet'. A NAT64 that forwards hairpin packets back to the IPv6 host is defined as supporting "hairpinning". Hairpinning support is important for peer-to-peer applications, as there are cases when two different hosts on the same side of a NAT can only communicate using sessions that hairpin through the NAT. Hairpin packets can be either TCP or UDP. More detailed explanation of hairpinning and examples for the UDP case can be found in [RFC4787].
发夹：让一个包在NAT内做一个“U形转弯”，然后从到达的同一侧返回。如果目标IPv6地址及其嵌入的IPv4地址都分配给NAT64本身，则数据包将被发送到连接到同一NAT64的另一个IPv6主机。这种包被称为“发夹包”。将发夹数据包转发回IPv6主机的NAT64定义为支持“发夹”。发夹支持对于对等应用程序非常重要，因为在某些情况下，NAT同一侧的两个不同主机只能使用发夹通过NAT的会话进行通信。发夹数据包可以是TCP或UDP。[RFC4787]中提供了关于发夹和UDP示例的更详细解释。
ICMP Query packet: ICMP packets that are not ICMP error messages. For ICMPv6, ICMPv6 Query Messages are the ICMPv6 Informational messages as defined in [RFC4443]. For ICMPv4, ICMPv4 Query messages are all ICMPv4 messages that are not ICMPv4 error messages.
ICMP查询数据包：不是ICMP错误消息的ICMP数据包。对于ICMPv6，ICMPv6查询消息是[RFC4443]中定义的ICMPv6信息性消息。对于ICMPv4，ICMPv4查询消息是所有不是ICMPv4错误消息的ICMPv4消息。
Mapping or Binding: A mapping between an IPv6 transport address and a IPv4 transport address or a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair. Used to translate the addresses and ports / ICMP Identifiers of packets flowing between the IPv6 host and the IPv4 host. In NAT64, the IPv4 address and port / ICMPv4 Identifier is always one assigned to the NAT64 itself, while the IPv6 address and port / ICMPv6 Identifier belongs to some IPv6 host.
映射或绑定：IPv6传输地址和IPv4传输地址之间的映射，或（IPv6地址，ICMPv6标识符）对和（IPv4地址，ICMPv4标识符）对之间的映射。用于转换在IPv6主机和IPv4主机之间流动的数据包的地址和端口/ICMP标识符。在NAT64中，IPv4地址和端口/ICMPv4标识符始终分配给NAT64本身，而IPv6地址和端口/ICMPv6标识符属于某些IPv6主机。
Session: The flow of packets between two different hosts. This may be TCP, UDP, or ICMP Queries. In NAT64, typically one host is an IPv4 host, and the other one is an IPv6 host. However, due to hairpinning, both hosts might be IPv6 hosts.
会话：两个不同主机之间的数据包流。这可能是TCP、UDP或ICMP查询。在NAT64中，通常一个主机是IPv4主机，另一个是IPv6主机。但是，由于发夹，两台主机可能都是IPv6主机。
Session table: A table of sessions kept by a NAT64. Each NAT64 has three session tables, one for TCP, one for UDP, and one for ICMP Queries.
会话表：NAT64保存的会话表。每个NAT64有三个会话表，一个用于TCP，一个用于UDP，一个用于ICMP查询。
Stateful NAT64: A function that has per-flow state that translates IPv6 packets to IPv4 packets and vice versa, for TCP, UDP, and ICMP. The NAT64 uses binding state to perform the translation between IPv6 and IPv4 addresses. In this document, we also refer to stateful NAT64 simply as NAT64.
有状态NAT64：对于TCP、UDP和ICMP，具有每流状态的函数，可将IPv6数据包转换为IPv4数据包，反之亦然。NAT64使用绑定状态执行IPv6和IPv4地址之间的转换。在本文中，我们也将有状态NAT64简称为NAT64。
Stateful NAT64 device: The device where the NAT64 function is executed. In this document, we also refer to stateful NAT64 device simply as NAT64 device.
有状态NAT64设备：执行NAT64功能的设备。在本文中，我们也将有状态NAT64设备简单地称为NAT64设备。
Transport Address: The combination of an IPv6 or IPv4 address and a port. Typically written as (IP address,port), e.g., (192.0.2.15,8001).
传输地址：IPv6或IPv4地址与端口的组合。通常写为（IP地址、端口），例如（192.0.2.158001）。
Tuple: Refers to either a 3-tuple or a 5-tuple as defined above.
元组：指上面定义的3元组或5元组。
For a detailed understanding of this document, the reader should also be familiar with NAT terminology [RFC4787].
要详细了解本文档，读者还应熟悉NAT术语[RFC4787]。
A NAT64 is a device with at least one IPv6 interface and at least one IPv4 interface. Each NAT64 device MUST have at least one unicast /n IPv6 prefix assigned to it, denoted Pref64::/n. Additional considerations about the Pref64::/n are presented in Section 3.5.4. A NAT64 MUST have one or more unicast IPv4 addresses assigned to it.
NAT64是具有至少一个IPv6接口和至少一个IPv4接口的设备。每个NAT64设备必须至少分配一个单播/n IPv6前缀，表示为Pref64:：/n。关于Pref64:：/n的其他注意事项见第3.5.4节。NAT64必须分配一个或多个单播IPv4地址。
A NAT64 uses the following conceptual dynamic data structures:
NAT64使用以下概念性动态数据结构：
o UDP Binding Information Base
o UDP绑定信息库
o UDP Session Table
o UDP会话表
o TCP Binding Information Base
o TCP绑定信息库
o TCP Session Table
o TCP会话表
o ICMP Query Binding Information Base
o ICMP查询绑定信息库
o ICMP Query Session Table
o ICMP查询会话表
These tables contain information needed for the NAT64 processing. The actual division of the information into six tables is done in order to ease the description of the NAT64 behavior. NAT64 implementations are free to use different data structures but they MUST store all the required information, and the externally visible outcome MUST be the same as the one described in this document.
这些表包含NAT64处理所需的信息。为了简化NAT64行为的描述，将信息实际划分为六个表。NAT64实现可以自由使用不同的数据结构，但它们必须存储所有必需的信息，并且外部可见的结果必须与本文档中描述的结果相同。
The notation used is the following: uppercase letters are IPv4 addresses; uppercase letters with a prime(') are IPv6 addresses; lowercase letters are ports; IPv6 prefixes of length n are indicated by "P::/n"; mappings are indicated as "(X,x) <--> (Y',y)".
使用的符号如下：大写字母是IPv4地址；带素数（'）的大写字母是IPv6地址；小写字母是端口；长度为n的IPv6前缀用“P:：/n”表示；映射表示为“（X，X）<-->（Y'，Y）”。
A NAT64 has three Binding Information Bases (BIBs): one for TCP, one for UDP, and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB entry specifies a mapping between an IPv6 transport address and an IPv4 transport address:
NAT64有三个绑定信息库（BIB）：一个用于TCP，一个用于UDP，一个用于ICMP查询。对于UDP和TCP BIB，每个BIB条目指定IPv6传输地址和IPv4传输地址之间的映射：
(X',x) <--> (T,t)
（X'，X）<-->（T，T）
where X' is some IPv6 address, T is an IPv4 address, and x and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. The BIB has then two columns: the BIB IPv6 transport address and the BIB IPv4 transport address. A given IPv6 or IPv4 transport address can appear in at most one entry in a BIB: for example,
其中X'是某个IPv6地址，T是IPv4地址，X和T是端口。T将始终是分配给NAT64的IPv4地址之一。BIB有两列：BIB IPv6传输地址和BIB IPv4传输地址。给定的IPv6或IPv4传输地址最多可以出现在BIB中的一个条目中：例如，
(2001:db8::17, 49832) can appear in at most one TCP and at most one UDP BIB entry. TCP and UDP have separate BIBs because the port number space for TCP and UDP are distinct. If the BIBs are implemented as specified in this document, it results in Endpoint-Independent Mappings in the NAT64. The information in the BIBs is also used to implement Endpoint-Independent Filtering. (Address-Dependent Filtering is implemented using the session tables described below.)
（2001:db8:：1749832）最多可以出现在一个TCP和一个UDP BIB条目中。TCP和UDP有单独的BIB，因为TCP和UDP的端口号空间是不同的。如果BIB按照本文档中的规定实现，则会导致NAT64中的端点独立映射。BIB中的信息还用于实现端点独立过滤。（使用下面描述的会话表实现与地址相关的过滤。）
In the case of the ICMP Query BIB, each ICMP Query BIB entry specifies a mapping between an (IPv6 address, ICMPv6 Identifier) pair and an (IPv4 address, ICMPv4 Identifier) pair.
对于ICMP查询BIB，每个ICMP查询BIB条目指定（IPv6地址，ICMPv6标识符）对和（IPv4地址，ICMPv4标识符）对之间的映射。
(X',i1) <--> (T,i2)
（X'，i1）<-->（T，i2）
where X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64. A given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can appear in at most one entry in the ICMP Query BIB.
其中X'是某个IPv6地址，T是IPv4地址，i1是ICMPv6标识符，i2是ICMPv4标识符。T将始终是分配给NAT64的IPv4地址之一。给定的（IPv6或IPv4地址、ICMPv6或ICMPv4标识符）对最多可以出现在ICMP查询BIB的一个条目中。
Entries in any of the three BIBs can be created dynamically as the result of the flow of packets as described in Section 3.5, but they can also be created manually by an administrator. NAT64 implementations SHOULD support manually configured BIB entries for any of the three BIBs. Dynamically created entries are deleted from the corresponding BIB when the last session associated with the BIB entry is removed from the session table. Manually configured BIB entries are not deleted when there is no corresponding Session Table Entry and can only be deleted by the administrator.
三个BIB中的任何一个都可以根据第3.5节所述的数据包流动态创建条目，但管理员也可以手动创建条目。NAT64实现应支持为三个BIB中的任何一个手动配置BIB条目。当从会话表中删除与BIB条目关联的最后一个会话时，将从相应BIB中删除动态创建的条目。当没有相应的会话表条目时，手动配置的BIB条目不会被删除，只能由管理员删除。
A NAT64 also has three session tables: one for TCP sessions, one for UDP sessions, and one for ICMP Query sessions. Each entry keeps information on the state of the corresponding session. In the TCP and UDP session tables, each entry specifies a mapping between a pair of IPv6 transport addresses and a pair of IPv4 transport addresses:
NAT64还有三个会话表：一个用于TCP会话，一个用于UDP会话，一个用于ICMP查询会话。每个条目保存有关相应会话状态的信息。在TCP和UDP会话表中，每个条目指定一对IPv6传输地址和一对IPv4传输地址之间的映射：
(X',x),(Y',y) <--> (T,t),(Z,z)
(X',x),(Y',y) <--> (T,t),(Z,z)
where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, and x, y, z, and t are ports. T will always be one of the IPv4 addresses assigned to the NAT64. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm applied by the NAT64 to create IPv6 representations of IPv4 addresses. y will always be equal to z.
其中X'和Y'是IPv6地址，T和Z是IPv4地址，X、Y、Z和T是端口。T将始终是分配给NAT64的IPv4地址之一。Y'始终是IPv4地址Z的IPv6表示形式，因此Y'是使用NAT64应用的算法从Z获得的，以创建IPv4地址的IPv6表示形式。y永远等于z。
For each TCP or UDP Session Table Entry (STE), there are then five columns. The terminology used for the STE columns is from the perspective of an incoming IPv6 packet being translated into an outgoing IPv4 packet. The columns are:
对于每个TCP或UDP会话表条目（STE），有五列。STE列中使用的术语是从传入IPv6数据包转换为传出IPv4数据包的角度来看的。各栏分别为：
The STE source IPv6 transport address; (X',x) in the example above.
STE源IPv6传输地址；（X'，X）在上述示例中。
The STE destination IPv6 transport address; (Y',y) in the example above.
STE目标IPv6传输地址；（Y'，Y）在上述示例中。
The STE source IPv4 transport address; (T,t) in the example above.
STE源IPv4传输地址；（T，T）在上述示例中。
The STE destination IPv4 transport address; (Z,z) in the example above.
STE目标IPv4传输地址；（Z，Z）在上述示例中。
The STE lifetime.
STE的一生。
In the ICMP Query session table, each entry specifies a mapping between a 3-tuple of IPv6 source address, IPv6 destination address, and ICMPv6 Identifier and a 3-tuple of IPv4 source address, IPv4 destination address, and ICMPv4 Identifier:
在ICMP查询会话表中，每个条目指定IPv6源地址、IPv6目标地址和ICMPv6标识符的三元组与IPv4源地址、IPv4目标地址和ICMPv4标识符的三元组之间的映射：
(X',Y',i1) <--> (T,Z,i2)
（X'，Y'，i1）<-->（T，Z，i2）
where X' and Y' are IPv6 addresses, T and Z are IPv4 addresses, i1 is an ICMPv6 Identifier, and i2 is an ICMPv4 Identifier. T will always be one of the IPv4 addresses assigned to the NAT64. Y' is always the IPv6 representation of the IPv4 address Z, so Y' is obtained from Z using the algorithm applied by the NAT64 to create IPv6 representations of IPv4 addresses.
其中X'和Y'是IPv6地址，T和Z是IPv4地址，i1是ICMPv6标识符，i2是ICMPv4标识符。T将始终是分配给NAT64的IPv4地址之一。Y'始终是IPv4地址Z的IPv6表示形式，因此Y'是使用NAT64应用的算法从Z获得的，以创建IPv4地址的IPv6表示形式。
For each ICMP Query Session Table Entry (STE), there are then seven columns:
对于每个ICMP查询会话表条目（STE），有七列：
The STE source IPv6 address; X' in the example above.
STE源IPv6地址；在上面的例子中是X。
The STE destination IPv6 address; Y' in the example above.
STE目标IPv6地址；在上面的例子中是Y。
The STE ICMPv6 Identifier; i1 in the example above.
STE ICMPv6标识符；在上面的例子中是i1。
The STE source IPv4 address; T in the example above.
STE源IPv4地址；T在上面的例子中。
The STE destination IPv4 address; Z in the example above.
STE目标IPv4地址；Z在上面的例子中。
The STE ICMPv4 Identifier; i2 in the example above.
STE ICMPv4标识符；i2在上面的示例中。
The STE lifetime.
STE的一生。
The NAT64 uses the session state information to determine when the session is completed, and also uses session information for Address-Dependent Filtering. A session can be uniquely identified by either an incoming tuple or an outgoing tuple.
NAT64使用会话状态信息确定会话何时完成，还使用会话信息进行地址相关过滤。会话可以由传入元组或传出元组唯一标识。
For each TCP or UDP session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 transport address (in the IPv6 --> IPv4 direction) or the destination IPv4 transport address (in the IPv4 --> IPv6 direction). For each ICMP Query session, there is a corresponding BIB entry, uniquely specified by either the source IPv6 address and ICMPv6 Identifier (in the IPv6 --> IPv4 direction) or the destination IPv4 address and the ICMPv4 Identifier (in the IPv4 --> IPv6 direction). However, for all the BIBs, a single BIB entry can have multiple corresponding sessions. When the last corresponding session is deleted, if the BIB entry was dynamically created, the BIB entry is deleted.
对于每个TCP或UDP会话，都有一个对应的BIB条目，由源IPv6传输地址（在IPv6-->IPv4方向）或目标IPv4传输地址（在IPv4-->IPv6方向）唯一指定。对于每个ICMP查询会话，都有一个对应的BIB条目，由源IPv6地址和ICMPv6标识符（在IPv6-->IPv4方向）或目标IPv4地址和ICMPv4标识符（在IPv4-->IPv6方向）唯一指定。但是，对于所有BIB，单个BIB条目可以有多个相应的会话。删除最后一个对应会话时，如果动态创建BIB条目，则会删除BIB条目。
The NAT64 will receive packets through its interfaces. These packets can be either IPv6 packets or IPv4 packets, and they may carry TCP traffic, UDP traffic, or ICMP traffic. The processing of the packets will be described next. In the case that the processing is common to all the aforementioned types of packets, we will refer to the packet as the incoming IP packet in general. In the case that the processing is specific to IPv6 packets, we will explicitly refer to the incoming packet as an incoming IPv6 packet; analogous terminology will apply in the case of processing that is specific to IPv4 packets.
NAT64将通过其接口接收数据包。这些数据包可以是IPv6数据包或IPv4数据包，它们可以承载TCP流量、UDP流量或ICMP流量。接下来将描述分组的处理。在处理对于上述所有类型的分组都是通用的情况下，我们通常将该分组称为传入IP分组。在处理特定于IPv6数据包的情况下，我们将显式地将传入数据包称为传入IPv6数据包；类似的术语将适用于特定于IPv4数据包的处理。
The processing of an incoming IP packet takes the following steps:
传入IP数据包的处理采取以下步骤：
1. Determining the incoming tuple
1. 确定传入元组
2. Filtering and updating binding and session information
2. 筛选和更新绑定和会话信息
3. Computing the outgoing tuple
3. 计算传出元组
4. Translating the packet
4. 翻译数据包
5. Handling hairpinning
5. 处理发夹
The details of these steps are specified in the following subsections.
以下小节详细说明了这些步骤。
This breakdown of the NAT64 behavior into processing steps is done for ease of presentation. 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行为分解为处理步骤是为了便于演示。NAT64可以以不同的顺序执行步骤，也可以执行不同的步骤，但外部可见的结果必须与本文档中描述的结果相同。
This step associates an incoming tuple with every incoming IP packet for use in subsequent steps. In the case of TCP, UDP, and ICMP error packets, the tuple is a 5-tuple consisting of the source IP address, source port, destination IP address, destination port, and transport protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting of the source IP address, destination IP address, and ICMP Identifier.
此步骤将传入的元组与每个传入的IP数据包相关联，以便在后续步骤中使用。对于TCP、UDP和ICMP错误数据包，元组是由源IP地址、源端口、目标IP地址、目标端口和传输协议组成的5元组。对于ICMP查询，元组是由源IP地址、目标IP地址和ICMP标识符组成的3元组。
If the incoming IP packet contains a complete (un-fragmented) UDP or TCP protocol packet, then the 5-tuple is computed by extracting the appropriate fields from the received packet.
如果传入的IP数据包包含完整的（未分段的）UDP或TCP协议数据包，则通过从接收的数据包中提取适当的字段来计算5元组。
If the incoming packet is a complete (un-fragmented) ICMP Query message (i.e., an ICMPv4 Query message or an ICMPv6 Informational message), the 3-tuple is the source IP address, the destination IP address, and the ICMP Identifier.
如果传入数据包是完整（未分段）的ICMP查询消息（即ICMPv4查询消息或ICMPv6信息消息），则三元组是源IP地址、目标IP地址和ICMP标识符。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing a UDP or a TCP packet, then the incoming 5-tuple is computed by extracting the appropriate fields from the IP packet embedded inside the ICMP error message. However, the role of source and destination is swapped when doing this: the embedded source IP address becomes the destination IP address in the incoming 5-tuple, the embedded source port becomes the destination port in the incoming 5-tuple, etc. If it is not possible to determine the incoming 5-tuple (perhaps because not enough of the embedded packet is reproduced inside the ICMP message), then the incoming IP packet MUST be silently discarded.
如果传入的IP数据包包含包含UDP或TCP数据包的完整（未分段）ICMP错误消息，则通过从嵌入ICMP错误消息中的IP数据包提取适当字段来计算传入的5元组。但是，在执行此操作时，源和目标的角色是交换的：如果无法确定传入的5元组，则嵌入的源IP地址将成为传入5元组中的目标IP地址，嵌入的源端口将成为传入5元组中的目标端口，等等（可能是因为在ICMP消息中没有足够的嵌入数据包被复制），因此必须悄悄地丢弃传入的IP数据包。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing an ICMP error message, then the packet is silently discarded.
如果传入的IP数据包包含包含ICMP错误消息的完整（未分段）ICMP错误消息，则该数据包将被自动丢弃。
If the incoming IP packet contains a complete (un-fragmented) ICMP error message containing an ICMP Query message, then the incoming 3-tuple is computed by extracting the appropriate fields from the IP packet embedded inside the ICMP error message. However, the role of source and destination is swapped when doing this: the embedded source IP address becomes the destination IP address in the incoming 3-tuple, the embedded destination IP address becomes the source
如果传入的IP数据包包含包含ICMP查询消息的完整（未分段）ICMP错误消息，则通过从嵌入ICMP错误消息中的IP数据包提取适当字段来计算传入的3元组。但是，在执行此操作时，源和目标的角色是交换的：嵌入的源IP地址成为传入3元组中的目标IP地址，嵌入的目标IP地址成为源
address in the incoming 3-tuple, and the embedded ICMP Identifier is used as the ICMP Identifier of the incoming 3-tuple. If it is not possible to determine the incoming 3-tuple (perhaps because not enough of the embedded packet is reproduced inside the ICMP message), then the incoming IP packet MUST be silently discarded.
传入3元组中的地址，嵌入的ICMP标识符用作传入3元组的ICMP标识符。如果无法确定传入的3元组（可能是因为ICMP消息中没有足够的嵌入数据包被复制），则必须悄悄地丢弃传入的IP数据包。
If the incoming IP packet contains a fragment, then more processing may be needed. This specification leaves open the exact details of how a NAT64 handles incoming IP packets containing fragments, and simply requires that the external behavior of the NAT64 be compliant with the following conditions:
如果传入的IP数据包包含一个片段，则可能需要更多的处理。本规范保留了NAT64如何处理包含片段的传入IP数据包的确切细节，仅要求NAT64的外部行为符合以下条件：
The NAT64 MUST handle fragments. In particular, NAT64 MUST handle fragments arriving out of order, conditional on the following:
NAT64必须处理片段。特别是，NAT64必须处理无序到达的片段，条件如下：
* The NAT64 MUST limit the amount of resources devoted to the storage of fragmented packets in order to protect from DoS attacks.
* NAT64必须限制用于存储碎片数据包的资源量，以防止DoS攻击。
* As long as the NAT64 has available resources, the NAT64 MUST allow the fragments to arrive over a time interval. The time interval SHOULD be configurable and the default value MUST be of at least FRAGMENT_MIN.
* 只要NAT64具有可用资源，NAT64就必须允许片段在一段时间间隔内到达。时间间隔应该是可配置的，默认值必须至少为FRAGMENT_MIN。
* The NAT64 MAY require that the UDP, TCP, or ICMP header be completely contained within the fragment that contains fragment offset equal to zero.
* NAT64可能要求UDP、TCP或ICMP标头完全包含在包含等于零的片段偏移量的片段中。
For incoming packets carrying TCP or UDP fragments with a non-zero checksum, NAT64 MAY elect to queue the fragments as they arrive and translate all fragments at the same time. In this case, the incoming tuple is determined as documented above to the un-fragmented packets. Alternatively, a NAT64 MAY translate the fragments as they arrive, by storing information that allows it to compute the 5-tuple for fragments other than the first. In the latter case, subsequent fragments may arrive before the first, and the rules (in the bulleted list above) about how the NAT64 handles (out-of-order) fragments apply.
对于带有非零校验和的TCP或UDP片段的传入数据包，NAT64可以选择在片段到达时对其排队，并同时转换所有片段。在这种情况下，如上文所述，将传入元组确定为未分段的数据包。或者，NAT64可以在片段到达时对其进行翻译，方法是存储允许其计算除第一个片段之外的片段的5元组的信息。在后一种情况下，后续片段可能在第一个片段之前到达，并且关于NAT64如何处理（无序）片段的规则（在上面的项目符号列表中）适用。
For incoming IPv4 packets carrying UDP packets with a zero checksum, if the NAT64 has enough resources, the NAT64 MUST reassemble the packets and MUST calculate the checksum. If the NAT64 does not have enough resources, then it MUST silently discard the packets. The handling of fragmented and un-fragmented UDP packets with a zero checksum as specified above deviates from that specified in [RFC6145].
对于携带校验和为零的UDP数据包的传入IPv4数据包，如果NAT64具有足够的资源，则NAT64必须重新组装数据包并计算校验和。如果NAT64没有足够的资源，那么它必须以静默方式丢弃数据包。如上所述，对校验和为零的分段和非分段UDP数据包的处理与[RFC6145]中的规定不同。
Implementers of NAT64 should be aware that there are a number of well-known attacks against IP fragmentation; see [RFC1858] and [RFC3128]. Implementers should also be aware of additional issues with reassembling packets at high rates, described in [RFC4963].
NAT64的实现者应该知道，存在许多针对IP碎片的众所周知的攻击；参见[RFC1858]和[RFC3128]。实施者还应注意[RFC4963]中所述的以高速率重新组装数据包的其他问题。
If the incoming packet is an IPv6 packet that contains a protocol other than TCP, UDP, or ICMPv6 in the last Next Header, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 4 (Port Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64.
如果传入数据包是IPv6数据包，在最后一个下一个报头中包含TCP、UDP或ICMPv6以外的协议，则应丢弃该数据包，如果安全策略允许，NAT64应向接收数据包的源地址发送代码为4（端口不可访问）的ICMPv6目的地不可访问错误消息。注意：此行为可能会在将来的文档中更新，这些文档定义了NAT64如何处理其他协议，如SCTP或DCCP。
If the incoming packet is an IPv4 packet that contains a protocol other than TCP, UDP, or ICMPv4, then the packet SHOULD be discarded and, if the security policy permits, the NAT64 SHOULD send an ICMPv4 Destination Unreachable error message with Code 2 (Protocol Unreachable) to the source address of the received packet. NOTE: This behavior may be updated by future documents that define how other protocols such as SCTP or DCCP are processed by NAT64.
如果传入数据包是包含TCP、UDP或ICMPv4以外协议的IPv4数据包，则应丢弃该数据包，并且如果安全策略允许，NAT64应向接收数据包的源地址发送代码为2（协议不可访问）的ICMPv4目标不可访问错误消息。注意：此行为可能会在将来的文档中更新，这些文档定义了NAT64如何处理其他协议，如SCTP或DCCP。
This step updates binding and session information stored in the appropriate tables. This step may also filter incoming packets, if desired.
此步骤更新存储在相应表中的绑定和会话信息。如果需要，此步骤还可以过滤传入的数据包。
The details of this step depend on the protocol, i.e., UDP, TCP, or ICMP. The behaviors for UDP, TCP, and ICMP Queries are described in Section 3.5.1, Section 3.5.2, and Section 3.5.3, respectively. For the case of ICMP error messages, they do not affect in any way either the BIBs or the session tables, so there is no processing resulting from these messages in this section. ICMP error message processing continues in Section 3.6.
此步骤的详细信息取决于协议，即UDP、TCP或ICMP。UDP、TCP和ICMP查询的行为分别在第3.5.1节、第3.5.2节和第3.5.3节中描述。对于ICMP错误消息，它们不会以任何方式影响BIB或会话表，因此在本节中不会对这些消息进行处理。第3.6节继续处理ICMP错误消息。
Irrespective of the transport protocol used, the NAT64 MUST silently discard all incoming IPv6 packets containing a source address that contains the Pref64::/n. This is required in order to prevent hairpinning loops as described in Section 5. In addition, the NAT64 MUST only process incoming IPv6 packets that contain a destination address that contains Pref64::/n. Likewise, the NAT64 MUST only process incoming IPv4 packets that contain a destination address that belongs to the IPv4 pool assigned to the NAT64.
无论使用何种传输协议，NAT64都必须以静默方式丢弃所有传入的IPv6数据包，这些数据包包含包含Pref64:：/n的源地址。这是为了防止第5节所述的发夹环。此外，NAT64必须仅处理包含包含Pref64:：/n的目标地址的传入IPv6数据包。同样，NAT64必须只处理包含属于分配给NAT64的IPv4池的目标地址的传入IPv4数据包。
The following state information is stored for a UDP session:
为UDP会话存储以下状态信息：
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Lifetime: a timer that tracks the remaining lifetime of the UDP session. When the timer expires, the UDP session is deleted. If all the UDP sessions corresponding to a dynamically created UDP BIB entry are deleted, then the UDP BIB entry is also deleted.
生存期：跟踪UDP会话剩余生存期的计时器。计时器过期时，UDP会话将被删除。如果删除了与动态创建的UDP BIB条目对应的所有UDP会话，则该UDP BIB条目也将被删除。
An IPv6 incoming packet with an incoming tuple with source transport address (X',x) and destination transport address (Y',y) is processed as follows:
具有具有源传输地址（X'，X）和目标传输地址（Y'，Y）的传入元组的IPv6传入数据包的处理如下：
The NAT64 searches for a UDP BIB entry that contains the BIB IPv6 transport address that matches the IPv6 source transport address (X',x). If such an entry does not exist, the NAT64 tries to create a new entry (if resources and policy permit). The source IPv6 transport address of the packet (X',x) is used as the BIB IPv6 transport address, and the BIB IPv4 transport address is set to (T,t), which is allocated using the rules defined in Section 3.5.1.1. The result is a BIB entry as follows: (X',x) <--> (T,t).
NAT64搜索包含与IPv6源传输地址（X'，X）匹配的BIB IPv6传输地址的UDP BIB条目。如果这样一个条目不存在，NAT64将尝试创建一个新条目（如果资源和策略允许）。数据包的源IPv6传输地址（X'，X）用作BIB IPv6传输地址，BIB IPv4传输地址设置为（T，T），使用第3.5.1.1节中定义的规则进行分配。结果是BIB条目如下所示：（X'，X）<-->（T，T）。
The NAT64 searches for the Session Table Entry corresponding to the incoming 5-tuple. If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). The information included in the session table is as follows:
NAT64搜索与传入的5元组对应的会话表条目。如果没有找到这样的条目，NAT64将尝试创建一个新条目（如果资源和策略允许）。会话表中包含的信息如下：
* The STE source IPv6 transport address is set to (X',x), i.e., the source IPv6 transport address contained in the received IPv6 packet.
* STE源IPv6传输地址设置为（X'，X），即接收到的IPv6数据包中包含的源IPv6传输地址。
* The STE destination IPv6 transport address is set to (Y',y), i.e., the destination IPv6 transport address contained in the received IPv6 packet.
* STE目标IPv6传输地址设置为（Y'，Y），即接收到的IPv6数据包中包含的目标IPv6传输地址。
* The STE source IPv4 transport address is extracted from the corresponding UDP BIB entry, i.e., it is set to (T,t).
* STE源IPv4传输地址从相应的UDP BIB条目中提取，即设置为（T，T）。
* The STE destination IPv4 transport is set to (Z(Y'),y), y being the same port as the STE destination IPv6 transport address and Z(Y') being algorithmically generated from the IPv6 destination address (i.e., Y') using the reverse algorithm (see Section 3.5.4).
* STE目标IPv4传输设置为（Z（Y'），Y），Y是与STE目标IPv6传输地址相同的端口，Z（Y'）是使用反向算法从IPv6目标地址（即Y'）通过算法生成的（见第3.5.4节）。
The result is a Session Table Entry as follows:
(X',x),(Y',y) <--> (T,t),(Z(Y'),y)
The result is a Session Table Entry as follows:
(X',x),(Y',y) <--> (T,t),(Z(Y'),y)
The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is translated and forwarded as described in the following sections.
NAT64将会话表项中的计时器设置（或重置）为最大会话生存期。可以配置最大会话生存期，默认值至少应为UDP_default。最大会话生存期不得小于UDP_MIN。数据包将按照以下部分中的说明进行转换和转发。
An IPv4 incoming packet, with an incoming tuple with source IPv4 transport address (W,w) and destination IPv4 transport address (T,t) is processed as follows:
IPv4传入数据包的传入元组具有源IPv4传输地址（W，W）和目标IPv4传输地址（T，T），处理如下：
The NAT64 searches for a UDP BIB entry that contains the BIB IPv4 transport address matching (T,t), i.e., the IPv4 destination transport address in the incoming IPv4 packet. If such an entry does not exist, the packet MUST be dropped. An ICMP error message with Type 3 (Destination Unreachable) MAY be sent to the original sender of the packet.
NAT64搜索包含BIB IPv4传输地址匹配（T，T）的UDP BIB条目，即传入IPv4数据包中的IPv4目标传输地址。如果这样的条目不存在，则必须丢弃数据包。可能会将类型为3（无法到达目的地）的ICMP错误消息发送给数据包的原始发送方。
If the NAT64 applies Address-Dependent Filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the Address-Dependent Filtering rule. To do this, it searches for a Session Table Entry with an STE source IPv4 transport address equal to (T,t), i.e., the destination IPv4 transport address in the incoming packet, and STE destination IPv4 address equal to W, i.e., the source IPv4 address in the incoming packet. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited).
如果NAT64在其IPv4接口上应用了地址相关筛选器，则NAT64将根据地址相关筛选器规则检查是否允许传入数据包。为此，它搜索会话表条目，其中STE源IPv4传输地址等于（T，T），即传入数据包中的目标IPv4传输地址，STE目标IPv4地址等于W，即传入数据包中的源IPv4地址。如果找到这样的条目（可能有多个条目），则数据包处理将继续。否则，数据包将被丢弃。如果数据包被丢弃，则可能会向数据包的原始发送者发送ICMP错误消息。ICMP错误消息（如果发送）的类型为3（无法到达目的地）和代码13（管理禁止通信）。
In case the packet is not discarded in the previous processing (either because the NAT64 is not filtering or because the packet is compliant with the Address-Dependent Filtering rule), then the NAT64 searches for the Session Table Entry containing the STE source IPv4 transport address equal to (T,t) and the STE destination IPv4 transport address equal to (W,w). If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). In case a new UDP Session Table Entry is created, it contains the following information:
如果在之前的处理中没有丢弃该数据包（因为NAT64未进行过滤，或者因为该数据包符合与地址相关的过滤规则），则NAT64将搜索包含等于（T，T）的STE源IPv4传输地址的会话表条目并且STE目标IPv4传输地址等于（W，W）。如果没有找到这样的条目，NAT64将尝试创建一个新条目（如果资源和策略允许）。如果创建了新的UDP会话表条目，它将包含以下信息：
* The STE source IPv6 transport address is extracted from the corresponding UDP BIB entry.
* STE源IPv6传输地址从相应的UDP BIB条目中提取。
* The STE destination IPv6 transport address is set to (Y'(W),w), w being the same port w as the source IPv4 transport address and Y'(W) being the IPv6 representation of W, generated using the algorithm described in Section 3.5.4.
* STE目标IPv6传输地址设置为（Y’（W），W为与源IPv4传输地址相同的端口W，Y’（W）为使用第3.5.4节所述算法生成的W的IPv6表示形式。
* The STE source IPv4 transport address is set to (T,t), i.e., the destination IPv4 transport addresses contained in the received IPv4 packet.
* STE源IPv4传输地址设置为（T，T），即接收到的IPv4数据包中包含的目标IPv4传输地址。
* The STE destination IPv4 transport is set to (W,w), i.e., the source IPv4 transport addresses contained in the received IPv4 packet.
* STE目标IPv4传输设置为（W，W），即接收到的IPv4数据包中包含的源IPv4传输地址。
The NAT64 sets (or resets) the timer in the Session Table Entry to the maximum session lifetime. The maximum session lifetime MAY be configurable, and the default SHOULD be at least UDP_DEFAULT. The maximum session lifetime MUST NOT be less than UDP_MIN. The packet is translated and forwarded as described in the following sections.
NAT64将会话表项中的计时器设置（或重置）为最大会话生存期。可以配置最大会话生存期，默认值至少应为UDP_default。最大会话生存期不得小于UDP_MIN。数据包将按照以下部分中的说明进行转换和转发。
When a new UDP BIB entry is created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry as follows:
当为源传输地址（S'，S）创建新的UDP BIB条目时，NAT64为该BIB条目分配IPv4传输地址，如下所示：
If there exists some other BIB entry containing S' as the IPv6 address and mapping it to some IPv4 address T, then the NAT64 SHOULD use T as the IPv4 address. Otherwise, use any IPv4 address of the IPv4 pool assigned to the NAT64 to be used for translation.
如果存在其他BIB条目，其中包含S'作为IPv6地址并将其映射到某个IPv4地址T，则NAT64应使用T作为IPv4地址。否则，请使用分配给NAT64的IPv4池的任何IPv4地址进行转换。
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
如果端口s在众所周知的端口范围0-1023内，并且NAT64在相同的端口范围内有一个可用的端口t，那么NAT64应该分配端口t。如果NAT64在同一范围内没有可用的端口，NAT64可以从另一个具有可用端口的范围分配端口t。（此行为在[RFC4787]的要求3-a中建议。）
If the port s is in the range 1024-65535, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port. (This behavior is recommended in REQ 3-a of [RFC4787].)
如果端口s在1024-65535范围内，并且NAT64在同一端口范围内有一个可用端口t，则NAT64应分配端口t。如果NAT64在同一范围内没有可用的端口，NAT64可以从另一个具有可用端口的范围分配端口t。（此行为在[RFC4787]的要求3-a中建议。）
The NAT64 SHOULD preserve the port parity (odd/even), as per Section 4.2.2 of [RFC4787]).
根据[RFC4787]第4.2.2节，NAT64应保留端口奇偶校验（奇偶校验）。
In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs).
在所有情况下，分配的IPv4传输地址（T，T）不得在同一BIB中的其他条目中使用，但可以在其他BIB（例如UDP和TCP BIB）中使用。
If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable).
如果无法分配适当的IPv4传输地址或创建BIB条目，则丢弃该数据包。NAT64应发送一条ICMPv6目标不可访问错误消息，代码为3（地址不可访问）。
In this section, we describe how the TCP BIB and session table are populated. We do so by defining the state machine that the NAT64 uses for TCP. We first describe the states and the information contained in them, and then we describe the actual state machine and state transitions.
在本节中，我们将描述如何填充TCP BIB和会话表。我们通过定义NAT64用于TCP的状态机来实现。我们首先描述状态和其中包含的信息，然后描述实际的状态机和状态转换。
The following state information is stored for a TCP session:
为TCP会话存储以下状态信息：
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Lifetime: a timer that tracks the remaining lifetime of the TCP session. When the timer expires, the TCP session is deleted. If all the TCP sessions corresponding to a TCP BIB entry are deleted, then the dynamically created TCP BIB entry is also deleted.
生存期：跟踪TCP会话剩余生存期的计时器。计时器过期时，TCP会话将被删除。如果删除了与TCP BIB条目对应的所有TCP会话，则动态创建的TCP BIB条目也将被删除。
Because the TCP session inactivity lifetime is set to at least 2 hours and 4 minutes (as per [RFC5382]), it is important that each TCP Session Table Entry corresponds to an existing TCP session. In order to do that, for each TCP session established, the TCP connection state is tracked using the following state machine.
由于TCP会话非活动生存期设置为至少2小时4分钟（根据[RFC5382]），因此每个TCP会话表条目对应于现有的TCP会话非常重要。为此，对于建立的每个TCP会话，使用以下状态机跟踪TCP连接状态。
The states are as follows:
各国情况如下：
CLOSED: Analogous to [RFC0793], CLOSED is a fictional state because it represents the state when there is no state for this particular 5-tuple, and therefore no connection.
CLOSED：与[RFC0793]类似，CLOSED是一个虚构的状态，因为它表示当这个特定的5元组没有状态时的状态，因此没有连接。
V4 INIT: An IPv4 packet containing a TCP SYN was received by the NAT64, implying that a TCP connection is being initiated from the IPv4 side. The NAT64 is now waiting for a matching IPv6 packet containing the TCP SYN in the opposite direction.
V4 INIT:NAT64接收到一个包含TCP SYN的IPv4数据包，这意味着正在从IPv4端启动TCP连接。NAT64现在正在等待一个匹配的IPv6数据包，该数据包包含反向的TCP SYN。
V6 INIT: An IPv6 packet containing a TCP SYN was received, translated, and forwarded by the NAT64, implying that a TCP connection is being initiated from the IPv6 side. The NAT64 is now waiting for a matching IPv4 packet containing the TCP SYN in the opposite direction.
V6 INIT：NAT64接收、转换和转发了包含TCP SYN的IPv6数据包，这意味着正在从IPv6端启动TCP连接。NAT64现在正在等待一个匹配的IPv4数据包，该数据包包含反向的TCP SYN。
ESTABLISHED: Represents an open connection, with data able to flow in both directions.
已建立：表示开放连接，数据可以双向流动。
V4 FIN RCV: An IPv4 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN in the opposite direction.
V4 FIN RCV:NAT64接收到一个包含TCP FIN的IPv4数据包，数据仍然可以在连接中流动，并且NAT64正在相反方向等待匹配的TCP FIN。
V6 FIN RCV: An IPv6 packet containing a TCP FIN was received by the NAT64, data can still flow in the connection, and the NAT64 is waiting for a matching TCP FIN in the opposite direction.
V6 FIN RCV:NAT64接收到一个包含TCP FIN的IPv6数据包，数据仍然可以在连接中流动，并且NAT64正在相反方向等待匹配的TCP FIN。
V6 FIN + V4 FIN RCV: Both an IPv4 packet containing a TCP FIN and an IPv6 packet containing an TCP FIN for this connection were received by the NAT64. The NAT64 keeps the connection state alive and forwards packets in both directions for a short period of time to allow remaining packets (in particular, the ACKs) to be delivered.
V6 FIN+V4 FIN RCV：NAT64接收到包含TCP FIN的IPv4数据包和包含此连接的TCP FIN的IPv6数据包。NAT64使连接状态保持活动状态，并在短时间内在两个方向上转发数据包，以允许传递剩余的数据包（特别是ACK）。
TRANS: The lifetime of the state for the connection is set to TCP_TRANS minutes either because a packet containing a TCP RST was received by the NAT64 for this connection or simply because the lifetime of the connection has decreased and there are only TCP_TRANS minutes left. The NAT64 will keep the state for the connection for TCP_TRANS minutes, and if no other data packets for that connection are received, the state for this connection is then terminated.
TRANS：连接状态的生存期设置为TCP_TRANS minutes，这可能是因为NAT64为此连接接收到包含TCP RST的数据包，也可能是因为连接的生存期已缩短，只剩下TCP_TRANS minutes。NAT64将保持连接状态达TCP_TRANS分钟，如果未收到该连接的其他数据包，则该连接的状态将终止。
The state machine used by the NAT64 for the TCP session processing is depicted next. The described state machine handles all TCP segments received through the IPv6 and IPv4 interface. There is one state machine per TCP connection that is potentially established through the NAT64. After bootstrapping of the NAT64 device, all TCP sessions are in CLOSED state. As we mention above, the CLOSED state is a fictional state when there is no state for that particular connection in the NAT64. It should be noted that there is one state machine per connection, so only packets belonging to a given connection are inputs to the state machine associated to that connection. In other words, when in the state machine below we state that a packet is received, it is implicit that the incoming 5-tuple of the data packet matches to the one of the state machine.
下面描述NAT64用于TCP会话处理的状态机。所述状态机处理通过IPv6和IPv4接口接收的所有TCP段。每个TCP连接都有一个可能通过NAT64建立的状态机。NAT64设备引导后，所有TCP会话都处于关闭状态。如上所述，当NAT64中没有特定连接的状态时，关闭状态是一种虚构状态。应该注意的是，每个连接都有一个状态机，因此只有属于给定连接的数据包才是与该连接相关联的状态机的输入。换句话说，当我们在下面的状态机中声明接收到一个数据包时，隐含的是数据包的传入5元组与状态机中的一个匹配。
A TCP segment with the SYN flag set that is received through the IPv6 interface is called a V6 SYN, similarly, V4 SYN, V4 FIN, V6 FIN, V6 FIN + V4 FIN, V6 RST, and V4 RST.
通过IPv6接口接收的设置了SYN标志的TCP段称为V6 SYN，类似地，称为V4 SYN、V4 FIN、V6 FIN、V6 FIN+V4 FIN、V6 RST和V4 RST。
The figure presents a simplified version of the state machine; refer to the text for the full specification of the state machine.
该图显示了状态机的简化版本；有关状态机的完整规格，请参阅本文。
+-----------------------------+
| |
V |
V6 +------+ V4 |
+----SYN------|CLOSED|-----SYN------+ |
| +------+ | |
| ^ | |
| |TCP_TRANS T.O. | |
V | V |
+-------+ +-------+ +-------+ |
|V6 INIT| | TRANS | |V4 INIT| |
+-------+ +-------+ +-------+ |
| | ^ | |
| data pkt | | |
| | V4 or V6 RST | |
| | TCP_EST T.O. | |
V4 SYN V | V6 SYN |
| +--------------+ | |
+--------->| ESTABLISHED |<---------+ |
+--------------+ |
| | |
V4 FIN V6 FIN |
| | |
V V |
+---------+ +----------+ |
| V4 FIN | | V6 FIN | |
| RCV | | RCV | |
+---------+ +----------+ |
| | |
V6 FIN V4 FIN TCP_TRANS
| | T.O.
V V |
+---------------------+ |
| V4 FIN + V6 FIN RCV |--------------------+
+---------------------+
+-----------------------------+
| |
V |
V6 +------+ V4 |
+----SYN------|CLOSED|-----SYN------+ |
| +------+ | |
| ^ | |
| |TCP_TRANS T.O. | |
V | V |
+-------+ +-------+ +-------+ |
|V6 INIT| | TRANS | |V4 INIT| |
+-------+ +-------+ +-------+ |
| | ^ | |
| data pkt | | |
| | V4 or V6 RST | |
| | TCP_EST T.O. | |
V4 SYN V | V6 SYN |
| +--------------+ | |
+--------->| ESTABLISHED |<---------+ |
+--------------+ |
| | |
V4 FIN V6 FIN |
| | |
V V |
+---------+ +----------+ |
| V4 FIN | | V6 FIN | |
| RCV | | RCV | |
+---------+ +----------+ |
| | |
V6 FIN V4 FIN TCP_TRANS
| | T.O.
V V |
+---------------------+ |
| V4 FIN + V6 FIN RCV |--------------------+
+---------------------+
We next describe the state information and the transitions.
接下来我们将描述状态信息和转换。
*** CLOSED ***
*** CLOSED ***
If a V6 SYN is received with an incoming tuple with source transport address (X',x) and destination transport address (Y',y) (this is the case of a TCP connection initiated from the IPv6 side), the processing is as follows:
如果接收到带有传入元组的V6 SYN，该元组具有源传输地址（X'，X）和目标传输地址（Y'，Y）（这是从IPv6端启动TCP连接的情况），则处理如下：
1. The NAT64 searches for a TCP BIB entry that matches the IPv6 source transport address (X',x).
1. NAT64搜索与IPv6源传输地址（X'，X）匹配的TCP BIB条目。
If such an entry does not exist, the NAT64 tries to create a new BIB entry (if resources and policy permit). The BIB IPv6 transport address is set to (X',x), i.e., the source IPv6 transport address of the packet. The BIB IPv4 transport address is set to an IPv4 transport address allocated using the rules defined in Section 3.5.2.3. The processing of the packet continues as described in bullet 2.
如果这样的条目不存在，NAT64将尝试创建新的BIB条目（如果资源和策略允许）。BIB IPv6传输地址设置为（X'，X），即数据包的源IPv6传输地址。BIB IPv4传输地址设置为使用第3.5.2.3节中定义的规则分配的IPv4传输地址。数据包的处理如项目符号2中所述继续进行。
If the entry already exists, then the processing continues as described in bullet 2.
如果条目已经存在，则处理将继续，如项目符号2中所述。
2. Then the NAT64 tries to create a new TCP session entry in the TCP session table (if resources and policy permit). The information included in the session table is as follows:
2. 然后NAT64尝试在TCP会话表中创建新的TCP会话条目（如果资源和策略允许）。会话表中包含的信息如下：
The STE source IPv6 transport address is set to (X',x), i.e., the source transport address contained in the received V6 SYN packet.
STE源IPv6传输地址设置为（X'，X），即接收到的V6 SYN数据包中包含的源传输地址。
The STE destination IPv6 transport address is set to (Y',y), i.e., the destination transport address contained in the received V6 SYN packet.
STE目的地IPv6传输地址设置为（Y'，Y），即接收到的V6 SYN数据包中包含的目的地传输地址。
The STE source IPv4 transport address is set to the BIB IPv4 transport address of the corresponding TCP BIB entry.
STE源IPv4传输地址设置为相应TCP BIB条目的BIB IPv4传输地址。
The STE destination IPv4 transport address contains the port y (i.e., the same port as the IPv6 destination transport address) and the IPv4 address that is algorithmically generated from the IPv6 destination address (i.e., Y') using the reverse algorithm as specified in Section 3.5.4.
STE目标IPv4传输地址包含端口y（即与IPv6目标传输地址相同的端口）和IPv4地址，该地址是使用第3.5.4节中规定的反向算法从IPv6目标地址（即y'）通过算法生成的。
The lifetime of the TCP Session Table Entry is set to at least TCP_TRANS (the transitory connection idle timeout as defined in [RFC5382]).
TCP会话表项的生存期至少设置为TCP_TRANS（在[RFC5382]中定义的临时连接空闲超时）。
3. The state of the session is moved to V6 INIT.
3. 会话的状态被移动到V6 INIT。
4. The NAT64 translates and forwards the packet as described in the following sections.
4. NAT64按照以下部分所述转换和转发数据包。
If a V4 SYN packet is received with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x) (this is the case of a TCP connection initiated from the IPv4 side), the processing is as follows:
如果接收到V4 SYN数据包时，传入的元组具有源IPv4传输地址（Y，Y）和目标IPv4传输地址（X，X）（这是从IPv4端启动TCP连接的情况），则处理如下：
If the security policy requires silently dropping externally initiated TCP connections, then the packet is silently discarded.
如果安全策略要求以静默方式丢弃外部启动的TCP连接，则会以静默方式丢弃数据包。
Else, if the destination transport address contained in the incoming V4 SYN (i.e., X,x) is not in use in the TCP BIB, then:
否则，如果传入V4 SYN（即X，X）中包含的目标传输地址未在TCP BIB中使用，则：
The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy permit), containing the following information:
NAT64尝试在TCP会话表中创建一个新的会话表条目（如果资源和策略允许），其中包含以下信息：
+ The STE source IPv4 transport address is set to (X,x), i.e., the destination transport address contained in the V4 SYN.
+ STE源IPv4传输地址设置为（X，X），即V4 SYN中包含的目标传输地址。
+ The STE destination IPv4 transport address is set to (Y,y), i.e., the source transport address contained in the V4 SYN.
+ STE目标IPv4传输地址设置为（Y，Y），即V4 SYN中包含的源传输地址。
+ The STE transport IPv6 source address is left unspecified and may be populated by other protocols that are out of the scope of this specification.
+ STE传输IPv6源地址未指定，可能由超出本规范范围的其他协议填充。
+ The STE destination IPv6 transport address contains the port y (i.e., the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (i.e., the IPv4 address of the STE destination IPv4 transport address), generated using the algorithm described in Section 3.5.4.
+ STE目标IPv6传输地址包含端口y（即，与STE目标IPv4传输地址相同的端口）和y的IPv6表示形式（即，STE目标IPv4传输地址的IPv4地址），使用第3.5.4节中描述的算法生成。
The state is moved to V4 INIT.
状态被移动到V4 INIT。
The lifetime of the STE entry is set to TCP_INCOMING_SYN as per [RFC5382], and the packet is stored. The result is that the NAT64 will not drop the packet based on the filtering, nor create a BIB entry. Instead, the NAT64 will only create the Session Table Entry and store the packet. The motivation for this is to support simultaneous open of TCP connections.
根据[RFC5382]，STE条目的生存期设置为TCP_INCOMING_SYN，并存储数据包。结果是NAT64不会基于过滤丢弃数据包，也不会创建BIB条目。相反，NAT64将只创建会话表条目并存储数据包。其动机是支持同时打开TCP连接。
If the destination transport address contained in the incoming V4 SYN (i.e., X,x) is in use in the TCP BIB, then:
如果传入V4 SYN（即X，X）中包含的目标传输地址正在TCP BIB中使用，则：
The NAT64 tries to create a new Session Table Entry in the TCP session table (if resources and policy permit), containing the following information:
NAT64尝试在TCP会话表中创建一个新的会话表条目（如果资源和策略允许），其中包含以下信息：
+ The STE source IPv4 transport address is set to (X,x), i.e., the destination transport address contained in the V4 SYN.
+ STE源IPv4传输地址设置为（X，X），即V4 SYN中包含的目标传输地址。
+ The STE destination IPv4 transport address is set to (Y,y), i.e., the source transport address contained in the V4 SYN.
+ STE目标IPv4传输地址设置为（Y，Y），即V4 SYN中包含的源传输地址。
+ The STE transport IPv6 source address is set to the IPv6 transport address contained in the corresponding TCP BIB entry.
+ STE传输IPv6源地址设置为相应TCP BIB条目中包含的IPv6传输地址。
+ The STE destination IPv6 transport address contains the port y (i.e., the same port as the STE destination IPv4 transport address) and the IPv6 representation of Y (i.e., the IPv4 address of the STE destination IPv4 transport address), generated using the algorithm described in Section 3.5.4.
+ STE目标IPv6传输地址包含端口y（即，与STE目标IPv4传输地址相同的端口）和y的IPv6表示形式（即，STE目标IPv4传输地址的IPv4地址），使用第3.5.4节中描述的算法生成。
The state is moved to V4 INIT.
状态被移动到V4 INIT。
If the NAT64 is performing Address-Dependent Filtering, the lifetime of the STE entry is set to TCP_INCOMING_SYN as per [RFC5382], and the packet is stored. The motivation for creating the Session Table Entry and storing the packet (instead of simply dropping the packet based on the filtering) is to support simultaneous open of TCP connections.
如果NAT64正在执行地址相关过滤，则根据[RFC5382]将STE条目的生存期设置为TCP_INCOMING_SYN，并存储数据包。创建会话表条目并存储数据包（而不是简单地基于过滤丢弃数据包）的动机是支持同时打开TCP连接。
If the NAT64 is not performing Address-Dependent Filtering, the lifetime of the STE is set to at least TCP_TRANS (the transitory connection idle timeout as defined in [RFC5382]), and it translates and forwards the packet as described in the following sections.
如果NAT64未执行地址相关过滤，则STE的生存期至少设置为TCP_TRANS（在[RFC5382]中定义的临时连接空闲超时），并且它按照以下部分中的描述转换和转发数据包。
For any other packet belonging to this connection:
对于属于此连接的任何其他数据包：
If there is a corresponding entry in the TCP BIB, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
如果TCP BIB中有相应的条目，则应在安全策略允许的情况下翻译和转发数据包。国家保持不变。
If there is no corresponding entry in the TCP BIB, the packet is silently discarded.
如果TCP BIB中没有相应的条目，则会自动丢弃该数据包。
*** V4 INIT ***
*** V4 INIT ***
If a V6 SYN is received with incoming tuple with source transport address (X',x) and destination transport address (Y',y), then the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded. The state is moved to ESTABLISHED.
如果接收到带有传入元组的V6 SYN，该元组具有源传输地址（X'，X）和目标传输地址（Y'，Y），则TCP会话表项的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不得小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。数据包被翻译和转发。该州被移至已建立的州。
If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code 3) containing the IPv4 SYN packet stored is sent back to the source of the v4 SYN, the Session Table Entry is deleted, and the state is moved to CLOSED.
如果生存期到期，包含存储的IPv4 SYN数据包的ICMP端口不可访问错误（类型3，代码3）将发送回v4 SYN的源，会话表条目将被删除，状态将移动到关闭。
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
对于任何其他数据包，如果安全策略允许，则应翻译和转发数据包。国家保持不变。
*** V6 INIT ***
*** V6 INIT ***
If a V4 SYN is received (with or without the ACK flag set), with an incoming tuple with source IPv4 transport address (Y,y) and destination IPv4 transport address (X,x), then the state is moved to ESTABLISHED. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The packet is translated and forwarded.
如果接收到V4 SYN（设置了ACK标志或未设置ACK标志），以及具有源IPv4传输地址（Y，Y）和目标IPv4传输地址（X，X）的传入元组，则状态将移动到已建立。TCP会话表项的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不得小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。数据包被翻译和转发。
If the lifetime expires, the Session Table Entry is deleted, and the state is moved to CLOSED.
如果生存期到期，则删除会话表条目，并将状态移到“关闭”。
If a V6 SYN packet is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least TCP_TRANS. The state remains unchanged.
如果接收到V6 SYN数据包，则该数据包将被转换和转发。TCP会话表项的生存期至少设置为TCP_TRANS。国家保持不变。
For any other packet, the packet SHOULD be translated and forwarded if the security policy allows doing so. The state remains unchanged.
对于任何其他数据包，如果安全策略允许，则应翻译和转发数据包。国家保持不变。
*** ESTABLISHED ***
*** ESTABLISHED ***
If a V4 FIN packet is received, the packet is translated and forwarded. The state is moved to V4 FIN RCV.
如果接收到V4 FIN数据包，则该数据包将被转换和转发。状态移动到V4 FIN RCV。
If a V6 FIN packet is received, the packet is translated and forwarded. The state is moved to V6 FIN RCV.
如果接收到V6 FIN数据包，则该数据包将被转换和转发。状态移动到V6 FIN RCV。
If a V4 RST or a V6 RST packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS and the state is moved to TRANS. (Since the NAT64 is uncertain whether the peer will accept the RST packet, instead of moving the state to CLOSED, it moves to TRANS, which has a shorter lifetime. If no other packets are received for this connection during the short timer, the NAT64 assumes that the peer has accepted the RST packet and moves to CLOSED. If packets keep flowing, the NAT64 assumes that the peer has not accepted the RST packet and moves back to the ESTABLISHED state. This is described below in the TRANS state processing description.)
如果接收到V4 RST或V6 RST数据包，则该数据包将被转换和转发。生存期设置为TCP_TRANS，状态移动为TRANS。（由于NAT64不确定对等方是否会接受RST数据包，因此它不会将状态移动到关闭，而是移动到寿命较短的TRANS。如果在较短的计时器期间未接收到此连接的其他数据包，NAT64将假定对等方已接受RST数据包并移动到关闭。如果数据包继续流动，则NAT64假设对等方未接受RST数据包，并返回到已建立状态。这在下面的TRANS-state处理描述中描述。）
If any other packet is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as ESTABLISHED.
如果接收到任何其他数据包，则对该数据包进行翻译和转发。TCP会话表项的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不得小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。国家仍然保持不变。
If the lifetime expires, then the NAT64 SHOULD send a probe packet (as defined next) to at least one of the endpoints of the TCP connection. The probe packet is a TCP segment for the connection with no data. The sequence number and the acknowledgment number are set to zero. All flags but the ACK flag are set to zero. The state is moved to TRANS.
如果生存期到期，NAT64应向TCP连接的至少一个端点发送探测数据包（定义见下文）。探测数据包是用于无数据连接的TCP段。序列号和确认号设置为零。除ACK标志外，所有标志均设置为零。该州被移至TRANS。
Upon the reception of this probe packet, the endpoint will reply with an ACK containing the expected sequence number for that connection. It should be noted that, for an active connection, each of these probe packets will generate one packet from each end involved in the connection, since the reply of the first point to the probe packet will generate a reply from the other endpoint.
在接收到此探测数据包后，端点将使用包含该连接的预期序列号的ACK进行应答。应当注意，对于活动连接，这些探测数据包中的每一个都将从连接中涉及的每一端生成一个数据包，因为第一点对探测数据包的应答将从另一个端点生成应答。
*** V4 FIN RCV ***
*** V4 FIN RCV ***
If a V6 FIN packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS. The state is moved to V6 FIN + V4 FIN RCV.
如果接收到V6 FIN数据包，则该数据包将被转换和转发。生存期设置为TCP_TRANS。状态移动到V6 FIN+V4 FIN RCV。
If any packet other than the V6 FIN is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be
如果接收到除V6 FIN以外的任何数据包，则该数据包将被转换和转发。TCP会话表项的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不能配置
less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V4 FIN RCV.
小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。该状态保持不变，为V4 FIN RCV。
If the lifetime expires, the Session Table Entry is deleted, and the state is moved to CLOSED.
如果生存期到期，则删除会话表条目，并将状态移到“关闭”。
*** V6 FIN RCV ***
*** V6 FIN RCV ***
If a V4 FIN packet is received, the packet is translated and forwarded. The lifetime is set to TCP_TRANS. The state is moved to V6 FIN + V4 FIN RCV.
如果接收到V4 FIN数据包，则该数据包将被转换和转发。生存期设置为TCP_TRANS。状态移动到V6 FIN+V4 FIN RCV。
If any packet other than the V4 FIN is received, the packet is translated and forwarded. The lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state remains unchanged as V6 FIN RCV.
如果接收到V4 FIN以外的任何数据包，则该数据包将被转换和转发。TCP会话表项的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不得小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。该状态保持不变，为V6 FIN RCV。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
如果生存期到期，将删除会话表条目，并将状态移动到“关闭”。
*** V6 FIN + V4 FIN RCV ***
*** V6 FIN + V4 FIN RCV ***
All packets are translated and forwarded.
所有数据包都被翻译和转发。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
如果生存期到期，将删除会话表条目，并将状态移动到“关闭”。
*** TRANS ***
*** TRANS ***
If a packet other than a RST packet is received, the lifetime of the TCP Session Table Entry is set to at least the maximum session lifetime. The value for the maximum session lifetime MAY be configurable, but it MUST NOT be less than TCP_EST (the established connection idle timeout as defined in [RFC5382]). The default value for the maximum session lifetime SHOULD be set to TCP_EST. The state is moved to ESTABLISHED.
如果接收到RST数据包以外的数据包，则TCP会话表条目的生存期至少设置为最大会话生存期。最大会话生存期的值可以配置，但不得小于TCP_EST（在[RFC5382]中定义的已建立连接空闲超时）。最大会话生存期的默认值应设置为TCP_EST。该州被移至已建立的州。
If the lifetime expires, the Session Table Entry is deleted and the state is moved to CLOSED.
如果生存期到期，将删除会话表条目，并将状态移动到“关闭”。
When a new TCP BIB entry is created for a source transport address of (S',s), the NAT64 allocates an IPv4 transport address for this BIB entry as follows:
当为源传输地址（S'，S）创建新的TCP BIB条目时，NAT64为该BIB条目分配IPv4传输地址，如下所示：
If there exists some other BIB entry in any of the BIBs that contains S' as the IPv6 address and maps it to some IPv4 address T, then T SHOULD be used as the IPv4 address. Otherwise, use any IPv4 address of the IPv4 pool assigned to the NAT64 to be used for translation.
如果任何BIB中存在其他BIB条目，其中包含S'作为IPv6地址，并将其映射到某个IPv4地址T，则应将T用作IPv4地址。否则，请使用分配给NAT64的IPv4池的任何IPv4地址进行转换。
If the port s is in the Well-Known port range 0-1023, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port.
如果端口s在众所周知的端口范围0-1023内，并且NAT64在相同的端口范围内有一个可用的端口t，那么NAT64应该分配端口t。如果NAT64在同一范围内没有可用的端口，NAT64可以从另一个具有可用端口的范围分配端口t。
If the port s is in the range 1024-65535, and the NAT64 has an available port t in the same port range, then the NAT64 SHOULD allocate the port t. If the NAT64 does not have a port available in the same range, the NAT64 MAY assign a port t from another range where it has an available port.
如果端口s在1024-65535范围内，并且NAT64在同一端口范围内有一个可用端口t，则NAT64应分配端口t。如果NAT64在同一范围内没有可用的端口，NAT64可以从另一个具有可用端口的范围分配端口t。
In all cases, the allocated IPv4 transport address (T,t) MUST NOT be in use in another entry in the same BIB, but can be in use in other BIBs (e.g., the UDP and TCP BIBs).
在所有情况下，分配的IPv4传输地址（T，T）不得在同一BIB中的其他条目中使用，但可以在其他BIB（例如UDP和TCP BIB）中使用。
If it is not possible to allocate an appropriate IPv4 transport address or create a BIB entry, then the packet is discarded. The NAT64 SHOULD send an ICMPv6 Destination Unreachable error message with Code 3 (Address Unreachable).
如果无法分配适当的IPv4传输地址或创建BIB条目，则丢弃该数据包。NAT64应发送一条ICMPv6目标不可访问错误消息，代码为3（地址不可访问）。
The following state information is stored for an ICMP Query session in the ICMP Query session table:
ICMP查询会话表中存储了ICMP查询会话的以下状态信息：
Binding:(X',Y',i1) <--> (T,Z,i2)
Binding:(X',Y',i1) <--> (T,Z,i2)
Lifetime: a timer that tracks the remaining lifetime of the ICMP Query session. When the timer expires, the session is deleted. If all the ICMP Query sessions corresponding to a dynamically created ICMP Query BIB entry are deleted, then the ICMP Query BIB entry is also deleted.
生存期：跟踪ICMP查询会话剩余生存期的计时器。计时器过期时，会话将被删除。如果删除了与动态创建的ICMP查询BIB条目对应的所有ICMP查询会话，则ICMP查询BIB条目也将被删除。
An incoming ICMPv6 Informational packet with IPv6 source address X', IPv6 destination address Y', and ICMPv6 Identifier i1 is processed as follows:
具有IPv6源地址X’、IPv6目标地址Y’和ICMPv6标识符i1的传入ICMPv6信息包的处理如下：
If the local security policy determines that ICMPv6 Informational packets are to be filtered, the packet is silently discarded. Else, the NAT64 searches for an ICMP Query BIB entry that matches the (X',i1) pair. If such an entry does not exist, the NAT64 tries to create a new entry (if resources and policy permit) with the following data:
如果本地安全策略确定要过滤ICMPv6信息数据包，则该数据包将被自动丢弃。否则，NAT64将搜索与（X'，i1）对匹配的ICMP查询BIB条目。如果此类条目不存在，NAT64将尝试使用以下数据创建新条目（如果资源和策略允许）：
* The BIB IPv6 address is set to X' (i.e., the source IPv6 address of the IPv6 packet).
* BIB IPv6地址设置为X'（即IPv6数据包的源IPv6地址）。
* The BIB ICMPv6 Identifier is set to i1 (i.e., the ICMPv6 Identifier).
* BIB ICMPv6标识符设置为i1（即ICMPv6标识符）。
* If there exists another BIB entry in any of the BIBs that contains the same IPv6 address X' and maps it to an IPv4 address T, then use T as the BIB IPv4 address for this new entry. Otherwise, use any IPv4 address assigned to the IPv4 interface.
* 如果任何BIB中存在另一个包含相同IPv6地址X'并将其映射到IPv4地址T的BIB条目，则使用T作为此新条目的BIB IPv4地址。否则，请使用分配给IPv4接口的任何IPv4地址。
* Any available value is used as the BIB ICMPv4 Identifier, i.e., any identifier value for which no other entry exists with the same (IPv4 address, ICMPv4 Identifier) pair.
* 任何可用值都用作BIB ICMPv4标识符，即任何标识符值，对于该值，不存在具有相同（IPv4地址，ICMPv4标识符）对的其他条目。
The NAT64 searches for an ICMP Query Session Table Entry corresponding to the incoming 3-tuple (X',Y',i1). If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit). The information included in the new Session Table Entry is as follows:
NAT64搜索与传入的3元组（X'，Y'，i1）对应的ICMP查询会话表条目。如果没有找到这样的条目，NAT64将尝试创建一个新条目（如果资源和策略允许）。新会话表条目中包含的信息如下：
* The STE IPv6 source address is set to X' (i.e., the address contained in the received IPv6 packet).
* STE IPv6源地址设置为X'（即，接收到的IPv6数据包中包含的地址）。
* The STE IPv6 destination address is set to Y' (i.e., the address contained in the received IPv6 packet).
* STE IPv6目标地址设置为Y'（即，接收到的IPv6数据包中包含的地址）。
* The STE ICMPv6 Identifier is set to i1 (i.e., the identifier contained in the received IPv6 packet).
* STE ICMPv6标识符设置为i1（即，接收到的IPv6数据包中包含的标识符）。
* The STE IPv4 source address is set to the IPv4 address contained in the corresponding BIB entry.
* STE IPv4源地址设置为相应BIB条目中包含的IPv4地址。
* The STE ICMPv4 Identifier is set to the IPv4 identifier contained in the corresponding BIB entry.
* STE ICMPv4标识符设置为相应BIB条目中包含的IPv4标识符。
* The STE IPv4 destination address is algorithmically generated from Y' using the reverse algorithm as specified in Section 3.5.4.
* STE IPv4目标地址是使用第3.5.4节规定的反向算法从Y'生成的。
The NAT64 sets (or resets) the timer in the session table entry to the maximum session lifetime. By default, the maximum session lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be configurable. The packet is translated and forwarded as described in the following sections.
NAT64将会话表项中的计时器设置（或重置）为最大会话生存期。默认情况下，最大会话生存期为ICMP_default。最大生存期值应该是可配置的。数据包按照以下章节中的描述进行翻译和转发。
An incoming ICMPv4 Query packet with source IPv4 address Y, destination IPv4 address X, and ICMPv4 Identifier i2 is processed as follows:
具有源IPv4地址Y、目标IPv4地址X和ICMPv4标识符i2的传入ICMPv4查询数据包的处理如下：
The NAT64 searches for an ICMP Query BIB entry that contains X as the IPv4 address and i2 as the ICMPv4 Identifier. If such an entry does not exist, the packet is dropped. An ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3, Code 1 (Host Unreachable).
NAT64搜索ICMP查询BIB条目，该条目包含X作为IPv4地址和i2作为ICMPv4标识符。如果这样的条目不存在，则丢弃数据包。ICMP错误消息可发送至数据包的原始发送方。ICMP错误消息（如果发送）的类型为3，代码为1（无法访问主机）。
If the NAT64 filters on its IPv4 interface, then the NAT64 checks to see if the incoming packet is allowed according to the Address-Dependent Filtering rule. To do this, it searches for a Session Table Entry with an STE source IPv4 address equal to X, an STE ICMPv4 Identifier equal to i2, and a STE destination IPv4 address equal to Y. If such an entry is found (there may be more than one), packet processing continues. Otherwise, the packet is discarded. If the packet is discarded, then an ICMP error message MAY be sent to the original sender of the packet. The ICMP error message, if sent, has Type 3 (Destination Unreachable) and Code 13 (Communication Administratively Prohibited).
如果NAT64在其IPv4接口上进行过滤，则NAT64将根据地址相关过滤规则检查传入数据包是否被允许。为此，它搜索一个会话表条目，其中STE源IPv4地址等于X，STE ICMPv4标识符等于i2，STE目标IPv4地址等于Y。如果找到这样一个条目（可能有多个条目），数据包处理将继续。否则，数据包将被丢弃。如果数据包被丢弃，则可能会向数据包的原始发送者发送ICMP错误消息。ICMP错误消息（如果发送）的类型为3（无法到达目的地）和代码13（管理禁止通信）。
In case the packet is not discarded in the previous processing steps (either because the NAT64 is not filtering or because the packet is compliant with the Address-Dependent Filtering rule), then the NAT64 searches for a Session Table Entry with an STE source IPv4 address equal to X, an STE ICMPv4 Identifier equal to i2, and a STE destination IPv4 address equal to Y. If no such entry is found, the NAT64 tries to create a new entry (if resources and policy permit) with the following information:
如果在前面的处理步骤中未丢弃该数据包（因为NAT64未进行过滤，或者因为该数据包符合地址相关过滤规则），则NAT64将搜索STE源IPv4地址等于X、STE ICMPv4标识符等于i2的会话表条目，和等于Y的STE目标IPv4地址。如果未找到此类条目，NAT64将尝试使用以下信息创建新条目（如果资源和策略允许）：
* The STE source IPv4 address is set to X.
* STE源IPv4地址设置为X。
* The STE ICMPv4 Identifier is set to i2.
* STE ICMPv4标识符设置为i2。
* The STE destination IPv4 address is set to Y.
* STE目标IPv4地址设置为Y。
* The STE source IPv6 address is set to the IPv6 address of the corresponding BIB entry.
* STE源IPv6地址设置为相应BIB条目的IPv6地址。
* The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of the corresponding BIB entry.
* STE ICMPv6标识符设置为相应BIB条目的ICMPv6标识符。
* The STE destination IPv6 address is set to the IPv6 representation of the IPv4 address of Y, generated using the algorithm described in Section 3.5.4.
* STE目标IPv6地址设置为IPv4地址Y的IPv6表示形式，使用第3.5.4节中描述的算法生成。
* The NAT64 sets (or resets) the timer in the session table entry to the maximum session lifetime. By default, the maximum session lifetime is ICMP_DEFAULT. The maximum lifetime value SHOULD be configurable. The packet is translated and forwarded as described in the following sections.
* NAT64将会话表项中的计时器设置（或重置）为最大会话生存期。默认情况下，最大会话生存期为ICMP_default。最大生存期值应该是可配置的。数据包按照以下章节中的描述进行翻译和转发。
NAT64 supports multiple algorithms for the generation of the IPv6 representation of an IPv4 address and vice versa. The constraints imposed on the generation algorithms are the following:
NAT64支持多种算法来生成IPv4地址的IPv6表示形式，反之亦然。对生成算法施加的约束如下：
The algorithm MUST be reversible, i.e., it MUST be possible to derive the original IPv4 address from the IPv6 representation.
该算法必须是可逆的，即必须能够从IPv6表示中派生原始IPv4地址。
The input for the algorithm MUST be limited to the IPv4 address, the IPv6 prefix (denoted Pref64::/n) used in the IPv6 representations, and optionally a set of stable parameters that are configured in the NAT64 (such as a fixed string to be used as a suffix).
算法的输入必须限于IPv4地址、IPv6表示中使用的IPv6前缀（表示为Pref64:：/n）以及NAT64中配置的一组稳定参数（如用作后缀的固定字符串）。
If we note n the length of the prefix Pref64::/n, then n MUST be less than or equal to 96. If a Pref64::/n is configured through any means in the NAT64 (such as manually configured, or other automatic means not specified in this document), the default algorithm MUST use this prefix. If no prefix is available, the algorithm SHOULD use the Well-Known Prefix (64:ff9b::/96) defined in [RFC6052].
如果我们注意到前缀Pref64:：/n的长度，则n必须小于或等于96。如果通过NAT64中的任何方式（如手动配置或本文档中未指定的其他自动方式）配置Pref64:：/n，则默认算法必须使用此前缀。如果没有可用的前缀，则算法应使用[RFC6052]中定义的众所周知的前缀（64:ff9b:：/96）。
NAT64 MUST support the algorithm for generating IPv6 representations of IPv4 addresses defined in Section 2.3 of [RFC6052]. The aforementioned algorithm SHOULD be used as default algorithm.
NAT64必须支持生成[RFC6052]第2.3节中定义的IPv4地址的IPv6表示的算法。上述算法应作为默认算法使用。
This step computes the outgoing tuple by translating the IP addresses and port numbers or ICMP Identifier in the incoming tuple.
此步骤通过转换传入元组中的IP地址和端口号或ICMP标识符来计算传出元组。
In the text below, a reference to a BIB means the TCP BIB, the UDP BIB, or the ICMP Query BIB, as appropriate.
在下文中，对BIB的引用指TCP BIB、UDP BIB或ICMP查询BIB（视情况而定）。
NOTE: Not all addresses are translated using the BIB. BIB entries are used to translate IPv6 source transport addresses to IPv4 source transport addresses, and IPv4 destination transport addresses to IPv6 destination transport addresses. They are NOT used to translate IPv6 destination transport addresses to IPv4 destination transport addresses, nor to translate IPv4 source transport addresses to IPv6 source transport addresses. The latter cases are handled by applying the algorithmic transformation described in Section 3.5.4. This distinction is important; without it, hairpinning doesn't work correctly.
注：并非所有地址都使用BIB进行翻译。BIB条目用于将IPv6源传输地址转换为IPv4源传输地址，将IPv4目标传输地址转换为IPv6目标传输地址。它们不用于将IPv6目标传输地址转换为IPv4目标传输地址，也不用于将IPv4源传输地址转换为IPv6源传输地址。后一种情况通过应用第3.5.4节所述的算法转换进行处理。这种区别很重要；没有它，发夹就不能正常工作。
3.6.1. Computing the Outgoing 5-Tuple for TCP, UDP, and for ICMP Error Messages Containing a TCP or UDP Packets
3.6.1. 计算TCP、UDP和包含TCP或UDP数据包的ICMP错误消息的传出5元组
The transport protocol in the outgoing 5-tuple is always the same as that in the incoming 5-tuple. When translating from IPv4 ICMP to IPv6 ICMP, the protocol number in the last next header field in the protocol chain is set to 58 (IPv6-ICMP). When translating from IPv6 ICMP to IPv4 ICMP, the protocol number in the protocol field of the IP header is set to 1 (ICMP).
传出5元组中的传输协议始终与传入5元组中的传输协议相同。从IPv4 ICMP转换为IPv6 ICMP时，协议链中最后一个下一个标头字段中的协议号设置为58（IPv6 ICMP）。从IPv6 ICMP转换为IPv4 ICMP时，IP头的协议字段中的协议号设置为1（ICMP）。
When translating in the IPv6 --> IPv4 direction, let the source and destination transport addresses in the incoming 5-tuple be (S',s) and (D',d), respectively. The outgoing source transport address is computed as follows: if the BIB contains an entry (S',s) <--> (T,t), then the outgoing source transport address is (T,t).
在IPv6-->IPv4方向上进行转换时，让传入的5元组中的源传输地址和目标传输地址分别为（S'，S）和（D'，D）。传出源传输地址的计算如下：如果BIB包含一个条目（S'，S）<-->（T，T），则传出源传输地址为（T，T）。
The outgoing destination address is computed algorithmically from D' using the address transformation described in Section 3.5.4.
使用第3.5.4节中描述的地址转换，从D'算法计算出输出目的地地址。
When translating in the IPv4 --> IPv6 direction, let the source and destination transport addresses in the incoming 5-tuple be (S,s) and (D,d), respectively. The outgoing source transport address is computed as follows:
在IPv4-->IPv6方向上进行转换时，让传入的5元组中的源传输地址和目标传输地址分别为（S，S）和（D，D）。传出源传输地址的计算如下：
The outgoing source transport address is generated from S using the address transformation algorithm described in Section 3.5.4.
使用第3.5.4节中描述的地址转换算法从S生成传出源传输地址。
The BIB table is searched for an entry (X',x) <--> (D,d), and if one is found, the outgoing destination transport address is set to (X',x).
在BIB表中搜索条目（X'，X）<-->（D，D），如果找到条目，则输出目的地传输地址设置为（X'，X）。
3.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages and for ICMP Error Messages Containing an ICMP Query
3.6.2. 计算ICMP查询消息和包含ICMP查询的ICMP错误消息的传出3元组
When translating in the IPv6 --> IPv4 direction, let the source and destination addresses in the incoming 3-tuple be S' and D', respectively, and the ICMPv6 Identifier be i1. The outgoing source address is computed as follows: the BIB contains an entry (S',i1) <--> (T,i2), then the outgoing source address is T and the ICMPv4 Identifier is i2.
在IPv6-->IPv4方向上进行转换时，让传入的3元组中的源地址和目标地址分别为S'和D'，ICMPv6标识符为i1。传出源地址的计算如下：BIB包含一个条目（S'，i1）<-->（T，i2），则传出源地址为T，ICMPv4标识符为i2。
The outgoing IPv4 destination address is computed algorithmically from D' using the address transformation described in Section 3.5.4.
传出IPv4目标地址是使用第3.5.4节中描述的地址转换从D'算法计算的。
When translating in the IPv4 --> IPv6 direction, let the source and destination addresses in the incoming 3-tuple be S and D, respectively, and the ICMPv4 Identifier is i2. The outgoing source address is generated from S using the address transformation algorithm described in Section 3.5.4. The BIB is searched for an entry containing (X',i1) <--> (D,i2), and, if found, the outgoing destination address is X' and the outgoing ICMPv6 Identifier is i1.
在IPv4-->IPv6方向上进行转换时，让传入的3元组中的源地址和目标地址分别为S和D，ICMPv4标识符为i2。使用第3.5.4节中描述的地址转换算法从S生成传出源地址。在BIB中搜索包含（X'，i1）<-->（D，i2）的条目，如果找到，则输出目标地址为X'，输出ICMPv6标识符为i1。
This step translates the packet from IPv6 to IPv4 or vice versa.
此步骤将数据包从IPv6转换为IPv4，反之亦然。
The translation of the packet is as specified in Sections 4 and 5 of the IP/ICMP Translation Algorithm [RFC6145], with the following modifications:
数据包的翻译如IP/ICMP翻译算法[RFC6145]第4节和第5节所述，并进行以下修改：
o When translating an IP header (Sections 4.1 and 5.1 of [RFC6145]), the source and destination IP address fields are set to the source and destination IP addresses from the outgoing tuple as determined in Section 3.6.
o 翻译IP头（RFC6145第4.1节和第5.1节）时，源和目标IP地址字段设置为第3.6节确定的传出元组的源和目标IP地址。
o When the protocol following the IP header is TCP or UDP, then the source and destination ports are modified to the source and destination ports from the outgoing 5-tuple. In addition, the TCP or UDP checksum must also be updated to reflect the translated addresses and ports; note that the TCP and UDP checksum covers the pseudo-header that contains the source and destination IP addresses. An algorithm for efficiently updating these checksums is described in [RFC3022].
o 当IP头后面的协议是TCP或UDP时，源端口和目标端口将从传出的5元组修改为源端口和目标端口。此外，还必须更新TCP或UDP校验和，以反映转换后的地址和端口；请注意，TCP和UDP校验和包含源和目标IP地址的伪报头。[RFC3022]中描述了有效更新这些校验和的算法。
o When the protocol following the IP header is ICMP and it is an ICMP Query message, the ICMP Identifier is set to the one from the outgoing 3-tuple as determined in Section 3.6.2.
o 当IP头后面的协议为ICMP且为ICMP查询消息时，ICMP标识符设置为第3.6.2节中确定的传出3元组中的标识符。
o When the protocol following the IP header is ICMP and it is an ICMP error message, the source and destination transport addresses in the embedded packet are set to the destination and source transport addresses from the outgoing 5-tuple (note the swap of source and destination).
o 当IP头后面的协议是ICMP并且是ICMP错误消息时，嵌入数据包中的源和目标传输地址被设置为传出5元组中的目标和源传输地址（注意源和目标的交换）。
The size of outgoing packets as well and the potential need for fragmentation is done according to the behavior defined in the IP/ ICMP Translation Algorithm [RFC6145].
根据IP/ICMP转换算法[RFC6145]中定义的行为来确定传出数据包的大小以及可能的碎片需求。
If the destination IP address of the translated packet is an IPv4 address assigned to the NAT64 itself, then the packet is a hairpin packet. Hairpin packets are processed as follows:
如果转换数据包的目标IP地址是分配给NAT64本身的IPv4地址，则该数据包是发夹数据包。发卡包的处理如下：
o The outgoing 5-tuple becomes the incoming 5-tuple.
o 传出的5元组成为传入的5元组。
o The packet is treated as if it was received on the outgoing interface.
o 数据包被视为是在传出接口上接收到的。
o Processing of the packet continues at step 2 -- "Filtering and Updating Binding and Session Information" (Section 3.5).
o 数据包的处理在步骤2——“过滤和更新绑定和会话信息”（第3.5节）继续进行。
UDP_MIN: 2 minutes (as defined in [RFC4787])
UDP_MIN:2分钟（如[RFC4787]中所定义）
UDP_DEFAULT: 5 minutes (as defined in [RFC4787])
UDP_默认值：5分钟（如[RFC4787]中所定义）
TCP_TRANS: 4 minutes (as defined in [RFC5382])
TCP_传输：4分钟（定义见[RFC5382]）
TCP_EST: 2 hours (The minimum lifetime for an established TCP session defined in [RFC5382] is 2 hours and 4 minutes, which is achieved by adding the 2 hours with this timer and the 4 minutes with the TCP_TRANS timer.)
TCP_EST:2小时（在[RFC5382]中定义的已建立TCP会话的最短生存期为2小时4分钟，这是通过使用此计时器添加2小时和使用TCP_TRANS计时器添加4分钟来实现的。）
TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382])
TCP_传入_同步：6秒（如[RFC5382]中所定义）
FRAGMENT_MIN: 2 seconds
碎片最小值：2秒
ICMP_DEFAULT: 60 seconds (as defined in [RFC5508])
ICMP_默认值：60秒（定义见[RFC5508]）
Any protocols that protect IP header information are essentially incompatible with NAT64. This implies that end-to-end IPsec verification will fail when the Authentication Header (AH) is used (both transport and tunnel mode) and when ESP is used in transport mode. This is inherent in any network-layer translation mechanism. End-to-end IPsec protection can be restored, using UDP encapsulation as described in [RFC3948]. The actual extensions to support IPsec are out of the scope of this document.
任何保护IP头信息的协议本质上都与NAT64不兼容。这意味着在使用身份验证头（AH）（传输和隧道模式）以及在传输模式下使用ESP时，端到端IPsec验证将失败。这是任何网络层转换机制所固有的。可以使用[RFC3948]中所述的UDP封装恢复端到端IPsec保护。支持IPsec的实际扩展超出了本文档的范围。
NAT64 creates binding state using packets flowing from the IPv6 side to the IPv4 side. In accordance with the procedures defined in this document following the guidelines defined in [RFC4787], a NAT64 MUST offer "Endpoint-Independent Mapping". This means:
NAT64使用从IPv6端流向IPv4端的数据包创建绑定状态。根据本文件中定义的程序以及[RFC4787]中定义的指南，NAT64必须提供“端点独立映射”。这意味着：
For any IPv6 packet with source (S'1,s1) and destination (Pref64::D1,d1) that creates an external mapping to (S1,s1v4), (D1,d1), for any subsequent packet from (S'1,s1) to (Pref64::D2,d2) that creates an external mapping to (S2,s2v4), (D2,d2), within a given binding timer window,
对于源（S'1，s1）和目标（Pref64:：D1，D1）创建到（s1，s1v4）、（D1，D1）的外部映射的任何IPv6数据包，对于在给定绑定计时器窗口内从（S'1，s1）到（Pref64:：D2，D2）创建到（S2，s2v4）、（D2，D2）的外部映射的任何后续数据包，
(S1,s1v4) = (S2,s2v4) for all values of D2,d2
(S1,s1v4) = (S2,s2v4) for all values of D2,d2
Implementations MAY also provide support for "Address-Dependent Mapping" as also defined in this document and following the guidelines defined in [RFC4787].
实现还可以提供对“地址相关映射”的支持，如本文档中所定义，并遵循[RFC4787]中定义的指南。
The security properties, however, are determined by which packets the NAT64 filter allows in and which it does not. The security properties are determined by the filtering behavior and filtering configuration in the filtering portions of the NAT64, not by the address mapping behavior. For example:
但是，安全属性由NAT64筛选器允许和不允许的数据包决定。安全属性由NAT64的过滤部分中的过滤行为和过滤配置决定，而不是由地址映射行为决定。例如：
Without filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will traverse the NAT64 gateway and be forwarded
to the IPv6 transport address that created the binding. However,
Without filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will traverse the NAT64 gateway and be forwarded
to the IPv6 transport address that created the binding. However,
With filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will first be processed against the filtering
With filtering - When "Endpoint-Independent Mapping" is used in
NAT64, once a binding is created in the IPv6 ---> IPv4 direction,
packets from any node on the IPv4 side destined to the IPv6
transport address will first be processed against the filtering
rules. If the source IPv4 address is permitted, the packets will be forwarded to the IPv6 transport address. If the source IPv4 address is explicitly denied -- or the default policy is to deny all addresses not explicitly permitted -- then the packet will be discarded. A dynamic filter may be employed whereby the filter will only allow packets from the IPv4 address to which the original packet that created the binding was sent. This means that only the IPv4 addresses to which the IPv6 host has initiated connections will be able to reach the IPv6 transport address, and no others. This essentially narrows the effective operation of the NAT64 device to an "Address-Dependent Mapping" behavior, though not by its mapping behavior, but instead by its filtering behavior.
规则。如果允许使用源IPv4地址，则数据包将转发到IPv6传输地址。如果源IPv4地址被明确拒绝，或者默认策略是拒绝所有未明确允许的地址，则数据包将被丢弃。可以采用动态过滤器，其中过滤器将仅允许来自创建绑定的原始数据包被发送到的IPv4地址的数据包。这意味着只有IPv6主机已启动连接的IPv4地址才能到达IPv6传输地址，而其他地址则不能。这从本质上将NAT64设备的有效操作限制为“地址相关映射”行为，尽管不是通过其映射行为，而是通过其过滤行为。
As currently specified, the NAT64 only requires filtering traffic based on the 5-tuple. In some cases (e.g., statically configured mappings), this may make it easy for an attacker to guess. An attacker need not be able to guess other fields, e.g., the TCP sequence number, to get a packet through the NAT64. While such traffic might be dropped by the final destination, it does not provide additional mitigations against bandwidth/CPU attacks targeting the internal network. To avoid this type of abuse, a NAT64 MAY keep track of the sequence number of TCP packets in order to verify the proper sequencing of exchanged segments, in particular, those of the SYNs and the FINs.
按照目前的规定，NAT64只需要基于5元组过滤流量。在某些情况下（例如，静态配置的映射），这可能使攻击者很容易猜测。攻击者不必猜测其他字段，例如TCP序列号，就可以通过NAT64获取数据包。虽然最终目的地可能会丢弃此类流量，但它不能提供针对内部网络的带宽/CPU攻击的额外缓解措施。为了避免这种类型的滥用，NAT64可以跟踪TCP分组的序列号，以便验证交换段的正确顺序，特别是SYN和FIN的正确顺序。
The NAT64 device itself is a potential victim of different types of attacks. In particular, the NAT64 can be a victim of DoS attacks. The NAT64 device has a limited number of resources that can be consumed by attackers creating a DoS attack. The NAT64 has a limited number of IPv4 addresses that it uses to create the bindings. Even though the NAT64 performs address and port translation, it is possible for an attacker to consume all the IPv4 transport addresses by sending IPv6 packets with different source IPv6 transport addresses. This attack can only be launched from the IPv6 side, since IPv4 packets are not used to create binding state. DoS attacks can also affect other limited resources available in the NAT64 such as memory or link capacity. For instance, it is possible for an attacker to launch a DoS attack on the memory of the NAT64 device by sending fragments that the NAT64 will store for a given period. If the number of fragments is high enough, the memory of the NAT64 could be exhausted. Similarly, a DoS attack against the NAT64 can be crafted by sending either V4 or V6 SYN packets that consume memory in the form of session and/or binding table entries. In the case of IPv4 SYNs the situation is aggravated by the requirement to also store the data packets for a given amount of time, requiring more
NAT64设备本身是不同类型攻击的潜在受害者。尤其是NAT64可能是DoS攻击的受害者。NAT64设备的资源数量有限，可被创建DoS攻击的攻击者使用。NAT64用于创建绑定的IPv4地址数量有限。即使NAT64执行地址和端口转换，攻击者也可能通过发送具有不同源IPv6传输地址的IPv6数据包来使用所有IPv4传输地址。此攻击只能从IPv6端发起，因为IPv4数据包不用于创建绑定状态。DoS攻击还可能影响NAT64中可用的其他有限资源，如内存或链路容量。例如，攻击者可以通过发送NAT64将在给定时间段内存储的片段，对NAT64设备的内存发起DoS攻击。如果片段数量足够多，NAT64的内存可能会耗尽。类似地，针对NAT64的DoS攻击可以通过发送V4或V6 SYN数据包来实现，这些数据包以会话和/或绑定表条目的形式消耗内存。在IPv4 SYN的情况下，还需要在给定的时间段内存储数据包，这就加剧了这种情况，需要更多的时间
memory from the NAT64 device. NAT64 devices MUST implement proper protection against such attacks, for instance, allocating a limited amount of memory for fragmented packet storage as specified in Section 3.4.
来自NAT64设备的内存。NAT64设备必须针对此类攻击实施适当的保护，例如，按照第3.4节的规定，为碎片数据包存储分配有限的内存。
Another consideration related to NAT64 resource depletion refers to the preservation of binding state. Attackers may try to keep a binding state alive forever by sending periodic packets that refresh the state. In order to allow the NAT64 to defend against such attacks, the NAT64 MAY choose not to extend the session entry lifetime for a specific entry upon the reception of packets for that entry through the external interface. As described in the framework document [RFC6144], the NAT64 can be deployed in multiple scenarios, in some of which the Internet side is the IPv6 one, and in others of which the Internet side is the IPv4 one. It is then important to properly set which is the Internet side of the NAT64 in each specific configuration.
与NAT64资源消耗相关的另一个考虑因素是保留绑定状态。攻击者可能会通过发送定期刷新绑定状态的数据包，试图使绑定状态永远保持活动状态。为了允许NAT64防御此类攻击，NAT64可以选择在通过外部接口接收特定条目的分组时不延长该条目的会话条目生存期。如框架文档[RFC6144]中所述，NAT64可以部署在多个场景中，其中一些场景中的Internet端是IPv6，另一些场景中的Internet端是IPv4。然后，在每个特定配置中正确设置NAT64的Internet端非常重要。
If an IPv6-only client can guess the IPv4 binding address that will be created, it can use the IPv6 representation of that address as the source address for creating this binding. Then, any packet sent to the binding's IPv4 address could loop in the NAT64. This is prevented in the current specification by filtering incoming packets containing Pref64::/n in the source address, as described below.
如果仅限IPv6的客户端可以猜测将创建的IPv4绑定地址，则它可以使用该地址的IPv6表示形式作为创建此绑定的源地址。然后，发送到绑定IPv4地址的任何数据包都可以在NAT64中循环。在当前规范中，通过过滤源地址中包含Pref64:：/n的传入数据包来防止这种情况，如下所述。
Consider the following example:
考虑下面的例子：
Suppose that the IPv4 pool is 192.0.2.0/24
假设IPv4池为192.0.2.0/24
Then, the IPv6-only client sends this to NAT64:
然后，仅限IPv6的客户端将其发送到NAT64：
Source: [Pref64::192.0.2.1]:500
Source: [Pref64::192.0.2.1]:500
Destination: any
目的地：任何
The NAT64 allocates 192.0.2.1:500 as the IPv4 binding address. Now anything sent to 192.0.2.1:500, be it a hairpinned IPv6 packet or an IPv4 packet, could loop.
NAT64分配192.0.2.1:500作为IPv4绑定地址。现在，发送到192.0.2.1:500的任何内容，无论是发夹式IPv6数据包还是IPv4数据包，都可能循环。
It is not hard to guess the IPv4 address that will be allocated. First, the attacker creates a binding and uses (for example) Simple Traversal of the UDP Protocol through NAT (STUN) [RFC5389] to learn its external IPv4 address. New bindings will always have this address. Then, it uses a source port in the range 1-1023. This will increase the chances to 1/512 (since range and parity are preserved by NAT64 in UDP).
不难猜测将分配的IPv4地址。首先，攻击者创建绑定，并使用（例如）通过NAT（STUN）[RFC5389]简单遍历UDP协议来了解其外部IPv4地址。新绑定将始终具有此地址。然后，它使用范围为1-1023的源端口。这将使几率增加到1/512（因为UDP中NAT64保留了范围和奇偶校验）。
In order to address this vulnerability, the NAT64 MUST drop IPv6 packets whose source address is in Pref64::/n, as defined in Section 3.5.
为了解决此漏洞，NAT64必须丢弃其源地址位于Pref64:：/n中的IPv6数据包，如第3.5节所定义。
George Tsirtsis Qualcomm tsirtsis@googlemail.com
George Tsirtsis高通公司tsirtsis@googlemail.com
Greg Lebovitz Juniper gregory.ietf@gmail.com
格雷格·勒博维茨·杜松·格雷戈里。ietf@gmail.com
Simon Perreault Viagenie simon.perreault@viagenie.ca
西蒙·佩雷尔特·维亚根尼·西蒙。perreault@viagenie.ca
Dave Thaler, Dan Wing, Alberto Garcia-Martinez, Reinaldo Penno, Ranjana Rao, Lars Eggert, Senthil Sivakumar, Zhen Cao, Xiangsong Cui, Mohamed Boucadair, Dong Zhang, Bryan Ford, Kentaro Ebisawa, Charles Perkins, Magnus Westerlund, Ed Jankiewicz, David Harrington, Peter McCann, Julien Laganier, Pekka Savola, and Joao Damas reviewed the document and provided useful comments to improve it.
戴夫·泰勒、丹·荣、阿尔贝托·加西亚·马丁内斯、雷纳尔多·佩诺、兰贾娜·拉奥、拉尔斯·艾格特、森希尔·西瓦库马尔、曹真、崔湘松、穆罕默德·布卡达尔、张东、布莱恩·福特、肯塔罗·埃比萨瓦、查尔斯·帕金斯、马格纳斯·韦斯特隆德、埃德·詹基维茨、大卫·哈灵顿、彼得·麦肯、朱利安·拉加尼尔、佩卡·萨沃拉、，Joao Damas审查了该文件，并提供了有用的意见以改进该文件。
The content of the document was improved thanks to discussions with Christian Huitema, Fred Baker, and Jari Arkko.
由于与Christian Huitema、Fred Baker和Jari Arkko进行了讨论，该文件的内容得到了改进。
Marcelo Bagnulo and Iljitsch van Beijnum are partly funded by Trilogy, a research project supported by the European Commission under its Seventh Framework Program.
Marcelo Bagnulo和Iljitsch van Beijnum的部分资金来自Trilogy，该研究项目由欧盟委员会第七个框架计划支持。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[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月。
[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., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.translate error, please retry
[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月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 31281001年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月。
[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.
[RFC4963]Heffner，J.，Mathis，M.，和B.Chandler，“高数据速率下的IPv4重组错误”，RFC 4963，2007年7月。
[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月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年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月。
[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月。
Authors' Addresses
作者地址
Marcelo Bagnulo UC3M Av. Universidad 30 Leganes, Madrid 28911 Spain
马塞洛·巴格努洛UC3M Av。西班牙马德里勒加内斯30大学28911
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Phone: +34-91-6249500
EMail: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es/marcelo
Philip Matthews Alcatel-Lucent 600 March Road Ottawa, Ontario Canada
加拿大安大略省渥太华市3月路600号菲利普·马修斯阿尔卡特朗讯公司
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Phone: +1 613-592-4343 x224
EMail: philip_matthews@magma.ca
Iljitsch van Beijnum IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes, Madrid 28918 Spain
Iljitsch van Beijnum IMDEA Networks Avda。德尔马尔地中海，22勒加内斯，马德里28918西班牙
EMail: iljitsch@muada.com
EMail: iljitsch@muada.com