Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6296 Painless Security
Category: Experimental F. Baker
ISSN: 2070-1721 Cisco Systems
June 2011
Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6296 Painless Security
Category: Experimental F. Baker
ISSN: 2070-1721 Cisco Systems
June 2011
IPv6-to-IPv6 Network Prefix Translation
IPv6到IPv6网络前缀转换
Abstract
摘要
This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.
本文档描述了一个无状态、传输不可知的IPv6-to-IPv6网络前缀转换（NPTv6）功能，该功能提供了与IPv4-to-IPv4 NAT（NAPT44）相关的地址独立性优势，并在“内部”和“外部”前缀中的地址之间提供了1:1的关系，从而在网络层保持了端到端的可达性。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6296.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6296.
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
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从该文档中提取的代码组件必须
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.
包括信托法律条款第4.e节中所述的简化BSD许可证文本，且不提供简化BSD许可证中所述的担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Address Independence? . . . . . . . . . . . . . . 4
1.2. NPTv6 Applicability . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Terminology . . . . . . . . . . . . . . . . . 7
2. NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. NPTv6: The Simplest Case . . . . . . . . . . . . . . . . . 7
2.2. NPTv6 between Peer Networks . . . . . . . . . . . . . . . 8
2.3. NPTv6 Redundancy and Load Sharing . . . . . . . . . . . . 9
2.4. NPTv6 Multihoming . . . . . . . . . . . . . . . . . . . . 9
2.5. Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
2.6. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 10
3. NPTv6 Algorithmic Specification . . . . . . . . . . . . . . . 11
3.1. NPTv6 Configuration Calculations . . . . . . . . . . . . . 11
3.2. NPTv6 Translation, Internal Network to External Network . 12
3.3. NPTv6 Translation, External Network to Internal Network . 12
3.4. NPTv6 with a /48 or Shorter Prefix . . . . . . . . . . . . 12
3.5. NPTv6 with a /49 or Longer Prefix . . . . . . . . . . . . 13
3.6. /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13
3.7. Address Mapping for Longer Prefixes . . . . . . . . . . . 14
4. Implications of Network Address Translator Behavioral
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Prefix Configuration and Generation . . . . . . . . . . . 15
4.2. Subnet Numbering . . . . . . . . . . . . . . . . . . . . . 15
4.3. NAT Behavioral Requirements . . . . . . . . . . . . . . . 15
5. Implications for Applications . . . . . . . . . . . . . . . . 16
5.1. Recommendation for Network Planners Considering Use of
NPTv6 Translation . . . . . . . . . . . . . . . . . . . . 17
5.2. Recommendations for Application Writers . . . . . . . . . 18
5.3. Recommendation for Future Work . . . . . . . . . . . . . . 18
6. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Why GSE? . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Verification Code . . . . . . . . . . . . . . . . . . 25
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Address Independence? . . . . . . . . . . . . . . 4
1.2. NPTv6 Applicability . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Terminology . . . . . . . . . . . . . . . . . 7
2. NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. NPTv6: The Simplest Case . . . . . . . . . . . . . . . . . 7
2.2. NPTv6 between Peer Networks . . . . . . . . . . . . . . . 8
2.3. NPTv6 Redundancy and Load Sharing . . . . . . . . . . . . 9
2.4. NPTv6 Multihoming . . . . . . . . . . . . . . . . . . . . 9
2.5. Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
2.6. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 10
3. NPTv6 Algorithmic Specification . . . . . . . . . . . . . . . 11
3.1. NPTv6 Configuration Calculations . . . . . . . . . . . . . 11
3.2. NPTv6 Translation, Internal Network to External Network . 12
3.3. NPTv6 Translation, External Network to Internal Network . 12
3.4. NPTv6 with a /48 or Shorter Prefix . . . . . . . . . . . . 12
3.5. NPTv6 with a /49 or Longer Prefix . . . . . . . . . . . . 13
3.6. /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13
3.7. Address Mapping for Longer Prefixes . . . . . . . . . . . 14
4. Implications of Network Address Translator Behavioral
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Prefix Configuration and Generation . . . . . . . . . . . 15
4.2. Subnet Numbering . . . . . . . . . . . . . . . . . . . . . 15
4.3. NAT Behavioral Requirements . . . . . . . . . . . . . . . 15
5. Implications for Applications . . . . . . . . . . . . . . . . 16
5.1. Recommendation for Network Planners Considering Use of
NPTv6 Translation . . . . . . . . . . . . . . . . . . . . 17
5.2. Recommendations for Application Writers . . . . . . . . . 18
5.3. Recommendation for Future Work . . . . . . . . . . . . . . 18
6. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Why GSE? . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Verification Code . . . . . . . . . . . . . . . . . . 25
This document describes a stateless IPv6-to-IPv6 Network Prefix Translation (NPTv6) function, designed to provide address independence to the edge network. It is transport-agnostic with respect to transports that do not checksum the IP header, such as SCTP, and to transports that use the TCP/UDP/DCCP (Datagram Congestion Control Protocol) pseudo-header and checksum [RFC1071].
本文档描述了无状态IPv6到IPv6网络前缀转换（NPTv6）功能，旨在为边缘网络提供地址独立性。对于不校验IP报头（如SCTP）的传输，以及使用TCP/UDP/DCCP（数据报拥塞控制协议）伪报头和校验和的传输[RFC1071]，传输不可知。
For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. Where translation is implemented, however, this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful Network Address Translator in an IPv6 environment. It also provides a useful alternative to the complexities and costs imposed by multihoming using provider-independent addressing and the routing and network management issues of overlaid ISP address space. Some problems remain, however. The reader should consider the alternatives suggested in [RFC4864] and the considerations of [RFC5902] for improved approaches.
出于[RFC2993]和第5节中讨论的原因，IETF不建议在IPv6中使用网络地址转换技术。然而，在实现转换的地方，本规范提供了一种机制，与在IPv6环境中仅实现传统的有状态网络地址转换器相比，该机制具有更少的体系结构问题。它还提供了一个有用的替代方案，以解决使用独立于提供商的寻址和覆盖ISP地址空间的路由和网络管理问题的多归属所带来的复杂性和成本。然而，仍然存在一些问题。读者应该考虑在[RCFC4664 ]中提出的替代方案和[RCF5902]的改进方法的考虑。
The stateless approach described in this document has several ramifications:
本文档中描述的无状态方法有几个分支：
o Any security benefit that NAPT44 might offer is not present in NPTv6, necessitating the use of a firewall to obtain those benefits if desired. An example of such a firewall is described in [RFC6092].
o NPTv6中不存在NAPT44可能提供的任何安全优势，如果需要，需要使用防火墙来获得这些优势。[RFC6092]中描述了此类防火墙的示例。
o End-to-end reachability is preserved, although the address used "inside" the edge network differs from the address used "outside" the edge network. This has implications for application referrals and other uses of Internet layer addresses.
o 尽管“在”边缘网络“内部”使用的地址与“在”边缘网络“外部”使用的地址不同，但仍保留了端到端的可达性。这对应用程序引用和Internet层地址的其他使用有影响。
o If there are multiple identically configured prefix translators between two networks, there is no need for them to exchange dynamic state, as there is no dynamic state -- the algorithmic translation will be identical across each of them. The network can therefore asymmetrically route, load share, and fail-over among them without issue.
o 如果两个网络之间有多个配置相同的前缀转换器，则它们不需要交换动态状态，因为没有动态状态——每个网络的算法转换都是相同的。因此，网络可以在它们之间进行不对称路由、负载共享和故障转移，而不会出现问题。
o Since translation is 1:1 at the network layer, there is no need to modify port numbers or other transport parameters.
o 由于网络层的转换为1:1，因此无需修改端口号或其他传输参数。
o TCP sessions that authenticate peers using the TCP Authentication Option [RFC5925] cannot have their addresses translated, as the addresses are used in the calculation of the Message Authentication Code. This consideration applies in general to any
o 使用TCP身份验证选项[RFC5925]对对等方进行身份验证的TCP会话不能转换其地址，因为这些地址用于计算消息身份验证代码。这种考虑一般适用于任何
UNilateral Self-Address Fixing (UNSAF) [RFC3424] Protocol, which the IAB recommends against the deployment of in an environment that changes Internet addresses.
单边自地址固定（UNSAF）[RFC3424]协议，IAB建议不要在更改Internet地址的环境中部署。
o Applications using the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] should, at least in theory, detect the presence of the translator; while no NAT traversal solution is required, [RFC5996] would require such sessions to use UDP.
o 使用互联网密钥交换协议版本2（IKEv2）[RFC5996]的应用程序至少在理论上应该检测到翻译器的存在；虽然不需要NAT遍历解决方案，[RFC5996]将要求此类会话使用UDP。
For the purposes of this document, IPv6 address independence consists of the following set of properties:
在本文档中，IPv6地址独立性由以下一组属性组成：
From the perspective of the edge network:
从边缘网络的角度来看：
* The IPv6 addresses used inside the local network (for interfaces, access lists, and logs) do not need to be renumbered if the global prefix(es) assigned for use by the edge network are changed.
* 如果为边缘网络指定的全局前缀发生更改，则本地网络内使用的IPv6地址（用于接口、访问列表和日志）无需重新编号。
* The IPv6 addresses used inside the edge network (for interfaces, access lists, and logs) or within other upstream networks (such as when multihoming) do not need to be renumbered when a site adds, drops, or changes upstream networks.
* 当站点添加、删除或更改上游网络时，边缘网络内部（用于接口、访问列表和日志）或其他上游网络内部（如多宿主时）使用的IPv6地址不需要重新编号。
* It is not necessary for an administration to convince an upstream network to route its internal IPv6 prefixes or for it to advertise prefixes derived from other upstream networks into it.
* 管理部门无需说服上游网络路由其内部IPv6前缀，也无需向其播发从其他上游网络派生的前缀。
* Unless it wants to optimize routing between multiple upstream networks in the process of multihoming, there is no need for a BGP exchange with the upstream network.
* 除非它希望在多宿过程中优化多个上游网络之间的路由，否则不需要与上游网络进行BGP交换。
From the perspective of the upstream network:
从上游网络的角度来看：
* IPv6 addresses used by the edge network are guaranteed to have a provider-allocated prefix, eliminating the need and concern for BCP 38 [RFC2827] ingress filtering and the advertisement of customer-specific prefixes.
* 边缘网络使用的IPv6地址保证具有提供商分配的前缀，从而消除了BCP 38[RFC2827]入口过滤和客户特定前缀广告的需要和顾虑。
Thus, address independence has ramifications for the edge network, networks it directly connects with (especially its upstream networks), and the Internet as a whole. The desire for address independence has been a primary driver for IPv4 NAT deployment in medium- to large-sized enterprise networks, including NAT deployments
因此，地址独立性对边缘网络、直接连接的网络（尤其是其上游网络）以及整个互联网都有影响。对地址独立性的渴望一直是中大型企业网络中IPv4 NAT部署（包括NAT部署）的主要驱动因素
in enterprises that have plenty of IPv4 provider-independent address space (from IPv4 "swamp space"). It has also been a driver for edge networks to become members of Regional Internet Registry (RIR) communities, seeking to obtain BGP Autonomous System Numbers and provider-independent prefixes, and as a result has been one of the drivers of the explosion of the IPv4 route table. Service providers have stated that the lack of address independence from their customers has been a negative incentive to deployment, due to the impact of customer routing expected in their networks.
在拥有大量独立于IPv4提供商的地址空间（来自IPv4“沼泽空间”）的企业中。它还推动边缘网络成为区域互联网注册（RIR）社区的成员，寻求获得BGP自治系统编号和独立于提供商的前缀，因此成为IPv4路由表爆炸的驱动因素之一。服务提供商表示，由于其网络中预期的客户路由的影响，缺乏与客户的地址独立性一直是部署的负面动机。
The Local Network Protection [RFC4864] document discusses a related concept called "Address Autonomy" as a benefit of NAPT44. [RFC4864] indicates that address autonomy can be achieved by the simultaneous use of global addresses on all nodes within a site that need external connectivity and Unique Local Addresses (ULAs) [RFC4193] for all internal communication. However, this solution fails to meet the requirement for address independence, because if an ISP renumbering event occurs, all of the hosts, routers, DHCP servers, Access Control Lists (ACLs), firewalls, and other internal systems that are configured with global addresses from the ISP will need to be renumbered before global connectivity is fully restored.
本地网络保护[RFC4864]文档讨论了一个称为“地址自治”的相关概念，作为NAPT44的一个优点。[RFC4864]表示地址自治可以通过在站点内需要外部连接的所有节点上同时使用全局地址和所有内部通信的唯一本地地址（ULA）[RFC4193]来实现。但是，此解决方案无法满足地址独立性的要求，因为如果发生ISP重新编号事件，所有主机、路由器、DHCP服务器、访问控制列表（ACL）、防火墙、，在完全恢复全局连接之前，需要对配置了ISP全局地址的其他内部系统重新编号。
The use of IPv6 provider-independent (PI) addresses has also been suggested as a means to fulfill the address-independence requirement. However, this solution requires that an enterprise qualify to receive a PI assignment and persuade its ISP to install specific routes for the enterprise's PI addresses. There are a number of practical issues with this approach, especially if there is a desire to route to a number of geographically and topologically diverse sites, which can sometimes involve coordinating with several ISPs to route portions of a single PI prefix. These problems have caused numerous enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT for part, or substantially all, of their internal network instead of using their provider-independent address space.
还建议使用IPv6提供商独立（PI）地址作为满足地址独立性要求的一种手段。但是，此解决方案要求企业有资格接收PI分配，并说服其ISP为企业的PI地址安装特定路由。这种方法存在许多实际问题，特别是如果希望路由到多个地理和拓扑不同的站点，这有时可能涉及与多个ISP协调以路由单个PI前缀的部分。这些问题已导致许多拥有大量IPv4沼泽空间的企业选择将IPv4 NAT用于其内部网络的一部分或大部分，而不是使用其独立于提供商的地址空间。
NPTv6 provides a simple and compelling solution to meet the address-independence requirement in IPv6. The address-independence benefit stems directly from the translation function of the network prefix translator. To avoid as many of the issues associated with NAPT44 as possible, NPTv6 is defined to include a two-way, checksum-neutral, algorithmic translation function, and nothing else.
NPTv6提供了一个简单而引人注目的解决方案，以满足IPv6中的地址独立性要求。地址独立性的好处直接来自网络前缀转换器的翻译功能。为了尽可能避免与NAPT44相关的许多问题，NPTv6被定义为包含一个双向、校验和中性、算法转换函数，而没有其他功能。
The fact that NPTv6 does not map ports and is checksum-neutral avoids the need for an NPTv6 Translator to rewrite transport layer headers. This makes it feasible to deploy new or improved transport layer
NPTv6不映射端口，并且是校验和中立的，这一事实避免了NPTv6转换器重写传输层头的需要。这使得部署新的或改进的传输层成为可能
protocols without upgrading NPTv6 Translators. Similarly, since NPTv6 does not rewrite transport layer headers, NPTv6 will not interfere with encryption of the full IP payload in many cases.
不升级NPTv6转换器的协议。类似地，由于NPTv6不会重写传输层报头，因此NPTv6在许多情况下不会干扰完整IP有效负载的加密。
The default NPTv6 address-mapping mechanism is purely algorithmic, so NPTv6 translators do not need to maintain per-node or per-connection state, allowing deployment of more robust and adaptive networks than can be deployed using NAPT44. Since the default NPTv6 mapping can be performed in either direction, it does not interfere with inbound connection establishment, thus allowing internal nodes to participate in direct Peer-to-Peer applications without the application layer overhead one finds in many IPv4 Peer-to-Peer applications.
默认的NPTv6地址映射机制是纯算法的，因此NPTv6转换器不需要维护每个节点或每个连接状态，从而允许部署比使用NAPT44部署更健壮、更自适应的网络。由于默认的NPTv6映射可以在任一方向上执行，因此它不会干扰入站连接的建立，从而允许内部节点参与直接对等应用程序，而不会产生许多IPv4对等应用程序中的应用层开销。
Although NPTv6 compares favorably to NAPT44 in several ways, it does not eliminate all of the architectural problems associated with IPv4 NAT, as described in [RFC2993]. NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header. NPTv6 may interfere with the use of application protocols that transmit IP addresses in the application-specific portion of the IP datagram. These applications currently require Application Layer Gateways (ALGs) to work correctly through NAPT44 devices, and similar ALGs may be required for these applications to work through NPTv6 Translators. The use of separate internal and external prefixes creates complexity for DNS deployment, due to the desire for internal nodes to communicate with other internal nodes using internal addresses, while external nodes need to obtain external addresses to communicate with the same nodes. This frequently results in the deployment of "split DNS", which may add complexity to network configuration.
尽管NPTv6在几个方面都优于NAPT44，但它并没有消除与IPv4 NAT相关的所有架构问题，如[RFC2993]中所述。NPTv6涉及在传输过程中修改IP报头，因此它与为IP报头提供完整性保护的安全机制（如IPsec身份验证报头）不兼容。NPTv6可能会干扰在IP数据报的应用特定部分中传输IP地址的应用协议的使用。这些应用程序目前需要应用层网关（ALG）通过NAPT44设备正常工作，并且这些应用程序可能需要类似的ALG通过NPTv6转换器工作。由于希望内部节点使用内部地址与其他内部节点通信，而外部节点需要获取外部地址才能与相同节点通信，因此使用单独的内部和外部前缀会增加DNS部署的复杂性。这通常会导致部署“拆分DNS”，这可能会增加网络配置的复杂性。
The choice of address within the edge network bears consideration. One could use a ULA, which maximizes address independence. That could also be considered a misuse of the ULA; if the expectation is that a ULA prevents access to a system from outside the range of the ULA, NPTv6 overrides that. On the other hand, the administration is aware that it has made that choice and could deploy a second ULA for the purpose of privacy if it desired; the only prefix that will be translated is one that has an NPTv6 Translator configured to translate to or from it. Also, using any other global-scope address format makes one either obtain a PI prefix or be at the mercy of the agency from which it was allocated.
边缘网络内地址的选择需要考虑。可以使用一个最大化地址独立性的ULA。这也可被视为滥用了《统一法》；如果预期ULA阻止从ULA范围外访问系统，NPTv6将覆盖该范围。另一方面，政府当局知道它已经作出了这一选择，如果愿意，可以为隐私目的部署第二个ULA；唯一将被翻译的前缀是配置了NPTv6转换器的前缀，该转换器可向其翻译或从其翻译。此外，使用任何其他全局作用域地址格式可以使您获得PI前缀，或者由分配该前缀的机构决定。
There are significant technical impacts associated with the deployment of any prefix translation mechanism, including NPTv6, and we strongly encourage anyone who is considering the implementation or
任何前缀转换机制（包括NPTv6）的部署都会产生重大的技术影响，我们强烈鼓励任何正在考虑实施或部署前缀转换机制的人
deployment of NPTv6 to read [RFC4864] and [RFC5902], and to carefully consider the alternatives described in that document, some of which may cause fewer problems than NPTv6.
部署NPTV6来读取[RCFC46]和[RCF5902]，并仔细考虑该文档中描述的替代方案，其中一些可能导致比NPTV6更少的问题。
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]中所述进行解释。
NPTv6 may be implemented in an IPv6 router to map one IPv6 address prefix to another IPv6 prefix as each IPv6 datagram transits the router. A router that implements an NPTv6 prefix translation function is referred to as an NPTv6 Translator.
NPTv6可以在IPv6路由器中实现，以在每个IPv6数据报传输路由器时将一个IPv6地址前缀映射到另一个IPv6前缀。实现NPTv6前缀转换功能的路由器称为NPTv6转换器。
In its simplest form, an NPTv6 Translator interconnects two network links, one of which is an "internal" network link attached to a leaf network within a single administrative domain and the other of which is an "external" network with connectivity to the global Internet. All of the hosts on the internal network will use addresses from a single, locally routed prefix, and those addresses will be translated to/from addresses in a globally routable prefix as IP datagrams transit the NPTv6 Translator. The lengths of these two prefixes will be functionally the same; if they differ, the longer of the two will limit the ability to use subnets in the shorter.
NPTv6转换器以其最简单的形式连接两个网络链路，其中一个是连接到单个管理域内的叶网络的“内部”网络链路，另一个是连接到全球互联网的“外部”网络。内部网络上的所有主机都将使用单个本地路由前缀中的地址，当IP数据报传输NPTv6转换器时，这些地址将转换为全局路由前缀中的地址。这两个前缀的长度在功能上是相同的；如果两者不同，则两者中较长者将限制较短者使用子网的能力。
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+-------------+
| NPTv6 |
| Translator |
+-------------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+-------------+
| NPTv6 |
| Translator |
+-------------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 1: A Simple Translator
图1：一个简单的翻译器
Figure 1 shows an NPTv6 Translator attached to two networks. In this example, the internal network uses IPv6 Unique Local Addresses (ULAs) [RFC4193] to represent the internal IPv6 nodes, and the external network uses globally routable IPv6 addresses to represent the same nodes.
图1显示了连接到两个网络的NPTv6转换器。在此示例中，内部网络使用IPv6唯一本地地址（ULA）[RFC4193]表示内部IPv6节点，外部网络使用全局可路由IPv6地址表示相同节点。
When an NPTv6 Translator forwards datagrams in the "outbound" direction, from the internal network to the external network, NPTv6 overwrites the IPv6 source prefix (in the IPv6 header) with a corresponding external prefix. When datagrams are forwarded in the "inbound" direction, from the external network to the internal network, the IPv6 destination prefix is overwritten with a corresponding internal prefix. Using the prefixes shown in the diagram above, as an IP datagram passes through the NPTv6 Translator in the outbound direction, the source prefix (FD01:0203:0405:/48) will be overwritten with the external prefix (2001:0DB8:0001:/48). In an inbound datagram, the destination prefix (2001:0DB8:0001:/48) will be overwritten with the internal prefix (FD01:0203:0405:/48). In both cases, it is the local IPv6 prefix that is overwritten; the remote IPv6 prefix remains unchanged. Nodes on the internal network are said to be "behind" the NPTv6 Translator.
当NPTv6转换器以“出站”方向将数据报从内部网络转发到外部网络时，NPTv6会用相应的外部前缀覆盖IPv6源前缀（在IPv6头中）。当数据报以“入站”方向从外部网络转发到内部网络时，IPv6目标前缀将被相应的内部前缀覆盖。使用上图所示的前缀，当IP数据报在出站方向通过NPTv6转换器时，源前缀（FD01:0203:0405:/48）将被外部前缀（2001:0DB8:0001:/48）覆盖。在入站数据报中，目标前缀（2001:0DB8:0001:/48）将被内部前缀（FD01:0203:0405:/48）覆盖。在这两种情况下，都是本地IPv6前缀被覆盖；远程IPv6前缀保持不变。内部网络上的节点被称为NPTv6转换器的“后方”。
NPTv6 can also be used between two private networks. In these cases, both networks may use ULA prefixes, with each subnet in one network mapped into a corresponding subnet in the other network, and vice versa. Or, each network may use ULA prefixes for internal addressing and global unicast addresses on the other network.
NPTv6也可以在两个专用网络之间使用。在这些情况下，两个网络都可以使用ULA前缀，其中一个网络中的每个子网映射到另一个网络中的相应子网，反之亦然。或者，每个网络可以将ULA前缀用于另一个网络上的内部寻址和全局单播地址。
Internal Prefix = FD01:4444:5555:/48
--------------------------------------
V | External Prefix
V | 2001:0DB8:6666:/48
V +---------+ ^
V | NPTv6 | ^
V | Device | ^
V +---------+ ^
External Prefix | ^
2001:0DB8:0001:/48 | ^
--------------------------------------
Internal Prefix = FD01:0203:0405:/48
Internal Prefix = FD01:4444:5555:/48
--------------------------------------
V | External Prefix
V | 2001:0DB8:6666:/48
V +---------+ ^
V | NPTv6 | ^
V | Device | ^
V +---------+ ^
External Prefix | ^
2001:0DB8:0001:/48 | ^
--------------------------------------
Internal Prefix = FD01:0203:0405:/48
Figure 2: Flow of Information in Translation
图2：翻译中的信息流
In some cases, more than one NPTv6 Translator may be attached to a network, as shown in Figure 3. In such cases, NPTv6 Translators are configured with the same internal and external prefixes. Since there is only one translation, even though there are multiple translators, they map only one external address (prefix and Interface Identifier (IID)) to the internal address.
在某些情况下，可能会将多个NPTv6翻译程序连接到网络，如图3所示。在这种情况下，NPTv6转换器配置了相同的内部和外部前缀。由于只有一个转换，即使有多个转换器，它们也只将一个外部地址（前缀和接口标识符（IID））映射到内部地址。
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 3: Parallel Translators
图3：平行翻译
External Network #1: External Network #2:
Prefix = 2001:0DB8:0001:/48 Prefix = 2001:0DB8:5555:/48
--------------------------- --------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
External Network #1: External Network #2:
Prefix = 2001:0DB8:0001:/48 Prefix = 2001:0DB8:5555:/48
--------------------------- --------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 4: Parallel Translators with Different Upstream Networks
图4：具有不同上游网络的并行转换器
When multihoming, NPTv6 Translators are attached to an internal network, as shown in Figure 4, but are connected to different external networks. In such cases, NPTv6 Translators are configured with the same internal prefix but different external prefixes. Since
当多宿主时，NPTv6翻译器连接到内部网络，如图4所示，但连接到不同的外部网络。在这种情况下，NPTv6转换器配置为相同的内部前缀，但不同的外部前缀。自从
there are multiple translations, they map multiple external addresses (prefix and IID) to the common internal address. A system within the edge network is unable to determine which external address it is using apart from services such as Session Traversal Utilities for NAT (STUN) [RFC5389].
有多个转换，它们将多个外部地址（前缀和IID）映射到公共内部地址。边缘网络内的系统无法确定除了NAT（STUN）的会话遍历实用程序等服务之外，它正在使用哪个外部地址[RFC5389]。
Multihoming in this sense has one negative feature as compared with multihoming with a provider-independent address: when routes change between NPTv6 Translators, the translated prefix can change since the upstream network changes. This causes sessions and referrals dependent on it to fail as well. This is not expected to be a major issue, however, in networks where routing is generally stable.
从这个意义上讲，与具有独立于提供商地址的多主相比，多主具有一个负面特征：当NPTv6转换器之间的路由发生变化时，由于上游网络发生变化，翻译后的前缀可能会发生变化。这也会导致依赖它的会话和转介失败。然而，在路由通常是稳定的网络中，这并不是一个主要问题。
When NPTv6 is used as described in this document, no per-node or per-flow state is maintained in the NPTv6 Translator. Both inbound and outbound datagrams are translated algorithmically, using only information found in the IPv6 header. Due to this property, NPTv6's two-way, algorithmic address mapping can support both outbound and inbound connection establishment without the need for maintenance of mapping state or for state-priming or rendezvous mechanisms. This is a significant improvement over NAPT44 devices, but it also has significant security implications, which are described in Section 7.
如本文件所述使用NPTv6时，NPTv6转换器中不维护每节点或每流状态。入站和出站数据报都通过算法进行转换，只使用IPv6报头中的信息。由于这一特性，NPTv6的双向算法地址映射可以支持出站和入站连接的建立，而无需维护映射状态或状态启动或集合机制。这是对NAPT44设备的重大改进，但也有重大的安全影响，如第7节所述。
When a change is made to one of the IP header fields in the IPv6 pseudo-header checksum (such as one of the IP addresses), the checksum field in the transport layer header may become invalid. Fortunately, an incremental change in the area covered by the Internet standard checksum [RFC1071] will result in a well-defined change to the checksum value [RFC1624]. So, a checksum change caused by modifying part of the area covered by the checksum can be corrected by making a complementary change to a different 16-bit field covered by the same checksum.
当对IPv6伪报头校验和中的一个IP报头字段（例如其中一个IP地址）进行更改时，传输层报头中的校验和字段可能会变得无效。幸运的是，互联网标准校验和[RFC1071]所覆盖区域的增量更改将导致校验和值[RFC1624]的明确更改。因此，通过对相同校验和覆盖的不同16位字段进行补充更改，可以校正由修改校验和覆盖的部分区域引起的校验和更改。
The NPTv6 mapping mechanisms described in this document are checksum-neutral, which means that they result in IP headers that will generate the same IPv6 pseudo-header checksum when the checksum is calculated using the standard Internet checksum algorithm [RFC1071]. Any changes that are made during translation of the IPv6 prefix are offset by changes to other parts of the IPv6 address. This results in transport layers that use the Internet checksum (such as TCP and UDP) calculating the same IPv6 pseudo-header checksum for both the internal and external forms of the same datagram, which avoids the need for the NPTv6 Translator to modify those transport layer headers to correct the checksum value.
本文档中描述的NPTv6映射机制与校验和无关，这意味着它们产生的IP报头将在使用标准Internet校验和算法计算校验和时生成相同的IPv6伪报头校验和[RFC1071]。在转换IPv6前缀期间所做的任何更改都会被IPv6地址其他部分的更改所抵消。这导致使用Internet校验和（如TCP和UDP）的传输层为同一数据报的内部和外部形式计算相同的IPv6伪报头校验和，从而避免NPTv6转换器需要修改这些传输层报头以更正校验和值。
The outgoing checksum correction is achieved by making a change to a 16-bit section of the source address that is not used for routing in the external network. Due to the nature of checksum arithmetic, when the corresponding correction is applied to the same bits of destination address of the inbound packet, the Destination Address (DA) is returned to the correct internal value.
通过更改源地址中不用于外部网络路由的16位部分来实现传出校验和校正。由于校验和算法的性质，当对入站分组的目的地地址的相同位应用相应的校正时，目的地地址（DA）返回到正确的内部值。
As noted in Section 4.2, this mapping results in an edge network using a /48 external prefix to be unable to use subnet 0xFFFF.
如第4.2节所述，此映射导致使用/48外部前缀的边缘网络无法使用子网0xFFFF。
The [RFC4291] IPv6 Address is reproduced for clarity in Figure 5.
为了清晰起见，图5再现了[RFC4291]IPv6地址。
0 15 16 31 32 47 48 63 64 79 80 95 96 111 112 127
+-------+-------+-------+-------+-------+-------+-------+-------+
| Routing Prefix | Subnet| Interface Identifier (IID) |
+-------+-------+-------+-------+-------+-------+-------+-------+
0 15 16 31 32 47 48 63 64 79 80 95 96 111 112 127
+-------+-------+-------+-------+-------+-------+-------+-------+
| Routing Prefix | Subnet| Interface Identifier (IID) |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 5: Enumeration of the IPv6 Address [RFC4291]
图5:IPv6地址的枚举[RFC4291]
When an NPTv6 Translation function is configured, it is configured with
配置NPTv6翻译功能时，它配置为
o one or more "internal" interfaces with their "internal" routing domain prefixes, and
o 一个或多个“内部”接口及其“内部”路由域前缀，以及
o one or more "external" interfaces with their "external" routing domain prefixes.
o 一个或多个“外部”接口及其“外部”路由域前缀。
In the simple case, there is one of each. If a single router provides NPTv6 translation services between a multiplicity of domains (as might be true when multihoming), each internal/external pair must be thought of as a separate NPTv6 Translator from the perspective of this specification.
在简单的情况下，每种方法各有一种。如果一个路由器在多个域之间提供NPTv6翻译服务（多主时可能是这样），则从本规范的角度来看，每个内部/外部对必须被视为一个单独的NPTv6转换器。
When an NPTv6 Translator is configured, the translation function first ensures that the internal and external prefixes are the same length, extending the shorter of the two with zeroes if necessary. These two prefixes will be used in the prefix translation function described in Sections 3.2 and 3.3.
配置NPTv6转换器时，翻译功能首先确保内部和外部前缀长度相同，必要时用零扩展两者中较短的前缀。这两个前缀将用于第3.2节和第3.3节所述的前缀转换功能。
They are then zero-extended to /64 for the purposes of a calculation. The translation function calculates the one's complement sum of the 16-bit words of the /64 external prefix and the /64 internal prefix. It then calculates the difference between these values: internal
然后，为了计算的目的，它们被零扩展到/64。转换函数计算/64外部前缀和/64内部前缀的16位字的补和。然后计算这些值之间的差值：内部
minus external. This value, called the "adjustment", is effectively constant for the lifetime of the NPTv6 Translator configuration and is used in per-datagram processing.
减去外部。该值称为“调整”，在NPTv6转换器配置的生命周期内有效保持不变，并用于每个数据报处理。
When a datagram passes through the NPTv6 Translator from an internal to an external network, its IPv6 Source Address is either changed in two ways or results in the datagram being discarded:
当数据报通过NPTv6转换器从内部网络传输到外部网络时，其IPv6源地址会以两种方式更改，或导致数据报被丢弃：
o If the internal subnet number has no mapping, such as being 0xFFFF or simply not mapped, discard the datagram. This SHOULD result in an ICMP Destination Unreachable.
o 如果内部子网号没有映射，例如0xFFFF或根本没有映射，则丢弃数据报。这将导致无法访问ICMP目标。
o The internal prefix is overwritten with the external prefix, in effect subtracting the difference between the two checksums (the adjustment) from the pseudo-header's checksum, and
o 内部前缀被外部前缀覆盖，实际上从伪标头的校验和中减去两个校验和之间的差（调整），以及
o A 16-bit word of the address has the adjustment added to it using one's complement arithmetic. If the result is 0xFFFF, it is overwritten as zero. The choice of word is as specified in Sections 3.4 or 3.5 as appropriate.
o 地址的16位字使用补码算法进行调整。如果结果为0xFFFF，则将其覆盖为零。词语的选择如第3.4节或第3.5节所述（视情况而定）。
When a datagram passes through the NPTv6 Translator from an external to an internal network, its IPv6 Destination Address is changed in two ways:
当数据报通过NPTv6转换器从外部网络传输到内部网络时，其IPv6目标地址将以两种方式更改：
o The external prefix is overwritten with the internal prefix, in effect adding the difference between the two checksums (the adjustment) to the pseudo-header's checksum, and
o 外部前缀被内部前缀覆盖，实际上将两个校验和之间的差异（调整）添加到伪标头的校验和中，以及
o A 16-bit word of the address has the adjustment subtracted from it (bitwise inverted and added to it) using one's complement arithmetic. If the result is 0xFFFF, it is overwritten as zero. The choice of word is as specified in Section 3.4 or Section 3.5 as appropriate.
o 地址的16位字使用补码算法从中减去调整值（按位反转并添加到它）。如果结果为0xFFFF，则将其覆盖为零。词语的选择如第3.4节或第3.5节所述（视情况而定）。
When an NPTv6 Translator is configured with internal and external prefixes that are 48 bits in length (a /48) or shorter, the adjustment MUST be added to or subtracted from bits 48..63 of the address.
当NPTv6转换器配置有长度为48位（a/48）或更短的内部和外部前缀时，必须在地址的48..63位上加上或减去调整。
This mapping results in no modification of the Interface Identifier (IID), which is held in the lower half of the IPv6 address, so it will not interfere with future protocols that may use unique IIDs for node identification.
此映射不会修改保存在IPv6地址下半部分的接口标识符（IID），因此不会干扰可能使用唯一IID进行节点标识的未来协议。
NPTv6 Translator implementations MUST implement the /48 mapping.
NPTv6转换器实现必须实现/48映射。
When an NPTv6 Translator is configured with internal and external prefixes that are longer than 48 bits in length (such as a /52, /56, or /60), the adjustment must be added to or subtracted from one of the words in bits 64..79, 80..95, 96..111, or 112..127 of the address. While the choice of word is immaterial as long as it is consistent, these words MUST be inspected in that sequence and the first that is not initially 0xFFFF chosen, for consistency's sake.
当NPTv6转换器配置有长度超过48位的内部和外部前缀（如a/52、/56或/60）时，必须在地址的位64..79、80..95、96..111或112..127中的一个字上加上或减去调整。虽然单词的选择只要一致就无关紧要，但为了一致性起见，必须按顺序检查这些单词，并检查最初未选择的第一个单词0xFFFF。
NPTv6 Translator implementations SHOULD implement the mapping for longer prefixes.
NPTv6转换器实现应该实现较长前缀的映射。
For the network shown in Figure 1, the Internal Prefix is FD01:0203: 0405:/48, and the External Prefix is 2001:0DB8:0001:/48.
对于图1所示的网络，内部前缀为FD01:0203:0405:/48，外部前缀为2001:0DB8:0001:/48。
If a node with internal address FD01:0203:0405:0001::1234 sends an outbound datagram through the NPTv6 Translator, the resulting external address will be 2001:0DB8:0001:D550::1234. The resulting address is obtained by calculating the checksum of both the internal and external 48-bit prefixes, subtracting the internal prefix from the external prefix using one's complement arithmetic to calculate the "adjustment", and adding the adjustment to the 16-bit subnet field (in this case, 0x0001).
如果具有内部地址FD01:0203:0405:0001:：1234的节点通过NPTv6转换器发送出站数据报，则生成的外部地址将为2001:0DB8:0001:D550:：1234。通过计算内部和外部48位前缀的校验和，使用补码算法从外部前缀中减去内部前缀以计算“调整”，并将调整添加到16位子网字段（在本例中为0x0001），可以获得结果地址。
To show the work:
展示作品：
The one's complement checksum of FD01:0203:0405 is 0xFCF5. The one's complement checksum of 2001:0DB8:0001 is 0xD245. Using one's complement arithmetic, 0xD245 - 0xFCF5 = 0xD54F. The subnet in the original datagram is 0x0001. Using one's complement arithmetic, 0x0001 + 0xD54F = 0xD550. Since 0xD550 != 0xFFFF, it is not changed to 0x0000.
FD01:0203:0405的1的补码校验和为0xFCF5。2001:0DB8:0001的1的补码校验和为0xD245。使用补码运算，0xD245-0xFCF5=0xD54F。原始数据报中的子网为0x0001。使用补码算法，0x0001+0xD54F=0xD550。自0xD550！=0xFFFF，未更改为0x0000。
So, the value 0xD550 is written in the 16-bit subnet area, resulting in a mapped external address of 2001:0DB8:0001:D550::1234.
因此，将值0xD550写入16位子网区域，从而生成映射的外部地址2001:0DB8:0001:D550:：1234。
When a response datagram is received, it will contain the destination address 2001:0DB8:0001:D550::0001, which will be mapped back to FD01: 0203:0405:0001::1234 using the inverse mapping algorithm.
当接收到响应数据报时，它将包含目标地址2001:0DB8:0001:D550:：0001，该地址将使用反向映射算法映射回FD01:0203:0405:0001:：1234。
In this case, the difference between the two prefixes will be calculated as follows:
在这种情况下，两个前缀之间的差异将按如下方式计算：
Using one's complement arithmetic, 0xFCF5 - 0xD245 = 0x2AB0. The subnet in the original datagram = 0xD550. Using one's complement arithmetic, 0xD550 + 0x2AB0 = 0x0001. Since 0x0001 != 0xFFFF, it is not changed to 0x0000.
使用补码运算，0xFCF5-0xD245=0x2AB0。原始数据报中的子网=0xD550。使用补码运算，0xD550+0x2AB0=0x0001。自0x0001！=0xFFFF，未更改为0x0000。
So the value 0x0001 is written into the subnet field, and the internal value of the subnet field is properly restored.
因此，将值0x0001写入子网字段，并正确恢复子网字段的内部值。
If the prefix being mapped is longer than 48 bits, the algorithm is slightly more complex. A common case will be that the internal and external prefixes are of different lengths. In such a case, the shorter prefix is zero-extended to the length of the longer as described in Section 3.1 for the purposes of overwriting the prefix. Then, they are both zero-extended to 64 bits to facilitate one's complement arithmetic. The "adjustment" is calculated using those 64-bit prefixes.
如果映射的前缀长度超过48位，则算法稍微复杂一些。通常情况下，内部和外部前缀的长度不同。在这种情况下，如第3.1节所述，为了覆盖前缀，较短的前缀被零扩展到较长前缀的长度。然后，它们都被零扩展到64位，以便于进行补码运算。“调整”是使用这些64位前缀计算的。
For example, if the internal prefix is a /48 ULA and the external prefix is a /56 provider-allocated prefix, the ULA becomes a /56 with zeros in bits 48..55. For purposes of one's complement arithmetic, they are then both zero-extended to 64 bits. A side effect of this is that a subset of the subnets possible in the shorter prefix is untranslatable. While the security value of this is debatable, the administration may choose to use them for subnets that it knows need no external accessibility.
例如，如果内部前缀是/48 ULA，而外部前缀是/56提供者分配的前缀，则ULA变为位48..55中有零的/56。为了进行补码运算，它们都被零扩展到64位。这样做的一个副作用是，较短前缀中可能存在的子网子集是不可翻译的。虽然这种方法的安全性值得商榷，但政府可能会选择将其用于它知道不需要外部访问的子网。
We then find the first word in the IID that does not have the value 0xFFFF, trying bits 64..79, and then 80..95, 96..111, and finally 112..127. We perform the same calculation (with the same proof of correctness) as in Section 3.6 but apply it to that word.
然后我们在IID中找到第一个没有0xFFFF值的字，尝试位64..79，然后是80..95、96..111，最后是112..127。我们执行与第3.6节相同的计算（具有相同的正确性证明），但将其应用于该词。
Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an IID of all-ones is a reserved anycast identifier that should not be used on the network [RFC2526]. If an NPTv6 Translator discovers a datagram with an IID of all-zeros while performing address mapping, that datagram MUST be dropped, and an ICMPv6 Parameter Problem error SHOULD be generated [RFC4443].
尽管IPv6 IID的任何16位部分都可能包含0xFFFF，但所有IID都是保留的选播标识符，不应在网络上使用[RFC2526]。如果NPTv6转换器在执行地址映射时发现IID为全零的数据报，则必须删除该数据报，并生成ICMPv6参数问题错误[RFC4443]。
Note: This mechanism does involve modification of the IID; it may not be compatible with future mechanisms that use unique IIDs for node identification.
注：该机制不涉及IID的修改；它可能与使用唯一IID进行节点标识的未来机制不兼容。
NPTv6 Translators MUST support manual configuration of internal and external prefixes and MUST NOT place any restrictions on those prefixes except that they be valid IPv6 unicast prefixes as described in [RFC4291]. They MAY also support random generation of ULA addresses on command. Since the most common place anticipated for the implementation of an NPTv6 Translator is a Customer Premises Equipment (CPE) router, the reader is urged to consider the requirements of [RFC6204].
NPTv6转换器必须支持内部和外部前缀的手动配置，并且不得对这些前缀施加任何限制，除非它们是[RFC4291]中所述的有效IPv6单播前缀。它们还支持根据命令随机生成ULA地址。由于预期NPTv6翻译器的最常见的地方是客户驻地设备（CPE）路由器，因此敦促读者考虑[RCF6204]的要求。
For reasons detailed in Appendix B, a network using NPTv6 Translation and a /48 external prefix MUST NOT use the value 0xFFFF to designate a subnet that it expects to be translated.
出于附录B中详述的原因，使用NPTv6翻译和a/48外部前缀的网络不得使用值0xFFFF来指定其预期翻译的子网。
NPTv6 Translators MUST support hairpinning behavior, as defined in the NAT Behavioral Requirements for UDP document [RFC4787]. This means that when an NPTv6 Translator receives a datagram on the internal interface that has a destination address that matches the site's external prefix, it will translate the datagram and forward it internally. This allows internal nodes to reach other internal nodes using their external, global addresses when necessary.
NPTv6转换器必须支持发夹行为，如UDP文档[RFC4787]的NAT行为要求中所定义。这意味着，当NPTv6转换器在内部接口上接收到目标地址与站点外部前缀匹配的数据报时，它将转换数据报并在内部转发。这允许内部节点在必要时使用其外部全局地址到达其他内部节点。
Conceptually, the datagram leaves the domain (is translated as described in Section 3.2) and returns (is again translated as described in Section 3.3). As a result, the datagram exchange will be through the NPTv6 Translator in both directions for the lifetime of the session. The alternative would be to require the NPTv6 Translator to drop the datagram, forcing the sender to use the correct internal prefix for its peer. Performing only the external-to-internal translation results in the datagram being sent from the untranslated internal address of the source to the translated and therefore internal address of its peer, which would enable the session to bypass the NPTv6 Translator for future datagrams. It would also mean that the original sender would be unlikely to recognize the response when it arrived.
从概念上讲，数据报离开域（按照第3.2节所述进行翻译）并返回（再次按照第3.3节所述进行翻译）。因此，在会话的生命周期内，数据报交换将通过NPTv6转换器在两个方向上进行。另一种方法是要求NPTv6转换器删除数据报，迫使发送方为其对等方使用正确的内部前缀。仅执行外部到内部的转换将导致数据报从源的未翻译内部地址发送到对等方的已翻译内部地址，从而使会话能够绕过NPTv6转换器以获取未来的数据报。这也意味着原始发送者不太可能在响应到达时识别出响应。
Because NPTv6 does not perform port mapping and uses a one-to-one, reversible-mapping algorithm, none of the other NAT behavioral requirements apply to NPTv6.
因为NPTv6不执行端口映射，并且使用一对一的可逆映射算法，所以其他NAT行为要求都不适用于NPTv6。
NPTv6 Translation does not create several of the problems known to exist with other kinds of NATs as discussed in [RFC2993]. In particular, NPTv6 Translation is stateless, so a "reset" or brief outage of an NPTv6 Translator does not break connections that traverse the translation function, and if multiple NPTv6 Translators exist between the same two networks, the load can shift or be dynamically load shared among them. Also, an NPTv6 Translator does not aggregate traffic for several hosts/interfaces behind a fewer number of external addresses, so there is no inherent expectation for an NPTv6 Translator to block new inbound flows from external hosts and no issue with a filter or blacklist associated with one prefix within the domain affecting another. A firewall can, of course, be used in conjunction with an NPTv6 Translator; this would allow the network administrator more flexibility to specify security policy than would be possible with a traditional NAT.
NPTv6翻译不会产生[RFC2993]中讨论的其他类型NAT中已知存在的几个问题。特别是，NPTv6翻译是无状态的，因此NPTv6翻译的“重置”或短暂中断不会中断穿越翻译功能的连接，并且如果在相同的两个网络之间存在多个NPTv6翻译，负载可以在它们之间转移或动态共享。此外，NPTv6转换器不会在较少数量的外部地址后聚合多个主机/接口的通信量，因此NPTv6转换器不会固有地阻止来自外部主机的新入站流，也不会出现与域内一个前缀相关联的过滤器或黑名单影响另一个前缀的问题。当然，防火墙可以与NPTv6翻译器结合使用；这将允许网络管理员比传统NAT更灵活地指定安全策略。
However, NPTv6 Translation does create difficulties for some kinds of applications. Some examples include:
然而，NPTv6的翻译确实给某些应用带来了困难。一些例子包括：
o An application instance "behind" an NPTv6 Translator will see a different address for its connections than its peers "outside" the NPTv6 Translator.
o NPTv6翻译程序“后面”的应用程序实例将看到其连接地址与NPTv6翻译程序“外面”的对等程序不同。
o An application instance "outside" an NPTv6 Translator will see a different address for its connections than any peer "inside" an NPTv6 Translator.
o NPTv6转换器“外部”的应用程序实例将看到与NPTv6转换器“内部”的任何对等程序不同的连接地址。
o An application instance wishing to establish communication with a peer "behind" an NPTv6 Translator may need to use a different address to reach that peer depending on whether the instance is behind the same NPTv6 Translator or external to it. Since an NPTv6 Translator implements hairpinning (Section 4.3), it suffices for applications to always use their external addresses. However, this creates inefficiencies in the local network and may also complicate implementation of the NPTv6 Translator. [RFC3484] also would prefer the private address in such a case in order to reduce those inefficiencies.
o 希望与NPTv6转换器后面的对等方建立通信的应用程序实例可能需要使用不同的地址到达该对等方，这取决于实例是在同一NPTv6转换器后面还是在其外部。由于NPTv6转换器实现了发夹（第4.3节），因此应用程序始终使用其外部地址就足够了。然而，这在本地网络中造成了低效，也可能使NPTv6翻译器的实现复杂化。[RFC3484]在这种情况下，为了降低这些低效率，还希望使用专用地址。
o An application instance that moves from a realm "behind" an NPTv6 Translator to a realm that is "outside" the network, or vice versa, may find that it is no longer able to reach its peers at the same addresses it was previously able to use.
o 如果应用程序实例从NPTv6转换器“后面”的领域移动到网络“外部”的领域，或者从网络“外部”的领域移动到NPTv6转换器，则应用程序实例可能会发现，它不再能够到达其先前能够使用的相同地址的对等方。
o An application instance that is intermittently communicating with a peer that moves from behind an NPTv6 Translator to "outside" of it, or vice versa, may find that it is no longer able to reach that peer at the same address that it had previously used.
o 如果应用程序实例与从NPTv6转换器后面移动到NPTv6转换器“外部”的对等方进行间歇性通信，或者与NPTv6转换器“外部”移动到NPTv6转换器“外部”的对等方进行间歇性通信，则应用程序实例可能会发现，它不再能够以以前使用的相同地址到达该对等方。
Many, but not all, of the applications that are adversely affected by NPTv6 Translation are those that do "referrals" -- where an application instance passes its own addresses, and/or addresses of its peers, to other peers. (Some believe referrals are inherently undesirable; others believe that they are necessary in some circumstances. A discussion of the merits of referrals, or lack thereof, is beyond the scope of this document.)
许多（但不是所有）受到NPTv6翻译负面影响的应用程序都是进行“引用”的应用程序，即应用程序实例将自己的地址和/或其对等方的地址传递给其他对等方。（一些人认为转介本质上是不可取的；另一些人认为在某些情况下转介是必要的。关于转介优点或缺乏转介优点的讨论超出了本文件的范围。）
To some extent, the incidence of these difficulties can be reduced by DNS hacks that attempt to expose addresses "behind" an NPTv6 Translator only to hosts that are also behind the same NPTv6 Translator and perhaps to also expose only the "internal" addresses of hosts behind the NPTv6 Translator to other hosts behind the same NPTv6 Translator. However, this cannot be a complete solution. A full discussion of these issues is out of scope for this document, but briefly: (a) reliance on DNS to solve this problem depends on hosts always making queries from DNS servers in the same realm as they are (or on DNS interception proxies, which create their own problems) and on mobile hosts/applications not caching those results; (b) reliance on DNS to solve this problem depends on network administrators on all networks using such applications to reliably and accurately maintain current DNS entries for every host using those applications; and (c) reliance on DNS to solve this problem depends on applications always using DNS names, even though they often must run in environments where DNS names are not reliably maintained for every host. Other issues are that there is often no single distinguished name for a host and no reliable way for a host to determine what DNS names are associated with it and which names are appropriate to use in which contexts.
在某种程度上，DNS黑客可以降低这些困难的发生率，DNS黑客试图将NPTv6转换器“后面”的地址仅公开给同样位于同一NPTv6转换器后面的主机，也可能仅将NPTv6转换器后面的主机的“内部”地址公开给同样位于NPTv6转换器后面的其他主机。然而，这不是一个完整的解决方案。对这些问题的全面讨论超出了本文档的范围，但简单地说：（A）依靠DNS来解决此问题取决于主机始终从同一领域内的DNS服务器进行查询（或DNS拦截代理，这会造成它们自己的问题）以及不缓存这些结果的移动主机/应用程序；（b） 依靠DNS解决此问题取决于使用此类应用程序的所有网络上的网络管理员，以可靠和准确地维护使用这些应用程序的每个主机的当前DNS条目；（c）依赖DNS解决此问题取决于应用程序始终使用DNS名称，即使它们通常必须在DNS名称不能可靠地为每个主机维护的环境中运行。其他问题是，主机通常没有单一的可分辨名称，主机也没有可靠的方法来确定哪些DNS名称与之关联，以及哪些名称适合在哪些上下文中使用。
5.1. Recommendation for Network Planners Considering Use of NPTv6 Translation
5.1. 网络规划者考虑使用NPTv6翻译的建议
In light of the above, network planners considering the use of NPTv6 translation should carefully consider the kinds of applications that they will need to run in the future and determine whether the address-stability and provider-independence benefits are consistent with their application requirements.
鉴于上述情况，考虑使用NPTV6翻译的网络规划者应仔细考虑将来需要运行的应用程序的种类，并确定地址稳定性和提供者独立性的益处是否与它们的应用要求一致。
Several mechanisms (e.g., STUN [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245]) have been used with traditional IPv4 NAT to circumvent some of the limitations of such devices. Similar mechanisms could also be applied to circumvent some of the issues with an NPTv6 Translator. However, all of these require the assistance of an external server or a function co-located with the translator that can tell an "internal" host what its "external" addresses are.
传统IPv4 NAT使用了几种机制（例如STUN[RFC5389]、使用NAT周围的中继进行遍历（TURN）[RFC5766]和交互式连接建立（ICE）[RFC5245]），以规避此类设备的一些限制。类似的机制也可以用来规避NPTv6翻译的一些问题。然而，所有这些都需要一个外部服务器的帮助，或者一个与转换器位于同一位置的功能，它可以告诉“内部”主机它的“外部”地址是什么。
It might be desirable to define a general mechanism that would allow hosts within a translation domain to determine their external addresses and/or request that inbound traffic be permitted. If such a mechanism were to be defined, it would ideally be general enough to also accommodate other types of NAT likely to be encountered by IPV6 applications, in particular IPv4/IPv6 Translation [RFC6144] [RFC6147] [RFC6145] [RFC6146] [RFC6052]. For this and other reasons, such a mechanism is beyond the scope of this document.
可能需要定义一种通用机制，允许翻译域中的主机确定其外部地址和/或请求允许入站流量。如果要定义这样一种机制，理想情况下，它将足够通用，以适应IPV6应用程序可能遇到的其他类型的NAT，特别是IPv4/IPV6转换[RFC6144][RFC6147][RFC6145][RFC6146][RFC6052]。由于这一原因和其他原因，这种机制超出了本文件的范围。
In addition to overwriting IP addresses when datagrams are forwarded, NAPT44 devices overwrite the source port number in outbound traffic and the destination port number in inbound traffic. This mechanism is called "port mapping".
除了在转发数据报时覆盖IP地址外，NAPT44设备还覆盖出站流量中的源端口号和入站流量中的目标端口号。这种机制称为“端口映射”。
The major benefit of port mapping is that it allows multiple computers to share a single IPv4 address. A large number of internal IPv4 addresses (typically from one of the [RFC1918] private address spaces) can be mapped into a single external, globally routable IPv4 address, with the local port number used to identify which internal node should receive each inbound datagram. This address-amplification feature is not generally foreseen as a necessity at this time.
端口映射的主要好处是它允许多台计算机共享一个IPv4地址。大量内部IPv4地址（通常来自[RFC1918]专用地址空间之一）可以映射到单个外部全局可路由IPv4地址，本地端口号用于标识哪个内部节点应接收每个入站数据报。目前通常不认为有必要使用此地址放大功能。
Since port mapping requires rewriting a portion of the transport layer header, it requires NAPT44 devices to be aware of all of the transport protocols that they forward, thus stifling the development of new and improved transport protocols and preventing the use of IPsec encryption. Modifying the transport layer header is incompatible with security mechanisms that encrypt the full IP payload and restricts the NAPT44 to forwarding transport layers that use weak checksum algorithms that are easily recalculated in routers.
由于端口映射需要重写传输层报头的一部分，因此需要NAPT44设备了解它们转发的所有传输协议，从而抑制新的和改进的传输协议的开发，并阻止使用IPsec加密。修改传输层标头与加密完整IP有效负载的安全机制不兼容，并将NAPT44限制为转发使用弱校验和算法的传输层，这些算法很容易在路由器中重新计算。
Since there is significant detriment caused by modifying transport layer headers and very little, if any, benefit to the use of port mapping in IPv6, NPTv6 Translators that comply with this specification MUST NOT perform port mapping.
由于修改传输层报头会造成重大损害，并且在IPv6中使用端口映射的好处很小（如果有的话），因此符合此规范的NPTv6转换器不得执行端口映射。
When NPTv6 is deployed using either of the two-way, algorithmic mappings defined in this document, it allows direct inbound connections to internal nodes. While this can be viewed as a benefit of NPTv6 versus NAPT44, it does open internal nodes to attacks that would be more difficult in a NAPT44 network. From a security standpoint, although this situation is not substantially worse than running IPv6 with no NAT, some enterprises may assume that an NPTv6 Translator will offer similar protection to a NAPT44 device.
当使用本文档中定义的任何一种双向算法映射部署NPTv6时，它允许到内部节点的直接入站连接。虽然这可以被视为NPTv6相对于NAPT44的优势，但它确实会使内部节点受到NAPT44网络中更为困难的攻击。从安全角度来看，尽管这种情况并不比在没有NAT的情况下运行IPv6严重，但一些企业可能会认为NPTv6转换器将为NAPT44设备提供类似的保护。
The port mapping mechanism in NAPT44 implementations requires that state be created in both directions. This has lead to an industry-wide perception that NAT functionality is the same as a stateful firewall. It is not. The translation function of the NAT only creates dynamic state in one direction and has no policy. For this reason, it is RECOMMENDED that NPTv6 Translators also implement firewall functionality such as described in [RFC6092], with appropriate configuration options including turning it on or off.
NAPT44实现中的端口映射机制要求在两个方向上创建状态。这导致业界普遍认为NAT功能与有状态防火墙相同。事实并非如此。NAT的转换功能只在一个方向上创建动态状态，没有策略。因此，建议NPTv6转换器也实现防火墙功能，如[RFC6092]中所述，并提供适当的配置选项，包括打开或关闭防火墙。
When [RFC4864] talks about randomizing the subnet identifier, the idea is to make it harder for worms to guess a valid subnet identifier at an advertised network prefix. This should not be interpreted as endorsing concealment of the subnet identifier behind the obfuscating function of a translator such as NPTv6. [RFC4864] specifically talks about how to obtain the desired properties of concealment without using a translator. Topology hiding when using NAT is often ineffective in environments where the topology is visible in application layer messaging protocols such as DNS, SIP, SMTP, etc. If the information were not available through the application layer, [RFC2993] would not be valid.
当[RFC4864]谈到随机化子网标识符时，其想法是让蠕虫更难猜测广告网络前缀处的有效子网标识符。这不应解释为支持在翻译程序（如NPTv6）的模糊功能后面隐藏子网标识符。[RFC4864]专门讨论了如何在不使用翻译器的情况下获得所需的隐藏特性。在应用层消息传递协议（如DNS、SIP、SMTP等）中拓扑可见的环境中，使用NAT时拓扑隐藏通常无效。如果信息无法通过应用层获得，[RFC2993]将无效。
Due to the potential interactions with IKEv2/IPsec NAT traversal, it would be valuable to test interactions of NPTv6 with various aspects of current-day IKEv2/IPsec NAT traversal.
由于与IKEv2/IPsec NAT遍历的潜在交互，测试NPTv6与当前IKEv2/IPsec NAT遍历的各个方面的交互将是有价值的。
The checksum-neutral algorithmic address mapping described in this document is based on email written by Iljtsch van Beijnum.
本文中描述的校验和中性算法地址映射基于Iljtsch van Beijnum编写的电子邮件。
The following people provided advice or review comments that substantially improved this document: Allison Mankin, Christian Huitema, Dave Thaler, Ed Jankiewicz, Eric Kline, Iljtsch van Beijnum, Jari Arkko, Keith Moore, Mark Townsley, Merike Kaeo, Ralph Droms, Remi Despres, Steve Blake, and Tony Hain.
以下人员提供了实质性改进本文件的建议或评论：埃里森·曼金、克里斯蒂安·惠特马、戴夫·泰勒、埃德·詹基维茨、埃里克·克莱恩、伊尔杰奇·范·贝伊纳姆、贾里·阿尔科、基思·摩尔、马克·汤斯利、梅里克·卡奥、拉尔夫·德罗姆斯、雷米·德斯普雷斯、史蒂夫·布莱克和托尼·海因。
[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月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526]Johnson，D.和S.Deering，“保留的IPv6子网选播地址”，RFC 25261999年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[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月。
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, February 1997.
[GSE]O'Dell，M.，“GSE-IPv6的替代寻址体系结构”，正在进行的工作，1997年2月。
[NIST] NIST, "Draft NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0", September 2009.
[NIST]NIST，“NIST智能电网互操作性标准框架和路线图草案，1.0版”，2009年9月。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]Braden，R.，Borman，D.，Partridge，C.，和W.Plummer，“计算互联网校验和”，RFC 10711988年9月。
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994.
[RFC1624]Rijsinghani，A.，“通过增量更新计算互联网校验和”，RFC1624，1994年5月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[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月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[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月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，2010年4月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902]Thaler，D.，Zhang，L.，和G.Lebovitz，“IAB对IPv6网络地址转换的思考”，RFC 59022010年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925]Touch，J.，Mankin，A.，和R.Bonica，“TCP认证选项”，RFC 59252010年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，2011年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144]Baker，F.，Li，X.，Bao，C.，和K.Yin，“IPv4/IPv6转换框架”，RFC 61442011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 61472011年4月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204]Singh，H.，Beebee，W.，Donley，C.，Stark，B.，和O.Troan，“IPv6客户边缘路由器的基本要求”，RFC 62042011年4月。
Appendix A. Why GSE?
附录A：为什么是GSE？
For the purpose of this discussion, let us oversimplify the Internet's structure by distinguishing between two broad classes of networks: transit and edge. A "transit network", in this context, is a network that provides connectivity services to other networks. Its Autonomous System (AS) number may show up in a non-final position in BGP AS paths, or in the case of mobile and residential broadband networks, it may offer network services to smaller networks that cannot justify RIR membership. An "edge network", in contrast, is any network that is not a transit network; it is the ultimate customer, and while it provides internal connectivity for its own use, it is a consumer of transit services in other respects. In terms of routing, a network in the transit domain generally needs some way to make choices about how it routes to other networks; an edge network is generally quite satisfied with a simple default route.
在本次讨论中，让我们通过区分两大类网络来过分简化互联网的结构：传输和边缘。在这种情况下，“公交网络”是指向其他网络提供连接服务的网络。其自治系统（AS）编号可能以路径的形式出现在BGP的非最终位置，或者在移动和住宅宽带网络的情况下，它可能向无法证明RIR成员资格的较小网络提供网络服务。相比之下，“边缘网络”是指任何不是公交网络的网络；它是最终客户，虽然它为自己的使用提供内部连接，但在其他方面它是公交服务的消费者。在路由方面，运输域中的网络通常需要某种方式来选择如何路由到其他网络；边缘网络通常对简单的默认路由非常满意。
The [GSE] proposal, and as a result this proposal (which is similar to GSE in most respects and inspired by it), responds directly to current concerns in the RIR communities. Edge networks are used to an environment in IPv4 in which their addressing is disjoint from that of their upstream transit networks; it is either provider independent, or a network prefix translator makes their external address distinct from their internal address, and they like the distinction. In IPv6, there is a mantra that edge network addresses should be derived from their upstream, and if they have multiple upstreams, edge networks are expected to design their networks to use all of those prefixes equivalently. They see this as unnecessary and unwanted operational complexity and, as a result, are pushing very hard in the RIR communities for provider-independent addressing.
[GSE]提案以及该提案（在大多数方面与GSE类似，并受其启发）直接回应了RIR社区当前的担忧。边缘网络用于IPv4中的环境，在该环境中，边缘网络的地址与其上游传输网络的地址不相交；它要么独立于提供商，要么由网络前缀转换器将其外部地址与内部地址区分开来，并且他们喜欢这种区别。在IPv6中，有一个口号是边缘网络地址应该从其上游派生，如果它们有多个上游，则边缘网络应将其网络设计为等效地使用所有这些前缀。他们认为这是不必要的和不必要的操作复杂性，因此，RIR社区正在大力推动独立于提供商的寻址。
Widespread use of provider-independent addressing has a natural and perhaps unavoidable side effect that is likely to be very expensive in the long term. With widespread PI addressing, the routing table will enumerate the networks at the edge of the transit domain, the edge networks, rather than enumerate the transit domain. Per the BGP Update Report of 17 December 2010, there are currently over 36,000 Autonomous Systems being advertised in BGP, of which over 15,000 advertise only one prefix. There are in the neighborhood of 5000 ASs that show up in a non-final position in AS paths, and perhaps another 5000 networks whose AS numbers are terminal in more than one AS path. In other words, we have prefixes for some 36,000 transit and edge networks in the route table now, many of which arguably need an Autonomous System number only for multihoming. The vast majority of networks (2/3) having the tools necessary to multihome are not
广泛使用独立于提供商的寻址有一个自然的、也许是不可避免的副作用，从长远来看，这种副作用可能非常昂贵。使用广泛的PI寻址，路由表将枚举传输域边缘的网络，即边缘网络，而不是枚举传输域。根据2010年12月17日的BGP更新报告，目前在BGP中有36000多个自治系统进行广告宣传，其中15000多个系统只宣传一个前缀。大约有5000个ASs出现在AS路径的非最终位置，可能还有5000个网络的AS编号在多个AS路径中是终端。换句话说，我们现在在路由表中有36000个公交和边缘网络的前缀，其中许多可能只需要一个自治系统号来实现多宿。拥有多家庭所需工具的绝大多数网络（2/3）都不是
visibly doing so and would be well served by any solution that gives them address independence without the overhead of RIR membership and BGP routing.
这样做是显而易见的，任何解决方案都可以很好地为他们提供地址独立性，而不需要RIR成员资格和BGP路由的开销。
Current growth estimates suggest that we could easily see that be on the order of 10,000,000 within fifteen years. Tens of thousands of entries in the route table are very survivable; while our protocols and computers will likely do quite well with tens of millions of routes, the heat produced and power consumed by those routers, and the inevitable impact on the cost of those routers, is not a good outcome. To avoid having a massive and unscalable route table, we need to find a way that is politically acceptable and returns us to enumerating the transit domain, not the edge.
目前的增长估计表明，我们可以很容易地看到，在15年内，这一数字将达到10000000左右。路由表中数以万计的条目是非常有生存能力的；虽然我们的协议和计算机很可能在数千万条路由上表现出色，但这些路由器产生的热量和消耗的电力，以及对这些路由器成本的不可避免影响，并不是一个好结果。为了避免有一个庞大且不可扩展的路由表，我们需要找到一种政治上可以接受的方法，让我们重新枚举传输域，而不是边缘。
There have been a number of proposals. As described, Shim6 moves the complexity to the edge, and the edge is rebelling. Geographic addressing in essence forces ISPs to "own" geographic territory from a routing perspective, as otherwise there is no clue in the address as to what network a datagram should be delivered to in order to reach it. Metropolitan Addressing can imply regulatory authority and, even if it is implemented using internet exchange consortia, visits a great deal of complexity on the transit networks that directly serve the edge. The one that is likely to be most acceptable is any proposal that enables an edge network to be operationally independent of its upstreams, with no obligation to renumber when it adds, drops, or changes ISPs, and with no additional burden placed either on the ISP or the edge network as a result. From an application perspective, an additional operational requirement in the words of the Roadmap for the Smart Grid [NIST] is that
有许多建议。如前所述，Shim6将复杂性移动到边缘，边缘正在反叛。地理寻址本质上迫使ISP从路由的角度“拥有”地理区域，否则地址中就没有数据报应该传送到哪个网络才能到达的线索。大都市寻址可能意味着监管机构，即使它是使用互联网交换联盟实施的，也会访问直接服务于边缘的公交网络上的大量复杂性。最可能被接受的方案是使边缘网络在运营上独立于其上游，在添加、删除或更改ISP时无需重新编号，并且不会因此给ISP或边缘网络带来额外负担的任何方案。从应用的角度来看，用智能电网路线图[NIST]的话来说，另一个操作要求是
"...the network should provide the capability to enable an application in a particular domain to communicate with an application in any other domain over the information network, with proper management control as to who and where applications can be inter-connected."
“……网络应提供使特定域中的应用程序能够通过信息网络与任何其他域中的应用程序进行通信的能力，并对应用程序可以相互连接的人和地点进行适当的管理控制。”
In other words, the structure of the network should allow for and enable appropriate access control, but the structure of the network should not inherently limit access.
换句话说，网络结构应允许并启用适当的访问控制，但网络结构不应固有地限制访问。
The GSE model, by statelessly translating the prefix between an edge network and its upstream transit network, accomplishes that with a minimum of fuss and bother. Stated in the simplest terms, it enables the edge network to behave as if it has a provider-independent prefix from a multihoming and renumbering perspective without the overhead of RIR membership or maintenance of BGP connectivity, and it enables
GSE模型通过在边缘网络和其上游公交网络之间无状态地转换前缀，以最小的麻烦和麻烦实现了这一点。用最简单的术语来说，它使边缘网络能够从多归属和重新编号的角度表现为具有独立于提供商的前缀，而无需RIR成员资格或维护BGP连接的开销，并且它能够
the transit networks to aggressively aggregate what are from their perspective provider-allocated customer prefixes, to maintain a rational-sized routing table.
公交网络积极聚合从其角度来看供应商分配的客户前缀，以维护合理大小的路由表。
This non-normative appendix is presented as a proof of concept; it is in no sense optimized. For example, one's complement arithmetic is implemented in portable subroutines, where operational implementations might use one's complement arithmetic instructions through a pragma; such implementations probably need to explicitly force 0xFFFF to 0x0000, as the instruction will not. The original purpose of the code was to verify whether or not it was necessary to suppress 0xFFFF by overwriting with zero and whether predicted issues with subnet numbering were real.
本非规范性附录作为概念证明；它绝对不是优化的。例如，一个人的补码算法在可移植子例程中实现，其中操作实现可能通过pragma使用一个人的补码算法指令；这种实现可能需要显式地将0xFFFF强制为0x0000，因为指令不会这样做。代码的最初目的是验证是否有必要通过零覆盖来抑制0xFFFF，以及子网编号的预测问题是否真实。
The point is to
重点是
o demonstrate that if one or the other representation of zero is not used in the word in which the checksum is updated, the program maps inner and outer addresses in a manner that is, mathematically, 1:1 and onto (each inner address maps to a unique outer address, and that outer address maps back to exactly the same inner address), and
o 证明如果校验和被更新的字中未使用零的一种或另一种表示形式，则程序以数学上1:1的方式映射内部地址和外部地址（每个内部地址映射到一个唯一的外部地址，而外部地址映射回完全相同的内部地址），以及
o give guidance on the suppression of 0xFFFF checksums.
o 提供有关抑制0xFFFF校验和的指导。
In short, in one's complement arithmetic, x-x=0 but will take the negative representation of zero. If 0xFFFF results are forced to the value 0x0000, as is recommended in [RFC1071], the word the checksum is adjusted in cannot be initially 0xFFFF, as on the return it will be forced to 0. If 0xFFFF results are not forced to the value 0x0000 as is recommended in [RFC1071], the word the checksum is adjusted in cannot be initially 0, as on the return it will be calculated as 0+(~0) = 0xFFFF. We chose to follow [RFC1071]'s recommendations, which implies a requirement to not use 0xFFFF as a subnet number in networks with a /48 external prefix.
简言之，在一个人的补码运算中，x-x=0，但将取零的负表示。如果按照[RFC1071]中的建议，将0xFFFF结果强制为值0x0000，则校验和调整所用的字最初不能为0xFFFF，因为在返回时它将被强制为0。如果未按照[RFC1071]中的建议将0xFFFF结果强制为0x0000，则校验和调整的单词最初不能为0，因为在返回时，它将被计算为0+（~0）=0xFFFF。我们选择遵循[RFC1071]的建议，这意味着要求在带有/48外部前缀的网络中不使用0xFFFF作为子网号。
/*
* Copyright (c) 2011 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
/*
* Copyright (c) 2011 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include "stdio.h"
#include "assert.h"
/*
* program to verify the NPTv6 algorithm
*
* argument:
* Perform negative zero suppression: boolean
*
* method:
* We specify an internal and an external prefix. The prefix
* length is presumed to be the common length of both and, for
* this, is a /48. We perform the three algorithms specified.
* The "datagram" address is in effect the source address
* internal->external and the destination address
* external->internal.
*/
unsigned short inner_init[] = {
0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short outer_init[] = {
0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};
unsigned short inner[8];
unsigned short datagram[8];
unsigned char checksum[65536] = {0};
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include "stdio.h"
#include "assert.h"
/*
* program to verify the NPTv6 algorithm
*
* argument:
* Perform negative zero suppression: boolean
*
* method:
* We specify an internal and an external prefix. The prefix
* length is presumed to be the common length of both and, for
* this, is a /48. We perform the three algorithms specified.
* The "datagram" address is in effect the source address
* internal->external and the destination address
* external->internal.
*/
unsigned short inner_init[] = {
0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short outer_init[] = {
0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};
unsigned short inner[8];
unsigned short datagram[8];
unsigned char checksum[65536] = {0};
unsigned short outer[8];
unsigned short adjustment;
unsigned short suppress;
/*
* One's complement sum.
* return number1 + number2
*/
unsigned short
add1(number1, number2)
unsigned short number1;
unsigned short number2;
{
unsigned int result;
unsigned short outer[8];
unsigned short adjustment;
unsigned short suppress;
/*
* One's complement sum.
* return number1 + number2
*/
unsigned short
add1(number1, number2)
unsigned short number1;
unsigned short number2;
{
unsigned int result;
result = number1;
result += number2;
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
result = number1;
result += number2;
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* One's complement difference
* return number1 - number2
*/
unsigned short
sub1(number1, number2)
unsigned short number1;
unsigned short number2;
{
return add1(number1, ~number2);
}
/*
* One's complement difference
* return number1 - number2
*/
unsigned short
sub1(number1, number2)
unsigned short number1;
unsigned short number2;
{
return add1(number1, ~number2);
}
/*
* return one's complement sum of an array of numbers
*/
unsigned short
sum1(numbers, count)
unsigned short *numbers;
int count;
{
/*
* return one's complement sum of an array of numbers
*/
unsigned short
sum1(numbers, count)
unsigned short *numbers;
int count;
{
unsigned int result;
无符号整数结果；
result = *numbers++;
while (--count > 0) {
result += *numbers++;
}
result = *numbers++;
while (--count > 0) {
result += *numbers++;
}
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* NPTv6 initialization: Section 3.1 assuming Section 3.4
*
* Create the /48, a source address in internal format, and a
* source address in external format. Calculate the adjustment
* if one /48 is overwritten with the other.
*/
void
nptv6_initialization(subnet)
unsigned short subnet;
{
int i;
unsigned short inner48;
unsigned short outer48;
/*
* NPTv6 initialization: Section 3.1 assuming Section 3.4
*
* Create the /48, a source address in internal format, and a
* source address in external format. Calculate the adjustment
* if one /48 is overwritten with the other.
*/
void
nptv6_initialization(subnet)
unsigned short subnet;
{
int i;
unsigned short inner48;
unsigned short outer48;
/* Initialize the internal and external prefixes. */
for (i = 0; i < 8; i++) {
inner[i] = inner_init[i];
outer[i] = outer_init[i];
}
inner[3] = subnet;
outer[3] = subnet;
/* Calculate the checksum adjustment. */
inner48 = sum1(inner, 3);
outer48 = sum1(outer, 3);
adjustment = sub1(inner48, outer48);
}
/* Initialize the internal and external prefixes. */
for (i = 0; i < 8; i++) {
inner[i] = inner_init[i];
outer[i] = outer_init[i];
}
inner[3] = subnet;
outer[3] = subnet;
/* Calculate the checksum adjustment. */
inner48 = sum1(inner, 3);
outer48 = sum1(outer, 3);
adjustment = sub1(inner48, outer48);
}
/*
/*
* NPTv6 datagram from edge to transit: Section 3.2 assuming
* Section 3.4
*
* Overwrite the prefix in the source address with the outer
* prefix and adjust the checksum.
*/
void
nptv6_inner_to_outer()
{
int i;
* NPTv6 datagram from edge to transit: Section 3.2 assuming
* Section 3.4
*
* Overwrite the prefix in the source address with the outer
* prefix and adjust the checksum.
*/
void
nptv6_inner_to_outer()
{
int i;
/* Let's get the source address into the datagram. */
for (i = 0; i < 8; i++) {
datagram[i] = inner[i];
}
/* Let's get the source address into the datagram. */
for (i = 0; i < 8; i++) {
datagram[i] = inner[i];
}
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = outer[i];
}
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = outer[i];
}
/* Adjust the checksum. */
datagram[3] = add1(datagram[3], adjustment);
}
/* Adjust the checksum. */
datagram[3] = add1(datagram[3], adjustment);
}
/*
* NPTv6 datagram from transit to edge: Section 3.3 assuming
* Section 3.4
*
* Overwrite the prefix in the destination address with the
* inner prefix and adjust the checksum.
*/
void
nptv6_outer_to_inner()
{
int i;
/*
* NPTv6 datagram from transit to edge: Section 3.3 assuming
* Section 3.4
*
* Overwrite the prefix in the destination address with the
* inner prefix and adjust the checksum.
*/
void
nptv6_outer_to_inner()
{
int i;
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = inner[i];
}
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = inner[i];
}
/* Adjust the checksum. */
datagram[3] = sub1(datagram[3], adjustment);
}
/* Adjust the checksum. */
datagram[3] = sub1(datagram[3], adjustment);
}
/*
* Main program
/*
* Main program
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned subnet;
int i;
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned subnet;
int i;
if (argc < 2) {
fprintf(stderr, "usage: nptv6 supression\n");
assert(0);
}
suppress = atoi(argv[1]);
assert(suppress <= 1);
if (argc < 2) {
fprintf(stderr, "usage: nptv6 supression\n");
assert(0);
}
suppress = atoi(argv[1]);
assert(suppress <= 1);
for (subnet = 0; subnet < 0x10000; subnet++) {
/* Section 3.1: initialize the system */
nptv6_initialization(subnet);
for (subnet = 0; subnet < 0x10000; subnet++) {
/* Section 3.1: initialize the system */
nptv6_initialization(subnet);
/* Section 3.2: take a datagram from inside to outside */
nptv6_inner_to_outer();
/* Section 3.2: take a datagram from inside to outside */
nptv6_inner_to_outer();
/* The resulting checksum value should be unique. */
if (checksum[subnet]) {
printf("inner->outer duplicated checksum: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8), datagram[0], datagram[1],
datagram[2], datagram[3], datagram[4],
datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
/* The resulting checksum value should be unique. */
if (checksum[subnet]) {
printf("inner->outer duplicated checksum: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8), datagram[0], datagram[1],
datagram[2], datagram[3], datagram[4],
datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
checksum[subnet] = 1;
校验和[子网]=1；
/*
* The resulting checksum should be the same as the inner
* address's checksum.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("inner->outer incorrect: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8),
/*
* The resulting checksum should be the same as the inner
* address's checksum.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("inner->outer incorrect: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8),
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
/* Section 3.3: take a datagram from outside to inside */
nptv6_outer_to_inner();
/* Section 3.3: take a datagram from outside to inside */
nptv6_outer_to_inner();
/*
* The returning datagram should have the same checksum it
* left with.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("outer->inner checksum incorrect: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8), inner[0], inner[1], inner[2],
inner[3], inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8));
}
/*
* The returning datagram should have the same checksum it
* left with.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("outer->inner checksum incorrect: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8), inner[0], inner[1], inner[2],
inner[3], inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8));
}
/*
* And every octet should calculate back to the same inner
* value.
*/
for (i = 0; i < 8; i++) {
if (inner[i] != datagram[i]) {
printf("outer->inner different: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x "
"inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
datagram[0], datagram[1], datagram[2],
datagram[3], datagram[4], datagram[5],
datagram[6], datagram[7], inner[0], inner[1],
inner[2], inner[3], inner[4], inner[5],
inner[6], inner[7]);
break;
}
}
}
}
/*
* And every octet should calculate back to the same inner
* value.
*/
for (i = 0; i < 8; i++) {
if (inner[i] != datagram[i]) {
printf("outer->inner different: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x "
"inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
datagram[0], datagram[1], datagram[2],
datagram[3], datagram[4], datagram[5],
datagram[6], datagram[7], inner[0], inner[1],
inner[2], inner[3], inner[4], inner[5],
inner[6], inner[7]);
break;
}
}
}
}
Authors' Addresses
作者地址
Margaret Wasserman Painless Security North Andover, MA 01845 USA
Margaret Wasserman无痛安全美国马萨诸塞州北安多佛市01845
Phone: +1 781 405 7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Phone: +1 781 405 7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
美国加利福尼亚州圣巴巴拉市弗雷德·贝克思科系统公司，邮编：93117
Phone: +1-408-526-4257
EMail: fred@cisco.com
Phone: +1-408-526-4257
EMail: fred@cisco.com