Network Working Group C. Aoun
Request for Comments: 4966 Energize Urnet
Obsoletes: 2766 E. Davies
Category: Informational Folly Consulting
July 2007
Network Working Group C. Aoun
Request for Comments: 4966 Energize Urnet
Obsoletes: 2766 E. Davies
Category: Informational Folly Consulting
July 2007
Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status.
本文档讨论由RFC 2766中定义的网络地址转换器-协议转换器（NAT-PT）实现的IPv6-IPv4协议转换机制的具体形式的问题。这些问题非常严重，建议将RFC 2766作为通用过渡机制已不再可取，本文件建议IETF将RFC 2766从拟议标准重新分类为历史状态。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7
2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 7
2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 8
2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8
2.4. Loss of Information through Incompatible Semantics . . . . 9
2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10
2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12
2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12
3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13
3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 13
3.2. Scalability and Single Point of Failure Concerns . . . . . 14
3.3. Issues with Lack of Address Persistence . . . . . . . . . 15
3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 16
4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16
4.1. Address Selection Issues when Communicating with
Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16
4.2. Non-Global Validity of Translated RR Records . . . . . . . 18
4.3. Inappropriate Translation of Responses to A Queries . . . 19
4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19
4.5. Limitations on Deployment of DNS Security Capabilities . . 19
5. Impact on IPv6 Application Development . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7
2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 7
2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 8
2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8
2.4. Loss of Information through Incompatible Semantics . . . . 9
2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10
2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12
2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12
3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13
3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 13
3.2. Scalability and Single Point of Failure Concerns . . . . . 14
3.3. Issues with Lack of Address Persistence . . . . . . . . . 15
3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 16
4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16
4.1. Address Selection Issues when Communicating with
Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16
4.2. Non-Global Validity of Translated RR Records . . . . . . . 18
4.3. Inappropriate Translation of Responses to A Queries . . . 19
4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19
4.5. Limitations on Deployment of DNS Security Capabilities . . 19
5. Impact on IPv6 Application Development . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
The Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] defines a set of network-layer translation mechanisms designed to allow nodes that only support IPv4 to communicate with nodes that only support IPv6, during the transition to the use of IPv6 in the Internet.
网络地址转换器-协议转换器（NAT-PT）文档[RFC2766]定义了一组网络层转换机制，旨在允许仅支持IPv4的节点在过渡到Internet中使用IPv6期间与仅支持IPv6的节点通信。
[RFC2766] specifies the basic NAT-PT, in which only addresses are translated, and the Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. In the following discussion, where the term "NAT-PT" is used unqualified, the discussion applies to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to the basic address-only translator.
[RFC2766]指定基本NAT-PT，其中仅转换地址，以及网络地址端口转换器-协议转换器（NAPT-PT），该转换器还转换传输标识符，从而更经济地利用稀缺的IPv4地址。协议转换使用[RFC2765]中定义的无状态IP/ICMP转换算法（SIIT）执行。在以下讨论中，如果使用术语“NAT-PT”，则讨论适用于基本NAT-PT和NAPT-PT。如果点适用于仅基本地址转换器，则将使用“基本NAT-PT”。
A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues carried over from traditional IPv4 NATs, and identify some additional issues that have not been discussed elsewhere. Proposed solutions to the issues are mentioned and any resulting need for changes to the specification is identified.
以前的许多文件都对NAT-PT提出了问题。本文档将总结这些问题，注意传统IPv4 NAT遗留的几个其他问题，并确定一些其他地方未讨论的其他问题。提出了问题的建议解决方案，并确定了规范变更的任何需求。
Whereas NAT is seen as an ongoing capability that is needed to work around the limited availability of globally unique IPv4 addresses, NAT-PT has a different status as a transition mechanism for IPv6. As such, NAT-PT should not be allowed to constrain the development of IPv6 applications or impose limitations on future developments of IPv6.
NAT被视为一种持续的能力，需要它来解决全球唯一IPv4地址的有限可用性问题，而NAT-PT作为IPv6的转换机制具有不同的地位。因此，不应允许NAT-PT限制IPv6应用程序的开发或限制IPv6的未来发展。
This document draws the conclusion that the technical and operational difficulties resulting from these issues, especially the possible future constraints on the development of IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks.
本文件得出的结论是，这些问题导致的技术和操作困难，特别是IPv6网络发展的未来可能限制（见第5节），使得推荐[RFC2766]中所述的NAT-PT是不可取的作为IPv6网络和IPv4网络之间互通的通用转换机制。
Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a revised, possibly restricted version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status to
尽管包转换的[RFC2766]形式通常不适用，但在某些情况下，仅支持IPv4的节点可能需要与仅支持IPv6的节点通信；这需要某种翻译机制。尽管这可以由应用程序级代理或传输层转换器更好地执行，但仍可能存在这样的场景，即NAT-PT的修订版（可能是受限版本）是合适的解决方案；因此，本文件建议IETF将RFC 2766从拟定标准重新分类为历史状态，以
avoid it from being used in inappropriate scenarios while any replacement is developed.
在开发任何替换时，避免在不适当的情况下使用它。
The following documents relating directly to NAT-PT have been reviewed while drafting this document:
在起草本文件时，审查了以下与NAT-PT直接相关的文件：
o Network Address Translation - Protocol Translation (NAT-PT) [RFC2766]
o 网络地址转换-协议转换（NAT-PT）[RFC2766]
o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
o 无状态IP/ICMP转换算法（SIIT）[RFC2765]
o NAT-PT Applicability Statement [NATP-APP]
o NAT-PT适用性声明[NATP-APP]
o Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766 [DNS-ALG-ISSUES]
o RFC 2766中NAT-PT DNS ALG（应用层网关）的问题[DNS-ALG-Issues]
o NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
o NAT-PT DNS ALG解决方案[DNS-ALG-SOL]
o NAT-PT Security Considerations [NATPT-SEC]
o NAT-PT安全注意事项[NATPT-SEC]
o Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
o 在IPv4和IPv6之间转换时出现的问题[转换问题]
o IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
o 第三代合作伙伴计划（3GPP）网络中基于SIP的服务的IPv6-IPv4转换机制[3GPP-TRANS]
o Analysis on IPv6 Transition in 3GPP Networks [RFC4215]
o 3GPP网络IPv6过渡分析[RFC4215]
o Considerations for Mobile IP Support in NAT-PT [NATPT-MOB]
o NAT-PT[NATPT-MOB]中移动IP支持的考虑因素
o An IPv6-IPv4 Multicast Translator based on Internet Group Management Protocol / Multicast Listener Discovery (IGMP/MLD) Proxying (mtp) [MTP]
o 基于Internet组管理协议/多播侦听器发现（IGMP/MLD）代理（mtp）[mtp]的IPv6-IPv4多播转换器
o An IPv4-IPv6 Multicast Gateway [MCASTGW]
o IPv4-IPv6多播网关[MCASTGW]
o Scalable mNAT-PT Solution [MUL-NATPT]
o 可扩展mNAT PT解决方案[MUL-NATPT]
Because the majority of the documents containing discussions of the issues are documents that are unlikely to become RFCs, the issues are summarized here to avoid the need for normative references.
由于包含问题讨论的大多数文件都是不太可能成为RFC的文件，因此此处对这些问题进行了总结，以避免需要规范性引用。
Some additional issues can be inferred from corresponding issues known to exist in 'traditional' IPv4 NATs. The following documents are relevant:
从“传统”IPv4 NAT中已知的相应问题可以推断出一些其他问题。以下文件是相关的：
o Protocol Complications with the IP Network Address Translator [RFC3027]
o IP网络地址转换器的协议复杂性[RFC3027]
o IP Network Address Translator (NAT) Terminology and Considerations [RFC2663]
o IP网络地址转换器（NAT）术语和注意事项[RFC2663]
There is some ambiguity in [RFC2766] about whether the Application Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document) is an integral and mandatory part of the specification. The ambiguity arises mainly from the first section of the applicability section (Section 8), which appears to imply that 'simple' use of NAT-PT could avoid the use of the DNS-ALG.
[RFC2766]中对DNS的应用层网关（ALG）（在本文档中称为DNS-ALG）是否是规范的一个组成部分和强制性部分存在一些歧义。歧义主要来自适用性部分（第8节）的第一节，这似乎意味着“简单”使用NAT-PT可以避免使用DNS-ALG。
This is important because a number of the major issues arise from the interactions between DNS and NAT-PT. However, detailed inspection of [RFC2766] shows that the 'simple' case has not been worked out and it is unclear how information about the address translation could be passed to the hosts in the absence of the DNS-ALG. Therefore, this document assumes that the DNS-ALG is an integral part of NAT-PT; accordingly, issues with the DNS-ALG must be considered as issues for the whole specification.
这一点很重要，因为DNS和NAT-PT之间的交互会产生许多主要问题。然而，对[RFC2766]的详细检查表明，“简单”情况尚未解决，并且不清楚在没有DNS-ALG的情况下如何将地址转换信息传递给主机。因此，本文件假设DNS-ALG是NAT-PT不可分割的一部分；因此，DNS-ALG的问题必须视为整个规范的问题。
Note that issues not specifically related to the use of the DNS-ALG will apply to any network-layer translation scheme, including any based on the SIIT algorithm [RFC2765]. In the event that new forms of a translator are developed as alternatives to NAT-PT, the generic issues relevant to all IPv6-IPv4 translators should be borne in mind.
请注意，与DNS-ALG的使用无关的问题将适用于任何网络层转换方案，包括任何基于SIIT算法的方案[RFC2765]。如果开发新形式的转换器作为NAT-PT的替代品，则应记住与所有IPv6-IPv4转换器相关的一般问题。
Issues raised with IPv6-IPv4 translators in general and NAT-PT in particular can be categorized as follows:
一般而言，IPv6-IPv4转换器和NAT-PT转换器出现的问题可分为以下几类：
o Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of an IPv6-IPv4 translator:
o 独立于DNS-ALG使用的问题，因此适用于任何形式的IPv6-IPv4转换器：
* Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports).
* 中断在数据包有效负载中嵌入IP地址（和/或端口）或使用IP地址（和端口）应用完整性机制的所有协议。
* Inability to redirect traffic for protocols that lack demultiplexing capabilities or are not built on top of specific transport-layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts.
* 在一个NAPT-PT正在为多个IPv6主机进行转换的情况下，无法重定向缺少解复用功能或未构建在特定传输层协议之上的协议的流量。
* Requirement for applications to use keepalive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout.
* 要求应用程序使用keepalive机制来解决NAT-PT状态过早超时导致的连接问题。
* Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols.
* 由于标头和协议的IPv4和IPv6版本之间的语义不兼容而导致信息丢失。
* Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation.
* 在处理数据包碎片的NAPT-PT转换器中需要额外的状态和/或数据包重建。
* Interaction with SCTP and multihoming.
* 与SCTP和多归宿的交互。
* Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility.
* 当IPv6节点是移动的时，NAT-PT需要充当对应节点的代理，从而限制了移动性。
* NAT-PT not being able to handle multicast traffic.
* NAT-PT无法处理多播流量。
o Issues that are exacerbated by the use of a DNS-ALG and are, therefore, also applicable to any form of an IPv6-IPv4 translator:
o 由于使用DNS-ALG而加剧的问题，因此也适用于任何形式的IPv6-IPv4转换器：
* Constraints on network topology.
* 网络拓扑的约束。
* Scalability concerns together with introduction of a single point of failure and a security attack nexus.
* 可扩展性问题，以及引入单点故障和安全攻击关系。
* Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it.
* 缺少地址映射持久性：某些应用程序需要会话之间的地址保留。如果使用不同的映射，用户通信将中断。使用DNS-ALG创建具有有限生存期的地址映射意味着应用程序必须在创建映射后不久开始使用该地址，并在开始使用该地址后保持其活动状态。
* Creation of a DoS (Denial of Service) threat relating to exhaustion of memory and address/port pool resources on the translator.
* 创建与转换器上内存和地址/端口池资源耗尽有关的DoS（拒绝服务）威胁。
o Issues that result from the use of a DNS-ALG and are, therefore, specific to NAT-PT as defined in [RFC2766]:
o 由于使用DNS-ALG而产生的问题，因此，这些问题特定于[RFC2766]中定义的NAT-PT：
* Address selection issues when either the internal or external hosts implement both IPv4 and IPv6.
* 内部或外部主机同时实现IPv4和IPv6时的地址选择问题。
* Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it.
* 翻译后DNS记录的有效性受限：翻译后的记录可能会转发给无法使用它的应用程序。
* Inappropriate translation of responses to A queries from IPv6 nodes.
* 对来自IPv6节点的查询的响应转换不正确。
* Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes.
* 具有多地址节点的DNS-ALG中的地址选择问题和资源消耗。
* Limitations on DNS security capabilities when using a DNS-ALG.
* 使用DNS-ALG时对DNS安全功能的限制。
Section 2, Section 3 and Section 4 discuss these groups of issues. Section 5 examines the consequences of deploying NAT-PT for application developers and the long term effects of NAT-PT (or any form of generally deployed IPv6-IPv4 translator) on the further development of IPv6.
第2节、第3节和第4节讨论这些问题。第5节研究了部署NAT-PT对应用程序开发人员的影响，以及NAT-PT（或任何形式的普遍部署的IPv6-IPv4转换器）对IPv6进一步发展的长期影响。
The terminology used in this document is defined in [RFC2663], [RFC2766], and [RFC3314].
本文件中使用的术语定义见[RFC2663]、[RFC2766]和[RFC3314]。
It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] and [RFC3027]) that the large class of protocols that embed numeric IP addresses in their payloads either cannot work through NATs or require specific ALGs as helpers to translate the payloads in line with the address and port translations. The same set of protocols cannot pass through NAT-PT. The problem is exacerbated because the IPv6 and IPv4 addresses are of different lengths, so that packet lengths as well as packet contents are altered. [RFC2766] describes the consequences as part of the description of the FTP ALG. Similar workarounds are needed for all protocols with embedded IP addresses that run over TCP transports.
在IPv4 NAT上的工作（参见[RFC2663]和[RFC3027]的第8节）众所周知，在有效负载中嵌入数字IP地址的大型协议要么无法通过NAT工作，要么需要特定的ALG作为助手根据地址和端口转换来转换有效负载。同一组协议不能通过NAT-PT。由于IPv6和IPv4地址具有不同的长度，因此数据包长度和数据包内容都会发生变化，这使得问题更加严重。[RFC2766]将后果描述为FTP ALG描述的一部分。对于通过TCP传输运行的具有嵌入式IP地址的所有协议，都需要类似的解决方法。
The issues raised in Sections 2 and 3 of [RFC2663], relating to the authentication and encryption with NAT, are also applicable to NAT-PT.
[RFC2663]第2节和第3节中提出的与NAT认证和加密相关的问题也适用于NAT-PT。
Implementing a suite of ALGs requires that NAT-PT equipment includes the logic for each of the relevant protocols. Most of these protocols are continuously evolving, requiring continual and coordinated updates of the ALGs to keep them in step.
实现一套ALG需要NAT-PT设备包含每个相关协议的逻辑。其中大多数协议都在不断发展，需要对ALG进行持续和协调的更新，以保持一致。
Assuming that the NAT-PT contains a colocated ALG for one of the relevant protocols, the ALG could replace the embedded IP addresses and ports. However, this replacement can only happen if no cryptographic integrity mechanism is used and the protocol messages are sent in the clear (i.e., not encrypted).
假设NAT-PT包含一个相关协议的共定位ALG，ALG可以替换嵌入式IP地址和端口。但是，只有在未使用加密完整性机制且协议消息以明文形式发送（即未加密）时，才能进行此替换。
A possible workaround relies on the NAT-PT being party to the security association used to provide authentication and/or encryption. NAT-PT would then be aware of the cryptographic
一种可能的解决方法依赖于NAT-PT是用于提供身份验证和/或加密的安全关联的一方。然后，NAT-PT会意识到密码错误
algorithms and keys used to secure the traffic. It could then modify and re-secure the packets; this would certainly complicate network operations and provide additional points of security vulnerability.
用于保护流量的算法和密钥。然后，它可以修改和重新保护数据包；这肯定会使网络操作复杂化，并提供额外的安全漏洞点。
Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (Authentication Header), in transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection.
除非UDP封装用于IPsec[RFC3498]，否则在传输和隧道模式下使用IPsec AH（身份验证标头）的通信量以及在传输模式下使用IPsec ESP（封装安全有效负载）的通信量无法通过NAT-PT进行，而必须终止NAT-PT上的安全关联，由于使用了密码完整性保护。
A related issue with DNS security is discussed in Section 4.5.
第4.5节讨论了与DNS安全性相关的问题。
Section 4.2 of [RFC3027] discusses problems specific to RSVP and NATs, one of which is actually a more generic problem for all port translators. When several end-hosts are using a single NAPT-PT box, protocols that do not have a demultiplexing capability similar to transport-layer port numbers may be unable to work through NAPT-PT (and any other port translator) because there is nothing for NAPT-PT to use to identify the correct binding.
[RFC3027]的第4.2节讨论了RSVP和NAT特有的问题，其中一个问题实际上是所有端口转换器的更一般的问题。当多个终端主机使用单个NAPT-PT盒时，没有类似于传输层端口号的解复用功能的协议可能无法通过NAPT-PT（和任何其他端口转换器）工作，因为NAPT-PT无法使用任何东西来识别正确的绑定。
This type of issue affects IPsec encrypted packets where the transport port is not visible (although it might be possible to use the Security Parameter Index (SPI) as an alternative demultiplexer), and protocols, such as RSVP, which are carried directly in IP datagrams rather than using a standard transport-layer protocol such as TCP or UDP. In the case of RSVP, packets going from the IPv4 domain to the IPv6 domain do not necessarily carry a suitable demultiplexing field, because the port fields in the flow identifier and traffic specifications are optional.
这种类型的问题会影响传输端口不可见的IPsec加密数据包（尽管可以使用安全参数索引（SPI）作为替代解复用器）和协议，如RSVP，它们直接在IP数据报中传输，而不是使用标准传输层协议，如TCP或UDP。在RSVP的情况下，从IPv4域到IPv6域的数据包不一定携带合适的解复用字段，因为流标识符和流量规范中的端口字段是可选的。
Several ad hoc workarounds could be used to solve the demultiplexing issues, however in most cases these solutions are not documented anywhere, which could lead to non-deterministic and undesirable behavior (for example, such workarounds often assume particular network topologies, etc., in order to function correctly; if the assumptions are not met in a deployment, the workaround may not work as expected).
可以使用几个临时解决方案来解决解复用问题，但是在大多数情况下，这些解决方案没有记录在任何地方，这可能会导致不确定性和不良行为（例如，此类变通方法通常采用特定的网络拓扑等，以便正确运行；如果部署中未满足这些假设，则变通方法可能无法按预期工作）。
This issue is closely related to the fragmentation issue described in Section 2.5.
该问题与第2.5节中描述的碎片问题密切相关。
NAT-PT will generally use dynamically created bindings to reduce the need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both
NAT-PT通常使用动态创建的绑定来减少基本NAT-PT和NAPT-PT对IPv4地址的需求。二者都
basic NAT-PT and NAPT-PT use soft state mechanisms to manage the address and, in the case of NAPT-PT, port pools are used for dynamically created address bindings. This allows all types of NAT-PT boxes to operate autonomously without requiring clients to signal, either implicitly or explicitly, that a binding is no longer required. In any case, without soft state timeouts, network and application unreliability would inevitably lead to leaks, eventually causing address or port pool exhaustion.
基本NAT-PT和NAPT-PT使用软状态机制来管理地址，对于NAPT-PT，端口池用于动态创建的地址绑定。这允许所有类型的NAT-PT盒自动运行，而无需客户端隐式或显式地发出不再需要绑定的信号。在任何情况下，如果没有软状态超时，网络和应用程序的不可靠性将不可避免地导致泄漏，最终导致地址或端口池耗尽。
For a dynamic binding to persist for longer than the soft state timeout, packets must be sent periodically from one side of the NAT-PT to the other (the direction is not specified by the NAT-PT specification). If no packets are sent in the proper direction, the NAT-PT binding will not be refreshed and the application connection will be broken. Hence, all applications need to maintain their NAT-PT bindings during long idle periods by incorporating a keepalive mechanism, which may not be possible for legacy systems.
要使动态绑定持续时间长于软状态超时，必须定期将数据包从NAT-PT的一侧发送到另一侧（NAT-PT规范未指定方向）。如果没有向正确的方向发送数据包，NAT-PT绑定将不会刷新，应用程序连接将中断。因此，所有应用程序都需要通过合并keepalive机制在长时间空闲期间维护其NAT-PT绑定，这对于遗留系统来说可能是不可能的。
Also, [RFC2766] does not specify how to choose timeouts for bindings. As discussed in [RFC2663] for traditional NATs, selecting suitable values is a matter of heuristics, and coordinating with application expectations may be impossible.
而且，[RFC2766]没有指定如何为绑定选择超时。正如[RFC2663]中针对传统NAT所讨论的，选择合适的值是一个启发式问题，与应用程序期望相协调可能是不可能的。
NAT-PT reuses the SIIT header and protocol translations defined in [RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions can lead to loss of information when packets are translated. Three issues arising from this are:
NAT-PT重用[RFC2765]中定义的SIIT头和协议转换。IPv4和IPv6版本之间的语义不匹配可能导致数据包转换时信息丢失。由此产生的三个问题是：
o There is no equivalent in IPv4 for the flow label field of the IPv6 header. Hence, any special treatment of packets based on flow label patterns cannot be propagated into the IPv4 domain.
o 在IPv4中，IPv6标头的流标签字段没有等效项。因此，任何基于流标签模式的数据包特殊处理都不能传播到IPv4域。
o IPv6 extension headers provide flexibility for future improvements in the IP protocol suite and new headers that do not have equivalents in IPv4 may be defined. In practice, some existing extensions such as routing headers and mobility extensions are not translatable.
o IPv6扩展头为IP协议套件的未来改进提供了灵活性，并且可以定义在IPv4中没有等价物的新头。在实践中，一些现有的扩展（如路由头和移动性扩展）是不可翻译的。
o As described in Section 2.2 of [NATP-APP], there are no equivalents in IPv6 for some ICMP(v4) messages, while for others (notably the 'Parameter Problem' messages) the semantics are not equivalent. Translation of such messages may lead to the loss of information. However, this issue may not be very severe because the error messages relate to packets that have been translated by NAT-PT rather than by arbitrary packets. If the NAT-PT is
o 如[NATP-APP]第2.2节所述，IPv6中的某些ICMP（v4）消息没有等价物，而其他消息（尤其是“参数问题”消息）的语义不等价。翻译此类信息可能会导致信息丢失。然而，这个问题可能不是很严重，因为错误消息与NAT-PT转换的数据包有关，而不是与任意数据包有关。如果NAT-PT是
functioning correctly, there is, for example, no reason why IPv6 packets with unusual extension headers or options should be generated.
例如，如果功能正常，就没有理由生成具有异常扩展头或选项的IPv6数据包。
Loss of information in any of these cases could be a constraint to certain applications.
在这些情况下，信息丢失可能会对某些应用程序造成限制。
A related matter concerns the propagation of the Differentiated Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP field when translating packets. Accordingly, the IPv4 and IPv6 domains must have equivalent Per-Hop Behaviors for the same code point, or alternative means must be in place to translate the DSCP between domains.
一个相关事项涉及区分服务代码点（DSCP）的传播。翻译数据包时，NAT-PT和SIIT只需复制DSCP字段。因此，IPv4和IPv6域对于相同的代码点必须具有等效的每跳行为，或者必须采用替代方法在域之间转换DSCP。
As mentioned in [RFC3027], simple port translators are unable to translate packet fragments, other than the first, from a fragmented packet, because subsequent fragments do not contain the port number information.
如[RFC3027]中所述，简单端口转换器无法从碎片数据包中翻译除第一个以外的数据包片段，因为后续片段不包含端口号信息。
This means that, in general, fragmentation cannot be allowed for any traffic that traverses a NAPT-PT. One attempted workaround requires the NAPT-PT to maintain state information derived from the first fragment until all fragments of the packet have transited the NAPT-PT. This is not a complete solution because fragment misordering could lead to the first fragment appearing at the NAPT-PT after later fragments. Consequently, the NAPT-PT would not have the information needed to translate the fragments received before the first.
这意味着，通常情况下，任何通过NAPT-PT的流量都不允许出现碎片。一种尝试性的解决方法要求NAPT-PT维护从第一个片段派生的状态信息，直到数据包的所有片段都传输了NAPT-PT。这不是一个完整的解决方案，因为片段顺序错误可能会导致第一个片段出现在NAPT-PT上，然后出现在后面的片段上。因此，NAPT-PT将不具备翻译第一次测试之前收到的片段所需的信息。
Although it would not be expected in normal operation, NAPT-PT needs to be proofed against receiving short first fragments that don't contain the transport port numbers. Note that such packets are a problem for many forms of stateful packet inspection applied to IPv6 packets. The current specifications of IPv6 do not mandate (1) any minimum packet size beyond the need to carry the unfragmentable part (which doesn't include the transport port numbers) or (2) reassembly rules to minimize the effects of overlapping fragments. Thus, IPv6 is open to the sort of attacks described in [RFC1858] and [RFC3128].
虽然在正常操作中不会出现这种情况，但需要对NAPT-PT进行验证，以防收到不包含传输端口号的短首个片段。请注意，对于应用于IPv6数据包的许多形式的有状态数据包检查来说，这样的数据包都是一个问题。当前的IPv6规范没有强制要求（1）任何最小数据包大小超过携带不可分割部分的需要（不包括传输端口号）或（2）重新组装规则以最小化重叠片段的影响。因此，IPv6容易受到[RFC1858]和[RFC3128]中所述的攻击。
An additional concern arises when a fragmented IPv4 UDP packet, which does not have a transport-layer checksum, traverses any type of NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct the whole packet so that it can calculate the checksum needed for the translated IPv6 packet. This can result in a significant delay to the packet, especially if it has to be re-fragmented before transmission on the IPv6 side.
当不具有传输层校验和的分段IPv4 UDP数据包穿越任何类型的NAT-PT盒时，会出现另一个问题。如[RFC2766]所述，NAT-PT必须重构整个数据包，以便能够计算转换后的IPv6数据包所需的校验和。这可能会导致数据包严重延迟，尤其是在IPv6端传输之前必须对其进行重新分段的情况下。
If NAT-PT boxes reassembled all incoming fragmented packets (both from the IPv4 and IPv6 directions) in the same way they have to for unchecksummed IPv4 UDP packets, this would be a solution to the first problem. The resource cost would be considerable apart from the potential delay problem if the outgoing packet has to be re-fragmented. In any case, fragmentation would mean that the NAT-PT would consume extra memory and CPU resources, making the NAT-PT even less scalable (see Section 3.2).
如果NAT-PT盒将所有传入的碎片数据包（来自IPv4和IPv6方向）以与未选中的IPv4 UDP数据包相同的方式重新组装，这将是第一个问题的解决方案。如果传出数据包必须重新分段，那么除了潜在的延迟问题外，资源成本将相当可观。在任何情况下，碎片将意味着NAT-PT将消耗额外的内存和CPU资源，使NAT-PT的可伸缩性更低（参见第3.2节）。
Packet reassembly in a NAT-PT box also opens up the possibility of various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. Of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment, which would potentially overload the reconstruction buffers and consume large amounts of CPU resources.
NAT-PT盒中的数据包重组还可能引发各种碎片相关的安全攻击。其中一些类似于针对IPv4的攻击。特别值得关注的是，基于发送大量小片段而不终止最后一个片段的DoS攻击，这可能会使重建缓冲区过载并消耗大量CPU资源。
The Stream Control Transmission Protocol (SCTP) [RFC2960] is a transport protocol, which has been standardized since SIIT was specified. SIIT does not explicitly cover the translation of SCTP, but SCTP uses transport port numbers in the same way that UDP and TCP do, so similar techniques can be used when translating SCTP packets.
流控制传输协议（SCTP）[RFC2960]是一种传输协议，自指定SIIT以来，该协议已经标准化。SIIT没有明确涵盖SCTP的翻译，但SCTP使用传输端口号的方式与UDP和TCP相同，因此在翻译SCTP数据包时可以使用类似的技术。
However, SCTP also supports multihoming. During connection setup, SCTP control packets carry embedded addresses that would have to be translated. This would also require that the types of the options fields in the SCTP control packets be changed with consequent changes to packet length; the transport checksum would also have to be recalculated. The ramifications of multihoming as it might interact with NAT-PT have not been fully explored. Because of the 'chunked' nature of data transfer, it does not appear that that state would have to be maintained to relate packets transmitted using the different IP addresses associated with the connection.
但是，SCTP也支持多主定位。在连接设置期间，SCTP控制数据包携带必须转换的嵌入式地址。这还将要求SCTP控制分组中的选项字段的类型随着分组长度的随之改变而改变；传输校验和也必须重新计算。多归宿可能与NAT-PT相互作用的后果尚未得到充分探讨。由于数据传输的“分块”性质，似乎不需要保持该状态来关联使用与连接关联的不同IP地址传输的数据包。
Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' have not been fully explored, but one issue that will arise is described in Section 4.4. SCTP will need an associated "ALG" -- actually a Transport Layer Gateway -- to handle the packet payload modifications. If it turns out that that state is required, the state would have to be distributed and synchronized across several NAT-PT boxes in a multihomed environment.
即使可以克服这些技术问题，如果所有连接都通过相同的NAT-PT运行，那么在NAT-PT环境中使用SCTP可能会有效地抵消SCTP的多宿优势。使用与每个“家庭”相关的单独NAT-PT盒运行多家庭网络的后果尚未得到充分探讨，但将出现的一个问题在第4.4节中描述。SCTP需要一个关联的“ALG”——实际上是一个传输层网关——来处理数据包有效负载修改。如果结果表明该状态是必需的，则必须在多宿环境中跨多个NAT-PT盒分发和同步该状态。
SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1.
如第2.1节所述，在多宿环境中通过NAT-PT运行的SCTP也与IPsec不兼容。
As discussed in [NATPT-MOB], it is not possible to propagate Mobile IPv6 (MIPv6) control messages into the IPv4 domain. According to the IPv6 Node Requirements [RFC4294], IPv6 nodes should normally be prepared to support the route optimization mechanisms needed in a correspondent node. If communications from an IPv6 mobile node are traversing a NAT-PT, the destination IPv4 node will certainly not be able to support the correspondent node features needed for route optimization.
如[NATPT-MOB]中所述，无法将移动IPv6（MIPv6）控制消息传播到IPv4域。根据IPv6节点要求[RFC4294]，IPv6节点通常应准备好支持对应节点所需的路由优化机制。如果来自IPv6移动节点的通信正在穿越NAT-PT，则目标IPv4节点肯定无法支持路由优化所需的对应节点功能。
This can be resolved in two ways:
这可以通过两种方式解决：
o The NAT-PT can discard messages and headers relating to changes of care-of addresses, including reverse routing checks. Communications with the mobile node will continue through the home agent without route optimization. This is clearly sub-optimal, but communication should remain possible.
o NAT-PT可以丢弃与转交地址更改相关的消息和头，包括反向路由检查。与移动节点的通信将通过归属代理继续进行，而无需进行路由优化。这显然是次优的，但沟通仍有可能。
o Additional functionality could be implemented in the NAT-PT to allow it to function as a proxy correspondent node for all IPv4 nodes for which it has bindings. This scheme adds considerably to the complexity of NAT-PT. Depending on the routability of the IPv6 PREFIX used for translated IPv4 addresses, it may also limit the extent of mobility of the mobile node: all communications to the IPv4 destination have to go through the same NAT-PT, even if the mobile node moves to a network that does not have direct IPv6 connectivity with the NAT-PT.
o 可以在NAT-PT中实现其他功能，使其能够作为其绑定的所有IPv4节点的代理对应节点。该方案大大增加了NAT-PT的复杂性。根据用于转换IPv4地址的IPv6前缀的可路由性，它还可能限制移动节点的移动范围：到IPv4目的地的所有通信都必须通过相同的NAT-PT，即使移动节点移动到与NAT-PT没有直接IPv6连接的网络。
In both cases, the existing NAT-PT specification would need to be extended to deal with IPv6 mobile nodes, and neither is a fully satisfactory solution.
在这两种情况下，现有的NAT-PT规范都需要扩展以处理IPv6移动节点，这两种方案都不是完全令人满意的解决方案。
SIIT [RFC2765] cannot handle the translation of multicast packets and NAT-PT does not discuss a way to map multicast addresses between IPv4 and IPv6. Some separate work has been done to provide an alternative mechanism to handle multicast. This work uses a separate gateway that understands some or all of the relevant multicast control and routing protocols in each domain. It has not yet been carried through into standards.
SIIT[RFC2765]无法处理多播数据包的转换，NAT-PT没有讨论在IPv4和IPv6之间映射多播地址的方法。为了提供一种处理多播的替代机制，已经做了一些单独的工作。这项工作使用了一个独立的网关，它了解每个域中一些或所有相关的多播控制和路由协议。它还没有被纳入标准。
A basic mechanism, which involves only IGMP on the IPv4 side and MLD on the IPv6 side, is described in 'An IPv6-IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)' [MTP]. A more comprehensive approach, which includes proxying of the multicast routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' [MCASTGW]. Both approaches have several of the issues described in this section, notably issues with embedded addresses.
“基于IGMP/MLD代理（mtp）”的IPv6-IPv4多播转换器[mtp]中描述了一种基本机制，该机制只涉及IPv4端的IGMP和IPv6端的MLD。“IPv4-IPv6多播网关”[MCASTGW]中描述了一种更全面的方法，其中包括多播路由协议的代理。这两种方法都有本节中描述的几个问题，特别是嵌入地址的问题。
[NATPT-SEC] identifies the possibility of a multiplicative reflection attack if the NAT-PT can be spoofed into creating a binding for a multicast address. This attack would be very hard to mount because routers should not forward packets with multicast addresses in the source address field. However, it highlights the possibility that a naively implemented DNS-ALG could create such bindings from spoofed DNS responses since [RFC2766] does not mention the need for checks on the types of addresses in these responses.
[NATPT-SEC]确定如果NAT-PT被欺骗为多播地址创建绑定，则可能发生乘法反射攻击。由于路由器不应转发源地址字段中包含多播地址的数据包，因此很难装载此攻击。然而，它强调了一种可能性，即一个简单实现的DNS-ALG可以从伪造的DNS响应创建这样的绑定，因为[RFC2766]没有提到需要检查这些响应中的地址类型。
The issues for NAT-PT and multicast reflect the fact that NAT-PT is at best a partial solution. Completing the translation solution to cater for multicast traffic is likely to carry a similar set of issues to the current unicast NAT-PT and may open up significant additional security risks.
NAT-PT和多播的问题反映了这样一个事实，即NAT-PT充其量只是部分解决方案。完成翻译解决方案以满足多播流量可能会带来与当前单播NAT-PT类似的一系列问题，并可能带来显著的额外安全风险。
Traffic flow initiators in a NAT-PT environment are dependent on the DNS-ALG in the NAT-PT to provide the mapped address needed to communicate with the flow destination on the other side of the NAT-PT. Whether used for flows initiated in the IPv4 domain or the IPv6 domain, the NAT-PT has to be on the path taken by the DNS query sent by the flow initiator to the relevant DNS server; otherwise, the DNS query will not be modified and the response type will not be appropriate.
NAT-PT环境中的业务流启动器依赖于NAT-PT中的DNS-ALG，以提供与NAT-PT另一侧的流目的地通信所需的映射地址。无论是用于IPv4域还是IPv6域中启动的流，NAT-PT必须位于流启动器发送到相关DNS服务器的DNS查询所采用的路径上；否则，将不会修改DNS查询，并且响应类型将不合适。
The implication is that the NAT-PT box also has to be the default IPv6 router for the site so that the DNS-ALG is able to examine all DNS requests made over IPv6. On sites with both IPv6 and dual-stack nodes, this will result in all traffic flowing through the NAT-PT with consequent scalability concerns.
这意味着NAT-PT框还必须是站点的默认IPv6路由器，以便DNS-ALG能够检查通过IPv6发出的所有DNS请求。在同时具有IPv6和双栈节点的站点上，这将导致所有流量都流经NAT-PT，从而导致可伸缩性问题。
These constraints are described in more detail in [DNS-ALG-ISSUES].
这些约束在[DNS-ALG-ISSUES]中有更详细的描述。
[DNS-ALG-SOL] proposes a solution for flows initiated from the IPv6 domain, but it appears that this solution still has issues.
[DNS-ALG-SOL]为从IPv6域启动的流提出了一个解决方案，但该解决方案似乎仍然存在问题。
For IPv6-only clients, the solution requires the use of a DNS server in the IPv4 domain, accessed via an IPv6 address which uses the NAT-PT PREFIX (see [RFC2766]). Queries to this server would necessarily pass through the NAT-PT. Dual-stack hosts would use a separate DNS server accessed through a normal IPv6 address. This removes the need for the NAT-PT box to be the default IPv6 gateway for the domain.
对于仅限IPv6的客户端，解决方案需要在IPv4域中使用DNS服务器，通过使用NAT-PT前缀的IPv6地址访问（请参见[RFC2766]）。对此服务器的查询必须通过NAT-PT。双栈主机将使用通过正常IPv6地址访问的单独DNS服务器。这样就不需要NAT-PT框作为域的默认IPv6网关。
The primary proposal suggests that the IPv6-only clients should use this DNS server for all queries. This is expensive on NAT-PT resources because requests relating to hosts with native IPv6 addresses would also use the NAT-PT DNS-ALG.
主要建议是，仅限IPv6的客户端应将此DNS服务器用于所有查询。这在NAT-PT资源上非常昂贵，因为与具有本机IPv6地址的主机相关的请求也将使用NAT-PT DNS-ALG。
The alternate suggestion to reduce this burden appears to be flawed: if IPv6-only clients are provided with a list of DNS servers including both the server accessed via NAT-PT and server(s) accessed natively via IPv6, the proposal suggests that the client could avoid using NAT-PT for hosts that have native IPv6 addresses.
减轻这一负担的替代建议似乎存在缺陷：如果仅IPv6客户端提供了DNS服务器列表，包括通过NAT-PT访问的服务器和通过IPv6本机访问的服务器，则该建议建议客户端可以避免对具有本机IPv6地址的主机使用NAT-PT。
Unfortunately, for the alternate suggestion, there is no a priori way in which the initiator can decide which DNS server to use for a particular query. In the event that the initiator makes the wrong choice, the DNS query will return an empty list rather than failing to respond. With standard DNS logic, the initiator will not try alternative DNS servers because it has received a response. This means that the solution would consist of always using DNS servers having the NAT-PT PREFIX. This imposes the burden of always requiring the DNS RR (Resource Record) [RFC1035] translation.
不幸的是，对于另一种建议，没有一种先验的方式，发起者可以决定将哪个DNS服务器用于特定的查询。如果启动器做出错误的选择，DNS查询将返回一个空列表，而不是无法响应。使用标准DNS逻辑，启动器将不会尝试其他DNS服务器，因为它已收到响应。这意味着解决方案将包括始终使用具有NAT-PT前缀的DNS服务器。这就增加了总是需要DNS RR（资源记录）[RFC1035]转换的负担。
For flows initiated from the IPv4 network, the proposal recommends that the advertised DNS servers for the IPv6 network would have the IPv4 address of the NAT-PT. Again there is no deterministic way to choose the correct DNS server for each query resulting in the same issues as were raised for flows initiated from the IPv6 domain.
对于从IPv4网络发起的流，提案建议IPv6网络的公布DNS服务器将具有NAT-PT的IPv4地址。同样，没有确定的方法为每个查询选择正确的DNS服务器，从而导致与从IPv6域启动的流相同的问题。
Although the engineering workaround, just described, provides a partial solution to the topology constraints issue, it mandates that DNS queries and responses should still go through a NAT-PT even if there would normally be no reason to do so. This mandatory passage through the NAT-PT for all DNS requests will exacerbate the other DNS-related issues discussed in Section 3.4 and Section 4.1.
尽管刚才描述的工程解决方案为拓扑约束问题提供了部分解决方案，但它要求DNS查询和响应仍应通过NAT-PT，即使通常没有理由这样做。所有DNS请求都必须通过NAT-PT，这将加剧第3.4节和第4.1节中讨论的其他DNS相关问题。
As with traditional NAT, NAT-PT is a bottleneck in the network with significant scalability concerns. Furthermore, the anchoring of flows to a particular NAT-PT makes the NAT-PT a potential single
与传统的NAT一样，NAT-PT是网络中的一个瓶颈，具有显著的可扩展性问题。此外，将流锚定到特定的NAT-PT使NAT-PT成为单一电位
point of failure in the network. The addition of the DNS-ALG in NAT-PT further increases the scalability concerns.
网络中的故障点。在NAT-PT中添加DNS-ALG进一步增加了可伸缩性问题。
Solutions to both problems have been envisaged using collections of cooperating NAT-PT boxes, but such solutions require coordination and state synchronization, which has not yet been standardized and again adds to the functional and operational complexity of NAT-PT. One such solution is described in [MUL-NATPT].
这两个问题的解决方案都设想使用合作的NAT-PT箱集合，但这类解决方案需要协调和状态同步，这尚未标准化，再次增加了NAT-PT的功能和操作复杂性。[MUL-NATPT]中描述了一种此类解决方案。
As with traditional NAT, the concentration of flows through NAT-PT and the legitimate modification of packets in the NAT-PT make NAT-PTs enticing targets for security attacks.
与传统的NAT一样，通过NAT-PT的流量集中以及NAT-PT中数据包的合法修改使得NAT-PT成为安全攻击的诱因。
Using the DNS-ALG to create address bindings requires that the translated address returned by the DNS query is used for communications before the NAT-PT binding state is timed out (see Section 2.3). Applications will not normally be aware of this constraint, which may be different from the existing lifetime of DNS query responses. This could lead to "difficult to diagnose" problems with applications.
使用DNS-ALG创建地址绑定需要在NAT-PT绑定状态超时之前，将DNS查询返回的转换地址用于通信（请参阅第2.3节）。应用程序通常不会意识到此约束，这可能与DNS查询响应的现有生存期不同。这可能导致应用程序出现“难以诊断”的问题。
Additionally, the DNS-ALG needs to determine the initial lifetime of bindings that it creates. As noted in Section 2.3, this may need to be determined heuristically. The DNS-ALG does not know which protocol the mapping is to be used for, and so needs another way to determine the initial lifetime. This could be tied to the DNS response lifetime, but that might open up additional DoS attack possibilities if very long binding lifetimes are allowed. Also, the lifetime should be adjusted once the NAT-PT determines which protocol is being used with the binding.
此外，DNS-ALG需要确定其创建的绑定的初始生存期。如第2.3节所述，这可能需要试探性地确定。DNS-ALG不知道映射将用于哪个协议，因此需要另一种方法来确定初始生存期。这可能与DNS响应生存期有关，但如果允许很长的绑定生存期，则可能会增加DoS攻击的可能性。此外，一旦NAT-PT确定绑定使用哪个协议，就应该调整生存期。
As with traditional NATs (see Section 2.5 of [RFC3027]), NAT-PT will most likely break applications that require address mapping to be retained across contiguous sessions. These applications require the IPv4 to IPv6 address mapping to be retained between sessions so the same mapped address may be reused for subsequent session interactions. NAT-PT cannot know this requirement and may reassign the previously used mapped address to different hosts between sessions.
与传统NAT（见[RFC3027]第2.5节）一样，NAT-PT很可能会中断需要在连续会话中保留地址映射的应用程序。这些应用程序要求在会话之间保留IPv4到IPv6的地址映射，以便在后续会话交互中重用相同的映射地址。NAT-PT无法了解此要求，可能会在会话之间将以前使用的映射地址重新分配给不同的主机。
Trying to keep NAT-PT from discarding an address mapping would require either a NAT-PT extension protocol that would allow the application to request the NAT-PT device to retain the mappings, or an extended ALG (which has all the issues discussed in Section 2.1) that can interact with NAT-PT to keep the address mapping from being discarded after a session.
试图阻止NAT-PT丢弃地址映射需要NAT-PT扩展协议，该协议允许应用程序请求NAT-PT设备保留映射，或者需要扩展ALG（其具有第2.1节中讨论的所有问题）它可以与NAT-PT交互，以防止在会话后丢弃地址映射。
As discussed in Section 2.3, a NAT-PT may create dynamic NAT bindings, each of which consumes memory resources as well as an address (or port if NAPT-PT is used) from an address (or port) pool. A number of documents, including [RFC2766] and [NATPT-SEC] discuss the possible denial of service (DoS) attacks on basic NAT-PT and NAPT-PT that would result in a resource depletion associated with address and port pools. NAT-PT does not specify any authentication mechanisms; thus, an attacker may be able to create spurious bindings by spoofing addresses in packets sent through NAT-PT. The attack is more damaging if the attacker is able to spoof protocols with long binding timeouts (typically used for TCP).
如第2.3节所述，NAT-PT可以创建动态NAT绑定，每个NAT绑定都会消耗内存资源以及地址（或端口）池中的地址（或端口，如果使用NAPT-PT）。许多文档，包括[RFC2766]和[NATPT-SEC]讨论了可能对基本NAT-PT和NAPT-PT进行的拒绝服务（DoS）攻击，这些攻击将导致与地址池和端口池相关的资源耗尽。NAT-PT未指定任何身份验证机制；因此，攻击者可以通过欺骗通过NAT-PT发送的数据包中的地址来创建虚假绑定。如果攻击者能够欺骗具有长绑定超时的协议（通常用于TCP），则攻击的破坏性更大。
The use of the DNS-ALG in NAT-PT introduces another vulnerability that can result in resource depletion. The attack identified in [DNS-ALG-ISSUES] exploits the use of DNS queries traversing NAT-PT to create dynamic bindings. Every time a DNS query is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding without any end-host authentication or authorization mechanisms. This behavior could lead to a serious DoS attack on both memory and address or port pools. Address spoofing is not required for this attack to be successful.
在NAT-PT中使用DNS-ALG会引入另一个可能导致资源消耗的漏洞。[DNS-ALG-ISSUES]中识别的攻击利用DNS查询遍历NAT-PT来创建动态绑定。每次通过NAT-PT发送DNS查询时，NAT-PT都可以创建新的基本NAT-PT或NAPT-PT绑定，而无需任何终端主机身份验证或授权机制。这种行为可能导致对内存池、地址池或端口池的严重DoS攻击。此攻击成功不需要地址欺骗。
[DNS-ALG-SOL] proposes to mitigate the DoS attack by using Access Control Lists (ACLs) and static binds, which increases the operational cost and may not always be practical.
[DNS-ALG-SOL]建议通过使用访问控制列表（ACL）和静态绑定来减轻DoS攻击，这会增加运营成本，可能并不总是可行的。
The ideal mitigation solution would be to disallow dynamically created binds until authentication and authorization of the end-host needing the protocol translation has been carried out. This would require that the proper security infrastructure be in place to support the authentication and authorization, which increases the network operational complexity.
理想的缓解方案是在需要协议转换的终端主机的身份验证和授权完成之前，不允许动态创建绑定。这将需要适当的安全基础设施来支持身份验证和授权，这将增加网络操作的复杂性。
4.1. Address Selection Issues when Communicating with Dual-Stack End-Hosts
4.1. 与双栈端主机通信时的地址选择问题
[DNS-ALG-ISSUES] discusses NAT-PT DNS-ALG issues with regard to address selection. As specified in [RFC2766], the DNS-ALG returns AAAA Resource Records (RRs) from two possible sources, to the IPv6 host that has made an AAAA DNS query.
[DNS-ALG-ISSUES]讨论与地址选择有关的NAT-PT DNS-ALG问题。如[RFC2766]中所述，DNS-ALG将两个可能来源的AAAA资源记录（RRs）返回给进行AAAA DNS查询的IPv6主机。
If the query relates to a dual-stack host, the query will return both the native IPv6 address(es) and the translated IPv4 address(es) in AAAA RRs. Without additional information, the IPv6 host address
如果查询与双堆栈主机相关，则查询将返回AAAA RRs中的本机IPv6地址和转换后的IPv4地址。如果没有其他信息，IPv6主机地址
selection may pick a translated IPv4 address instead of selecting the more appropriate native IPv6 address. Under some circumstances, the address selection algorithms [RFC3484] will always prefer the translated address over the native IPv6 address; this is obviously undesirable.
选择可能会选择转换后的IPv4地址，而不是选择更合适的本机IPv6地址。在某些情况下，地址选择算法[RFC3484]总是更喜欢翻译后的地址而不是本机IPv6地址；这显然是不可取的。
[DNS-ALG-SOL] proposes a solution that involves modification to the NAT-PT specification intended to return only the most appropriate address(es) to an IPv6 capable host as described below:
[DNS-ALG-SOL]提出了一种涉及修改NAT-PT规范的解决方案，旨在仅向支持IPv6的主机返回最合适的地址，如下所述：
o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT will forward the query to the DNS server in the IPv4 domain unchanged, but using IPv4 transport. The following two results can occur:
o 当DNS AAAA查询遍历NAT-PT DNS-ALG时，NAT-PT将不加更改地将查询转发到IPv4域中的DNS服务器，但使用IPv4传输。可能出现以下两种结果：
* If the authoritative DNS server has one or more AAAA records, it returns them. The DNS-ALG then forwards this response to the IPv6 host and does not send an A query as the standard NAT-PT would do.
* 如果权威DNS服务器有一个或多个AAAA记录，它将返回这些记录。然后，DNS-ALG将此响应转发给IPv6主机，并且不会像标准NAT-PT那样发送查询。
* Otherwise, if the DNS server does not understand the AAAA query or has no AAAA entry for the host, it will return an error. The NAT-PT DNS-ALG will intercept the error or empty return and send an A query for the same host. If this query returns an IPv4 address, the ALG creates a binding and synthesizes a corresponding AAAA record, which it sends back to the IPv6 host.
* 否则，如果DNS服务器不理解AAAA查询或没有主机的AAAA条目，它将返回错误。NAT-PT DNS-ALG将截获错误或空返回，并发送同一主机的查询。如果此查询返回IPv4地址，ALG将创建绑定并合成相应的AAAA记录，并将其发送回IPv6主机。
o The NAT-PT thus forwards the result of the first successful DNS response back to the end-host or an error if neither succeeds. Consequently, only AAAA RRs from one source will be provided instead of two as specified in [RFC2766], and it will contain the most appropriate address for a dual-stack or IPv6-only querier.
o 因此，NAT-PT将第一次成功的DNS响应的结果转发回终端主机，如果两者均未成功，则转发错误。因此，将只提供来自一个源的AAAA RRs，而不是[RFC2766]中指定的两个，并且它将包含双堆栈或仅IPv6查询器的最合适地址。
There is, however, still an issue with the proposed solution:
然而，提议的解决方案仍然存在一个问题：
o The DNS client may timeout the query if it doesn't receive a response in time. This is more likely than for queries not passing through a DNS ALG because the NAT-PT may have to make two separate, sequential queries of which the client is not aware. It may be possible to reduce the response time by sending the two queries in parallel and ignoring the result of the A query if the AAAA returns one or more addresses. However, it is still necessary to delay after receiving the first response to determine if a second is coming, which may still trigger the DNS client timeout.
o 如果DNS客户端没有及时收到响应，它可能会使查询超时。这比不通过DNS ALG的查询更有可能，因为NAT-PT可能必须进行两个独立的顺序查询，而客户机不知道这两个查询。若AAAA返回一个或多个地址，可以通过并行发送两个查询并忽略查询结果来减少响应时间。但是，在接收到第一个响应后仍然需要延迟以确定是否有第二个响应，这可能仍然会触发DNS客户端超时。
Unfortunately, the two queries cannot be combined in a single DNS request (all known DNS servers only process a single DNS query per request message because of difficulties expressing authoritativeness for arbitrary combinations of requests).
不幸的是，这两个查询不能组合在一个DNS请求中（所有已知的DNS服务器对于每个请求消息只处理一个DNS查询，因为难以表达对任意请求组合的权威性）。
An alternative solution would be to allow the IPv6 host to use the NAT-PT PREFIX [RFC2766] within its address selection policies and to assign it a low selection priority. This solution requires an automatic configuration of the NAT-PT PREFIX as well as its integration within the address selection policies. The simplest way to integrate this automatic configuration would be through a configuration file download (in case the host or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server did not support vendor options and to avoid a standardization effort on the NAT-PT PREFIX option). This solution does not require any modification to the NAT-PT specification.
另一种解决方案是允许IPv6主机在其地址选择策略中使用NAT-PT前缀[RFC2766]，并为其分配较低的选择优先级。此解决方案需要自动配置NAT-PT前缀，并将其集成到地址选择策略中。集成此自动配置的最简单方法是下载配置文件（如果IPv6的主机或动态主机配置协议（DHCPv6）服务器不支持供应商选项，并避免NAT-PT前缀选项的标准化工作）。该解决方案不需要对NAT-PT规范进行任何修改。
Neither of these solutions resolves a second issue related to address selection that is identified in [DNS-ALG-ISSUES]. Applications have no way of knowing that the IPv6 address returned from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 address. The application may therefore, be led to believe that it has end-to-end IPv6 connectivity with the destination. As a result, the application may use IPv6-specific options that are not supported by NAT-PT. This issue is closely related to the issue described in Section 4.2 and the discussion in Section 5.
这两种解决方案都无法解决[DNS-ALG-ISSUES]中确定的与地址选择相关的第二个问题。应用程序无法知道从DNS-ALG返回的IPv6地址不是“真实”的IPv6地址，而是经过翻译的IPv4地址。因此，应用程序可能会认为它与目的地具有端到端IPv6连接。因此，应用程序可能会使用NAT-PT不支持的IPv6特定选项。该问题与第4.2节中描述的问题以及第5节中的讨论密切相关。
Some applications propagate information records retrieved from DNS to other applications. The published semantics of DNS imply that the results will be consistent to any user for the duration of the attached lifetime. RR records translated by NAT-PT violate these semantics because the retrieved addresses are only usable for communications through the translating NAT-PT.
某些应用程序将从DNS检索的信息记录传播到其他应用程序。DNS的已发布语义意味着在附加的生存期内，结果对任何用户都是一致的。NAT-PT转换的RR记录违反了这些语义，因为检索到的地址仅可用于通过转换NAT-PT的通信。
Applications that pass on retrieved DNS records to other applications will generally assume that they can rely on the passed on addresses to be usable by the receiving application. This may not be the case if the receiving application is on another node, especially if it is not in the domain served by the NAT-PT that generated the translation.
将检索到的DNS记录传递给其他应用程序的应用程序通常会假定它们可以依赖于传递的地址，以供接收应用程序使用。如果接收应用程序位于另一个节点上，尤其是如果它不在生成翻译的NAT-PT所服务的域中，则情况可能并非如此。
Some applications running on dual-stack nodes may wish to query the IPv4 address of a destination. If the resulting A query passes through the NAT-PT DNS-ALG, the DNS-ALG will translate the response inappropriately into a AAAA record using a translated address. This happens because the DNS-ALG specified in [RFC2766] operates statelessly and hence has no memory of the IPv6 query that induced the A request on the IPv4 side. The default action is to translate the response.
在双堆栈节点上运行的某些应用程序可能希望查询目标的IPv4地址。如果生成的A查询通过NAT-PT DNS-ALG，DNS-ALG将使用转换后的地址不适当地将响应转换为AAAA记录。发生这种情况是因为[RFC2766]中指定的DNS-ALG无状态运行，因此没有在IPv4端引发A请求的IPv6查询的内存。默认操作是转换响应。
The specification of NAT-PT could be modified to maintain a minimal state about queries passed through the DNS-ALG, and hence to respond correctly to A queries as well as AAAA queries.
可以修改NAT-PT规范，以保持有关通过DNS-ALG的查询的最小状态，从而正确响应a查询和AAAA查询。
Many IPv6 nodes, especially in multihomed situations but also in single homed deployments, can expect to have multiple global addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all these addresses. Since the DNS-ALG in the NAT-PT has no knowledge which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them.
许多IPv6节点，特别是在多宿情况下，但也在单宿部署中，可以预期具有多个全局地址。对于多宿IPv4节点也可能如此。对这些节点的DNS查询的响应通常包含所有这些地址。由于NAT-PT中的DNS-ALG不知道发出查询的应用程序可以或将使用哪些地址，因此有义务翻译所有这些地址。
This could be a significant drain on resources in both basic NAT-PT and NAPT-PT, as bindings will have to be created for each address.
这可能会严重消耗基本NAT-PT和NAPT-PT中的资源，因为必须为每个地址创建绑定。
When using SCTP in a multihomed network, the problem is exacerbated if multiple NAT-PTs translate multiple addresses. Also, it is not clear that SCTP will actually look up all the destination IP addresses via DNS, so that bindings may not be in place when packets arrive.
在多址网络中使用SCTP时，如果多个NAT PT转换多个地址，则问题会加剧。此外，还不清楚SCTP是否会通过DNS查找所有目标IP地址，因此当数据包到达时绑定可能不到位。
Secure DNS (DNSSEC) [RFC4033] uses public key cryptographic signing to authenticate DNS responses. The DNS-ALG modifies DNS query responses traversing the NAT-PT in both directions, which would invalidate the signatures as (partially) described in Section 7.5 of [RFC2766].
安全DNS（DNSSEC）[RFC4033]使用公钥加密签名来验证DNS响应。DNS-ALG修改在两个方向上穿越NAT-PT的DNS查询响应，这将使[RFC2766]第7.5节中描述的签名（部分）无效。
Workarounds have been proposed, such as making the DNS-ALG behave like a secure DNS server. This would need to be done separately for both the IPv6 and IPv4 domains. This is operationally very complex and there is a risk that the server could be mistaken for a conventional DNS server. The NAT-PT specification would have to be altered to implement any such workaround.
已经提出了解决办法，例如使DNS-ALG的行为类似于一个安全的DNS服务器。这需要对IPv6和IPv4域分别执行。这在操作上非常复杂，并且存在将服务器误认为传统DNS服务器的风险。必须修改NAT-PT规范以实现任何此类解决方案。
Hence, DNSSEC is not deployable in domains that use NAT-PT as currently specified. Widespread deployment of NAT-PT would become a serious obstacle to the large scale deployment of DNSSEC.
因此，DNSSEC不能在当前指定的使用NAT-PT的域中部署。NAT-PT的广泛部署将成为大规模部署DNSSEC的严重障碍。
One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet. Therefore, because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, developers creating applications to work with IPv6 may be tempted to assume that the complex expedients that might have been needed to make the application work in a 'NATted' IPv4 environment are not required.
IPv6的主要设计目标之一是恢复互联网的端到端透明度。因此，由于IPv6有望消除对NAT的需求以及透明度方面的类似障碍，因此创建使用IPv6的应用程序的开发人员可能会倾向于认为，不需要复杂的权宜之计，使应用程序在“NAT”IPv4环境中工作。
Consequently, some classes of applications (e.g., peer-to-peer) that would need special measures to manage NAT traversal, including special encapsulations, attention to binding lifetime, and provision of keepalives, may build in assumptions on whether IPv6 is being used or not. Developers would also like to exploit additional capabilities of IPv6 not available in IPv4.
因此，需要采取特殊措施来管理NAT穿越的某些类应用程序（例如，对等应用程序），包括特殊封装、对绑定生存期的关注以及keepalives的提供，可能会对是否使用IPv6进行假设。开发人员还希望利用IPv4中没有的IPv6附加功能。
NAT-PT as specified in [RFC2766] is intended to work autonomously and be transparent to applications. Therefore, there is no way for application developers to discover that a path contains a NAT-PT.
[RFC2766]中规定的NAT-PT旨在自主工作并对应用程序透明。因此，应用程序开发人员无法发现路径包含NAT-PT。
If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 environment may break when the traffic passes through a NAT-PT. This is bad enough, but requiring developers to include special capabilities to work around what is supposed to be a temporary transition 'aid' is even worse. Finally, deployment of NAT-PT is likely to inhibit the development and use of additional IPv6 capabilities enabled by the flexible extension header system in IPv6 packets.
如果部署了NAT-PT，则假定无NAT IPv6环境的应用程序可能会在流量通过NAT-PT时中断。这已经够糟糕的了，但要求开发人员包含特殊功能，以解决所谓的临时过渡“辅助”问题，这就更糟糕了。最后，NAT-PT的部署可能会抑制IPv6数据包中灵活扩展报头系统启用的额外IPv6功能的开发和使用。
Some of these deleterious effects could possibly be alleviated if applications could discover the presence of NAT-PT boxes on paths in use, allowing the applications to take steps to workaround the problems. However, requiring applications to incorporate extra code to workaround problems with a transition aid still seems to be a very bad idea: the behavior of the application in native IPv6 and NAT-PT environments would be likely to be significantly different.
如果应用程序能够发现正在使用的路径上存在NAT-PT盒，从而允许应用程序采取措施解决问题，则其中一些有害影响可能会得到缓解。然而，要求应用程序合并额外的代码来解决过渡辅助问题似乎仍然是一个非常糟糕的想法：应用程序在本机IPv6和NAT-PT环境中的行为可能会有显著的不同。
This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections:
本文档总结了与NAT-PT[RFC2766]规范相关的安全问题。安全问题在以下各节中讨论：
o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP encapsulation is not used [RFC3498]) and authentication and encryption are generally incompatible with NAT-PT.
o 第2.1节讨论了NAT-PT如何破坏IPsec AH（传输和隧道模式）和IPsec ESP传输模式（当未使用IPsec UDP封装[RFC3498]时），身份验证和加密通常与NAT-PT不兼容。
o Section 2.5 discusses possible fragmentation related security attacks on NAT-PT.
o 第2.5节讨论了NAT-PT上可能存在的碎片相关安全攻击。
o Section 2.8 discusses security issues related to multicast addresses and NAT-PT.
o 第2.8节讨论了与多播地址和NAT-PT相关的安全问题。
o Section 3.3 highlights that NAT-PT is an enticing nexus for security attacks.
o 第3.3节强调了NAT-PT是安全攻击的诱人纽带。
o Section 3.4 discusses possible NAT-PT DoS attacks on both memory and address/port pools.
o 第3.4节讨论了可能对内存池和地址/端口池的NAT-PT DoS攻击。
o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC [RFC4033] and how deployment of NAT-PT may inhibit deployment of DNSSEC.
o 第4.5节讨论了NAT-PT与DNSSEC[RFC4033]不兼容的原因，以及NAT-PT的部署如何抑制DNSSEC的部署。
This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP networks are currently the only 'standardised' scenario where NAT-PT is envisaged as a potential mechanism to allow communication between an IPv6-only host and an IPv4-only host as discussed in the 3GPP IPv6 transition analysis [RFC4215]. But RFC 4215 recommends that the generic form of NAT-PT should not be used and that modified forms should only be used under strict conditions. Moreover, it documents a number of caveats and security issues specific to 3GPP. In addition, NAT-PT has seen some limited usage for other purposes.
本文件讨论了[RFC2766]中定义的NAT-PT的许多重要问题。从部署角度来看，3GPP网络是目前唯一的“标准化”场景，其中NAT-PT被设想为一种潜在机制，允许仅IPv6主机和仅IPv4主机之间的通信，如3GPP IPv6过渡分析[RFC4215]中所述。但RFC 4215建议不应使用NAT-PT的通用形式，修改后的形式应仅在严格条件下使用。此外，它还记录了一些针对3GPP的警告和安全问题。此外，NAT-PT在其他方面的使用也很有限。
Although some of the issues identified with NAT-PT appear to have solutions, many of the solutions proposed require significant alterations to the existing specification and would likely increase operational complexity. Even if these solutions were applied, we have shown that NAT-PT still has significant, irresolvable issues and appears to have limited applicability. The potential constraints on the development of IPv6 applications described in Section 5 are particularly undesirable. It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of application proxies in 3GPP scenarios [RFC4215]
虽然通过NAT-PT确定的一些问题似乎有解决方案，但提出的许多解决方案需要对现有规范进行重大修改，并可能增加操作复杂性。即使应用了这些解决方案，我们已经证明NAT-PT仍然存在重大的、无法解决的问题，并且似乎适用性有限。第5节中描述的IPv6应用程序开发的潜在限制尤其不可取。似乎存在NAT-PT的替代方案，以涵盖NAT-PT被建议作为解决方案的情况，例如在3GPP场景中使用应用程序代理[RFC4215]
However, it is clear that in some circumstances an IPv6-IPv4 protocol translation solution may be a useful transitional solution,
但是，很明显，在某些情况下，IPv6-IPv4协议转换解决方案可能是一个有用的过渡解决方案，
particularly in more constrained situations where the translator is not required to deal with traffic for a wide variety of protocols that are not determined in advance. Therefore, it is possible that a more limited form of NAT-PT could be defined for use in specific situations.
特别是在更受限制的情况下，翻译器不需要处理各种各样的协议的流量，这些协议不是预先确定的。因此，有可能定义一种更为有限的NAT-PT形式，以便在特定情况下使用。
Accordingly, we recommend that:
因此，我们建议：
o the IETF no longer suggest its usage as a general IPv4-IPv6 transition mechanism in the Internet, and
o IETF不再建议将其用作Internet中的通用IPv4-IPv6转换机制，以及
o RFC 2766 is moved to Historic status to limit the possibility of it being deployed inappropriately.
o RFC 2766已移至历史状态，以限制其不适当部署的可能性。
This work builds on a large body of existing work examining the issues and applicability of NAT-PT: the work of the authors of the documents referred to in Section 1 has been extremely useful in creating this document. Particular thanks are due to Pekka Savola for rapid and thorough review of the document.
这项工作建立在大量研究NAT-PT问题和适用性的现有工作的基础上：第1节中提到的文件作者的工作在创建本文件时非常有用。特别感谢佩卡·萨沃拉对该文件的快速和彻底审查。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765]Nordmark，E.“无状态IP/ICMP转换算法（SIIT）”，RFC2765，2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]Wasserman，M.，“第三代合作伙伴项目（3GPP）标准中IPv6的建议”，RFC 3314，2002年9月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294]Loughney，J.，“IPv6节点要求”，RFC 42942006年4月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215]Wiljakka，J.，“第三代合作伙伴计划（3GPP）网络中IPv6过渡的分析”，RFC 4215，2005年10月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[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月。
[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月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.，和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures", RFC 3498, March 2003.
[RFC3498]Kuhfeld，J.，Johnson，J.，和M.Thatcher，“同步光网络（SONET）线性自动保护交换（APS）体系结构的受管对象定义”，RFC 3498，2003年3月。
[NATP-APP] Satapati, S., "NAT-PT Applicability", Work in Progress, October 2003.
[NATP-APP]Satapati，S.，“NAT-PT适用性”，正在进行的工作，2003年10月。
[DNS-ALG-ISSUES] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", Work in Progress, February 2002.
[DNS-ALG-ISSUES]Durand，A.，“RFC2766中NAT-PT DNS ALG的问题”，正在进行的工作，2002年2月。
[DNS-ALG-SOL] Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions", Work in Progress, July 2002.
[DNS-ALG-SOL]Hallingby，P.和S.Satapati，“NAT-PT DNS ALG解决方案”，正在进行的工作，2002年7月。
[NATPT-MOB] Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", Work in Progress, July 2005.
[NATPT-MOB]Shin，M.和J.Lee，“NAT-PT中移动支持的考虑因素”，正在进行的工作，2005年7月。
[NATPT-SEC] Okazaki, S. and A. Desai, "NAT-PT Security Considerations", Work in Progress, June 2003.
[NAPT-SEC]Okazaki，S.和A.Desai，“NAT-PT安全考虑”，正在进行的工作，2003年6月。
[TRANS-ISSUES] Pol, R., Satapati, S., and S. Sivakumar, "Issues when translating between IPv4 and IPv6", Work in Progress, January 2003.
[TRANS-ISSUES]Pol，R.，Satapati，S.和S.Sivakumar，“IPv4和IPv6之间转换时的问题”，正在进行的工作，2003年1月。
[3GPP-TRANS] Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks", Work in Progress, December 2003.
[3GPP-TRANS]Malki，K.，“第三代合作伙伴关系项目（3GPP）网络中基于SIP的服务的IPv6-IPv4转换机制”，正在进行的工作，2003年12月。
[MTP] Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", Work in Progress, February 2003.
[MTP]Tsuchiya，K.，Higuchi，H.，Sawada，S.，和S.Nozaki，“基于IGMP/MLD代理（MTP）的IPv6/IPv4多播转换器”，正在进行的工作，2003年2月。
[MCASTGW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in Progress, February 2003.
[MCASTGW]Venaas，S.，“IPv4-IPv6多播网关”，正在进行的工作，2003年2月。
[MUL-NATPT] Park, S., "Scalable mNAT-PT Solution", Work in Progress, May 2003.
[MUL-NATPT]Park，S.，“可扩展的mNAT PT解决方案”，正在进行的工作，2003年5月。
Authors' Addresses
作者地址
Cedric Aoun Energize Urnet Paris France
塞德里克·奥恩（Cedric Aoun）为法国巴黎瓮城（Urnet Paris）注入活力
EMail: ietf@energizeurnet.com
EMail: ietf@energizeurnet.com
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B.Davies Folly Consulting Soham，英国剑桥
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。