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
        
1. Introduction
1. 介绍

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。

1.1. What is Address Independence?
1.1. 什么是独立性?

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用于其内部网络的一部分或大部分,而不是使用其独立于提供商的地址空间。

1.2. NPTv6 Applicability
1.2. NPTv6适用性

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更少的问题。

1.3. Requirements Terminology
1.3. 需求术语

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]中所述进行解释。

2. NPTv6 Overview
2. NPTv6概述

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转换器。

2.1. NPTv6: The Simplest Case
2.1. 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转换器的“后方”。

2.2. NPTv6 between Peer Networks
2.2. 对等网络之间的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:翻译中的信息流

2.3. NPTv6 Redundancy and Load Sharing
2.3. NPTv6冗余和负载共享

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:平行翻译

2.4. NPTv6 Multihoming
2.4. NPTv6多归宿
            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转换器之间的路由发生变化时,由于上游网络发生变化,翻译后的前缀可能会发生变化。这也会导致依赖它的会话和转介失败。然而,在路由通常是稳定的网络中,这并不是一个主要问题。

2.5. Mapping with No Per-Flow State
2.5. 没有每个流状态的映射

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节所述。

2.6. Checksum-Neutral Mapping
2.6. 校验和中性映射

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。

3. NPTv6 Algorithmic Specification
3. NPTv6算法规范

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]

3.1. NPTv6 Configuration Calculations
3.1. NPTv6组态计算

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转换器配置的生命周期内有效保持不变,并用于每个数据报处理。

3.2. NPTv6 Translation, Internal Network to External Network
3.2. 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节所述(视情况而定)。

3.3. NPTv6 Translation, External Network to Internal Network
3.3. NPTv6翻译,外部网络到内部网络

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节所述(视情况而定)。

3.4. NPTv6 with a /48 or Shorter Prefix
3.4. 带有/48或更短前缀的NPTv6

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映射。

3.5. NPTv6 with a /49 or Longer Prefix
3.5. 带有/49或更长前缀的NPTv6

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转换器实现应该实现较长前缀的映射。

3.6. /48 Prefix Mapping Example
3.6. /48前缀映射示例

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写入子网字段,并正确恢复子网字段的内部值。

3.7. Address Mapping for Longer Prefixes
3.7. 较长前缀的地址映射

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进行节点标识的未来机制不兼容。

4. Implications of Network Address Translator Behavioral Requirements
4. 网络地址转换器行为要求的含义
4.1. Prefix Configuration and Generation
4.1. 前缀配置和生成

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]的要求。

4.2. Subnet Numbering
4.2. 子网编号

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来指定其预期翻译的子网。

4.3. NAT Behavioral Requirements
4.3. NAT行为要求

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。

5. Implications for Applications
5. 对申请的影响

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翻译的网络规划者应仔细考虑将来需要运行的应用程序的种类,并确定地址稳定性和提供者独立性的益处是否与它们的应用要求一致。

5.2. Recommendations for Application Writers
5.2. 对应用程序编写者的建议

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翻译的一些问题。然而,所有这些都需要一个外部服务器的帮助,或者一个与转换器位于同一位置的功能,它可以告诉“内部”主机它的“外部”地址是什么。

5.3. Recommendation for Future Work
5.3. 对今后工作的建议

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]。由于这一原因和其他原因,这种机制超出了本文件的范围。

6. A Note on Port Mapping
6. 关于端口映射的注记

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转换器不得执行端口映射。

7. Security Considerations
7. 安全考虑

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