Internet Engineering Task Force (IETF) R. Bush, Ed.
Request for Comments: 6346 Internet Initiative Japan
Category: Experimental August 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Bush, Ed.
Request for Comments: 6346 Internet Initiative Japan
Category: Experimental August 2011
ISSN: 2070-1721
The Address plus Port (A+P) Approach to the IPv4 Address Shortage
解决IPv4地址短缺的地址加端口（A+P）方法
Abstract
摘要
We are facing the exhaustion of the IANA IPv4 free IP address pool. Unfortunately, IPv6 is not yet deployed widely enough to fully replace IPv4, and it is unrealistic to expect that this is going to change before the depletion of IPv4 addresses. Letting hosts seamlessly communicate in an IPv4 world without assigning a unique globally routable IPv4 address to each of them is a challenging problem.
我们面临着IANA IPv4免费IP地址池的耗尽。不幸的是，IPv6还没有被广泛部署到足以完全取代IPv4的程度，而且期望在IPv4地址耗尽之前这种情况会发生变化是不现实的。让主机在IPv4世界中无缝通信而不为每个主机分配唯一的全局可路由IPv4地址是一个具有挑战性的问题。
This document proposes an IPv4 address sharing scheme, treating some of the port number bits as part of an extended IPv4 address (Address plus Port, or A+P). Instead of assigning a single IPv4 address to a single customer device, we propose to extend the address field by using bits from the port number range in the TCP/UDP header as additional endpoint identifiers, thus leaving a reduced range of ports available to applications. This means assigning the same IPv4 address to multiple clients (e.g., Customer Premises Equipment (CPE), mobile phones), each with its assigned port range. In the face of IPv4 address exhaustion, the need for addresses is stronger than the need to be able to address thousands of applications on a single host. If address translation is needed, the end-user should be in control of the translation process -- not some smart boxes in the core.
本文档提出了一种IPv4地址共享方案，将一些端口号位视为扩展IPv4地址（地址加端口，或A+P）的一部分。我们建议通过使用TCP/UDP报头中端口号范围中的位作为附加端点标识符来扩展地址字段，从而减少应用程序可用的端口范围，而不是将单个IPv4地址分配给单个客户设备。这意味着将相同的IPv4地址分配给多个客户端（例如，客户场所设备（CPE）、移动电话），每个客户端都有其分配的端口范围。在IPv4地址耗尽的情况下，对地址的需求比能够在单个主机上寻址数千个应用程序的需求更大。如果需要地址转换，最终用户应该控制转换过程——而不是核心中的一些智能盒。
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/rfc6346.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6346.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Constraints and Functions . . . . . . . . . . . . . . . 6
3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6
3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8
3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11
3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15
3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 16
3.4. A+P Experiments . . . . . . . . . . . . . . . . . . . . . 17
4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18
4.1. Stateless A+P Mapping (SMAP) Gateway Function
Description . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20
4.3. Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22
4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22
4.5. General Recommendations on SMAP . . . . . . . . . . . . . 23
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24
5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24
5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24
5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24
5.1.3. A+P from the Provider Network Perspective . . . . . . 25
5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27
5.3. Example of A+P-Forwarded Packets . . . . . . . . . . . . . 28
5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 32
5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 32
5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 33
5.3.4. Limitations of the A+P Approach . . . . . . . . . . . 33
5.3.5. Port Allocation Strategy Agnostic . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 35
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Design Constraints and Functions . . . . . . . . . . . . . . . 6
3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6
3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8
3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11
3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15
3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 16
3.4. A+P Experiments . . . . . . . . . . . . . . . . . . . . . 17
4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18
4.1. Stateless A+P Mapping (SMAP) Gateway Function
Description . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20
4.3. Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22
4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22
4.5. General Recommendations on SMAP . . . . . . . . . . . . . 23
5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24
5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24
5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24
5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24
5.1.3. A+P from the Provider Network Perspective . . . . . . 25
5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27
5.3. Example of A+P-Forwarded Packets . . . . . . . . . . . . . 28
5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 32
5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 32
5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 33
5.3.4. Limitations of the A+P Approach . . . . . . . . . . . 33
5.3.5. Port Allocation Strategy Agnostic . . . . . . . . . . 34
6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
8.2. Informative References . . . . . . . . . . . . . . . . . . 35
9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 37
This document describes a technique to deal with the imminent IPv4 address space exhaustion. Many large Internet Service Providers (ISPs) face the problem that their networks' customer edges are so large that it will soon not be possible to provide each customer with a unique public IPv4 address. Therefore, although undesirable, address sharing, in the same molds as NAT, is inevitable.
本文档描述了一种处理IPv4地址空间即将耗尽的技术。许多大型互联网服务提供商（ISP）面临的问题是，其网络的客户边缘太大，很快就不可能为每个客户提供唯一的公共IPv4地址。因此，尽管不受欢迎，但与NAT相同的模式中的地址共享是不可避免的。
To allow end-to-end connectivity between IPv4-speaking applications, we propose to extend the semantics of the IPv4 address with bits from the UDP/TCP header. Assuming we could limit the applications' port addressing to any number of bits lower than 16, we can increase the effective size of an IPv4 address by remaining additional bits of up to 16. In this scenario, 1 to 65536 customers could be multiplexed on the same IPv4 address, while allowing them a fixed or dynamic range of 1 to 65536 ports. Customers could, for example, receive an initial fixed port range, defined by the operator, and dynamically request additional blocks, depending on their contract. We call this "extended addressing" or "A+P" (Address plus Port) addressing. The main advantage of A+P is that it preserves the Internet "end-to-end" paradigm by not requiring translation (at least for some ports) of an IP address.
为了允许讲IPv4的应用程序之间的端到端连接，我们建议使用UDP/TCP报头中的位扩展IPv4地址的语义。假设我们可以将应用程序的端口寻址限制为低于16位的任意位数，那么我们可以通过剩余最多16位的额外位数来增加IPv4地址的有效大小。在这种情况下，1到65536个客户可以在相同的IPv4地址上进行多路复用，同时允许他们有1到65536个端口的固定或动态范围。例如，客户可以接收由运营商定义的初始固定端口范围，并根据其合同动态请求额外的数据块。我们称之为“扩展寻址”或“A+P”（地址加端口）寻址。A+P的主要优点是，它不需要翻译（至少对于某些端口而言）IP地址，从而保留了Internet“端到端”的模式。
Various forms of NATs will be installed at different levels and places in the IPv4 Internet to achieve address compression. This document argues for mechanisms where this happens as close to the edge of the network as possible, thereby minimizing damage to the End-to-End Principle and allowing end-customers to retain control over the address and port translation. Therefore, it is essential to create mechanisms to "bypass" NATs in the core, when applicable, and keep the control at the end-user.
将在IPv4互联网的不同级别和位置安装各种形式的NAT，以实现地址压缩。本文件提出了一种机制，使这种情况尽可能靠近网络边缘，从而最大限度地减少对端到端原则的损害，并允许最终客户保留对地址和端口转换的控制权。因此，在适用的情况下，必须在核心中创建“绕过”NAT的机制，并将控制权保留在最终用户手中。
With Carrier Grade NATs (CGNs) in the core of the network, the user is trapped behind unchangeable application policies, and the deployment of new applications is hindered by the need to implement the corresponding Application Level Gateways (ALGs) on the CGNs. This is the opposite of the "end-to-end" model of the Internet.
由于运营商级NAT（CGN）处于网络核心，用户被困在不可更改的应用程序策略后面，新应用程序的部署因需要在CGN上实现相应的应用程序级网关（ALG）而受阻。这与互联网的“端到端”模式相反。
With the smarts at the edges, one can easily deploy new applications between consenting endpoints by merely tweaking the NATs at the corresponding CPE, or even upgrading them to a new version that supports a specific ALG.
有了smarts，只需在相应的CPE调整NAT，甚至将其升级到支持特定ALG的新版本，就可以轻松地在同意的端点之间部署新的应用程序。
Today's NATs are typically mitigated by offering the customers limited control over them, e.g., port forwarding, Universal Plug and Play or the NAT Port Mapping Protocol (UPnP/NAT-PMP). However, this is not expected to work with CGNs. CGN proposals -- other than DS-Lite [RFC6333] with A+P or the Port Control Protocol (PCP) [PCP-BASE] -- admit that it is not expected that applications that require specific port assignment or port mapping from the NAT box will keep working.
今天的NAT通常通过向客户提供有限的控制来缓解，例如端口转发、通用即插即用或NAT端口映射协议（UPnP/NAT-PMP）。但是，这不适用于CGN。CGN提案——除了带有A+P或端口控制协议（PCP）[PCP-BASE]的DS Lite[RFC6333]之外——承认要求NAT箱中的特定端口分配或端口映射的应用程序不会继续工作。
Another issue with CGNs is the trade-off between session state and network placement. The farther from the edge the CGN is placed, the more session state needs to be kept due to larger subscriber aggregation and the more disruption that occurs in the case of a failure. In order to reduce the state, CGNs would end up somewhere closer to the edge. Thus, the CGN trades scalability for the amount of state that needs to be kept, which makes optimally placing a CGN a hard engineering problem.
CGNs的另一个问题是会话状态和网络布局之间的权衡。CGN距离边缘越远，需要保持的会话状态就越多，这是因为订户聚合越大，发生故障时发生的中断也越多。为了减少状态，CGN最终会靠近边缘。因此，CGN以可伸缩性换取需要保持的状态量，这使得最佳地放置CGN成为一个困难的工程问题。
In some deployment scenarios, a CGN can be seen as the single point of failure, and therefore the availability of delivered services can be impacted by a single CGN device. Means to ensure state synchronization and failover would be required to allow for service continuity whenever a failure occurs.
在某些部署场景中，CGN可被视为单点故障，因此交付服务的可用性可能会受到单个CGN设备的影响。需要确保状态同步和故障切换的方法，以便在发生故障时保持服务连续性。
Intra-domain paths may not be optimal for communications between two nodes connected to the same domain deploying CGNs; they may lead to path stretches.
对于连接到部署CGN的同一域的两个节点之间的通信，域内路径可能不是最优的；它们可能导致道路延伸。
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]中所述进行解释。
This document makes use of the following terms:
本文件使用了以下术语：
Public Realm: This realm contains only public routable IPv4 addresses. Packets in this realm are forwarded based on the destination IPv4 address.
公共领域：此领域仅包含公共可路由IPv4地址。此域中的数据包根据目标IPv4地址进行转发。
A+P Realm: This realm contains both public routable IPv4 and A+P addresses.
A+P域：此域包含公共可路由IPv4和A+P地址。
A+P Packet: A regular IPv4 packet is forwarded based on the destination IPv4 address and the TCP/UDP port numbers.
A+P数据包：根据目标IPv4地址和TCP/UDP端口号转发常规IPv4数据包。
Private Realm: This realm contains IPv4 addresses that are not globally routed. They may be taken from the [RFC1918] range. However, this document does not make such an assumption. We regard as private address space any IPv4 address that needs to be translated in order to gain global connectivity, irrespective of whether or not it falls in [RFC1918] space.
私有领域：此领域包含未全局路由的IPv4地址。它们可能来自[RFC1918]范围。然而，本文件并未做出这样的假设。我们将任何需要转换以获得全局连接的IPv4地址视为专用地址空间，无论其是否位于[RFC1918]空间。
Port-Range Router (PRR): A device that forwards A+P packets.
端口范围路由器（PRR）：转发A+P数据包的设备。
Customer Premises Equipment (CPE): cable or DSL modem.
客户场所设备（CPE）：电缆或DSL调制解调器。
Provider Edge (PE) Router: Customer aggregation router.
提供商边缘（PE）路由器：客户聚合路由器。
Provider Border Router (BR): Provider's edge to other providers.
提供者边界路由器（BR）：提供者到其他提供者的边界。
Network Core Routers (Core): Provider routers that are not at the edges.
网络核心路由器（Core）：不在边缘的提供商路由器。
The problem of address space shortage is first felt by providers with a very large end-user customer base, such as broadband providers and mobile service providers. Though the cases and requirements are slightly different, they share many commonalities. In the following text, we develop a set of overall design constraints for solutions addressing the IPv4 address shortage problem.
地址空间短缺的问题首先是由拥有大量最终用户客户群的提供商（如宽带提供商和移动服务提供商）感受到的。虽然案例和需求略有不同，但它们有许多共同点。在下面的文本中，我们为解决IPv4地址短缺问题的解决方案开发了一组总体设计约束。
We regard several constraints as important for our design:
我们认为几个约束对我们的设计很重要：
1) End-to-end is under customer control: Customers shall have the ability to deploy new application protocols at will. IPv4 address shortage should not be a license to break the Internet's end-to-end paradigm.
1) 端到端由客户控制：客户应能够随意部署新的应用程序协议。IPv4地址短缺不应成为打破互联网端到端模式的许可证。
2) Backward compatibility: Approaches should be transparent to unaware users. Devices or existing applications should be able to work without modification. Emergence of new applications should not be limited.
2) 向后兼容性：方法应该对不知情的用户透明。设备或现有应用程序应能够在不进行修改的情况下工作。新应用的出现不应受到限制。
3) Highly scalable and minimal state core: Minimal state should be kept inside the ISP's network. If the operator is rolling out A+P incrementally, it is understood there may be state in the core in the non-A+P part of such a roll-out.
3) 高度可扩展和最小状态核心：ISP网络中应保持最小状态。如果操作员以增量方式推出A+P，则可以理解，在此类推出的非A+P部分的核心中可能存在状态。
4) Efficiency versus complexity: Operators should have the flexibility to trade off port multiplexing efficiency and scalability and end-to-end transparency.
4) 效率与复杂性：运营商应该能够灵活地权衡端口复用效率、可扩展性和端到端透明度。
5) "Double-NAT" should be avoided: Multiple gateway devices might be present in a path, and once one has done some translation, those packets should not be retranslated.
5) 应该避免“双NAT”：一条路径中可能存在多个网关设备，一旦其中一个设备完成了一些转换，这些数据包就不应该被重新传输。
6) Legal traceability: ISPs must be able to provide the identity of a customer from the knowledge of the IPv4 public address and the port. This should have as low an impact as is reasonable on storage by the ISP. We assume that NATs on customer premises do not pose much of a problem, while provider NATs need to keep additional logs.
6) 法律可追溯性：ISP必须能够根据IPv4公共地址和端口提供客户身份。这对ISP存储的影响应尽可能小。我们假设客户场所的NAT不会造成太多问题，而提供商NAT需要保留额外的日志。
7) IPv6 deployment should be encouraged. NAT444 strongly biases the users to the deployment of RFC 1918 addressing.
7) 应鼓励部署IPv6。NAT444使用户强烈偏向于RFC1918寻址的部署。
Constraint 5 is important: while many techniques have been deployed to allow applications to work through a NAT, traversing cascaded NATs is crucial if NATs are being deployed in the core of a provider network.
约束5很重要：虽然已经部署了许多技术来允许应用程序通过NAT工作，但如果NAT部署在提供商网络的核心中，则遍历级联NAT是至关重要的。
The A+P architecture can be split into three distinct functions: encaps/decaps, NAT, and signaling.
A+P架构可以分为三个不同的功能：封装/解压缩、NAT和信令。
Encaps/decaps function: is used to forward port-restricted A+P packets over intermediate legacy devices. The encapsulation function takes an IPv4 packet, looks up the IP and TCP/UDP headers, and puts the packet into the appropriate tunnel. The state needed to perform this action is comparable to a forwarding table. The decapsulation device SHOULD check if the source address and port of packets coming out of the tunnel are legitimate (e.g., see [BCP38]). Based on the result of such a check, the packet MAY be forwarded untranslated, MAY be discarded, or MAY be NATed. In this document, we refer to a device that provides this encaps/decaps functionality as a Port-Range Router (PRR).
Encaps/decaps功能：用于通过中间遗留设备转发端口受限的A+P数据包。封装函数获取一个IPv4数据包，查找IP和TCP/UDP报头，并将数据包放入适当的隧道中。执行此操作所需的状态与转发表相当。解封设备应检查从隧道中出来的数据包的源地址和端口是否合法（例如，参见[BCP38]）。基于这种检查的结果，分组可以被转发而不被翻译，可以被丢弃，或者可以被丢弃。在本文档中，我们将提供这种封装/解压缩功能的设备称为端口范围路由器（PRR）。
Network Address Translation (NAT) function: is used to connect legacy end-hosts. Unless upgraded, end-hosts or end-systems are not aware of A+P restrictions and therefore assume a full IP address. The NAT function performs any address or port translation, including Application Level Gateways (ALGs) whenever required. The state that has to be kept to implement this function is the mapping for which external addresses and ports have been mapped to which internal addresses and ports, just as in CPEs embedding NAT today. A subtle,
网络地址转换（NAT）功能：用于连接传统终端主机。除非升级，否则终端主机或终端系统不知道A+P限制，因此采用完整IP地址。NAT功能执行任何地址或端口转换，包括在需要时执行应用程序级网关（ALG）。实现此功能必须保持的状态是外部地址和端口映射到内部地址和端口的映射，就像今天嵌入NAT的CPE一样。微妙的，
but very important, difference should be noted here: the customer has control over the NATing process or might choose to "bypass" the NAT. If this is done, we call the NAT a Large-Scale NAT (LSN). However, if the NAT does NOT allow the customer to control the translation process, we call it a CGN.
但非常重要的是，这里应该指出不同之处：客户可以控制NAT过程，也可以选择“绕过”NAT。如果这样做了，我们将NAT称为大规模NAT（LSN）。但是，如果NAT不允许客户控制翻译过程，我们称之为CGN。
Signaling function: is used to allow A+P-aware devices to get to know which ports are assigned to be passed through untranslated and what will happen to packets outside the assigned port range (e.g., could be NATed or discarded). Signaling may also be used to learn the encapsulation method and any endpoint information needed. In addition, the signaling function may be used to dynamically assign the requested port range.
信令功能：用于允许A+P感知设备了解哪些端口被分配通过未翻译的端口，以及分配端口范围外的数据包将发生什么情况（例如，可能被拒绝或丢弃）。信令还可用于学习封装方法和所需的任何端点信息。此外，信令功能可用于动态分配所请求的端口范围。
As mentioned above, the core architectural elements of the A+P solution are three separated and independent functions: the NAT function, the encaps/decaps function, and the signaling function. The NAT function is similar to a NAT as we know it today: it performs a translation between two different address realms. When the external realm is public IPv4 address space, we assume that the translation is many-to-one, in order to multiplex many customers on a single public IPv4 address. The only difference with a traditional NAT (Figure 1) is that the translator might only be able to use a restricted range of ports when mapping multiple internal addresses onto an external one, e.g., the external address realm might be port-restricted.
如上所述，A+P解决方案的核心架构元素是三个独立的功能：NAT功能、encaps/decaps功能和信令功能。NAT函数类似于我们今天所知道的NAT：它在两个不同的地址域之间执行转换。当外部领域是公共IPv4地址空间时，我们假设转换为多对一，以便在单个公共IPv4地址上多路传输多个客户。与传统NAT（图1）的唯一区别在于，当将多个内部地址映射到外部地址时，转换器可能只能使用有限范围的端口，例如，外部地址域可能是端口受限的。
"internal-side" "external-side"
+-----+
internal | N | external
address <---| A |---> address
realm | T | realm
+-----+
"internal-side" "external-side"
+-----+
internal | N | external
address <---| A |---> address
realm | T | realm
+-----+
Figure 1: Traditional NAT
图1：传统NAT
The encaps/decaps function, on the other hand, is the ability to establish a tunnel with another endpoint providing the same function. This implies some form of signaling to establish a tunnel. Such signaling can be viewed as integrated with DHCP or as a separate service. Section 3.3.1 discusses the constraints of this signaling function. The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2 tunnel, or some other form of softwire. Note that the presence of a tunnel allows unmodified, naive, or even legacy devices between the two endpoints.
另一方面，encaps/decaps功能是通过提供相同功能的另一个端点建立隧道的能力。这意味着建立隧道的某种形式的信号。这种信令可以被视为与DHCP集成或作为单独的服务。第3.3.1节讨论了该信号功能的限制。隧道可以是IPv6或IPv4封装、第2层隧道或某种其他形式的软线。请注意，隧道的存在允许在两个端点之间使用未经修改、原始甚至遗留的设备。
Two or more devices that provide the encaps/decaps function are linked by tunnels to form an A+P subsystem. The function of each gateway is to encapsulate and decapsulate, respectively. Figure 2
两个或多个提供收存/解存功能的设备通过隧道连接，形成A+P子系统。每个网关的功能分别是封装和解封。图2
depicts the simplest possible A+P subsystem, that is, two devices providing the encaps/decaps function.
描述了可能最简单的A+P子系统，即两个提供收存/解存功能的设备。
+------------------------------------+
Private | +----------+ tunnel +----------+ | Public
address --|-| gateway |==========| gateway |-|-- address
realm | +----------+ +----------+ | realm
+------------------------------------+
A+P subsystem
+------------------------------------+
Private | +----------+ tunnel +----------+ | Public
address --|-| gateway |==========| gateway |-|-- address
realm | +----------+ +----------+ | realm
+------------------------------------+
A+P subsystem
Figure 2: A Simple A+P Subsystem
图2：一个简单的A+P子系统
Within an A+P subsystem, the public address realm is extended by using bits from the port number when forwarding packets. Each device is assigned one address from the external realm and a range of port numbers. Hence, devices that are part of an A+P subsystem can communicate with the public realm without the need for address translation (i.e., preserving end-to-end packet integrity): an A+P packet originated from within the A+P subsystem can be simply forwarded over tunnels up to the endpoint, where it gets decapsulated and routed in the external realm.
在A+P子系统中，通过在转发数据包时使用端口号中的位来扩展公共地址领域。每个设备从外部领域分配一个地址和一系列端口号。因此，作为A+P子系统的一部分的设备可以与公共域通信，而无需地址转换（即，保持端到端数据包完整性）：起源于A+P子系统内的A+P数据包可以简单地通过隧道转发到端点，在那里它被解封并在外部域中路由。
The following information needs to be available on all the gateways in the A+P subsystem. It is expected that there will be a signaling protocols such as [PR-ADDR-ASSIGN], [SHARED-ADDR-OPT], [PORT-RANGE-OPT], or [PCP-BASE].
需要在A+P子系统的所有网关上提供以下信息。预计将存在诸如[PR-ADDR-ASSIGN]、[SHARED-ADDR-OPT]、[PORT-RANGE-OPT]或[PCP-BASE]等信令协议。
The information that needs to be shared is the following:
需要共享的信息如下：
o a set of public IPv4 addresses,
o 一组公共IPv4地址，
o for each IPv4 address, a starting point for the allocated port range,
o 对于每个IPv4地址，分配的端口范围的起点，
o the number of delegated ports,
o 委派端口的数量，
o the optional key that enables partial or full preservation of entropy in port randomization -- see [PR-ADDR-ASSIGN],
o 可在端口随机化中部分或完全保留熵的可选键--请参阅[PR-ADDR-ASSIGN]，
o the lifetime for each IPv4 address and set of allocated ports,
o 每个IPv4地址和分配端口集的生存期，
o the tunneling technology to be used (e.g., "IPv6-encapsulation"),
o 要使用的隧道技术（例如，“IPv6封装”），
o addresses of the tunnel endpoints (e.g., IPv6 address of tunnel endpoints),
o 隧道端点的地址（例如，隧道端点的IPv6地址），
o whether or not NAT function is provided by the gateway,
o 无论网关是否提供NAT功能，
o a device identification number and some authentication mechanisms, and
o 设备标识号和一些身份验证机制，以及
o a version number and some reserved bits for future use.
o 版本号和一些保留位供将来使用。
Note that the functions of encapsulation and decapsulation have been separated from the NAT function. However, to accommodate legacy hosts, NATing is likely to be provided at some point in the path; therefore, the availability or absence of NATing MUST be communicated in signaling, as A+P is agnostic about NAT placement.
注意，封装和去封装功能已与NAT功能分离。然而，为了适应遗留主机，可能会在路径中的某个点上提供本机服务；因此，本地的可用性或不可用性必须在信令中进行通信，因为A+P对于NAT的放置是不可知的。
The port ranges can be allocated in two different ways:
可以通过两种不同的方式分配端口范围：
o If applications or end-hosts behind the CPE are not UPnPv2/ NAT-PMP-aware, then the CPE SHOULD request ports via mechanisms, e.g., as described in [PR-ADDR-ASSIGN] and [PORT-RANGE-OPT]. Note that different port ranges can have different lifetimes, and the CPE is not entitled to use them after they expire -- unless it refreshes those ranges. It is up to the ISP to put mechanisms in place (to prevent denial-of-service attacks) that determine what percentage of already allocated port ranges should be exhausted before a CPE may request additional ranges, how often the CPE can request additional ranges, and so on.
o 如果CPE后面的应用程序或终端主机不支持UPnPv2/NAT PMP，则CPE应通过机制请求端口，如[PR-ADDR-ASSIGN]和[PORT-RANGE-OPT]中所述。请注意，不同的端口范围可能有不同的生存期，CPE无权在它们过期后使用它们，除非它刷新这些范围。ISP有责任建立机制（防止拒绝服务攻击），以确定在CPE可能请求附加范围之前，应耗尽已分配端口范围的百分比，CPE可以请求附加范围的频率，等等。
o If applications behind the CPE are UPnPv2/NAT-PMP-aware, additional ports MAY be requested through that mechanism. In this case, the CPE should forward those requests to the LSN, and the LSN should reply reporting if the requested ports are available or not (and if they are not available, some alternatives should be offered). Here again, to prevent potential denial-of-service attacks, mechanisms should be in place to prevent UPnPv2/NAT-PMP packet storms and fast port allocation. A detailed description of this mechanism, called PCP, is in [PCP-BASE].
o 如果CPE后面的应用程序支持UPnPv2/NAT PMP，则可以通过该机制请求额外的端口。在这种情况下，CPE应将这些请求转发给LSN，LSN应回复报告请求的端口是否可用（如果不可用，则应提供一些替代方案）。在这里，为了防止潜在的拒绝服务攻击，应该建立机制来防止UPnPv2/NAT-PMP数据包风暴和快速端口分配。[PCP-BASE]中详细描述了这种称为PCP的机制。
Whatever signaling mechanism is used inside the tunnels -- DHCP, IP Control Protocol (IPCP), or PCP based, synchronization between the signaling server and PRR must be established in both directions. For example, if we use DHCP as the signaling mechanism, the PRR must communicate to the DHCP server at least its IP range. The DHCP server then starts to allocate IP addresses and port ranges to CPEs and communicates back to the PRR which IP and port range have been allocated to which CPE, so the PRR knows to which tunnel to redirect incoming traffic. In addition, DHCP MUST also communicate lifetimes
无论隧道内使用何种信令机制——DHCP、IP控制协议（IPCP）或基于PCP的，信令服务器和PRR之间的同步必须在两个方向上建立。例如，如果我们使用DHCP作为信令机制，PRR必须至少在其IP范围内与DHCP服务器通信。然后，DHCP服务器开始向CPE分配IP地址和端口范围，并向PRR传回分配给哪个CPE的IP和端口范围，以便PRR知道将传入流量重定向到哪个隧道。此外，DHCP还必须在生命周期内进行通信
of port ranges assigned to CPE via the PRR. DHCP server may be co-located with the PRR function to ease address management and also to avoid the need to introduce a communication protocol between the PRR and DHCP.
通过PRR分配给CPE的端口范围。DHCP服务器可以与PRR功能位于同一位置，以简化地址管理，并避免在PRR和DHCP之间引入通信协议。
If UPnPv2/NAT-PMP is used as the dynamic port allocation mechanism, the PRR must also communicate to the DHCP (or IPCP) server to avoid those ports. The PRR must somehow (e.g., using DHCP or IPCP options) communicate back to CPE that the allocation of ports was successful, so CPE adds those ports to existing port ranges.
如果UPnPv2/NAT-PMP用作动态端口分配机制，PRR还必须与DHCP（或IPCP）服务器通信以避免这些端口。PRR必须以某种方式（例如，使用DHCP或IPCP选项）向CPE传回端口分配成功的消息，因此CPE将这些端口添加到现有端口范围中。
Note that operation can be even simplified if a fixed length of port ranges is assigned to all customers and no differentiation is implemented based on port-range length. In such case, the binding table maintained by the PRR can be dynamically built upon the receipt of a first packet from a port-restricted device.
请注意，如果将固定长度的端口范围分配给所有客户，并且不根据端口范围长度进行区分，则操作甚至可以简化。在这种情况下，由PRR维护的绑定表可以在从端口受限设备接收到第一分组时动态构建。
Each gateway within the A+P subsystem manages a certain portion of A+P address space; that is, a portion of IPv4 space that is extended by borrowing bits from the port number. This address space may be a single, port-restricted IPv4 address. The gateway MAY use its managed A+P address space for several purposes:
A+P子系统内的每个网关管理A+P地址空间的特定部分；也就是说，通过从端口号借用位来扩展IPv4空间的一部分。此地址空间可以是单个端口受限的IPv4地址。网关可将其托管A+P地址空间用于多种用途：
o Allocation of a sub-portion of the A+P address space to other authenticated A+P gateways in the A+P subsystem (referred to as delegation). We call the allocated sub-portion delegated address space.
o 将a+P地址空间的一个子部分分配给a+P子系统中其他经过身份验证的a+P网关（称为委派）。我们称分配的子部分为委托地址空间。
o Exchange of (untranslated) packets with the external address realm. For this to work, such packets MUST use a source address and port belonging to the non-delegated address space.
o 与外部地址域交换（未翻译）数据包。要使其工作，此类数据包必须使用属于非委托地址空间的源地址和端口。
If the gateway is also capable of performing the NAT function, it MAY translate packets arriving on an internal interface that are outside of its managed A+P address space into non-delegated address space.
如果网关也能够执行NAT功能，则它可以将到达其管理的A+P地址空间之外的内部接口的分组转换为非委托地址空间。
Hence, a provider may have 'islands' of A+P as they slowly deploy over time. The provider does not have to replace CPE until they want to provide the A+P function to an island of users or even to one particular user in a sea of non-A+P users.
因此，随着时间的推移，提供者可能会有a+P的“孤岛”。提供商不必更换CPE，直到他们想要向一个用户孤岛，甚至向一个非A+P用户海洋中的特定用户提供A+P功能。
An A+P gateway ("A"), accepts incoming connections from other A+P gateways ("B"). Upon connection establishment (provided appropriate authentication), B would "ask" A for delegation of an A+P address. In turn, A will inform B about its public IPv4 address and will
A+P网关（“A”）接受来自其他A+P网关（“B”）的传入连接。建立连接（提供适当的身份验证）后，B将“请求”A委派A+P地址。反过来，A将通知B其公共IPv4地址，并将
delegate a portion of its port range to B. In addition, A will also negotiate the encaps/decaps function with B (e.g., let B know the address of the decaps device at the endpoint of the tunnel).
将其端口范围的一部分委托给B。此外，a还将与B协商encaps/decaps功能（例如，让B知道隧道端点处的decaps设备的地址）。
This could be implemented, for example, via a NAT-PMP- or DHCP-like solution. In general, the following rule applies: a sub-portion of the managed A+P address space is delegated as long as devices below ask for it; otherwise, private IPv4 is provided to support legacy hosts.
这可以通过NAT-PMP或类似DHCP的解决方案来实现。通常，以下规则适用：只要下面的设备请求，托管a+P地址空间的一个子部分就会被委派；否则，将提供专用IPv4以支持旧主机。
The following examples use an IPv4 address from the blocks reserved for documentation as defined in [RFC5737].
以下示例使用[RFC5737]中定义的为文档保留的块中的IPv4地址。
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm +-----+ +-----+
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm +-----+ +-----+
Address space realm of A: public IPv4 address = 192.0.2.1 port range = 0-65535
A的地址空间域：公共IPv4地址=192.0.2.1端口范围=0-65535
Address space realm of B: public IPv4 address = 192.0.2.1 port range = 2560-3071
B的地址空间域：公共IPv4地址=192.0.2.1端口范围=2560-3071
Figure 3: Configuration Example
图3：配置示例
Figure 3 illustrates a sample configuration. Note that A might actually consist of three different devices: one that handles signaling requests from B; one that performs encapsulation and decapsulation; and, if provided, one device that performs the NATing function (e.g., an LSN). Packet forwarding is assumed to be as follows: in the "outbound" case, a packet arrives from the private address realm to B. As stated above, B has two options: it can either apply or not apply the NAT function. The decision depends upon the specific configuration and/or the capabilities of A and B. Note that NAT functionality is required to support legacy hosts; however, this can be done at either of the two devices A or B. The term "NAT" refers to translating the packet into the managed A+P address (B has address 192.0.2.1 and ports 2560-3071 in the example above). We then have two options:
图3展示了一个示例配置。注意，A实际上可能由三个不同的设备组成：一个处理来自B的信令请求；进行封装和去封装的器件；以及，如果提供，一个执行本机功能的设备（例如，LSN）。包转发假设如下：在“出站”情况下，包从专用地址域到达B。如上所述，B有两个选项：它可以应用或不应用NAT功能。决定取决于A和B的特定配置和/或能力。请注意，NAT功能是支持传统主机所必需的；然而，这可以在两个设备A或B中的任何一个上完成。术语“NAT”指将分组转换为受管A+P地址（在上面的示例中，B具有地址192.0.2.1和端口2560-3071）。我们有两个选择：
1) B NATs the packet. The translated packet is then tunneled to A. A recognizes that the packet has already been translated because the source address and port match the delegated space. A decapsulates the packet and releases it in the public Internet.
1) B对数据包进行NAT。然后将转换后的数据包通过隧道传输到A。A确认数据包已被转换，因为源地址和端口与委派的空间匹配。A将数据包解封并在公共互联网上发布。
2) B does not NAT the packet. The untranslated packet is then tunneled to A. A recognizes that the packet has not been translated, so A forwards the packet to a co-located NATing device, which translates the packet and routes it in the public Internet. This device, e.g., an LSN, has to store the mapping between the source port used to NAT and the tunnel where the packet came from, in order to correctly route the reply. Note that A cannot use a port number from the range that has been delegated to B. As a consequence, A has to assign a part of its non-delegated address space to the NATing function.
2) B不NAT数据包。然后，未翻译的数据包通过隧道传输到A。A识别出该数据包尚未翻译，因此A将该数据包转发到位于同一位置的本地设备，该设备翻译该数据包并将其路由到公共互联网。该设备（例如，LSN）必须存储用于NAT的源端口与数据包来自的隧道之间的映射，以便正确路由应答。请注意，A不能使用已委托给B的范围内的端口号。因此，A必须将其未委托的地址空间的一部分分配给本机功能。
"Inbound" packets are handled in the following way: a packet from the public realm arrives at A. A analyzes the destination port number to understand whether or not the packet needs to be NATed.
“入站”数据包的处理方式如下：来自公共领域的数据包到达a。a分析目标端口号，以了解是否需要对数据包进行加密。
1) If the destination port number belongs to the range that A delegated to B, then A tunnels the packet to B. B NATs the packet using its stored mapping and forwards the translated packet to the private domain.
1) 如果目标端口号属于A委托给B的范围，则A将数据包隧道到B。B使用其存储的映射NAT数据包，并将转换后的数据包转发到私有域。
2) If the destination port number is from the address space of the LSN, then A passes the packet on to the co-located LSN, which uses its stored mapping to NAT the packet into the private address realm of B. The appropriate tunnel is stored as well in the mapping of the initial NAT. The LSN then encapsulates the packet to B, which decapsulates it and normally routes it within its private realm.
2) 如果目标端口号来自LSN的地址空间，则A将数据包传递给位于同一位置的LSN，LSN使用其存储的映射将数据包NAT到B的私有地址域。相应的隧道也存储在初始NAT的映射中。然后，LSN将数据包封装到B，B将其解封，并通常在其私有领域内对其进行路由。
3) Finally, if the destination port number falls in neither a delegated range nor the address range of the LSN, A discards the packet. If the packet is passed to the LSN, but no mapping can be found, the LSN discards the packet.
3) 最后，如果目标端口号既不在授权范围内，也不在LSN的地址范围内，则a丢弃该数据包。如果数据包被传递到LSN，但找不到映射，LSN将丢弃该数据包。
Observe that A must be able to receive all IPv4 packets destined to the public IPv4 address (192.0.2.1 in the example), so that it can make routing decisions according to the port number. On the other hand, B receives IPv4 packets destined to the public IPv4 address only via the established tunnel with A. In other words, B uses the public IPv4 address just for translation purposes, but it is not used to make routing decisions. This allows us to keep the routing logic at B as simple as described above, while enabling seamless communication between A+P devices sharing the same public IPv4 address.
请注意，A必须能够接收所有发送到公共IPv4地址（本例中为192.0.2.1）的IPv4数据包，以便它能够根据端口号做出路由决定。另一方面，B仅通过与A建立的隧道接收目的地为公共IPv4地址的IPv4数据包。换句话说，B仅出于转换目的使用公共IPv4地址，但不用于做出路由决策。这使我们能够保持B的路由逻辑如上所述的简单，同时实现共享相同公共IPv4地址的A+P设备之间的无缝通信。
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm 1 +-----+ +-----+
|
private +-----+ |
address ---| C |============/
realm 2 +-----+
private +-----+ +-----+ public
address ---| B |==========| A |--- Internet
realm 1 +-----+ +-----+
|
private +-----+ |
address ---| C |============/
realm 2 +-----+
Address space realm of A: public IPv4 address = 192.0.2.1 port range = 0-65535
A的地址空间域：公共IPv4地址=192.0.2.1端口范围=0-65535
Address space realm of B: public IPv4 address = 192.0.2.1 port range = 2560-3071
B的地址空间域：公共IPv4地址=192.0.2.1端口范围=2560-3071
Address space realm of C: public IPv4 address = 192.0.2.1 port range = 0-2559
C的地址空间域：公共IPv4地址=192.0.2.1端口范围=0-2559
Figure 4: Hierarchical A+P
图4：分层A+P
Consider the example shown in Figure 4. Here, both B and C use the encaps/decaps function to establish a tunnel with A, and they are assigned the same public IPv4 address with different, non-overlapping port ranges. Assume that a host in B's private realm sends a packet destined to address 192.0.2.1 and port 2000, and that B has been instructed to NAT all packets destined to 192.0.2.1. Under these assumptions, B receives the packet and NATs it using its own public IPv4 address (192.0.2.1) and a port selected from its configured port range (e.g., 3000). B then tunnels the translated packet to A. When A receives the packet via the tunnel, it looks at the destination address and port, recognizes C's delegated range, and then tunnels the packet to C. Observe that, apart from stripping the tunnel header, A handles the packet as if it came from the public Internet. When C receives the packet, it NATs the destination address into one address chosen from its private address realm, while keeping the source address (192.0.2.1) and port (3000) untranslated. Return traffic is handled the same way. Such a mechanism allows hosts behind A+P devices to communicate seamlessly even when they share the same public IPv4 address.
考虑图4中所示的示例。在这里，B和C都使用encaps/decaps函数与a建立一个隧道，并为它们分配相同的公共IPv4地址和不同的、不重叠的端口范围。假设B的私有领域中的主机发送一个目的地为地址192.0.2.1和端口2000的数据包，并且B已被指示NAT所有目的地为192.0.2.1的数据包。在这些假设下，B接收数据包并使用其自己的公共IPv4地址（192.0.2.1）和从其配置的端口范围（例如3000）中选择的端口对其进行NAT。B然后将翻译后的数据包通过隧道传输到A。当A通过隧道接收数据包时，它会查看目的地址和端口，识别C的委托范围，然后将数据包通过隧道传输到C。注意，除了剥离隧道头外，A处理数据包就像它来自公共互联网一样。当C接收到数据包时，它将目标地址NAT到从其私有地址域中选择的一个地址中，同时保持源地址（192.0.2.1）和端口（3000）不被翻译。返回流量的处理方式相同。这种机制允许a+P设备后面的主机无缝通信，即使它们共享相同的公共IPv4地址。
Please refer to Section 4 for a discussion of an alternative A+P mechanism that does not incur path-stretch penalties for intra-domain communication.
关于替代a+P机制的讨论，请参阅第4节，该机制不会对域内通信产生路径扩展惩罚。
Since each device in an A+P subsystem provides the encaps/decaps function, new devices can establish tunnels and become in turn part of an A+P subsystem. As noted above, being part of an A+P subsystem implies the capability of talking to the external address realm without any translation. In particular, as described in the previous section, a device X in an A+P subsystem can be reached from the external domain by simply using the public IPv4 address and a port that has been delegated to X. Figure 5 shows an example where three devices are connected in a chain. In other words, A+P signaling can be used to extend end-to-end connectivity to the devices that are in an A+P subsystem. This allows A+P-aware applications (or OSes) running on end-hosts to enter an A+P subsystem and exploit untranslated connectivity.
由于A+P子系统中的每个设备都提供了“汇入/汇出”功能，因此新设备可以建立隧道，并依次成为A+P子系统的一部分。如上所述，作为A+P子系统的一部分意味着能够在不进行任何转换的情况下与外部地址域通信。特别是，如前一节所述，a+P子系统中的设备X可以通过简单地使用公共IPv4地址和已委托给X的端口从外部域访问。图5显示了三个设备在链中连接的示例。换句话说，A+P信令可用于将端到端连接扩展到A+P子系统中的设备。这允许在终端主机上运行的A+P感知应用程序（或操作系统）进入A+P子系统并利用未转换的连接。
There are two modes for end-hosts to gain fine-grained control of end-to-end connectivity. The first is where actual end-hosts perform the NAT function and the encaps/decaps function that is required to join the A+P subsystem. This option works in a similar way to the NAT-in-the-host trick employed by virtualization software such as VMware, where the guest operating system is connected via a NAT to the host operating system. The second mode is when applications autonomously ask for an A+P address and use it to join the A+P subsystem. This capability is necessary for some applications that require end-to-end connectivity (e.g., applications that need to be contacted from outside).
终端主机有两种模式可以获得端到端连接的细粒度控制。第一个是实际的终端主机执行NAT功能和加入A+P子系统所需的encaps/decaps功能。此选项的工作方式与虚拟化软件（如VMware）采用的主机技巧中的NAT类似，其中来宾操作系统通过NAT连接到主机操作系统。第二种模式是应用程序自动请求A+P地址并使用它加入A+P子系统。对于某些需要端到端连接的应用程序（例如，需要从外部联系的应用程序），此功能是必需的。
+---------+ +---------+ +---------+
internal | gateway | | gateway | | gateway | external
realm --| 1 |======| 2 |======| 3 |-- realm
+---------+ +---------+ +---------+
+---------+ +---------+ +---------+
internal | gateway | | gateway | | gateway | external
realm --| 1 |======| 2 |======| 3 |-- realm
+---------+ +---------+ +---------+
Figure 5: An A+P Subsystem with Multiple Devices
图5：具有多个设备的A+P子系统
Whatever the reasons might be, the Internet was built on a paradigm that end-to-end connectivity is important. A+P makes this still possible in a time where address shortage forces ISPs to use NATs at various levels. In that sense, A+P can be regarded as a way to bypass NATs.
不管原因是什么，互联网是建立在端到端连接非常重要的范例之上的。在地址短缺迫使ISP在不同级别上使用NAT的情况下，A+P仍然可以实现这一点。从这个意义上说，A+P可以被视为绕过NAT的一种方式。
+---+ (customer2)
|A+P|-. +---+
+---+ \ NAT|A+P|-.
\ +---+ |
\ | forward if in range
+---+ \+---+ +---+ /
|A+P|------|A+P|----|A+P|----
+---+ /+---+ +---+ \
/ NAT if necessary
/ (cust1) (prov. (e.g., provider NAT)
+---+ / router)
|A+P|-'
+---+
+---+ (customer2)
|A+P|-. +---+
+---+ \ NAT|A+P|-.
\ +---+ |
\ | forward if in range
+---+ \+---+ +---+ /
|A+P|------|A+P|----|A+P|----
+---+ /+---+ +---+ \
/ NAT if necessary
/ (cust1) (prov. (e.g., provider NAT)
+---+ / router)
|A+P|-'
+---+
Figure 6: A Complex A+P Subsystem
图6：复杂的A+P子系统
Figure 6 depicts a complex scenario, where the A+P subsystem is composed of multiple devices organized in a hierarchy. Each A+P gateway decapsulates the packet and then re-encapsulates it again to the next tunnel.
图6描述了一个复杂的场景，其中a+P子系统由层次结构中组织的多个设备组成。每个A+P网关解除对数据包的封装，然后将其重新封装到下一个隧道。
A packet can be NATed either when it enters the A+P subsystem, at intermediate devices, or when it exits the A+P subsystem. This could be, for example, a gateway installed within the provider's network, together with an LSN. Then, each customer operates its own CPE. However, behind the CPE, applications might also be A+P-aware and run their own A+P-gateways; this enables them to have end-to-end connectivity.
当数据包进入A+P子系统、在中间设备或退出A+P子系统时，可以对其进行隔离。例如，这可以是安装在提供商网络中的网关以及LSN。然后，每个客户运营自己的CPE。然而，在CPE背后，应用程序也可能是A+P感知的，并运行自己的A+P网关；这使它们具有端到端的连接。
One limitation applies when "delayed translation" is used (e.g., translation at the LSN instead of the CPE). If devices using "delayed translation" want to talk to each other, they SHOULD use A+P addresses or out-of-band addressing.
当使用“延迟翻译”时，一个限制适用（例如，在LSN而不是CPE进行翻译）。如果使用“延迟转换”的设备希望彼此通信，则应使用A+P地址或带外寻址。
A+P architecture
A+P体系结构
IPv4 Full-A+P AFTR CGN
| | | |
<-- Full IPv4 ---- Port range ---- Port range ---- Provider --->
allocated & dynamic & LSN NAT ONLY
allocation (NAT on CPE (No mechanism)
(no NAT) (NAT on CPE) and on LSN) for customer to
bypass CGN)
IPv4 Full-A+P AFTR CGN
| | | |
<-- Full IPv4 ---- Port range ---- Port range ---- Provider --->
allocated & dynamic & LSN NAT ONLY
allocation (NAT on CPE (No mechanism)
(no NAT) (NAT on CPE) and on LSN) for customer to
bypass CGN)
Figure 7: A+P Overall Architecture
图7:A+P总体架构
The A+P architecture defines various deployment options within an ISP. Figure 7 shows the spectrum of deployment options. On the far left is the common deployment method for broadband subscribers today, an IPv4 address unrestricted with full port range. Full-A+P refers to a port-range allocation from the ISP. The customer must operate an A+P-aware CPE device, and no NATing functionality is provided by the ISP. The Address Family Transition Router (AFTR), such as DS-Lite [RFC6333], is a hybrid. There is NAT present in the core (in this document, referred to as LSN), but the user has the option to "bypass" that NAT in one form or an other, for example, via A+P, NAT-PMP, etc. Finally, a service provider that only deploys CGN will place a NAT in the provider's core and does not allow the customer to "bypass" the translation process or modify ALGs on the NAT. The customer is provider-locked. Notice that all options (besides full IPv4) require some form of tunneling mechanism (e.g., 4in6) and a signaling mechanism (see Section 3.3.1).
A+P体系结构定义了ISP中的各种部署选项。图7显示了部署选项的范围。最左边是目前宽带用户常用的部署方法，IPv4地址不受限制，具有完整的端口范围。Full-A+P是指ISP分配的端口范围。客户必须操作A+P感知CPE设备，ISP不提供本机功能。地址族转换路由器（AFTR），如DS Lite[RFC6333]，是一种混合型路由器。核心中存在NAT（在本文档中，称为LSN），但用户可以选择以一种或另一种形式“绕过”该NAT，例如，通过A+P、NAT-PMP等。最后，仅部署CGN的服务提供商将在提供商的核心中放置NAT，并且不允许客户“绕过”翻译过程或修改NAT上的ALG。客户已被提供商锁定。请注意，所有选项（除了完整的IPv4）都需要某种形式的隧道机制（例如4in6）和信令机制（参见第3.3.1节）。
There are implementations of A+P as well as documented experiments. France Telecom did experiments that are described in [A+P-EXPERIMENTS]. As seen in that experiment, most tested applications are unaffected. There are problems with torrent protocol and applications, as the listening port is out of A+P port range and some UPnP may be required to make it work with A+P.
有A+P的实现，也有记录在案的实验。法国电信进行了[A+P-实验]中描述的实验。从该实验中可以看出，大多数经过测试的应用程序都不受影响。torrent协议和应用程序存在问题，因为侦听端口超出A+P端口范围，可能需要一些UPnP才能使其与A+P一起工作。
Problems with BitTorrent have already been experienced in the wild by users trapped behind a non-UPnP-capable CPE. The current workaround for the end-user is to statically map ports, which can be done in the A+P scenario as well.
被困在不支持UPnP的CPE后面的用户已经在野外遇到了BitTorrent的问题。最终用户当前的解决方法是静态映射端口，这也可以在A+P场景中完成。
BitTorrent tests and experiments in shared IP and port-range environments are well described in [BITTORRENT-ADDR-SHARING]. Conclusions in that document tell us that two limitations were experienced. The first occurred when two clients sharing the same IP address tried to simultaneously retrieve the SAME file located in a SINGLE remote peer. The second limitation occurred when a client tried to download a file located on several seeders, when those seeders shared the same IP address. Mutual file sharing between hosts having the same IP address has been checked. Indeed, machines having the same IP address can share files with no alteration compared to current IP architectures.
[BitTorrent-ADDR-SHARING]中详细介绍了共享IP和端口范围环境中的BitTorrent测试和实验。该文件中的结论告诉我们，存在两个局限性。第一种情况发生在共享同一IP地址的两个客户端试图同时检索位于单个远程对等机中的同一文件时。第二个限制发生在客户端尝试下载位于多个种子机上的文件时，这些种子机共享相同的IP地址。已检查具有相同IP地址的主机之间的相互文件共享。事实上，与当前的IP架构相比，具有相同IP地址的机器可以共享文件，而不会进行任何更改。
Working implementations of A+P can be found in:
A+P的工作实现可以在以下内容中找到：
o Internet Systems Consortium AFTR (http://www.isc.org/software/aftr),
o 互联网系统联盟(http://www.isc.org/software/aftr),
o FT Orange opensource A+P (http://opensourceaplusp.weebly.com/) developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and
o FT Orange开源A+P(http://opensourceaplusp.weebly.com/)由赵晓宇、邓晓红、郑涛和
o 4rd (IPv4 Residual Deployment) from ipinfusion.com, which is stateless A+P.
o ipinfusion.com上的第4rd（IPv4剩余部署），它是无状态的A+P。
SMAP stands for Stateless A+P Mapping. This function is responsible for, in a stateless scheme, encapsulating IPv4 packets in IPv6 ones as well as decapsulating IPv4 packets from IPv6 ones. An SMAP function may be hosted in a PRR, end-user device, etc.
SMAP代表无状态A+P映射。在无状态方案中，此函数负责将IPv4数据包封装在IPv6数据包中，以及从IPv6数据包中解封IPv4数据包。SMAP功能可以托管在PRR、最终用户设备等中。
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
如[RFC6052]第4.1节所述，后缀部分可包含端口。
The Stateless A+P Mapping (SMAP) gateway consists in two basic functions as described in Figure 8.
无状态A+P映射（SMAP）网关由两个基本功能组成，如图8所示。
1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4 address, in an IPv6 one. The IPv6 source address is constructed using an IPv4-embedded IPv6 address [RFC6052] from the IPv4 source address and port number plus the IPv6 prefix that has been provisioned to the node performing the SMAP function. The destination IPv6 address is constructed using the shared IPv4 destination address and port number plus the IPv6 prefix that has been provisioned to the SMAP function and that is dedicated to IPv4 destination addresses.
1. SMAP将IPv4数据包封装在IPv6数据包中，目的地为共享IPv4地址。IPv6源地址使用IPv4嵌入IPv6地址[RFC6052]构造，该地址来自IPv4源地址和端口号，加上已提供给执行SMAP功能的节点的IPv6前缀。目标IPv6地址是使用共享IPv4目标地址和端口号加上已提供给SMAP函数且专用于IPv4目标地址的IPv6前缀构建的。
2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones that have IPv6 source addresses belonging to the prefix of the node performing the SMAP function. Extracted IPv4 packets are then forwarded to the point identified by the IPv4 destination address and port number.
2. SMAP从具有属于执行SMAP功能的节点前缀的IPv6源地址的IPv6传入数据包中提取IPv4传入数据包。提取的IPv4数据包然后转发到由IPv4目标地址和端口号标识的点。
+-------------------+
| |----IPv6---\
----IPv4---\| |----IPv4---\\
-----------/| |-----------//
| |-----------/
| SMAP |
| | /--IPv6-----
/---IPv4----| |//---IPv4----
\-----------| |\\-----------
| | \-----------
+-------------------+
+-------------------+
| |----IPv6---\
----IPv4---\| |----IPv4---\\
-----------/| |-----------//
| |-----------/
| SMAP |
| | /--IPv6-----
/---IPv4----| |//---IPv4----
\-----------| |\\-----------
| | \-----------
+-------------------+
Figure 8: Stateless A+P Mapping Gateway Function
图8：无状态A+P映射网关功能
An SMAP-enabled node will perform the stateless 6/4 mapping function for all public shared IPv4 addresses for which it was designated as a stateless 6/4 mapping gateway.
启用SMAP的节点将为其指定为无状态6/4映射网关的所有公共共享IPv4地址执行无状态6/4映射功能。
To perform the stateless 6/4 mapping function, an SMAP gateway must:
要执行无状态6/4映射功能，SMAP网关必须：
o be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway uses this prefix to construct IPv6 source addresses for all IPv4 shared addresses for which it was designated as an SMAP gateway. The IPv6 prefix may be provisioned statically or dynamically (e.g., DHCP).
o 应提供IPv6前缀（即Pref6）。SMAP网关使用此前缀为其指定为SMAP网关的所有IPv4共享地址构造IPv6源地址。IPv6前缀可以静态地或动态地提供（例如，DHCP）。
o be able to know the IPv6 prefix of the node serving as another SMAP gateway for IPv4 destination addresses. This prefix may be known in various ways:
o 能够知道作为IPv4目标地址的另一个SMAP网关的节点的IPv6前缀。该前缀可以以各种方式已知：
* Default or Well-Known Prefix (i.e., 64:ff9b::/96) that was provisioned statically or dynamically;
* 静态或动态设置的默认或已知前缀（即64:ff9b:：/96）；
* Retained at the reception of incoming IPv4-in-IPv6 encapsulated packets;
* 在接收传入的IPv4-in-IPv6封装数据包时保留；
* Discovered at the start of communication, thanks to mechanisms such as DNS resolution, for example.
* 例如，由于DNS解析等机制，在通信开始时发现。
When the SMAP-enabled node receives IPv4 packets with IPv4 source addresses for which it was not designated as an smap gateway, it will not perform stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed).
启用SMAP的节点接收到IPv4源地址为其未指定为SMAP网关的IPv4数据包时，将不会对这些数据包执行无状态6/4映射功能。这些数据包将以经典方式处理（即转发、丢弃或本地处理）。
When the SMAP-enabled node receives IPv6 packets with IPv6 addresses that do not match with its IPv6 prefix, it will not perform the stateless 6/4 mapping function for those packets. Those packets will be handled in a classical way (i.e., forwarded, dropped, or locally processed).
当启用SMAP的节点接收到IPv6地址与其IPv6前缀不匹配的IPv6数据包时，它将不会对这些数据包执行无状态6/4映射功能。这些数据包将以经典方式处理（即转发、丢弃或本地处理）。
In this configuration, the node A performs the stateless mapping function on the received IPv4 traffic (encapsulated in IPv6 packets) before forwarding to the node B. The node B performs the stateless mapping function on the received IPv6 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic to the destination identified by the IPv4 destination address and port number. In the opposite direction, and as previously, the node B performs the stateless mapping function on the received IPv4 traffic (encapsulating in IPv6 packets) before forwarding to the node A. The node A performs the stateless mapping function on the received IPv6 traffic (extracting IPv4 packets) before forwarding the IPv4 traffic to the point identified by the IPv4 destination address and port number. In this case, only IPv6 traffic is managed in the network segment between the nodes A and B.
在此配置中，节点A在转发到节点B之前对接收到的IPv4流量（封装在IPv6数据包中）执行无状态映射功能。节点B对接收到的IPv6流量（提取IPv4数据包）执行无状态映射功能将IPv4通信转发到由IPv4目标地址和端口号标识的目标之前。在相反方向上，如前所述，节点B在转发到节点A之前对接收到的IPv4通信量执行无状态映射功能（封装在IPv6数据包中）。节点A对接收到的IPv6通信量执行无状态映射功能（提取IPv4数据包）将IPv4通信转发到由IPv4目标地址和端口号标识的点之前。在这种情况下，节点A和B之间的网段中仅管理IPv6通信量。
+------+ +------+
| |----IPv6---\ | |
----IPv4---\| |----IPv4---\\| |----IPv4---\
-----------/| |-----------//| |-----------/
| |-----------/ | |
| SMAP | | SMAP |
| | /----IPv6---| |
/---IPv4----| |//---IPv4----| |/---IPv4----
\-----------| |\\-----------| |\-----------
| | \-----------| |
+------+ +------+
node A node B
+------+ +------+
| |----IPv6---\ | |
----IPv4---\| |----IPv4---\\| |----IPv4---\
-----------/| |-----------//| |-----------/
| |-----------/ | |
| SMAP | | SMAP |
| | /----IPv6---| |
/---IPv4----| |//---IPv4----| |/---IPv4----
\-----------| |\\-----------| |\-----------
| | \-----------| |
+------+ +------+
node A node B
Figure 9
图9
Several deployment scenarios of the SMAP function may be envisaged in the context of port-range-based solutions:
在基于港口范围的解决方案中，可以设想SMAP功能的几种部署场景：
o An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes are deployed in the boundaries between IPv6- enabled realms and IPv4 ones. This scenario may be deployed particularly for intra-domain communications so as to interconnect heterogeneous realms (i.e., IPv6/IPv4) within the same Autonomous System (AS).
o SMAP函数嵌入在端口受限设备中。其他支持SMAP的节点部署在支持IPv6的领域和IPv4领域之间的边界上。该场景可以特别针对域内通信进行部署，以便在同一自治系统（as）内互连异构领域（即IPv6/IPv4）。
o An SMAP function is embedded in a port-restricted device. Other SMAP-enabled nodes are deployed in the interconnection segment (with adjacent IPv4-only ones) of a given AS. This deployment scenario is more suitable for service providers targeting the deployment of IPv6 since it eases the migration to full IPv6. Core nodes are not required to continue to activate both IPv4 and IPv6 transfer capabilities.
o SMAP函数嵌入在端口受限设备中。其他支持SMAP的节点部署在给定AS的互连段中（只有相邻的IPv4节点）。此部署场景更适合于以部署IPv6为目标的服务提供商，因为它简化了向完整IPv6的迁移。核心节点无需继续激活IPv4和IPv6传输功能。
Other considerations regarding the interconnection of SMAP-enabled domains should be elaborated. The following provides a non-exhaustive list of interconnection schemes.
应详细说明与支持SMAP的域互连有关的其他考虑因素。以下提供了互连方案的非详尽列表。
o The interconnection of two domains implementing the SMAP function may be deployed via IPv4 Internet (Figure 10): this means that IPv4 packets encapsulated in IPv6 packets are transferred using IPv6 until reaching the first SMAP-enabled node. Then, these packets are decapsulated and are forwarded using IPv4 transfer capabilities. A remote SMAP-enabled node will receive those packets and proceed to an IPv4-in-IPv6 encapsulation. These packets are then routed normally until reaching the port-restricted devices that decapsulate the packets.
o 实现SMAP功能的两个域的互连可以通过IPv4 Internet部署（图10）：这意味着封装在IPv6数据包中的IPv4数据包使用IPv6传输，直到到达第一个启用SMAP的节点。然后，这些数据包被解封，并使用IPv4传输功能进行转发。启用SMAP的远程节点将接收这些数据包并继续进行IPv4-in-IPv6封装。然后，这些数据包将正常路由，直到到达解除数据包封装的端口受限设备。
+------+ +------+ +--------+ +------+ +------+
| |--IPv6--\ | | | | | |---IPv6--\ | |
| |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| |
| |--------//| |---|--------|--/| |---------//| |
| |--------/ | | |Internet| | |---------/ | |
| SMAP | | SMAP | | IPv4 | | SMAP | | SMAP |
| | /--IPv6--| | | | | | /---IPv6--| |
| |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| |
| |\\--------| |\--|--------|---| |\\---------| |
| | \--------| | | | | | \---------| |
+------+ +------+ +--------+ +------+ +------+
Source node A node B Destination
+------+ +------+ +--------+ +------+ +------+
| |--IPv6--\ | | | | | |---IPv6--\ | |
| |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| |
| |--------//| |---|--------|--/| |---------//| |
| |--------/ | | |Internet| | |---------/ | |
| SMAP | | SMAP | | IPv4 | | SMAP | | SMAP |
| | /--IPv6--| | | | | | /---IPv6--| |
| |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| |
| |\\--------| |\--|--------|---| |\\---------| |
| | \--------| | | | | | \---------| |
+------+ +------+ +--------+ +------+ +------+
Source node A node B Destination
Figure 10: Interconnection Scenario 1
图10：互连场景1
o A second scheme is to use IPv6 to interconnect two realms that implement the SMAP function (Figure 11). An IPv6 prefix (i.e., Pref6) assigned by IANA is used for this service. If appropriate routing configurations have been enforced, then the IPv6- encapsulated packets will be routed until the final destination. In order to implement this model, IPv4-inferred IPv6 prefixes are required to be injected in the IPv6 inter-domain routing tables.
o 第二种方案是使用IPv6互连实现SMAP功能的两个领域（图11）。IANA分配的IPv6前缀（即Pref6）用于此服务。如果执行了适当的路由配置，则IPv6封装的数据包将被路由到最终目的地。为了实现此模型，需要在IPv6域间路由表中注入IPv4推断的IPv6前缀。
+------+ +------------+ +------+
| | | | | |
| |----IPv6-----|----IPv6----|----IPv6----\ | |
| |----IPv4-----|------------|----IPv4----\\| |
| |-------------|------------|------------//| |
| |-------------|------------|------------/ | |
| SMAP | | Internet v6| | SMAP |
| | /-----IPv6--|------------|-----IPv6-----| |
| |//---IPv4----|------------|-------IPv4---| |
| |\\-----------|------------|--------------| |
| | \-----------|------------|--------------| |
| | | | | |
+------+ +------------+ +------+
Source Destination
+------+ +------------+ +------+
| | | | | |
| |----IPv6-----|----IPv6----|----IPv6----\ | |
| |----IPv4-----|------------|----IPv4----\\| |
| |-------------|------------|------------//| |
| |-------------|------------|------------/ | |
| SMAP | | Internet v6| | SMAP |
| | /-----IPv6--|------------|-----IPv6-----| |
| |//---IPv4----|------------|-------IPv4---| |
| |\\-----------|------------|--------------| |
| | \-----------|------------|--------------| |
| | | | | |
+------+ +------------+ +------+
Source Destination
Figure 11: Interconnection Scenario 2
图11：互连场景2
The deployment of the SMAP function allows for smooth migration of networks to an IPv6-only scheme while maintaining the delivery of IPv4 connectivity services to customers. The delivery of IPv4 connectivity services over an IPv6-only network does not require any stateful function to be deployed on the core network. Owing to this A+P mode, both the IPv4 service continuity and the migration to an IPv6-only deployment model are facilitated.
SMAP功能的部署允许将网络顺利迁移到仅限IPv6的方案，同时保持向客户提供IPv4连接服务。通过仅限IPv6的网络提供IPv4连接服务不需要在核心网络上部署任何有状态功能。由于这种A+P模式，IPv4服务连续性和迁移到仅IPv6部署模型都得到了促进。
The SMAP section (Section 4) discusses two modes: the binding and the stateless modes. Dynamic port allocation is not a feature of the stateless mode, but it is supported in the binding mode. In the binding mode, distinct external IPv4 addresses may be used, but this is not recommended.
SMAP部分（第4节）讨论了两种模式：绑定模式和无状态模式。动态端口分配不是无状态模式的功能，但在绑定模式中受支持。在绑定模式下，可以使用不同的外部IPv4地址，但不建议这样做。
o Stateless Mode
o 无状态模式
Complete stateless mapping implies that the IPv4 address and the significant bits coding the port range are reflected inside the IPv6 prefix assigned to the port-restricted device. This can be achieved either by embedding the full IPv4 address and the significant bits in the IPv6 prefix or by applying an algorithmic approach. Two alternatives are offered when such a stateless mapping is to be enabled:
完全无状态映射意味着IPv4地址和编码端口范围的有效位反映在分配给端口受限设备的IPv6前缀中。这可以通过在IPv6前缀中嵌入完整的IPv4地址和有效位，或者通过应用算法方法来实现。在启用这种无状态映射时，提供了两种备选方案：
- use the IPv6 prefix already used for native IPv6 traffic, or
- 使用已用于本机IPv6通信的IPv6前缀，或
- provide two prefixes to the port-restricted device: one for the native IPv6 traffic and one for the IPv4 traffic.
- 为端口受限设备提供两个前缀：一个用于本机IPv6流量，另一个用于IPv4流量。
Note that:
请注意：
- Providing two IPv6 prefixes has the advantages of allowing a /64 prefix for the port-restricted device along with another prefix (e.g., a /56 or /64) for native IPv6 traffic. This alternative allows the service provider to relate the native IPv6 traffic addressing plan to the IPv4 addressing plan. The drawback is having to allocate two prefixes to each port-restricted device and to route them. In addition, an address selection issue may be encountered.
- 提供两个IPv6前缀的优点是允许端口受限设备使用/64前缀，同时允许本地IPv6流量使用另一个前缀（例如，a/56或/64）。此备选方案允许服务提供商将本机IPv6流量寻址计划与IPv4寻址计划相关联。缺点是必须为每个端口受限的设备分配两个前缀并对其进行路由。此外，可能会遇到地址选择问题。
- Providing one prefix for both needs (e.g., a /56 or a /64) allows the service provider to handle two types of IPv6 prefix for the port-restricted device and in routing tables. But the drawback is that it strongly links the IPv4 addressing plan to the allocated IPv6 prefixes.
- 为这两种需要（例如，a/56或a/64）提供一个前缀允许服务提供商为端口受限设备和路由表处理两种类型的IPv6前缀。但缺点是它将IPv4寻址计划与分配的IPv6前缀紧密链接。
As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose the port.
如[RFC6052]第4.1节所述，后缀部分可包含端口。
o Binding Table Mode
o 绑定表模式
Another alternative is to assign a "normal" IPv6 prefix to the port-restricted device and to use a binding table, which can be hosted by a service node to correlate the (shared IPv4 address, port range) with an IPv6 address part of the assigned IPv6 prefix. For scalability reasons, this table should be instantiated within PRR-enabled nodes that are close to the port-restricted devices. The number of required entries if hosted at the interconnection segment would be equal to the amount of subscribed users (one per port-restricted device).
另一种选择是向端口受限设备分配“正常”IPv6前缀，并使用绑定表，该绑定表可由服务节点托管，以将（共享IPv4地址、端口范围）与分配的IPv6前缀的IPv6地址部分相关联。出于可伸缩性原因，应在靠近端口受限设备的启用PRR的节点内实例化此表。如果在互连段托管，则所需条目的数量将等于订阅的用户数量（每个端口受限设备一个）。
If a Stateless A+P Mapping (SMAP) type of implementation is deployed over intermediate IPv6-only-capable devices, it is recommended that default routes are configured, and the IPv4 routing table is not "leaked" into the IPv6 routing table in terms of having reachability for the packets going towards the Internet.
如果在仅支持IPv6的中间设备上部署了无状态a+P映射（SMAP）类型的实现，则建议配置默认路由，并且IPv4路由表不会“泄漏”到IPv6路由表中，因为它具有通向Internet的数据包的可达性。
One of the stateless A+P variants is 4rd [4rd].
无状态A+P变体之一是4rd[4rd]。
Some large broadband providers will not have enough public IPv4 address space to provide every customer with a single IP address. The natural solution is sharing a single IP address among many customers. Multiplexing customers is usually accomplished by allocating different port numbers to different customers somewhere within the network of the provider.
一些大型宽带提供商将没有足够的公共IPv4地址空间为每个客户提供单个IP地址。自然的解决方案是在多个客户之间共享一个IP地址。多路复用客户通常是通过将不同的端口号分配给提供商网络中的某个地方的不同客户来实现的。
It is expected that, when the provider wishes to enable A+P for a customer or a range of customers, the CPE can be upgraded or replaced to support A+P encaps/decaps functionality. Ideally, the CPE also provides NATing functionality. Further, it is expected that at least another component in the ISP network provides the corresponding A+P functionality, and hence is able to establish an A+P subsystem with the CPE. This device is referred to as an A+P router or Port-Range Router (PRR), and could be located close to PE routers. The core of the network MUST support the tunneling protocol (which SHOULD be IPv6, as per Constraint 7) but MAY be another tunneling technology when necessary. In addition, we do not wish to restrict any initiative of customers who might want to run an A+P-capable network on or behind their CPE. To satisfy both Constraints 1 and 2, unmodified legacy hosts should keep working seamlessly, while upgraded/new end-systems should be given the opportunity to exploit enhanced features.
预计，当提供商希望为一个客户或一系列客户启用+P时，CPE可以升级或更换以支持A+P转换/转换功能。理想情况下，CPE还提供本地功能。此外，期望ISP网络中的至少另一组件提供相应的A+P功能，因此能够与CPE建立A+P子系统。该设备称为A+P路由器或端口范围路由器（PRR），可位于PE路由器附近。网络的核心必须支持隧道协议（根据约束7，应该是IPv6），但必要时可以是另一种隧道技术。此外，我们不希望限制可能希望在其CPE上或背后运行A+P网络的客户的任何主动权。为了满足约束条件1和约束条件2，未经修改的旧主机应保持无缝工作，而升级/新的终端系统应获得利用增强功能的机会。
In the case of mobile service providers, the situation is slightly different. The A+P border is assumed to be the gateway (e.g., Gateway GPRS Support Node (GGSN) / Packet Data Network (PDN) gateway (GW) of 3GPP, or Access Service Network (ASN) GW of Worldwide Interoperability for Microwave Access (WiMAX)). The need to extend the address is not within the provider network, but on the edge between the mobile phone devices and the gateway. While desirable, IPv6 connectivity may or may not be provided.
就移动服务提供商而言，情况略有不同。假定A+P边界是网关（例如，3GPP的网关GPRS支持节点（GGSN）/分组数据网络（PDN）网关（GW），或全球微波接入互操作性（WiMAX）的接入服务网络（ASN）GW）。扩展地址的需要不在提供商网络内，而是在移动电话设备和网关之间的边缘。虽然需要IPv6连接，但可以提供也可以不提供。
For mobile providers, we use the following terms and assumptions:
对于移动提供商，我们使用以下术语和假设：
1. provider network (PN)
1. 提供商网络（PN）
2. gateway (GW)
2. 网关（GW）
3. mobile phone device (phone)
3. 移动电话设备（电话）
4. devices behind the phone, e.g., laptop computer connecting via phone to Internet
4. 手机后面的设备，例如通过手机连接到互联网的笔记本电脑
We expect that the gateway has a pool of IPv4 addresses and is always in the data-path of the packets. Transport between the gateway and phone devices is assumed to be an end-to-end layer-2 tunnel. We assume that the phone as well as gateway can be upgraded to support A+P. However, some applications running on the phone or devices behind the phone (such as laptop computers connecting via the phone) are not expected to be upgraded. Again, while we do not expect that devices behind the phone will be A+P-aware or upgraded, we also do not want to hinder their evolution. In this sense, the mobile phone would be comparable to the CPE in the broadband provider case; it would be the gateway to the PRR/LSN box in the network of the broadband provider.
我们期望网关有一个IPv4地址池，并且始终位于数据包的数据路径中。网关和电话设备之间的传输假定为端到端第2层隧道。我们假设手机和网关可以升级以支持A+P。但是，手机上运行的某些应用程序或手机后面的设备（如通过手机连接的笔记本电脑）预计不会升级。同样，虽然我们不希望手机后面的设备能够感知A+P或升级，但我们也不想阻碍它们的发展。从这个意义上讲，移动电话将可与宽带提供商案例中的CPE相媲美；它将是宽带提供商网络中PRR/LSN盒的网关。
ISPs suffering from IPv4 address space exhaustion are interested in achieving a high address space compression ratio. In this respect, an A+P subsystem allows much more flexibility than traditional NATs: the NAT can be placed at the customer and/or in the provider network. In addition, hosts or applications can request ports and thus have untranslated end-to-end connectivity.
遭受IPv4地址空间耗尽的ISP对实现高地址空间压缩率感兴趣。在这方面，A+P子系统比传统NAT具有更大的灵活性：NAT可以放置在客户和/或提供商网络中。此外，主机或应用程序可以请求端口，因此具有未翻译的端到端连接。
+---------------------------+
private | +------+ A+P-in +-----+ | dual-stacked
(RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network
space | +------+ tunnel +-----+ | (public addresses)
| ^ +-----+ |
| | IPv6-only | LSN | |
| | network +-----+ |
+----+----------------- ^ --+
| |
on customer within provider
premises and control network
+---------------------------+
private | +------+ A+P-in +-----+ | dual-stacked
(RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network
space | +------+ tunnel +-----+ | (public addresses)
| ^ +-----+ |
| | IPv6-only | LSN | |
| | network +-----+ |
+----+----------------- ^ --+
| |
on customer within provider
premises and control network
Figure 12: A Simple A+P Subsystem Example
图12：一个简单的A+P子系统示例
Consider the deployment scenario in Figure 12, where an A+P subsystem is formed by the CPE and a PRR within the ISP core network and preferably is close to the customer edge. Inside the subsystem, packets are forwarded based on address and port. The provider MAY deploy an LSN co-located with the PRR to handle packets that have not been translated by the CPE. In such a configuration, the ISP allows the customer to freely decide whether the translation is done at the
考虑图12中的部署场景，其中A+P子系统由CPE和ISP核心网络内的PRR形成，并且优选地接近客户边缘。在子系统内部，根据地址和端口转发数据包。提供商可以部署与PRR位于同一位置的LSN来处理尚未被CPE翻译的分组。在这种配置中，ISP允许客户自由决定是否在同一时间进行翻译
CPE or at the LSN. In order to establish the A+P subsystem, the CPE will be configured automatically (e.g., via a signaling protocol that conforms to the requirements stated above).
CPE或LSN。为了建立A+P子系统，CPE将自动配置（例如，通过符合上述要求的信令协议）。
Note that the CPE in the example above is provisioned with only an IPv6 address on the external interface.
注意，上面示例中的CPE仅在外部接口上配置了IPv6地址。
+------------ IPv6-only transport ------------+
| +---------------+ | | |
| |A+P-application| | +--------+ | +-----+ | dual-stacked
| | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network
| +---------------+ | +--------+ | +-----+ | (public addresses)
+---------------+ | +--------+ | +-----+ |
private IPv4 <-*--+->| NAT | | | LSN | |
address space \ | +--------+ | +-----+ |
for legacy +|--------------|----------+
hosts | |
| |
end-host with | CPE device | provider
upgraded | on customer | network
application | premises |
+------------ IPv6-only transport ------------+
| +---------------+ | | |
| |A+P-application| | +--------+ | +-----+ | dual-stacked
| | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network
| +---------------+ | +--------+ | +-----+ | (public addresses)
+---------------+ | +--------+ | +-----+ |
private IPv4 <-*--+->| NAT | | | LSN | |
address space \ | +--------+ | +-----+ |
for legacy +|--------------|----------+
hosts | |
| |
end-host with | CPE device | provider
upgraded | on customer | network
application | premises |
Figure 13: An Extended A+P Subsystem with End-Host Running A+P-Aware Applications
图13：扩展A+P子系统，终端主机运行A+P感知应用程序
Figure 13 shows an example of how an upgraded application running on a legacy end-host can connect to another host in the public realm. The legacy host is provisioned with a private IPv4 address allocated by the CPE. Any packet sent from the legacy host will be NATed either at the CPE (if configured to do so) or at the LSN (if available).
图13显示了运行在遗留终端主机上的升级应用程序如何连接到公共领域中的另一台主机的示例。传统主机配置有CPE分配的专用IPv4地址。从传统主机发送的任何数据包都将在CPE（如果配置为这样做）或LSN（如果可用）上进行解析。
An A+P-aware application running on the end-host MAY use the signaling described in Section 3.3.1 to connect to the A+P subsystem. In this case, the application will be delegated some space in the A+P address realm, and will be able to contact the public realm (i.e., the public Internet) without the need for translation.
在终端主机上运行的A+P感知应用程序可以使用第3.3.1节中描述的信令连接到A+P子系统。在这种情况下，应用程序将被授予A+P地址域中的一些空间，并且将能够联系公共域（即公共互联网），而无需翻译。
Note that part of A+P signaling is that the NATs are optional. However, if neither the CPE nor the PRR provides NATing functionality, then it will not be possible to connect legacy end-hosts.
注意，A+P信令的一部分是nat是可选的。但是，如果CPE和PRR都不提供本机功能，则无法连接传统终端主机。
To enable packet forwarding with A+P, the ISP MUST install at its A+P border a PRR that encaps/decaps packets. However, to achieve a higher address space compression ratio and/or to support CPEs without NATing functionality, the ISP MAY decide to provide an LSN as well. If no LSN is installed in some part of the ISP's topology, all CPEs
要启用与A+P的数据包转发，ISP必须在其A+P边界安装一个PRR，该PRR用于封装/解压缩数据包。然而，为了实现更高的地址空间压缩比和/或在没有本地功能的情况下支持cpe，ISP也可以决定提供LSN。如果ISP拓扑的某些部分未安装LSN，则所有CPE
in that part of the topology MUST support NAT functionality. For reasons of scalability, it is assumed that the PRR is located within the access portion of the network. The CPE would be configured automatically (e.g., via an extended DHCP or NAT-PMP, which has the signaling requirements stated above) with the address of the PRR and of the LSN (if one is being provided). Figure 12 illustrates a possible deployment scenario.
在该部分中，拓扑必须支持NAT功能。出于可伸缩性的原因，假设PRR位于网络的接入部分内。CPE将自动配置（例如，通过扩展DHCP或NAT-PMP，其具有上述信令要求）具有PRR和LSN的地址（如果提供）。图12说明了一个可能的部署场景。
Allocating a fixed number of ports to all CPEs may lead to exhaustion of ports for high-usage customers. This is a perfect recipe for upsetting more demanding customers. On the other hand, allocating to all customers ports sufficiently to match the needs of peak users will not be very efficient. A mechanism for dynamic allocation of port ranges allows the ISP to achieve two goals: a more efficient compression ratio of the number of customers on one IPv4 address and, on the other hand, no limit of the more demanding customers' communication.
为所有CPE分配固定数量的端口可能会导致高使用率客户的端口耗尽。这是让要求更高的客户感到不安的完美方法。另一方面，为所有客户分配足够的端口以满足高峰用户的需求将不是非常有效。动态分配端口范围的机制允许ISP实现两个目标：一个IPv4地址上客户数量的更有效压缩比，另一方面，对要求更高的客户的通信没有限制。
Additional allocation of ports or port ranges may be made after an initial static allocation of ports.
端口或端口范围的额外分配可在端口的初始静态分配之后进行。
The mechanism would prefer allocations of port ranges from the same IP address as the initial allocation. If it is not possible to allocate an additional port range from the same IP, then the mechanism can allocate a port range from another IP within the same subnet. With every additional port range allocation, the PRR updates its routing table. The mechanism for allocating additional port ranges may be part of normal signaling that is used to authenticate the CPE to the ISP.
该机制倾向于从与初始分配相同的IP地址分配端口范围。如果无法从同一IP分配其他端口范围，则该机制可以从同一子网内的另一IP分配端口范围。每分配一个额外的端口范围，PRR就会更新其路由表。用于分配额外端口范围的机制可以是用于向ISP认证CPE的正常信令的一部分。
The ISP controls the dynamic allocation of port ranges by the PRR by setting the initial allocation size and maximum number of allocations per CPE, or the maximum allocations per subscription, depending on subscription level. There is a general observation that the more demanding customer uses around 1024 ports when heavily communicating. So, for example, a first suggestion might be 128 ports initially and then dynamic allocations of ranges of 128 ports up to 511 more allocations maximum. A configured maximum number of allocations could be used to prevent one customer acting in a destructive manner should they become infected. The maximum number of allocations might also be more finely grained, with parameters of how many allocations a user may request per some time frame. If this is used, evasive applications may need to be limited in their bad behavior; for example, one additional allocation per minute would considerably slow a port request storm.
ISP通过设置初始分配大小和每个CPE的最大分配数，或根据订阅级别设置每个订阅的最大分配数，控制PRR对端口范围的动态分配。一般观察到，要求更高的客户在频繁通信时使用大约1024个端口。因此，例如，第一个建议可能是最初128个端口，然后动态分配128个端口的范围，最多分配511个端口。配置的最大分配数可用于防止一个客户在受到感染时以破坏性方式行事。分配的最大数量也可能更细粒度，参数是用户在某个时间范围内可以请求多少分配。如果使用这种方法，可能需要限制规避应用程序的不良行为；例如，每分钟增加一次分配将大大减缓端口请求风暴。
There is likely no minimum request size. This is because A+P-aware applications running on end-hosts MAY request a single port (or a few ports) for the CPE to be contacted on (e.g., Voice over IP (VoIP) clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port). The implementation on the CPE or PRR will dictate how to handle such requests for smaller blocks: for example, half of available blocks might be used for "block-allocations", 1/6 for single port requests, and the rest for NATing.
可能没有最小请求大小。这是因为在终端主机上运行的A+P感知应用程序可能会请求一个端口（或几个端口）用于联系CPE（例如，IP语音（VoIP）客户端注册公共IP和来自CPE的单个委托端口，并在该端口上接受传入呼叫）。CPE或PRR上的实现将规定如何处理较小块的此类请求：例如，一半可用块可用于“块分配”，1/6用于单端口请求，其余用于本机。
Another possible mechanism to allocate additional ports is UPnP/ NAT-PMP (as defined in Section 3.3.1), if applications behind CPE support it. In the case of the LSN implementation (DS-Lite), as described in Section 3.3.4 about the A+P overall architecture, signaling packets are simply forwarded by the CPE to the LSN and back to the host running the application that requested the ports, and the PRR allocates the requested port to the appropriate CPE. The same behavior may be chosen with AFTR, if requested ports are outside of the static initial port allocation. If a full A+P implementation is selected, then UPnPv2/NAT-PMP packets are accepted by the CPE, processed, and the requested port number is communicated through the normal signaling mechanism between CPE and PRR tunnel endpoints (PCP).
另一种分配额外端口的可能机制是UPnP/NAT-PMP（定义见第3.3.1节），前提是CPE后面的应用程序支持它。在LSN实现（DS Lite）的情况下，如关于A+P总体架构的第3.3.4节所述，CPE只需将信令包转发给LSN并返回运行请求端口的应用程序的主机，PRR将请求的端口分配给适当的CPE。如果请求的端口不在静态初始端口分配范围内，AFTR也可以选择相同的行为。如果选择了完整的a+P实现，则CPE接受并处理UPnPv2/NAT-PMP数据包，并且通过CPE和PRR隧道端点（PCP）之间的正常信令机制传送请求的端口号。
This section provides a detailed example of A+P setup, configuration, and packet flow from an end-host connected to an A+P service provider to any host in the IPv4 Internet, and how the return packets flow back. The following example discusses an A+P-unaware end-host, where the NATing is done at the CPE. Figure 14 illustrates how the CPE receives an IPv4 packet from the end-user device. We first describe the case where the CPE has been configured to provide the NAT functionality (e.g., by the customer through interaction with a website or by automatic signaling). In the following, we call a packet that is translated at the CPE an "A+P-forwarded packet", an analogy with the port-forwarding function employed in today's CPEs. Upon receiving a packet from the internal interface, the CPE translates, encapsulates, and forwards it to the PRR. The NAT on the CPE is assumed to have a default route to the public realm through its tunnel interface.
本节提供了从连接到a+P服务提供商的终端主机到IPv4 Internet中任何主机的a+P设置、配置和数据包流的详细示例，以及返回数据包如何回流。下面的示例讨论A+P-Unknowledge终端主机，在该主机上，本地在CPE上完成。图14说明了CPE如何从最终用户设备接收IPv4数据包。我们首先描述CPE被配置为提供NAT功能的情况（例如，由客户通过与网站交互或通过自动信令）。在下文中，我们将在CPE处翻译的数据包称为“a+P转发数据包”，类似于当今CPE中使用的端口转发功能。当从内部接口接收到数据包时，CPE转换、封装并将其转发给PRR。假定CPE上的NAT具有通过其隧道接口到公共领域的默认路由。
When the PRR receives the A+P-forwarded packet, it decapsulates the inner IPv4 packet and checks the source address. If the source address does match the range assigned to A+P-enabled CPEs, then the PRR simply forwards the decapsulated packet onward. This is always the case for A+P-forwarded packets. Otherwise, the PRR assumes that the packet is not A+P-forwarded and passes it to the LSN function,
当PRR接收到A+P转发数据包时，它会解除内部IPv4数据包的封装并检查源地址。如果源地址与分配给启用+P的CPE的范围不匹配，则PRR仅向前转发解除封装的数据包。对于A+P转发的数据包，情况总是如此。否则，PRR假设该分组不是+P转发的，并将其传递给LSN函数，
which in turn translates and forwards the packet based on the destination address. Figure 14 shows the packet flow for an outgoing A+P-forwarded packet.
然后根据目的地地址转换和转发数据包。图14显示了传出A+P转发数据包的数据包流。
+-----------+
| Host |
+-----+-----+
| | 198.51.100.2
IPv4 datagram 1 | |
| |
v | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
| ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
v ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
| | 192.0.2.1
IPv4 datagram 3 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
v | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
+-----------+
| Host |
+-----+-----+
| | 198.51.100.2
IPv4 datagram 1 | |
| |
v | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
| ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
v ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
| | 192.0.2.1
IPv4 datagram 3 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
v | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 14: Forwarding of Outgoing A+P-Forwarded Packets
图14：发送A+P转发数据包的转发
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 198.51.100.2 |
| | TCP Dst | 80 |
| | TCP Src | 8000 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::1 |
| | IPv6 Src | 2001:db8::2 |
| | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
+-----------------+--------------+-----------------------------+
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 198.51.100.2 |
| | TCP Dst | 80 |
| | TCP Src | 8000 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::1 |
| | IPv6 Src | 2001:db8::2 |
| | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 |
| | IPv4 Src | 192.0.2.3 |
| | TCP Dst | 80 |
| | TCP Src | 100 |
+-----------------+--------------+-----------------------------+
Datagram Header Contents
数据报头内容
An incoming packet undergoes the reverse process. When the PRR receives an IPv4 packet on an external interface, it first checks whether or not the destination address falls within the A+P CPE delegated range. If the address space was delegated, then the PRR encapsulates the incoming packet and forwards it through the appropriate tunnel for that IP/port range. If the address space was not delegated, the packet would be handed to the LSN to check if a mapping is available.
传入的数据包经历相反的过程。当PRR在外部接口上接收到IPv4数据包时，它首先检查目标地址是否在A+P CPE授权范围内。如果地址空间被委派，则PRR将封装传入的数据包，并通过该IP/端口范围的适当隧道将其转发。如果地址空间未被委派，则数据包将被交给LSN，以检查映射是否可用。
Figure 15 shows how an incoming packet is forwarded, under the assumption that the port number matches the port range that was delegated to the CPE.
图15显示了在端口号与委托给CPE的端口范围匹配的假设下，如何转发传入数据包。
+-----------+
| Host |
+-----+-----+
^ | 198.51.100.2
IPv4 datagram 3 | |
| |
| | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
^ ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
| ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
^ | 192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
| | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
+-----------+
| Host |
+-----+-----+
^ | 198.51.100.2
IPv4 datagram 3 | |
| |
| | 198.51.100.1
+---------|---------+
|CPE | |
+--------|||--------+
^ ||| 2001:db8::2
| ||| 192.0.2.3 (100-200)
IPv6 datagram 2| |||
| |||<-IPv4-in-IPv6
| |||
-----|-|||-------
/ | ||| \
| ISP access network |
\ | ||| /
-----|-|||-------
| |||
| ||| 2001:db8::1
+--------|||--------+
|PRR ||| |
+---------|---------+
^ | 192.0.2.1
IPv4 datagram 1 | |
-----|--|--------
/ | | \
| ISP network / |
\ Internet /
-----|--|--------
| |
| | 203.0.113.1
+-----+-----+
| IPv4 Host |
+-----------+
Figure 15: Forwarding of Incoming A+P-Forwarded Packets
图15：传入A+P转发数据包的转发
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::2 |
| | IPv6 Src | 2001:db8::1 |
| | IPv4 Dst | 198.51.100.3 |
| | IP Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 8000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------------------+
+-----------------+--------------+-----------------------------+
| Datagram | Header field | Contents |
+-----------------+--------------+-----------------------------+
| IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv6 datagram 2 | IPv6 Dst | 2001:db8::2 |
| | IPv6 Src | 2001:db8::1 |
| | IPv4 Dst | 198.51.100.3 |
| | IP Src | 203.0.113.1 |
| | TCP Dst | 100 |
| | TCP Src | 80 |
| --------------- | ------------ | --------------------------- |
| IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 |
| | IPv4 Src | 203.0.113.1 |
| | TCP Dst | 8000 |
| | TCP Src | 80 |
+-----------------+--------------+-----------------------------+
Datagram Header Contents
数据报头内容
Note that datagram 1 travels untranslated up to the CPE; thus, the customer has the same control over the translation as he has today -- a home gateway with customizable port-forwarding.
注意，数据报1未经翻译地向上传送到CPE；因此，客户对翻译的控制权与现在一样——一个具有可定制端口转发的家庭网关。
Packets for which the CPE does not have a corresponding port-forwarding rule are tunneled to the PRR that provides the LSN function. We underline that the LSN MUST NOT use the delegated space for NATing. See [RFC6333] for network diagrams that illustrate the packet flow in this case.
CPE没有相应端口转发规则的数据包通过隧道传输到提供LSN功能的PRR。我们强调，LSN不得使用授权空间进行NATing。请参阅[RFC6333]以了解说明本例中数据包流的网络图。
ICMP is problematic for all NATs because it lacks port numbers. A+P routing exacerbates the problem.
ICMP对于所有NAT都有问题，因为它缺少端口号。A+P路由加剧了问题。
Most ICMP messages fall into one of two categories: error reports or ECHO/ECHO replies (commonly known as "pings"). For error reports, the offending packet header is embedded within the ICMP packet; NAT devices can then rewrite that portion and route the packet to the actual destination host. This functionality will remain the same with A+P; however, the PRR will need to examine the embedded header to extract the port number, while the A+P gateway will do the necessary rewriting.
大多数ICMP消息分为两类：错误报告或回显/回显回复（通常称为“ping”）。对于错误报告，在ICMP数据包中嵌入有问题的数据包头；NAT设备随后可以重写该部分，并将数据包路由到实际的目标主机。该功能将与A+P保持相同；然而，PRR将需要检查嵌入式报头以提取端口号，而A+P网关将进行必要的重写。
ECHO and ECHO replies are more problematic. For ECHO, the A+P gateway device must rewrite the "Identifier" and perhaps "Sequence Number" fields in the ICMP request, treating them as if they were port numbers. This way, the PRR can build the correct A+P address for the returning ECHO replies, so they can be correctly routed back to the appropriate host in the same way as TCP/UDP packets. Pings originated from the public realm (Internet) towards an A+P device are not supported.
ECHO和ECHO回复的问题更大。对于ECHO，A+P网关设备必须重写ICMP请求中的“标识符”和“序列号”字段，将其视为端口号。通过这种方式，PRR可以为返回的回显回复构建正确的A+P地址，因此它们可以以与TCP/UDP数据包相同的方式正确路由回相应的主机。不支持从公共领域（Internet）向A+P设备发起的ping。
In order to deliver a fragmented IP packet to its final destination (among those having the same IP address), the PRR should activate a dedicated procedure similar to the one used by [RFC6146], Section 3.5, in the sense that it should reassemble the fragments in order to look at the destination port number.
为了将碎片化IP数据包传送到其最终目的地（在具有相同IP地址的数据包中），PRR应激活一个专用程序，类似于[RFC6146]第3.5节所使用的程序，即它应重新组装碎片以查看目的地端口号。
Note that it is recommended to use a Path MTU Discovery (PMTUD) mechanism (e.g., [RFC1191]).
注意，建议使用路径MTU发现（PMTUD）机制（例如[RFC1191]）。
Security issues related to fragmentation are out of scope of this document. For more details, refer to [RFC1858].
与碎片相关的安全问题超出了本文档的范围。有关更多详细信息，请参阅[RFC1858]。
One limitation that A+P shares with any other IP-address-sharing mechanism is the availability of well-known ports. In fact, services run by customers that share the same IP address will be distinguished by the port number. As a consequence, it will be impossible for two customers who share the same IP address to run services on the same port (e.g., port 80). Unfortunately, working around this limitation usually implies application-specific hacks (e.g., HTTP and HTTPS redirection), discussion of which is out of the scope of this document. Of course, a provider might charge more for giving a customer the well-known port range, 0..1024, thus allowing the customer to provide externally available services. Many applications require the availability of well-known ports. However, those applications are not expected to work in an A+P environment unless they can adapt to work with different ports. Such applications do not work behind today's NATs either.
A+P与任何其他IP地址共享机制共享的一个限制是已知端口的可用性。事实上，共享相同IP地址的客户运行的服务将通过端口号进行区分。因此，共享相同IP地址的两个客户不可能在同一端口（例如端口80）上运行服务。不幸的是，绕过此限制通常意味着特定于应用程序的黑客行为（例如HTTP和HTTPS重定向），对此的讨论超出了本文档的范围。当然，提供商为客户提供众所周知的端口范围0..1024可能会收取更高的费用，从而允许客户提供外部可用的服务。许多应用程序需要知名端口的可用性。但是，除非这些应用程序能够适应不同的端口，否则它们不希望在A+P环境中工作。这些应用程序在今天的NAT背后也不起作用。
Another problem that is common to all NATs is coexistence with IPsec. In fact, a NAT that also translates port numbers prevents the Authentication Header (AH) and Encapsulating Security Payload (ESP) from functioning properly, both in tunnel and in transport mode. In this respect, we stress that, since an A+P subsystem exhibits the same external behavior as a NAT, well-known workarounds (such as [RFC3715]) can be employed.
所有NAT的另一个共同问题是与IPsec共存。事实上，同时转换端口号的NAT会阻止身份验证头（AH）和封装安全负载（ESP）在隧道和传输模式下正常工作。在这方面，我们强调，由于A+P子系统表现出与NAT相同的外部行为，因此可以采用众所周知的变通方法（如[RFC3715]）。
A+P, as all other port-sharing solutions, suffers from the issues documented in [RFC6269], but that's something we'll have to live with.
与所有其他端口共享解决方案一样，A+P也存在[RFC6269]中记录的问题，但这是我们必须面对的问题。
For the host-based A+P, issues related to application conflicts when trying to bind to an out-of-range port are to be further assessed. Note that extensions to the host-based model have been proposed in the past (e.g., the Port-Enhanced Address Resolution Protocol (ARP) extension documented in http://software.merit.edu/pe-arp/).
对于基于主机的A+P，将进一步评估与尝试绑定到范围外端口时的应用程序冲突相关的问题。请注意，过去曾提议对基于主机的模型进行扩展（例如，中记录的端口增强地址解析协议（ARP）扩展）http://software.merit.edu/pe-arp/).
Issues raised by [PR-IP-ISSUES] have been analyzed in [STATELESS-4v6]. As seen in that document, most of the issues apply to host-based port-sharing solutions. A+P is not intended to be a host-based port-sharing solution.
[PR-IP-Issues]提出的问题已在[STATELESS-4v6]中进行了分析。如该文档所示，大多数问题适用于基于主机的端口共享解决方案。A+P不是基于主机的端口共享解决方案。
The conclusion of [STATELESS-4v6] is that the set of issues specifically attributed to A+P either do not apply to CPE-based flavors or can be mitigated. The A+P solution represents a reasonable trade-off compared to alternatives in areas such as binding logging (for data storage purposes) and ease of deployment and operations, all of which are actually facilitated by such a solution.
[STATELESS-4v6]的结论是，专门归因于A+P的一组问题要么不适用于基于CPE的口味，要么可以缓解。与绑定日志记录（用于数据存储目的）和易于部署和操作等领域的替代方案相比，A+P解决方案是一种合理的折衷方案，所有这些实际上都是通过这种解决方案实现的。
With CGNs/LSNs, tracing hackers, spammers, and other criminals will be difficult, requiring logging, recording, and storing of all connection-based mapping information. The need for storage implies a trade-off. On one hand, the LSNs can manage addresses and ports as dynamically as possible in order to maximize aggregation. On the other hand, the more quickly the mapping between private and public space changes, the more information needs to be recorded. This would cause concern not only for law enforcement services, but also for privacy advocates.
使用CGN/LSN，追踪黑客、垃圾邮件发送者和其他罪犯将非常困难，需要记录、记录和存储所有基于连接的映射信息。对存储的需求意味着一种权衡。一方面，LSN可以尽可能动态地管理地址和端口，以最大化聚合。另一方面，私人和公共空间之间的映射变化越快，需要记录的信息就越多。这不仅会引起执法部门的关注，也会引起隐私权倡导者的关注。
A+P offers a better set of trade-offs. All that needs to be logged is the allocation of a range of port numbers to a customer. By design, this will be done rarely, improving scalability. If the NAT functionality is moved further up the tree, the logging requirement will be as well, increasing the load on one node, but giving it more resources to allocate to a busy customer, perhaps decreasing the frequency of allocation requests.
A+P提供了一套更好的折衷方案。需要记录的只是将一系列端口号分配给客户。根据设计，这将很少实现，从而提高了可伸缩性。如果NAT功能进一步向上移动，那么日志记录需求也会随之增加，这会增加一个节点上的负载，但会给它更多的资源分配给忙碌的客户，可能会降低分配请求的频率。
The other extreme is A+P NAT on the customer premises. Such a node would be no different than today's NAT boxes, which do no such logging. We thus conclude that A+P is no worse than today's situation, while being considerably better than CGNs.
另一个极端是客户场所的A+P NAT。这样的节点与今天的NAT盒没有什么不同，NAT盒没有这样的日志记录。因此，我们得出结论，A+P并不比今天的情况更糟，但比CGN要好得多。
The authors wish to especially thank Remi Despres and Pierre Levis for their help on the development of the A+P approach. We also thank David Ward for review, constructive criticism, and interminable questions, and Dave Thaler for useful criticism on "stackable" A+P gateways. We would also like to thank the following persons for their feedback on earlier versions of this work: Rob Austein, Gert Doering, Dino Farinacci, Russ Housley, Ruediger Volk, Tina Tsou, and Pasi Sarolahti.
作者希望特别感谢Remi Despres和Pierre Levis在A+P方法开发方面提供的帮助。我们还感谢David Ward的评论、建设性的批评和没完没了的问题，以及Dave Thaler对“可堆叠”A+P网关的有用批评。我们还要感谢以下人士对本研究早期版本的反馈：Rob Austein、Gert Doering、Dino Farinaci、Russ Housley、Ruediger Volk、Tina Tsou和Pasi Sarolahti。
[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月。
[4rd] Despres, R., Matsushima, S., Murakami, T., and O. Troan, "IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional", Work in Progress, March 2011.
[4]Despres，R.，Matsushima，S.，Murakami，T.，和O.Troan，“跨IPv6服务网络的IPv4剩余部署（第4次）ISP-NAT成为可选”，正在进行的工作，2011年3月。
[A+P-EXPERIMENTS] Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P in the provider's IPv6-only network", Work in Progress, March 2011.
[A+P-实验]Deng，X.，Boucadair，M.，和F.Telecom，“在提供商的纯IPv6网络中实施A+P”，正在进行的工作，2011年3月。
[BCP38] 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.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[BITTORRENT-ADDR-SHARING] Boucadair, M., Grimault, J., Levis, P., and A. Villefranque, "Behavior of BitTorrent service in an IP Shared Address Environment", Work in Progress, March 2011.
[BITTORRENT-ADDR-SHARING]Boucadair，M.，Grimault，J.，Levis，P.，和A.Villefranque，“IP共享地址环境中BITTORRENT服务的行为”，正在进行的工作，2011年3月。
[PCP-BASE] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, July 2011.
[PCP-BASE]Wing，D.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，正在进行的工作，2011年7月。
[PORT-RANGE-OPT] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and T. ZOU), "Huawei Port Range Configuration Options for PPP IPCP", Work in Progress, June 2011.
[PORT-RANGE-OPT]Boucadair，M.，Levis，P.，Bajko，G.，Savolainen，T.，和T.ZOU），“华为PPP IPCP的端口范围配置选项”，正在进行的工作，2011年6月。
[PR-ADDR-ASSIGN] Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, "Port Restricted IP Address Assignment", Work in Progress, September 2010.
[PR-ADDR-ASSIGN]Bajko，G.，Savolainen，T.，Boucadair，M.，和P.Levis，“端口限制IP地址分配”，正在进行的工作，2010年9月。
[PR-IP-ISSUES] Thaler, D., "Issues With Port-Restricted IP Addresses", Work in Progress, February 2010.
[PR-IP-ISSUES]Thaler，D.，“端口受限IP地址的问题”，正在进行的工作，2010年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[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月。
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3715]Aboba，B.和W.Dixon，“IPsec网络地址转换（NAT）兼容性要求”，RFC 3715，2004年3月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737]Arkko，J.，Cotton，M.和L.Vegoda，“为文档保留的IPv4地址块”，RFC 5737，2010年1月。
[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月。
[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月。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，布卡达尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[SHARED-ADDR-OPT] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Work in Progress, December 2009.
[SHARED-ADDR-OPT]Boucadair，M.，Levis，P.，Grimault，J.，Savolainen，T.，和G.Bajko，“共享IP地址解决方案的动态主机配置协议（DHCPv6）选项”，正在进行的工作，2009年12月。
[STATELESS-4v6] Dec, W., Asati, R., Bao, C., and H. Deng, "Stateless 4Via6 Address Sharing", Work in Progress, July 2011.
[无状态4v6]Dec，W.，Asati，R.，Bao，C.，和H.Deng，“无状态4Via6地址共享”，正在进行的工作，2011年7月。
This document has nine primary authors.
本文件有九位主要作者。
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
Gabor Bajko诺基亚电子邮件：Gabor。bajko@nokia.com
Mohamed Boucadair France Telecom 3, Av Francois Chateaux Rennes 35000 France EMail: mohamed.boucadair@orange-ftgroup.co
Mohamed Boucadair法国电信3号，Av Francois Chateaux Rennes 35000法国电子邮件：Mohamed。boucadair@orange-ftgroup.co
Steven M. Bellovin Columbia University 1214 Amsterdam Avenue MC 0401 New York, NY 10027 US Phone: +1 212 939 7149 EMail: bellovin@acm.org
Steven M.Bellovin哥伦比亚大学1214阿姆斯特丹大道MC 0401纽约，NY 10027美国电话：+1 212 939 7149电子邮件：bellovin@acm.org
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 EMail: randy@psg.com
Randy Bush互联网倡议日本5147 Crystal Springs班布里奇岛，华盛顿98110美国电话：+1 206 780 0431 x1电子邮件：randy@psg.com
Luca Cittadini Universita' Roma Tre via della Vasca Navale, 79 Rome, 00146 Italy Phone: +39 06 5733 3215 EMail: luca.cittadini@gmail.com
Luca Cittadini Universita'Roma Tre via della Vasca Navale，79罗马，00146意大利电话：+39 06 5733 3215电子邮件：Luca。cittadini@gmail.com
Olaf Maennel Loughborough University Department of Computer Science - N.2.03 Loughborough United Kingdom Phone: +44 115 714 0042 EMail: o@maennel.net
奥拉夫·梅内尔·拉夫堡大学计算机科学系-N.2.03英国拉夫堡电话：+44 115 714 0042电子邮件：o@maennel.net
Reinaldo Penno Juniper Networks 1194 North Mathilda Avenue Sunnyvale, California 94089 US EMail: rpenno@juniper.net
Reinaldo Penno Juniper Networks 1194 North Mathilda Avenue Sunnyvale，California 94089美国电子邮件：rpenno@juniper.net
Teemu Savolainen Nokia Hermiankatu 12 D TAMPERE, FI-33720 Finland EMail: teemu.savolainen@nokia.com
Teemu Savolainen诺基亚Hermiankatu 12 D TAMPERE，FI-33720芬兰电子邮件：Teemu。savolainen@nokia.com
Jan Zorz Go6 Institute Slovenia Frankovo naselje 165 Skofja Loka, 4220 Slovenia EMail: jan@go6.si
Jan Zorz Go6研究所斯洛文尼亚Frankovo naselje 165 Skofja Loka，4220斯洛文尼亚电子邮件：jan@go6.si
Editor's Address
编辑地址
Randy Bush (editor) Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 US
兰迪·布什（编辑）互联网倡议日本5147水晶泉班布里奇岛，华盛顿98110美国
Phone: +1 206 780 0431 x1
EMail: randy@psg.com
Phone: +1 206 780 0431 x1
EMail: randy@psg.com