Internet Engineering Task Force (IETF) M. Ford, Ed.
Request for Comments: 6269 Internet Society
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Durand
Juniper Networks
P. Levis
France Telecom
P. Roberts
Internet Society
June 2011
Internet Engineering Task Force (IETF) M. Ford, Ed.
Request for Comments: 6269 Internet Society
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Durand
Juniper Networks
P. Levis
France Telecom
P. Roberts
Internet Society
June 2011
Issues with IP Address Sharing
IP地址共享问题
Abstract
摘要
The completion of IPv4 address allocations from IANA and the Regional Internet Registries (RIRs) is causing service providers around the world to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches. Such issues include application failures, additional service monitoring complexity, new security vulnerabilities, and so on. Solution-specific discussions are out of scope.
IANA和区域互联网注册中心（RIR）完成IPv4地址分配后，世界各地的服务提供商开始质疑，当不再有足够的IPv4地址为每个订阅者分配一个IPv4地址时，他们将如何继续向订阅者提供IPv4连接服务。基于共享IPv4寻址的思想，现在出现了几个解决此问题的可能方案。这些解决方案引发了许多问题，本备忘录确定了所有此类地址共享方法的共同点。这些问题包括应用程序故障、额外的服务监控复杂性、新的安全漏洞等。特定于解决方案的讨论超出范围。
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein.
部署IPv6是缓解公共IPv4地址池压力的唯一长期方法，而不需要引起本文所述问题的地址共享机制。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/rfc6269.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6269.
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
2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
3. Analysis of Issues as They Relate to First and Third
Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 22
19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
25. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
Appendix B. Address Space Multiplicative Factor . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Shared Addressing Solutions . . . . . . . . . . . . . . . . . 4
3. Analysis of Issues as They Relate to First and Third
Parties . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Content Provider Example . . . . . . . . . . . . . . . . . . . 8
5. Port Allocation . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Outgoing Ports . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Incoming Ports . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. Port Negotiation . . . . . . . . . . . . . . . . . . . 11
5.2.2. Connection to a Well-Known Port Number . . . . . . . . 12
5.2.3. Port Discovery Mechanisms . . . . . . . . . . . . . . 12
6. Impact on Applications . . . . . . . . . . . . . . . . . . . . 12
7. Geo-location and Geo-proximity . . . . . . . . . . . . . . . . 14
8. Tracking Service Usage . . . . . . . . . . . . . . . . . . . . 15
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. MTU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Abuse Logging and Penalty Boxes . . . . . . . . . . . . . 18
13.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 19
13.3. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.4. Port Randomization . . . . . . . . . . . . . . . . . . . . 19
13.5. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.6. Policing Forwarding Behavior . . . . . . . . . . . . . . . 20
14. Transport Issues . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Parallel Connections . . . . . . . . . . . . . . . . . . . 20
14.2. Serial Connections . . . . . . . . . . . . . . . . . . . . 20
14.3. TCP Control Block Sharing . . . . . . . . . . . . . . . . 21
15. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 21
16. Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . 21
17. IPv6 Transition Issues . . . . . . . . . . . . . . . . . . . . 21
18. Introduction of Single Points of Failure . . . . . . . . . . . 22
19. State Maintenance Reduces Battery Life . . . . . . . . . . . . 22
20. Support of Multicast . . . . . . . . . . . . . . . . . . . . . 22
21. Support of Mobile-IP . . . . . . . . . . . . . . . . . . . . . 22
22. Security Considerations . . . . . . . . . . . . . . . . . . . 23
23. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23
24. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
25. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Classes of Address Sharing Solution . . . . . . . . . 27
Appendix B. Address Space Multiplicative Factor . . . . . . . . . 27
Allocations of IPv4 addresses from the Internet Assigned Numbers Authority (IANA) were completed on February 3, 2011 [IPv4_Pool]. Allocations from Regional Internet Registries (RIRs) are anticipated to be complete around a year later, although the exact date will vary from registry to registry. This is causing service providers around the world to start to question how they will continue providing IPv4 connectivity service to their subscribers when there are no longer sufficient IPv4 addresses to allocate them one per subscriber. Several possible solutions to this problem are now emerging based around the idea of shared IPv4 addressing. These solutions give rise to a number of issues, and this memo identifies those common to all such address sharing approaches and collects them in a single document.
互联网分配号码管理局（IANA）的IPv4地址分配已于2011年2月3日完成[IPv4_池]。区域互联网登记处（RIR）的拨款预计将在大约一年后完成，尽管具体日期因登记处而异。这导致世界各地的服务提供商开始质疑，当不再有足够的IPv4地址为每个订户分配一个IPv4连接服务时，他们将如何继续向订户提供IPv4连接服务。基于共享IPv4寻址的思想，现在出现了几个解决此问题的可能方案。这些解决方案引发了许多问题，本备忘录确定了所有此类地址共享方法的共同点，并将其收集在一个文档中。
Deploying IPv6 is the only perennial way to ease pressure on the public IPv4 address pool without the need for address sharing mechanisms that give rise to the issues identified herein. In the short term, maintaining growth of IPv4 services in the presence of IPv4 address depletion will require address sharing. Address sharing will cause issues for end-users, service providers, and third parties such as law enforcement agencies and content providers. This memo is intended to highlight and briefly discuss these issues.
部署IPv6是缓解公共IPv4地址池压力的唯一长期方法，而不需要引起本文所述问题的地址共享机制。在短期内，在IPv4地址耗尽的情况下保持IPv4服务的增长将需要地址共享。地址共享将给最终用户、服务提供商和第三方（如执法机构和内容提供商）带来问题。本备忘录旨在强调并简要讨论这些问题。
Increased IPv6 deployment should reduce the burden being placed on an address sharing solution, and should reduce the costs of operating that solution. Increasing IPv6 deployment should cause a reduction in the number of concurrent IPv4 sessions per subscriber. If the percentage of end-to-end IPv6 traffic significantly increases, so that the volume of IPv4 traffic begins decreasing, then the number of IPv4 sessions will decrease. The smaller the number of concurrent IPv4 sessions per subscriber, the higher the number of subscribers able to share the same IPv4 public address, and consequently, the lower the number of IPv4 public addresses required. However, this effect will only occur for subscribers who have both an IPv6 access and a shared IPv4 access. This motivates a strategy to systematically bind a shared IPv4 access to an IPv6 access. It is difficult to foresee to what extent growing IPv6 traffic will reduce the number of concurrent IPv4 sessions, but in any event, IPv6 deployment and use should reduce the pressure on the available public IPv4 address pool.
增加IPv6部署应可减轻地址共享解决方案的负担，并应降低该解决方案的运营成本。增加IPv6部署应该会减少每个订阅服务器的并发IPv4会话数。如果端到端IPv6通信量的百分比显著增加，以致IPv4通信量开始减少，则IPv4会话数将减少。每个订阅者的并发IPv4会话数越小，能够共享相同IPv4公共地址的订阅者数越高，因此所需的IPv4公共地址数越低。但是，这种影响只会发生在同时具有IPv6访问和共享IPv4访问的订阅服务器上。这激发了一种将共享IPv4访问系统地绑定到IPv6访问的策略。很难预测不断增长的IPv6流量会在多大程度上减少并发IPv4会话的数量，但无论如何，IPv6的部署和使用应该会减少对可用公共IPv4地址池的压力。
In many networks today, a subscriber is provided with a single public IPv4 address at their home or small business. For instance, in fixed broadband access, an IPv4 public address is assigned to each CPE
在当今的许多网络中，用户在家中或小型企业中都有一个单一的公共IPv4地址。例如，在固定宽带接入中，将IPv4公共地址分配给每个CPE
(Customer Premises Equipment). CPEs embed a NAT function that is responsible for translating private IPv4 addresses ([RFC1918] addresses) assigned to hosts within the local network, to the public IPv4 address assigned by the service provider (and vice versa). Therefore, devices located with the LAN share the single public IPv4 address and they are all associated with a single subscriber account and a single network operator.
（客户场所设备）。CPE嵌入了一个NAT功能，该功能负责将分配给本地网络内主机的专用IPv4地址（[RFC1918]地址）转换为服务提供商分配的公共IPv4地址（反之亦然）。因此，位于LAN的设备共享单个公共IPv4地址，并且它们都与单个订户帐户和单个网络运营商关联。
A number of proposals currently under consideration in the IETF rely upon the mechanism of multiplexing multiple subscribers' connections over a smaller number of shared IPv4 addresses. This is a significant change. These proposals include Carrier Grade NAT (CGN a.k.a. LSN for Large Scale NAT) [LSN-REQS], Dual-Stack Lite [DS-Lite], NAT64 [RFC6145] [RFC6146], Address+Port (A+P) proposals [A+P] [PORT-RANGE], and Stateless Address Mapping [SAM]. Appendix A and Appendix B provide a classification of these different types of solutions and discuss some of the design considerations to be borne in mind when deploying large-scale address sharing. Whether we're talking about DS-Lite, A+P, NAT64, or CGN isn't especially important -- it's the view from the outside that matters, and given that, most of the issues identified below apply regardless of the specific address sharing scenario in question.
IETF中目前正在考虑的许多方案依赖于在少量共享IPv4地址上多路复用多个用户连接的机制。这是一个重大变化。这些方案包括载波级NAT（CGN a.k.a.LSN，用于大规模NAT）[LSN-REQS]、双栈Lite[DS Lite]、NAT64[RFC6145][RFC6146]、地址+端口（a+P）方案[a+P][Port RANGE]，以及无状态地址映射[SAM]。附录A和附录B对这些不同类型的解决方案进行了分类，并讨论了部署大规模地址共享时应牢记的一些设计注意事项。无论我们谈论的是DS Lite、A+P、NAT64还是CGN都不是特别重要——重要的是外部的观点，鉴于此，下面确定的大多数问题都适用，而不管所讨论的具体地址共享场景如何。
In these new proposals, a single public IPv4 address would be shared by multiple homes or small businesses (i.e., multiple subscribers), so the operational paradigm described above would no longer apply. In this document, we refer to this new paradigm as large-scale address sharing. All these proposals extend the address space by adding port information; they differ in the way they manage the port value.
在这些新提案中，单个公共IPv4地址将由多个家庭或小型企业（即多个订户）共享，因此上述运营模式将不再适用。在本文中，我们将这种新范式称为大规模地址共享。所有这些方案都通过添加端口信息来扩展地址空间；它们管理端口值的方式不同。
Security issues associated with NAT have long been documented (see [RFC2663] and [RFC2993]). However, sharing IPv4 addresses across multiple subscribers by any means, either moving the NAT functionality from the home gateway to the core of the service provider network or restricting the port choice in the subscriber's NAT, creates additional issues for subscribers, content providers, and network operators. Many of these issues are created today by public Wi-Fi hotspot deployments. As such large-scale address sharing solutions become more widespread in the face of IPv4 address depletion, these issues will become both more severe and more commonly felt. NAT issues in the past typically only applied to a single legal entity; as large-scale address sharing becomes more prevalent, these issues will increasingly span across multiple legal entities simultaneously.
与NAT相关的安全问题早就被记录在案（参见[RFC2663]和[RFC2993]）。但是，通过任何方式在多个订阅者之间共享IPv4地址，或者将NAT功能从家庭网关移动到服务提供商网络的核心，或者限制订阅者NAT中的端口选择，都会给订阅者、内容提供商和网络运营商带来额外的问题。如今，公共Wi-Fi热点部署造成了许多此类问题。随着这种大规模地址共享解决方案在IPv4地址耗尽的情况下变得越来越普遍，这些问题将变得更加严重，也更加普遍。过去的NAT问题通常只适用于单个法律实体；随着大规模地址共享变得越来越普遍，这些问题将越来越多地同时跨越多个法律实体。
All large-scale address sharing proposals share technical and operational issues, and these are addressed in the sections that follow. These issues are common to any service-provider NAT, enterprise NAT, and also non-NAT solutions that share individual IPv4 addresses across multiple subscribers. This document is intended to bring all of these issues together in one place.
所有大型地址共享方案都有技术和操作问题，这些问题将在下面的章节中讨论。这些问题对于任何服务提供商NAT、企业NAT以及跨多个订阅者共享单个IPv4地址的非NAT解决方案都是常见的。本文件旨在将所有这些问题集中在一个地方。
In this section, we present an analysis of whether the issues identified in the remainder of this document are applicable to the organization deploying the shared addressing mechanism (and by extension their subscribers) and/or whether these issues impact third parties (e.g., content providers, law enforcement agencies, etc.). In this analysis, issues that affect end-users are deemed to affect first parties, as end-users can be expected to complain to their service provider when problems arise. Where issues can expect to be foreseen and addressed by the party deploying the shared addressing solution, they are not attributed.
在本节中，我们将分析本文件其余部分中确定的问题是否适用于部署共享寻址机制的组织（及其订户），以及/或者这些问题是否影响第三方（例如，内容提供商、执法机构等）。在本分析中，影响最终用户的问题被视为影响第一方，因为当出现问题时，最终用户可能会向其服务提供商投诉。如果部署共享寻址解决方案的一方可以预见并解决问题，则不将其归因于此。
In Figure 1, we have also tried to indicate (with 'xx') where issues are newly created in addition to what could be expected from the introduction of a traditional NAT device. Issues marked with a single 'x' are already present today in the case of typical CPE NAT; however, they can be expected to be more severe and widespread in the case of large-scale address sharing.
在图1中，除了传统NAT设备的引入可能带来的问题外，我们还尝试指出（使用“xx”）新产生的问题。在典型的CPE NAT中，标有单个“x”的问题已经存在；然而，在大规模地址共享的情况下，它们可能会更加严重和广泛。
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | |
| ports will impact performance for end-users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Assigned Ports will | x | |
| not work | | |
| | | |
| Port discovery mechanisms will not work | x | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| Assumptions about parallel/serial connections | x | x |
| may fail | | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| Restricted allocations of outgoing | x | |
| ports will impact performance for end-users | | |
| | | |
| Incoming port negotiation mechanisms may fail | xx | |
| | | |
| Incoming connections to Assigned Ports will | x | |
| not work | | |
| | | |
| Port discovery mechanisms will not work | x | |
| | | |
| Some applications will fail to operate | x | x |
| | | |
| Assumptions about parallel/serial connections | x | x |
| may fail | | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x |
| | | |
| Reverse DNS will be affected | x | x |
| | | |
| Inbound ICMP will fail in many cases | x | x |
| | | |
| Amplification of security issues will occur | xx | xx |
| | | |
| Fragmentation will require special handling | x | |
| | | |
| Single points of failure and increased | x | |
| network instability may occur | | |
| | | |
| Port randomization will be affected | x | |
| | | |
| Service usage monitoring and abuse logging | xx | xx |
| will be impacted for all elements in the chain | | |
| between service provider and content provider | | |
| | | |
| Penalty boxes will no longer work | xx | xx |
| | | |
| Spam blacklisting will be affected | xx | xx |
| | | |
| Geo-location services will be impacted | xx | xx |
| | | |
| Geo-proximity mechanisms will be impacted | xx | xx |
| | | |
| Load balancing algorithms may be impacted | | xx |
| | | |
| Authentication mechanisms may be impacted | | x |
| | | |
| Traceability of network usage and abusage will | | xx |
| be affected | | |
| | | |
| IPv6 transition mechanisms will be affected | xx | |
| | | |
| Frequent keep-alives will reduce battery life | x | |
| | | |
+------------------------------------------------+--------+---------+
+------------------------------------------------+--------+---------+
| Issue | 1st | 3rd |
| | party | parties |
+------------------------------------------------+--------+---------+
| TCP control block sharing will be affected | x | x |
| | | |
| Reverse DNS will be affected | x | x |
| | | |
| Inbound ICMP will fail in many cases | x | x |
| | | |
| Amplification of security issues will occur | xx | xx |
| | | |
| Fragmentation will require special handling | x | |
| | | |
| Single points of failure and increased | x | |
| network instability may occur | | |
| | | |
| Port randomization will be affected | x | |
| | | |
| Service usage monitoring and abuse logging | xx | xx |
| will be impacted for all elements in the chain | | |
| between service provider and content provider | | |
| | | |
| Penalty boxes will no longer work | xx | xx |
| | | |
| Spam blacklisting will be affected | xx | xx |
| | | |
| Geo-location services will be impacted | xx | xx |
| | | |
| Geo-proximity mechanisms will be impacted | xx | xx |
| | | |
| Load balancing algorithms may be impacted | | xx |
| | | |
| Authentication mechanisms may be impacted | | x |
| | | |
| Traceability of network usage and abusage will | | xx |
| be affected | | |
| | | |
| IPv6 transition mechanisms will be affected | xx | |
| | | |
| Frequent keep-alives will reduce battery life | x | |
| | | |
+------------------------------------------------+--------+---------+
Figure 1: Shared addressing issues for first and third parties
图1：第一方和第三方的共享解决问题
As can be seen from Figure 1, deployment of large-scale address sharing will create almost as many problems for third parties as it does for the service provider deploying the address sharing mechanism. Several of these issues are specific to the introduction of large-scale address sharing as well. All of these issues are discussed in further detail below.
从图1可以看出，大规模地址共享的部署将为第三方带来几乎与部署地址共享机制的服务提供商一样多的问题。其中有几个问题也与大规模地址共享的引入有关。下面将进一步详细讨论所有这些问题。
Taking a content provider as an example of a third party, and focusing on the issues that are created specifically by the presence of large-scale address sharing, we identify the following issues as being of particular concern:
以内容提供商作为第三方的例子，重点关注大规模地址共享带来的问题，我们发现以下问题特别值得关注：
o Degraded geo-location for targeted advertising and licensed content restrictions (see Section 7).
o 针对目标广告和许可内容限制的降级地理位置（见第7节）。
o Additional latency due to indirect routing and degraded geo-proximity (see Section 7).
o 间接路由和地理位置邻近性降低导致的额外延迟（见第7节）。
o Exposure to new amplification attacks (see Section 13).
o 暴露于新的放大攻击（见第13节）。
o Service usage monitoring is made more complicated (see Section 8).
o 服务使用监控变得更加复杂（参见第8节）。
o Incoming port negotiation mechanisms may fail (see Section 5.2.1).
o 传入端口协商机制可能失败（见第5.2.1节）。
o IP blocking for abuse/spam will cause collateral damage (see Section 13).
o 滥用/垃圾邮件的IP阻止将造成附带损害（见第13节）。
o Load balancing algorithms may be impacted (see Section 16).
o 负载平衡算法可能会受到影响（参见第16节）。
o Traceability of network usage and abuse will be impacted (see Section 12).
o 网络使用和滥用的可追溯性将受到影响（见第12节）。
When we talk about port numbers, we need to make a distinction between outgoing connections and incoming connections. For outgoing connections, the actual source port number used is usually irrelevant. (While this is true today, in a port-range solution, it is necessary for the source port to be within the allocated range.) But for incoming connections, the specific port numbers allocated to subscribers matter because they are part of external referrals (used by third parties to contact services run by the subscribers).
当我们谈论端口号时，我们需要区分传出连接和传入连接。对于传出连接，实际使用的源端口号通常不相关。（虽然这在今天的端口范围解决方案中是正确的，但源端口必须在分配的范围内。）但对于传入连接，分配给订阅者的特定端口号很重要，因为它们是外部引用的一部分（由第三方用于联系订阅者运行的服务）。
The total number of subscribers able to share a single IPv4 address will depend upon assumptions about the average number of ports required per active subscriber, and the average number of
能够共享单个IPv4地址的订阅者总数将取决于对每个活动订阅者所需的平均端口数和平均端口数的假设
simultaneously active subscribers. It is important to realize that the TCP design makes it undesirable for clients to re-use ports while they remain in the TIME-WAIT state (typically 4 minutes after the connection has concluded). TIME-WAIT state removes the hazard of old duplicates for "fast" or "long" connections, in which clock-driven Initial Sequence Number selection is unable to prevent overlap of the old and new sequence spaces. The TIME-WAIT delay allows all old duplicate segments time enough to die in the Internet before the connection is reopened [RFC1337]. Therefore, ports in this state must be included in calculations concerning port usage per subscriber.
同时激活用户。重要的是要认识到，TCP设计不希望客户端在保持等待状态（通常在连接结束后4分钟）时重复使用端口。TIME-WAIT状态消除了“快”或“长”连接的旧副本的危险，在这种情况下，时钟驱动的初始序列号选择无法防止新旧序列空间重叠。等待时间延迟允许所有旧的重复段在重新打开连接之前有足够的时间在Internet上消失[RFC1337]。因此，此状态下的端口必须包含在有关每个订户的端口使用情况的计算中。
Most of the time the source port selected by a client application will be translated (unless there is direct knowledge of a port-range restriction in the client's stack), either by a NAT in the subscriber's device, or by a CPE NAT, or by a CPE NAT and a CGN.
大多数情况下，客户机应用程序选择的源端口将被用户设备中的NAT、CPE NAT或CPE NAT和CGN转换（除非直接知道客户机堆栈中的端口范围限制）。
[RFC1700] (which was replaced by an online database, as described by [RFC3232]) defines the Assigned Ports (both System and User). IANA has further classified the whole port space into three categories, as defined in [IANA_Ports]:
[RFC1700]（由在线数据库代替，如[RFC3232]所述）定义分配的端口（系统和用户）。IANA进一步将整个港口空间分为三类，如[IANA_Ports]中所定义：
o The Well-Known Ports are those from 0 through 1023.
o 众所周知的端口是从0到1023的端口。
o The Registered Ports are those from 1024 through 49151.
o 注册端口为1024到49151之间的端口。
o The Dynamic and/or Private Ports are those from 49152 through 65535.
o 动态和/或专用端口是从49152到65535的端口。
[RFC4787] notes that current NATs have different policies with regard to this classification; some NATs restrict their translations to the use of dynamic ports, some also include registered ports, some preserve the port if it is in the well-known range. [RFC4787] makes it clear that the use of port space (1024-65535) is safe: "mapping a source port to a source port that is already registered is unlikely to have any bad effects". Therefore, for all address sharing solutions, there is no reason to only consider a subset of the port space (1024-65535) for outgoing source ports.
[RFC4787]注意到当前的NAT对此分类有不同的政策；一些NAT将其转换限制为使用动态端口，一些NAT还包括注册端口，一些NAT保留已知范围内的端口。[RFC4787]明确指出，端口空间（1024-65535）的使用是安全的：“将源端口映射到已注册的源端口不太可能产生任何不良影响”。因此，对于所有的地址共享解决方案，没有理由只考虑端口空间的一个子集（1024—655 35）用于输出源端口。
According to measurements, the average number of outgoing ports consumed per active subscriber is much, much smaller than the maximum number of ports a subscriber can use at any given time. However, the distribution is heavy-tailed, so there are typically a small number of subscribers who use a very high number of ports [CGN_Viability]. This means that an algorithm that dynamically allocates outgoing port numbers from a central pool will typically allow more subscribers to
根据测量结果，每个活动用户使用的传出端口的平均数量远小于用户在任何给定时间可以使用的最大端口数量。但是，该分布是重尾分布，因此通常只有少数用户使用非常多的端口[CGN_]。这意味着动态分配来自中央池的传出端口号的算法通常会允许更多订阅者访问
share a single IPv4 address than algorithms that statically divide the resource by pre-allocating a fixed number of ports to each subscriber. Similarly, such an algorithm should be more able to accommodate subscribers wishing to use a relatively high number of ports.
共享单个IPv4地址，而不是通过向每个订户预先分配固定数量的端口来静态划分资源的算法。类似地，这种算法应该能够更好地适应希望使用相对较多端口的用户。
It is important to note here that the desire to dynamically allocate outgoing port numbers will make a service provider's job of maintaining records of subscriber port number allocations considerably more onerous (see Section 12). The number of records per subscriber will increase from 1 in a scheme where ports are statically allocated, to a much larger number equivalent to the total number of outgoing ports consumed by that subscriber during the time period for which detailed logs must be kept.
这里需要注意的是，动态分配传出端口号的愿望将使服务提供商维护订户端口号分配记录的工作更加繁重（参见第12节）。在静态分配端口的方案中，每个订阅服务器的记录数将从1增加到相当于该订阅服务器在必须保存详细日志的时间段内消耗的传出端口总数的更大数量。
A potential problem with dynamic allocation occurs when one of the subscriber devices behind such a port-shared IPv4 address becomes infected with a worm, which then quickly sets about opening many outbound connections in order to propagate itself. Such an infection could rapidly exhaust the shared resource of the single IPv4 address for all connected subscribers. It is therefore necessary to impose limits on the total number of ports available to an individual subscriber to ensure that the shared resource (the IPv4 address) remains available in some capacity to all the subscribers using it. However, static schemes for ports assignment may introduce security issues [RFC6056] when small contiguous port ranges are statically assigned to subscribers. Another way to mitigate this issue is to kill off (randomly) established connections when the port space runs out. A user with many connections will be proportionally more likely to get impacted.
动态分配的一个潜在问题发生在这样一个端口共享IPv4地址后面的一个订户设备感染蠕虫时，蠕虫随后会迅速开始打开许多出站连接以传播自身。这种感染可能会迅速耗尽所有已连接订户的单个IPv4地址的共享资源。因此，有必要对单个订阅者可用的端口总数施加限制，以确保共享资源（IPv4地址）在某些容量下对使用它的所有订阅者保持可用。然而，当小的连续端口范围被静态分配给订户时，端口分配的静态方案可能会引入安全问题[RFC6056]。缓解此问题的另一种方法是在端口空间用完时关闭（随机）建立的连接。具有多个连接的用户在比例上更容易受到影响。
Session failure due to NAT state overflow or timeout (when the NAT discards session state because it's run out of resource) can be experienced when the configured quota per user is reached or if the NAT is out of resources.
当达到每个用户配置的配额或NAT资源不足时，可能会遇到由于NAT状态溢出或超时（NAT因资源不足而放弃会话状态）导致的会话失败。
It is desirable to ensure that incoming ports remain stable over time. This is challenging as the network doesn't know anything in particular about the applications that it is supporting, and therefore has no real notion of how long an application/service session is still ongoing and therefore requiring port stability.
希望确保传入端口随时间保持稳定。这是一个挑战，因为网络不知道它所支持的应用程序的任何特定信息，因此不知道应用程序/服务会话持续多长时间，因此需要端口稳定性。
Early measurements [CGN_Viability] also seem to indicate that, on average, only very few ports are used by subscribers for incoming connections. However, a majority of subscribers accept at least one inbound connection.
早期的测量[CGN_生存能力]似乎也表明，平均而言，订阅者只使用很少的端口进行传入连接。但是，大多数订阅服务器至少接受一个入站连接。
This means that it is not necessary to pre-allocate a large number of incoming ports to each subscriber. It is possible to either pre-allocate a small number of ports for incoming connections or do port allocation on demand when the application wishing to receive a connection is initiated. The bulk of incoming ports can be reserved as a centralized resource shared by all subscribers using a given public IPv4 address.
这意味着无需为每个订户预先分配大量的传入端口。可以为传入连接预先分配少量端口，也可以在希望接收连接的应用程序启动时按需分配端口。大部分传入端口可以保留为使用给定公共IPv4地址的所有订户共享的集中资源。
In current deployments, one important and widely used feature of many CPE devices is the ability to open incoming ports (port forwarding) either manually, or with a protocol such as the Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD]. If a CGN is present, the port must also be opened in the CGN. CGN makes subscribers dependent on their service provider for this functionality.
在当前部署中，许多CPE设备的一个重要且广泛使用的功能是能够手动或使用通用即插即用互联网网关设备（UPnP IGD）[UPnP IGD]等协议打开传入端口（端口转发）。如果存在CGN，则还必须在CGN中打开端口。CGN使订阅者依赖其服务提供商来实现此功能。
CPE and CGN will need to cooperate in order for port forwarding functionality to work. UPnP, or NAT-PMP proxy could be a solution if there is a direct link (or tunnel) between the CPE and the CGN. An alternative solution is a web interface to configure the incoming port mapping on the CGN. Protocol development is underway in the IETF to provide a generalized, automated solution via the Port Control Protocol [PCP].
CPE和CGN需要合作，以便端口转发功能正常工作。如果CPE和CGN之间存在直接链路（或隧道），UPnP或NAT-PMP代理可能是解决方案。另一种解决方案是在CGN上配置传入端口映射的web界面。IETF正在进行协议开发，以通过端口控制协议[PCP]提供通用的自动化解决方案。
Note that such an interface effectively makes public what was previously a private management interface and this raises security concerns that must be addressed.
请注意，这样的接口有效地公开了以前的私有管理接口，这引起了必须解决的安全问题。
For port-range solutions, port forwarding capabilities may still be present at the CPE, with the limitation that the open incoming port must be within the allocated port range (for instance, it is not possible to open port 5002 for incoming connections if port 5002 is not within the allocated port range).
对于端口范围解决方案，端口转发功能可能仍然存在于CPE，但限制是打开的传入端口必须在分配的端口范围内（例如，如果端口5002不在分配的端口范围内，则无法为传入连接打开端口5002）。
Using the UPnP semantic, an application asks "I want to use port number X, is that OK?", and the answer is yes or no. If the answer is no, the application will typically try the next port in sequence, until it either finds one that works or gives up after a limited number of attempts. UPnP IGD 1.0 has no way to redirect the application to use another port number. UPnP IGD 2.0 improves this situation and allows for allocation of any available port.
使用UPnP语义，应用程序会询问“我想使用端口号X，可以吗？”，答案是“是”或“否”。如果答案是“否”，应用程序通常会依次尝试下一个端口，直到找到一个可以工作的端口或在有限的尝试次数后放弃。UPnP IGD 1.0无法重定向应用程序以使用其他端口号。UPnP IGD 2.0改进了这种情况，并允许分配任何可用端口。
NAT-PMP enables the NAT to redirect the requesting application to a port deemed to be available for use by the NAT state mapping table.
NAT-PMP使NAT能够将请求应用程序重定向到NAT状态映射表认为可用的端口。
Once an IPv4-address sharing mechanism is in place, inbound connections to well-known port numbers will not work in the general case. Any application that is not port-agile cannot be expected to work. Some workaround (e.g., redirects to a port-specific URI) could be deployed given sufficient incentives. There exist several proposals for 'application service location' protocols that would provide a means of addressing this problem, but historically these proposals have not gained much deployment traction.
一旦IPv4地址共享机制到位，到已知端口号的入站连接在一般情况下将不起作用。任何不是端口敏捷的应用程序都无法正常工作。如果有足够的激励，可以部署一些变通方法（例如重定向到特定于端口的URI）。对于“应用程序服务位置”协议，有几种建议可以提供解决此问题的方法，但从历史上看，这些建议并没有获得太多的部署吸引力。
For example, the use of DNS SRV records [RFC2782] provides a potential solution for subscribers wishing to host services in the presence of a shared-addressing scheme. SRV records make it possible to specify a port value related to a service, thereby making services accessible on ports other than the well-known ports. It is worth noting that this mechanism is not applicable to HTTP and many other protocols.
例如，DNS SRV记录[RFC2782]的使用为希望在共享寻址方案存在的情况下托管服务的订户提供了一个潜在的解决方案。SRV记录使指定与服务相关的端口值成为可能，从而使服务可以在已知端口以外的端口上访问。值得注意的是，此机制不适用于HTTP和许多其他协议。
Port discovery using a UDP port to discover a service available on a corresponding TCP port, either through broadcast, multicast, or unicast, is a commonly deployed mechanism. Unsolicited inbound UDP will be dropped by address sharing mechanisms as they have no live mapping to enable them to forward the packet to the appropriate host. Address sharing thereby breaks this service discovery technique.
端口发现使用UDP端口通过广播、多播或单播来发现相应TCP端口上可用的服务，这是一种常用的部署机制。地址共享机制将丢弃未经请求的入站UDP，因为它们没有实时映射，无法将数据包转发到适当的主机。因此，地址共享破坏了这种服务发现技术。
Address sharing solutions will have an impact on the following types of applications:
地址共享解决方案将对以下类型的应用程序产生影响：
o Applications that establish inbound communications - These applications will have to ensure that ports selected for inbound communications are either within the allocated range (for port-range solutions) or are forwarded appropriately by the CGN (for CGN-based solutions). See Section 5.2 for more discussion.
o 建立入站通信的应用程序-这些应用程序必须确保为入站通信选择的端口在分配范围内（对于端口范围解决方案）或由CGN适当转发（对于基于CGN的解决方案）。更多讨论见第5.2节。
o Applications that carry address and/or port information in their payload - Where translation of port and/or address information is performed at the IP and transport layers by the address sharing solution, an ALG will also be required to ensure application-layer
o 在其有效负载中携带地址和/或端口信息的应用程序-如果通过地址共享解决方案在IP和传输层执行端口和/或地址信息的转换，还需要ALG来确保应用层
data is appropriately modified. Note that ALGs are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around a lack of ALGs in address translators, to the point of it being preferable to avoid any support in the NAT.
数据经过适当修改。请注意，在某些情况下需要ALG，而在许多其他情况下，端到端协议机制已经开发出来，以解决地址转换器中缺少ALG的问题，因此最好避免NAT中的任何支持。
o Applications that use fixed ports - See Section 5.2.2 for more discussion.
o 使用固定端口的应用程序-有关更多讨论，请参阅第5.2.2节。
o Applications that do not use any port (e.g., ICMP echo) - Such applications will require special handling -- see Section 9 for more discussion.
o 不使用任何端口的应用程序（如ICMP echo）——此类应用程序需要特殊处理——更多讨论请参见第9节。
o Applications that assume the uniqueness of source addresses (e.g., IP address as identifier) - Such applications will fail to operate correctly in the presence of multiple, discrete, simultaneous connections from the same source IP address.
o 假定源地址唯一性的应用程序（例如，IP地址作为标识符）-此类应用程序在存在来自同一源IP地址的多个离散同时连接的情况下将无法正确运行。
o Applications that explicitly prohibit concurrent connections from the same address - Such applications will fail when multiple subscribers sharing an IP address attempt to use them simultaneously.
o 明确禁止来自同一地址的并发连接的应用程序-当共享一个IP地址的多个订户试图同时使用这些应用程序时，这些应用程序将失败。
o Applications that do not use TCP or UDP for transport - All IP-address sharing mechanisms proposed to date are limited to TCP, UDP, and ICMP, thereby preventing end-users from fully utilizing the Internet (e.g., SCTP, DCCP, RSVP, protocol 41 (IPv6-over-IPv4), protocol 50 (IPsec ESP)).
o 不使用TCP或UDP进行传输的应用程序-迄今提出的所有IP地址共享机制仅限于TCP、UDP和ICMP，从而阻止最终用户充分利用互联网（例如，SCTP、DCCP、RSVP、协议41（IPv6-over-IPv4）、协议50（IPsec ESP））。
Applications already frequently implement mechanisms in order to circumvent the presence of NATs (typically CPE NATs):
应用程序已经频繁地实施机制以避免NAT（通常是CPE NAT）的存在：
o Application Layer Gateways (ALGs): Many CPE devices today embed ALGs that allow applications to behave correctly despite the presence of NAT on the CPE. When the NAT belongs to the subscriber, the subscriber has flexibility to tailor the device to his or her needs. For CGNs, subscribers will be dependent on the set of ALGs that their service provider makes available. For port-range solutions, ALGs will require modification to deal with the port-range restriction, but will otherwise have the same capabilities as today. Note that ALGs are required in some cases, and in many other cases end-to-end protocol mechanisms have developed to work around a lack of ALGs, to the point of it being preferable to avoid any support in the NAT.
o 应用层网关（ALG）：如今许多CPE设备嵌入ALG，允许应用程序在CPE上存在NAT的情况下正常运行。当NAT属于用户时，用户可以灵活地根据自己的需要定制设备。对于CGN，订户将依赖于其服务提供商提供的ALG集。对于端口范围解决方案，ALG将需要修改以处理端口范围限制，但在其他方面将具有与今天相同的功能。请注意，在某些情况下需要ALG，在许多其他情况下，端到端协议机制已经开发出来，以解决ALG的不足，因此最好避免NAT中的任何支持。
o NAT Traversal Techniques: There are several commonly deployed mechanisms that support operating servers behind a NAT by forwarding specific TCP or UDP ports to specific internal hosts
o NAT穿越技术：有几种常用的部署机制，通过将特定的TCP或UDP端口转发到特定的内部主机来支持NAT后面的操作服务器
([UPnP-IGD], [NAT-PMP], and manual configuration). All of these mechanisms assume the NAT's WAN address is a publicly routable IP address, and fail to work normally when that assumption is wrong. There have been attempts to avoid that problem by automatically disabling the NAT function and bridging traffic instead upon assignment of a private IP address to the WAN interface (as is required for [Windows-Logo] certification). Bridging (rather than NATting) has other side effects (DHCP requests are served by an upstream DHCP server that can increase complexity of in-home networking).
（[UPnP IGD]、[NAT-PMP]和手动配置）。所有这些机制都假设NAT的WAN地址是一个可公开路由的IP地址，如果假设错误，则无法正常工作。有人试图通过自动禁用NAT功能和桥接流量来避免该问题，而不是在向WAN接口分配专用IP地址时（如[Windows徽标]认证所需）。桥接（而不是NATting）还有其他副作用（DHCP请求由上游DHCP服务器提供服务，这会增加家庭网络的复杂性）。
IP addresses are frequently used to indicate, with some level of granularity and some level of confidence, where a host is physically located. Using IP addresses in this fashion is a heuristic at best, and is already challenged today by other deployed capabilities, e.g., tunnels. Geo-location services are used by content providers to allow them to conform with regional content licensing restrictions, to target advertising at specific geographic areas, or to provide customized content. Geo-location services are also necessary for emergency services provision. In some deployment contexts (e.g., centralized CGN), shared addressing will reduce the level of confidence and level of location granularity that IP-based geo-location services can provide. Viewed from the content provider, a subscriber behind a CGN geo-locates to wherever the prefix of the CGN appears to be; very often that will be in a different city than the subscriber.
IP地址通常用于指示主机的物理位置，具有一定的粒度和可信度。以这种方式使用IP地址充其量只是一种试探性的做法，如今已经受到其他部署功能（如隧道）的挑战。内容提供商使用地理位置服务来遵守区域内容许可限制、针对特定地理区域的广告或提供定制内容。地理定位服务对于提供紧急服务也是必要的。在某些部署环境中（例如，集中式CGN），共享寻址将降低基于IP的地理位置服务可以提供的可信度和位置粒度级别。从内容提供商看，CGN geo后面的订户定位到CGN前缀出现的任何位置；通常情况下，用户所在的城市与用户所在的城市不同。
IP addresses are also used as input to geo-location services that resolve an IP address to a physical location using information from the network infrastructure. Current systems rely on resources such as RADIUS databases and DHCP lease tables. The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone. It will be necessary for users of such systems to provide more information (e.g., TCP or UDP port numbers), and for the systems to use this information to query additional network resources (e.g., Network Address Translation - Protocol Translation (NAT-PT) binding tables). Since these new data elements tend to be more ephemeral than those currently used for geo-location, their use by geo-location systems may require them to be cached for some period of time.
IP地址还用作地理位置服务的输入，该服务使用来自网络基础设施的信息将IP地址解析为物理位置。当前系统依赖于资源，如RADIUS数据库和DHCP租约表。使用地址共享将阻止这些系统仅基于IP地址解析主机位置。这类系统的用户需要提供更多信息（如TCP或UDP端口号），系统需要使用这些信息查询其他网络资源（如网络地址转换-协议转换（NAT-PT）绑定表）。由于这些新数据元素往往比当前用于地理定位的数据元素更短暂，因此地理定位系统可能需要将它们缓存一段时间。
Other forms of geo-location will still work as usual.
其他形式的地理定位仍将照常工作。
A slightly different use of an IP address is to calculate the proximity of a connecting host to a particular service delivery point. This use of IP address information impacts the efficient
IP地址的一种稍有不同的用途是计算连接主机到特定服务提供点的距离。IP地址信息的这种使用会影响效率
delivery of content to an end-user. If a CGN is introduced in communications and it is far from an end-user connected to it, application performance may be degraded insofar as IP-based geo-proximity is a factor.
向最终用户交付内容。如果在通信中引入CGN，并且CGN远离与其连接的最终用户，则应用程序性能可能会降低，因为基于IP的地理邻近性是一个因素。
As large-scale address sharing becomes more commonplace, monitoring the number of unique users of a service will become more complex than simply counting the number of connections from unique IP addresses. While this is a somewhat inexact methodology today due to the widespread use of CPE NAT, it will become a much less useful approach in the presence of widespread large-scale address sharing solutions. In general, all elements that monitor usage or abusage in the chain between a service provider that has deployed address sharing and a content provider will need to be upgraded to take account of the port value in addition to IP addresses.
随着大规模地址共享变得越来越普遍，监视服务的唯一用户数将变得比简单地计算唯一IP地址的连接数更加复杂。虽然由于CPE NAT的广泛使用，这在今天是一种有点不精确的方法，但在存在广泛的大规模地址共享解决方案的情况下，它将成为一种不太有用的方法。通常，除了IP地址外，还需要升级已部署地址共享的服务提供商和内容提供商之间的链中监控使用或滥用的所有元素，以考虑端口值。
ICMP does not include a port field and is consequently problematic for address sharing mechanisms. Some ICMP message types include a fragment of the datagram that triggered the signal to be sent, which is assumed to include port numbers. For some ICMP message types, the Identifier field has to be used as a de-multiplexing token. Sourcing ICMP echo messages from hosts behind an address sharing solution does not pose problems, although responses to outgoing ICMP echo messages will require special handling, such as making use of the ICMP Identifier value to route the response appropriately.
ICMP不包括端口字段，因此地址共享机制存在问题。某些ICMP消息类型包括触发要发送的信号的数据报片段，假定该片段包括端口号。对于某些ICMP消息类型，标识符字段必须用作解复用令牌。从地址共享解决方案后面的主机获取ICMP回显消息不会带来问题，但对传出ICMP回显消息的响应将需要特殊处理，例如使用ICMP标识符值来适当路由响应。
For inbound ICMP there are two cases. The first case is that of ICMP sourced from outside the network of the address sharing solution provider. Where ICMP messages include a fragment of an outgoing packet including port numbers, it may be possible to forward the packet appropriately. In addition to these network signaling messages, several applications (e.g., peer-to-peer applications) make use of ICMP echo messages that include no hints that could be used to route the packet correctly. Measurements derived by such applications in the presence of an address sharing solution will be erroneous or fail altogether. The second case is that of ICMP sourced from within the network of the address sharing solution provider (e.g., for network management, signaling, and diagnostic purposes). In this case, ICMP can be routed normally for CGN-based solutions owing to the presence of locally unique private IP addresses for each CPE device. For port-range solutions, ICMP echo messages will not be routable without special handling, e.g., placing a port number in the ICMP Identifier field, and having port-range routers make routing decisions based upon that field.
对于入站ICMP，有两种情况。第一种情况是来自地址共享解决方案提供商网络外部的ICMP。如果ICMP消息包括包括端口号的传出数据包的片段，则可以适当地转发该数据包。除了这些网络信令消息外，一些应用程序（例如，对等应用程序）使用ICMP回显消息，这些回显消息不包含可用于正确路由数据包的提示。在存在地址共享解决方案的情况下，由此类应用程序导出的测量结果将是错误的或完全失败的。第二种情况是来自地址共享解决方案提供商网络内的ICMP（例如，用于网络管理、信令和诊断目的）。在这种情况下，由于每个CPE设备都有本地唯一的专用IP地址，因此ICMP可以正常路由到基于CGN的解决方案。对于端口范围解决方案，如果没有特殊处理，ICMP回显消息将无法路由，例如，在ICMP标识符字段中放置端口号，并让端口范围路由器根据该字段做出路由决定。
Considerations related to ICMP message handling in NAT-based environments are specified in [RFC5508].
[RFC5508]中规定了与基于NAT的环境中ICMP消息处理相关的注意事项。
In applications where the end hosts are attempting to use path MTU Discovery [RFC1191] to optimize transmitted packet size with underlying network MTU, shared addressing has a number of items that must be considered. As covered in Section 9, ICMP "Packet Too Big" messages must be properly translated through the address sharing solution in both directions. However, even when this is done correctly, MTU can be a concern. Many end hosts cache information that was received via Path MTU Discovery (PMTUD) for a certain period of time. If the MTU behind the address sharing solution is inconsistent, the public end host may have the incorrect MTU value cached. This may cause it to send packets that are too large, causing them to be dropped if the DF (Don't Fragment) bit is set, or causing them to be fragmented by the network, increasing load and overhead. Because the host eventually will reduce MTU to the lowest common value for all hosts behind a given public address, it may also send packets that are below optimal size for the specific connection, increasing overhead and reducing throughput.
在终端主机试图使用路径MTU发现[RFC1191]优化底层网络MTU传输数据包大小的应用中，共享寻址有许多必须考虑的项目。如第9节所述，ICMP“数据包太大”消息必须通过地址共享解决方案在两个方向上正确翻译。然而，即使这样做是正确的，MTU也可能是一个问题。许多终端主机将通过路径MTU发现（PMTUD）接收的信息缓存一段时间。如果地址共享解决方案背后的MTU不一致，则公共终端主机可能缓存了不正确的MTU值。这可能会导致it发送过大的数据包，如果设置了DF（不分段）位，则会导致数据包被丢弃，或者导致数据包被网络分段，从而增加负载和开销。因为主机最终会将给定公共地址后面的所有主机的MTU降低到最低公共值，所以它还可能发送低于特定连接的最佳大小的数据包，从而增加开销并降低吞吐量。
This issue also generates a potential attack vector -- a malevolent user could send an ICMP "Packet Too Big" (Type 3, Code 4) message indicating a Next-Hop MTU of anything down to 68 octets. This value will be cached by the off-net server for all subscribers sharing the address of the malevolent user. This could lead to a denial of service (DoS) against both the remote server and the large-scale NAT device itself (as they will both have to handle many more packets per second).
这个问题也会产生潜在的攻击向量——恶意用户可以发送一个ICMP“包太大”（类型3，代码4），指示下一跳MTU的任何东西，直到68个八位字节。对于共享恶意用户地址的所有订阅者，此值将由离线服务器缓存。这可能导致对远程服务器和大规模NAT设备本身的拒绝服务（DoS）（因为它们都必须每秒处理更多的数据包）。
When a packet is fragmented, transport-layer port information (either UDP or TCP) is only present in the first fragment. Subsequent fragments will not carry the port information and so will require special handling. In addition, the IP Identifier may no longer be unique as required by the receiver to aid in assembling the fragments of a datagram.
当数据包被分割时，传输层端口信息（UDP或TCP）仅出现在第一个片段中。后续片段不会携带端口信息，因此需要特殊处理。此外，IP标识符可能不再是接收器所要求的唯一的，以帮助组装数据报的片段。
In many jurisdictions, service providers are legally obliged to provide the identity of a subscriber upon request to the appropriate authorities. Such legal requests have traditionally included the source IPv4 address and date (and usually the time), which is sufficient information when subscribers are assigned IPv4 addresses for a long duration.
在许多司法管辖区，服务提供商在法律上有义务应有关当局的要求提供订户的身份。传统上，此类法律请求包括源IPv4地址和日期（通常包括时间），这在为订阅者分配长时间IPv4地址时是足够的信息。
However, where one public IPv4 address is shared between several subscribers, the IPv4 address no longer uniquely identifies a subscriber. There are two solutions to this problem:
但是，如果一个公共IPv4地址在多个订户之间共享，则IPv4地址不再唯一标识订户。此问题有两种解决方案：
o The first solution is for servers to additionally log the source port of incoming connections and for the legal request to include the source port. The legal request should include the information: [Source IP address, Source Port, Timestamp] (and possibly other information). Accurate time-keeping (e.g., use of NTP or Simple NTP) is vital because port assignments are dynamic. A densely populated CGN could mean even very small amounts of clock skew between a third party's server and the CGN operator will result in ambiguity about which customer was using a specific port at a given time.
o 第一种解决方案是服务器额外记录传入连接的源端口，以及合法请求包含源端口。法律请求应包括以下信息：[源IP地址、源端口、时间戳]（以及可能的其他信息）。准确的时间保持（例如，使用NTP或简单NTP）至关重要，因为端口分配是动态的。密集的CGN可能意味着第三方服务器和CGN运营商之间即使是非常小的时钟偏差也会导致在给定时间使用特定端口的客户不明确。
o The second solution considers it unrealistic to expect all servers to log the source port number of incoming connections. To deal with this, service providers using IPv4 address sharing may need to log IP destination addresses.
o 第二种解决方案认为，期望所有服务器记录传入连接的源端口号是不现实的。为了解决这个问题，使用IPv4地址共享的服务提供商可能需要记录IP目标地址。
Destination logging is imperfect if multiple subscribers are accessing the same (popular) server at nearly the same time; it can be impossible to disambiguate which subscriber accessed the server, especially with protocols that involve several connections (e.g., HTTP). Thus, logging the destination address on the NAT is inferior to logging the source port at the server.
如果多个订阅者几乎同时访问同一（流行）服务器，则目标日志记录是不完善的；无法消除哪个订户访问服务器的歧义，尤其是使用涉及多个连接的协议（例如HTTP）。因此，在NAT上记录目标地址不如在服务器上记录源端口。
If neither solution is used (that is, the server is not logging source port numbers and the NAT is not logging destination IP addresses), the service provider cannot trace a particular activity to a specific subscriber. In this circumstance, the service provider would need to disclose the identity of all subscribers who had active sessions on the NAT during the time period in question. This may be a large number of subscribers.
如果两种解决方案均未使用（即，服务器未记录源端口号，而NAT未记录目标IP地址），则服务提供商无法将特定活动跟踪到特定订阅者。在这种情况下，服务提供商需要披露在所述时间段内在NAT上有活动会话的所有订户的身份。这可能是大量的订户。
Address sharing solutions must record and store all mappings (typically during 6-12 months, depending on the local jurisdiction) that they create. If we consider one mapping per session, a service provider should record and retain traces of all sessions created by
地址共享解决方案必须记录和存储它们创建的所有映射（通常在6-12个月内，具体取决于本地辖区）。如果我们考虑每个会话的一个映射，则服务提供者应该记录并保留由
all subscribers during one year (if the legal storage duration is one year). This may be challenging due to the volume of data requiring storage, the volume of data to repeatedly transfer to the storage location, and the volume of data to search in response to a query.
一年内的所有订阅服务器（如果合法存储期限为一年）。由于需要存储的数据量、重复传输到存储位置的数据量以及响应查询需要搜索的数据量，这可能具有挑战性。
Address sharing solutions may mitigate these issues to some extent by pre-allocating groups of ports. Then only the allocation of the group needs to be recorded, and not the creation of every session binding within that group. There are trade-offs to be made between the sizes of these port groups, the ratio of public addresses to subscribers, whether or not these groups timeout, and the impact on logging requirements and port randomization security [RFC6056].
地址共享解决方案可以通过预先分配端口组在一定程度上缓解这些问题。然后只需要记录组的分配，而不需要记录该组内每个会话绑定的创建。在这些端口组的大小、公共地址与订户的比率、这些组是否超时以及对日志记录要求和端口随机化安全性的影响之间需要进行权衡[RFC6056]。
Before noting some specific security-related issues caused by large-scale address sharing, it is perhaps worth noting that, in general, address sharing creates a vector for attack amplification in numerous ways. See Section 10 for one example.
在注意到大规模地址共享引起的一些特定的安全相关问题之前，也许值得注意的是，一般来说，地址共享会以多种方式为攻击放大创建一个向量。参见第10节中的一个示例。
When an abuse is reported today, it is usually done in the form: IPv4 address X has done something bad at time T0. This is not enough information to uniquely identify the subscriber responsible for the abuse when that IPv4 address is shared by more than one subscriber. Law enforcement authorities may be particularly impacted because of this. This particular issue can be fixed by logging port numbers, although this will increase logging data storage requirements.
当今天报告滥用时，通常是这样做的：IPv4地址X在时间T0时做了坏事。当IPv4地址由多个订阅者共享时，此信息不足以唯一标识导致滥用的订阅者。执法当局可能因此受到特别的影响。这个特殊的问题可以通过记录端口号来解决，尽管这会增加记录数据存储需求。
A number of services on the network today log the IPv4 source addresses used in connection attempts to protect themselves from certain attacks. For example, if a server sees too many requests from the same IPv4 address in a short period of time, it may decide to put that address in a penalty box for a certain time during which requests are denied, or it may require completion of a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) for future requests. If an IPv4 address is shared by multiple subscribers, this would have unintended consequences in a couple of ways. First it may become the natural behavior to see many login attempts from the same address because it is now shared across a potentially large number of subscribers. Second and more likely is that one user who fails a number of login attempts may block out other users who have not made any previous attempts but who will now fail on their first attempt. In the presence of widespread large-scale address sharing, penalty box solutions to service abuse simply will not work.
如今，网络上的许多服务都会记录连接尝试中使用的IPv4源地址，以保护自己免受某些攻击。例如，如果服务器在短时间内看到太多来自同一IPv4地址的请求，它可能会决定在请求被拒绝的特定时间内将该地址放入惩罚框中，或者可能需要为未来的请求完成CAPTCHA（区分计算机和人的完全自动公共图灵测试）。如果一个IPv4地址由多个订阅者共享，这将在几个方面产生意想不到的后果。首先，看到来自同一地址的多次登录尝试可能会成为一种自然行为，因为它现在在潜在的大量订阅者之间共享。第二个也是更可能的是，一个多次登录尝试失败的用户可能会阻止以前没有尝试过但现在第一次尝试失败的其他用户。在大规模地址共享广泛存在的情况下，针对服务滥用的惩罚箱解决方案根本不起作用。
In addition, there are web tie-ins into different blacklists that web administrators subscribe to in order to redirect users with infected machines (e.g., detect the presence of a worm) to a URL that says "Hey, your machine is infected!". With address sharing, someone else's worm can interfere with the ability to access the service for other subscribers sharing the same IP address.
此外，网络管理员还订阅了不同的黑名单，以便将感染机器的用户（例如，检测是否存在蠕虫）重定向到一个URL，该URL上写着“嘿，你的机器感染了！”。通过地址共享，其他人的蠕虫可能会干扰共享同一IP地址的其他订户访问服务的能力。
Simple address-based identification mechanisms that are used to populate access control lists will fail when an IP address is no longer sufficient to identify a particular subscriber. Including port numbers in access control list definitions may be possible at the cost of extra complexity, and may also require the service provider to make static port assignments, which conflicts with the requirement for dynamic assignments discussed in Section 5.1.
当IP地址不再足以识别特定订户时，用于填充访问控制列表的简单基于地址的标识机制将失败。在访问控制列表定义中包括端口号可能会增加复杂性，还可能要求服务提供商进行静态端口分配，这与第5.1节中讨论的动态分配要求相冲突。
Address or DNS-name-based signatures (e.g., some X.509 signatures) may also be affected by address sharing as the address itself is now a shared token, and the name to address mapping may not be current.
地址或基于DNS名称的签名（例如，一些X.509签名）也可能受到地址共享的影响，因为地址本身现在是一个共享令牌，并且名称到地址的映射可能不是当前的。
Another case of identifying abusers has to do with spam blacklisting. When a spammer is behind a CGN or using a port-shared address, blacklisting of their IP address will result in all other subscribers sharing that address having their ability to source SMTP packets restricted to some extent.
另一个识别滥用者的案例与垃圾邮件黑名单有关。当垃圾邮件发送者位于CGN后面或使用端口共享地址时，其IP地址的黑名单将导致共享该地址的所有其他订户在一定程度上限制其发送SMTP数据包的能力。
A blind attack that can be performed against TCP relies on the attacker's ability to guess the 5-tuple (Protocol, Source Address, Destination Address, Source Port, Destination Port) that identifies the transport protocol instance to be attacked. [RFC6056] describes a number of methods for the random selection of the source port number, such that the ability of an attacker to correctly guess the 5-tuple is reduced. With shared IPv4 addresses, the port selection space is reduced. Preserving port randomization is important and may be more or less difficult depending on the address sharing solution and the size of the port space that is being manipulated. Allocation of non-contiguous port ranges could help to mitigate this issue.
可以对TCP执行的盲攻击依赖于攻击者猜测识别要攻击的传输协议实例的5元组（协议、源地址、目标地址、源端口、目标端口）的能力。[RFC6056]描述了一些随机选择源端口号的方法，从而降低了攻击者正确猜测5元组的能力。使用共享IPv4地址，端口选择空间会减少。保留端口随机化很重要，根据地址共享解决方案和正在操作的端口空间的大小，可能会有或多或少的困难。分配非连续端口范围有助于缓解此问题。
It should be noted that guessing the port information may not be sufficient to carry out a successful blind attack. An in-window TCP Sequence Number (SN) should also be known or guessed. A TCP segment is processed only if all previous segments have been received, except for some Reset segment implementations that immediately process the
应该注意，猜测端口信息可能不足以成功执行盲攻击。窗口内TCP序列号（SN）也应该是已知的或猜测的。只有在接收到之前的所有数据段时，才会处理TCP数据段，但某些立即处理该数据段的重置数据段实现除外
Reset as long as it is within the Window. If SN is randomly chosen, it will be difficult to guess it (SN is 32 bits long); port randomization is one protection among others against blind attacks. There is more detailed discussion of improving TCP's robustness to Blind In-Window Attacks in [RFC5961].
只要它在窗口内，就可以重置。如果随机选择SN，则很难猜测它（SN为32位长）；端口随机化是防止盲攻击的一种保护措施。[RFC5961]中详细讨论了如何提高TCP对窗口内盲攻击的鲁棒性。
The impact of large-scale IP address sharing for IPsec operation should be evaluated and assessed. [RFC3947] proposes a solution to solve issues documented in [RFC3715]. [RFC5996] specifies Internet Key Exchange (IKE) Protocol Version 2, which includes NAT traversal mechanisms that are now widely used to enable IPsec to work in the presence of NATs in many cases. Nevertheless, service providers may wish to ensure that CGN deployments do not inadvertently block NAT traversal for security protocols such as IKE (refer to [NAT-SEC] for more information).
应评估大规模IP地址共享对IPsec操作的影响。[RFC3947]提出解决[RFC3715]中记录的问题的解决方案。[RFC5996]指定了Internet密钥交换（IKE）协议版本2，其中包括NAT遍历机制，目前广泛使用这些机制，以使IPsec在许多情况下能够在NAT存在的情况下工作。然而，服务提供商可能希望确保CGN部署不会无意中阻止安全协议（如IKE）的NAT遍历（有关更多信息，请参阅[NAT-SEC]）。
[RFC2827] motivates and discusses a simple, effective, and straightforward method for using ingress traffic filtering to prohibit DoS attacks that use forged IP addresses. Following this recommendation, service providers operating shared-addressing mechanisms should ensure that source addresses, or source ports in the case of port-range schemes, are set correctly in outgoing packets from their subscribers or they should drop the packets.
[RFC2827]提出并讨论了一种简单、有效且直接的方法，用于使用入口流量过滤来禁止使用伪造IP地址的DoS攻击。根据这一建议，运行共享寻址机制的服务提供商应确保在来自其订户的传出数据包中正确设置源地址，或者在端口范围方案的情况下正确设置源端口，或者应丢弃数据包。
If some form of IPv6 ingress filtering is deployed in the broadband network and DS-Lite service is restricted to those subscribers, then tunnels terminating at the CGN and coming from registered subscriber IPv6 addresses cannot be spoofed. Thus, a simple access control list on the tunnel transport source address is all that is required to accept traffic on the internal interface of a CGN.
如果在宽带网络中部署了某种形式的IPv6入口过滤，并且DS Lite服务仅限于这些订阅者，则无法伪造终止于CGN并来自注册订阅者IPv6地址的隧道。因此，隧道传输源地址上的简单访问控制列表是接受CGN内部接口上的通信所需的全部。
One issue is systems that assume that multiple simultaneous connections to a single IP address implies connectivity to a single host -- such systems may experience unexpected results.
一个问题是系统假设多个同时连接到一个IP地址意味着连接到一个主机——这样的系统可能会遇到意外的结果。
Another issue is systems that assume that returning to a given IP address means returning to the same physical host, as with stateful transactions. This may also affect cookie-based systems.
另一个问题是系统假设返回到给定的IP地址意味着返回到同一物理主机，就像有状态事务一样。这也可能影响基于cookie的系统。
[RFC2140] defines a performance optimization for TCP based on sharing state between TCP control blocks that pertain to connections to the same host, as opposed to maintaining state for each discrete connection. This optimization assumes that an address says something about the properties of the path between two hosts, which is clearly not the case if the address in question is shared by multiple hosts at different physical network locations. While CPE NAT today causes problems for sharing TCP control block state across multiple connections to a given IP address, large-scale address sharing will make these issues more severe and more widespread.
[RFC2140]基于与同一主机连接相关的TCP控制块之间的共享状态定义TCP性能优化，而不是维护每个离散连接的状态。这种优化假设一个地址反映了两台主机之间路径的属性，如果地址由位于不同物理网络位置的多台主机共享，则情况显然并非如此。虽然如今的CPE NAT在跨多个连接到给定IP地址共享TCP控制块状态方面存在问题，但大规模的地址共享将使这些问题更加严重和广泛。
Many service providers populate forward and reverse DNS zones for the public IPv4 addresses that they allocate to their subscribers. In the case where public addresses are shared across multiple subscribers, such strings are, by definition, no longer sufficient to identify an individual subscriber without additional information.
许多服务提供商为分配给其订户的公共IPv4地址填充正向和反向DNS区域。在公共地址在多个订阅者之间共享的情况下，根据定义，这样的字符串不再足以在没有附加信息的情况下识别单个订阅者。
Algorithms used to balance traffic load for popular destinations may be affected by the introduction of address sharing. Where balancing is achieved by deterministically routing traffic from specific source IP addresses to specific servers, imbalances in load may be experienced as address sharing is enabled for some of those source IP addresses. This will require re-evaluation of the algorithms used in the load-balancing design. In general, as the scale of address sharing grows, load-balancing designs will need to be re-evaluated and any assumptions about average load per source IP address revisited.
用于平衡流行目的地流量负载的算法可能会受到地址共享的影响。当通过确定地将流量从特定源IP地址路由到特定服务器来实现平衡时，可能会遇到负载不平衡，因为其中一些源IP地址启用了地址共享。这需要重新评估负载平衡设计中使用的算法。一般来说，随着地址共享规模的增长，需要重新评估负载平衡设计，并重新考虑关于每个源IP地址平均负载的任何假设。
IPv4 address sharing solutions may interfere with existing IPv4 to IPv6 transition mechanisms, which were not designed with IPv4 shortage considerations in mind. With port-range solutions, for instance, incoming 6to4 packets should be able to find their way from a 6to4 relay to the appropriate 6to4 CPE router, despite the lack of direct port-range information (UDP/TCP initial source port did not pass through the CPE port range translation process). One solution would be for a 6to4 IPv6 address to embed not only an IPv4 address but also a port range value.
IPv4地址共享解决方案可能会干扰现有的IPv4到IPv6转换机制，这些机制在设计时没有考虑到IPv4短缺问题。例如，使用端口范围解决方案，尽管缺少直接的端口范围信息（UDP/TCP初始源端口未通过CPE端口范围转换过程），但传入的6to4数据包应该能够从6to4中继找到到相应的6to4 CPE路由器的路径。一种解决方案是，6to4 IPv6地址不仅要嵌入IPv4地址，还要嵌入端口范围值。
Subscribers allocated with private addresses will not be able to utilize 6to4 [RFC3056] to access IPv6, but may be able to utilize Teredo [RFC4380].
使用专用地址分配的订户将无法利用6to4[RFC3056]访问IPv6，但可能能够利用Teredo[RFC4380]。
Some routers enable 6to4 on their WAN link. 6to4 requires a publicly routable IPv4 address. Enabling 6to4 when the apparently public IPv4 WAN address is in fact behind a NAT creates a disconnected IPv6 island.
一些路由器在其WAN链路上启用6to4。6to4需要一个可公开路由的IPv4地址。当表面上公开的IPv4 WAN地址实际上位于NAT后面时启用6to4会创建一个断开连接的IPv6孤岛。
In common with all deployments of new network functionality, the introduction of new nodes or functions to handle the multiplexing of multiple subscribers across shared IPv4 addresses could create single points of failure in the network. Any IP address sharing solution should consider the opportunity to add redundancy features in order to alleviate the impact on the robustness of the offered IP connectivity service. The ability of the solution to allow hot swapping from one machine to another should be considered. This is especially important where the address sharing solution in question requires the creation of per-flow state in the network.
与所有新网络功能的部署一样，引入新节点或功能来处理跨共享IPv4地址的多个订户的多路复用可能会在网络中造成单点故障。任何IP地址共享解决方案应考虑添加冗余特征的机会，以减轻对所提供的IP连接服务的鲁棒性的影响。应该考虑解决方案允许从一台机器到另一台机器进行热交换的能力。当所讨论的地址共享解决方案需要在网络中创建每流状态时，这一点尤为重要。
In order for hosts to maintain network state in the presence of NAT, keep-alive messages have to be sent at frequent intervals. For battery-powered devices, sending these keep-alive messages can result in significantly reduced battery performance than would otherwise be the case [Mobile_Energy_Consumption].
为了让主机在存在NAT的情况下保持网络状态，必须频繁发送保持活动状态的消息。对于电池供电的设备，发送这些保持活动状态的消息可能会导致电池性能显著降低，而不是[移动能源消耗]。
[RFC5135] specifies requirements for a NAT that supports Any Source IP Multicast or Source-Specific IP Multicast. Port-range routers that form part of port-range solutions will need to support similar requirements if multicast support is required.
[RFC5135]指定支持任何源IP多播或源特定IP多播的NAT的要求。如果需要多播支持，则构成端口范围解决方案一部分的端口范围路由器将需要支持类似的要求。
IP address sharing within the context of Mobile IP deployments (in the home network and/or in the visited network) will require Home Agents and/or Foreign Agents to be updated so as to take into account the relevant port information. There may also be issues raised when an additional layer of encapsulation is required thereby causing, or increasing the need for, fragmentation and reassembly.
移动IP部署（在家庭网络和/或访问网络中）环境中的IP地址共享需要更新家庭代理和/或外部代理，以便考虑相关端口信息。当需要额外的封装层从而导致或增加碎片和重新组装的需要时，也可能会出现问题。
Issues for Mobile-IP in the presence of NAT are discussed in [NAT64-MOBILITY].
NAT存在时的移动IP问题在[NAT64-MOBILITY]中讨论。
This memo does not define any protocol and therefore creates no new security issues. Section 13 discusses some of the security and identity-related implications of IP address sharing.
此备忘录未定义任何协议，因此不会产生新的安全问题。第13节讨论了IP地址共享的一些安全和身份相关影响。
This document is based on sources co-authored by J.L. Grimault and A. Villefranque of France Telecom.
本文件基于法国电信的J.L.Grimault和A.Villefranque合著的资料来源。
This memo was partly inspired by conversations that took place as part of Internet Society (ISOC) hosted roundtable events for operators and content providers deploying IPv6. Participants in those discussions included John Brzozowski, Leslie Daigle, Tom Klieber, Yiu Lee, Kurtis Lindqvist, Wes George, Lorenzo Colliti, Erik Kline, Igor Gashinsky, Jason Fesler, Rick Reed, Adam Bechtel, Larry Campbell, Tom Coffeen, David Temkin, Pete Gelbman, Mark Winter, Will Charnock, Martin Levy, Greg Wood, and Christian Jacquenet.
这份备忘录的部分灵感来自于互联网协会（ISOC）为部署IPv6的运营商和内容提供商举办的圆桌会议活动中的对话。这些讨论的参与者包括约翰·布佐夫斯基、莱斯利·戴格尔、汤姆·克莱伯、姚·李、库尔蒂斯·林克维斯特、韦斯·乔治、洛伦佐·科利蒂、埃里克·克莱恩、伊戈尔·加辛斯基、杰森·费斯勒、里克·里德、亚当·贝克特尔、拉里·坎贝尔、汤姆·科芬、大卫·坦金、皮特·格尔曼、马克·温特、威尔·夏诺克、马丁·利维、格雷格·伍德和克里斯蒂安·雅克内特。
The authors are also grateful to Christian Jacquenet, Iain Calder, Joel Halpern, Brian Carpenter, Gregory Lebovitz, Bob Briscoe, Marcelo Bagnulo, Dan Wing, and Wes George for their helpful comments and suggestions for improving the document.
作者还感谢Christian Jacquenet、Iain Calder、Joel Halpern、Brian Carpenter、Gregory Lebovitz、Bob Briscoe、Marcelo Bagnulo、Dan Wing和Wes George为改进该文件提供了有益的意见和建议。
This memo was created using the xml2rfc tool.
此备忘录是使用xml2rfc工具创建的。
[A+P] Bush, R., "The A+P Approach to the IPv4 Address Shortage", Work in Progress, February 2011.
[A+P]Bush，R.，“IPv4地址短缺的A+P方法”，正在进行的工作，2011年2月。
[CGN_Viability] Alcock, S., "Research into the Viability of Service-Provider NAT", 2008, <http://www.wand.net.nz/~salcock/ someisp/flow_counting/result_page.html>.
[CGN_生存能力]Alcock，S.，“服务提供商NAT生存能力研究”，2008年<http://www.wand.net.nz/~salcock/someisp/flow\u counting/result\u page.html>。
[DS-Lite] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, May 2011.
[DS Lite]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，正在进行的工作，2011年5月。
[IANA_Ports] IANA, "Port Numbers", <http://www.iana.org>.
[IANA_Ports]IANA，“端口号”<http://www.iana.org>.
[IPv4_Pool] ICANN, "Available Pool of Unallocated IPv4 Internet Addresses Now Completely Emptied", February 2011, <http://icann.org/en/news/releases/ release-03feb11-en.pdf>.
[IPv4_Pool]ICANN，“未分配IPv4互联网地址的可用池现在已完全清空”，2011年2月<http://icann.org/en/news/releases/ release-03feb11-en.pdf>。
[LSN-REQS] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common requirements for IP address sharing schemes", Work in Progress, March 2011.
[LSN-REQS]Perreault，S.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“IP地址共享方案的通用要求”，正在进行的工作，2011年3月。
[Mobile_Energy_Consumption] Haverinen, H., Siren, J., and P. Eronen, "Energy Consumption of Always-On Applications in WCDMA Networks", April 2007, <http://research.nokia.com/node/5597>.
[移动能源消耗]Haverinen，H.，Siren，J.，和P.Eronen，“WCDMA网络中常开应用的能源消耗”，2007年4月<http://research.nokia.com/node/5597>.
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP]柴郡，S.，“NAT端口映射协议（NAT-PMP）”，正在进行的工作，2008年4月。
[NAT-SEC] Gont, F. and P. Srisuresh, "Security implications of Network Address Translators (NATs)", Work in Progress, October 2009.
[NAT-SEC]Gont，F.和P.Srisuresh，“网络地址转换器（NAT）的安全影响”，正在进行的工作，2009年10月。
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", January 2011.
[NAT444]山形，I.，白崎，Y.，中川，A.，山口，J.，和H.Ashida，“NAT444”，2011年1月。
[NAT64-MOBILITY] Haddad, W. and C. Perkins, "A Note on NAT64 Interaction with Mobile IPv6", Work in Progress, March 2011.
[NAT64-MOBILITY]Haddad，W.和C.Perkins，“关于NAT64与移动IPv6交互的说明”，正在进行的工作，2011年3月。
[PCP] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, May 2011.
[PCP]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，正在进行的工作，2011年5月。
[PORT-RANGE] Boucadair, M., Levis, P., Bajko, G., and T. Savolainen, "IPv4 Connectivity Access in the Context of IPv4 Address Exhaustion: Port Range based IP Architecture", Work in Progress, July 2009.
[端口范围]Boucadair，M.，Levis，P.，Bajko，G.，和T.Savolainen，“IPv4地址耗尽背景下的IPv4连接访问：基于端口范围的IP架构”，正在进行的工作，2009年7月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337]Braden，B.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, October 1994.
[RFC1700]Reynolds，J.和J.Postel，“分配的数字”，RFC1700，1994年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月。
[RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[RFC2140]Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[RFC3232]Reynolds，J.，“分配号码：RFC 1700被在线数据库取代”，RFC 3232，2002年1月。
[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月。
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
[RFC3947]Kivinen，T.，Swander，B.，Huttunen，A.，和V.Volpe，“IKE中NAT穿越的协商”，RFC 3947，2005年1月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5135]Wing，D.和T.Eckert，“网络地址转换器（NAT）和网络地址端口转换器（NAPT）的IP多播要求”，BCP 135，RFC 5135，2008年2月。
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[RFC5508]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP的NAT行为要求”，BCP 148，RFC 5508，2009年4月。
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010.
[RFC5961]Ramaiah，A.，Stewart，R.，和M.Dalal，“提高TCP对窗口盲攻击的鲁棒性”，RFC 59612010年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996]Kaufman，C.，Hoffman，P.，Nir，Y.，和P.Eronen，“互联网密钥交换协议版本2（IKEv2）”，RFC 59962010年9月。
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.
[RFC6056]Larsen，M.和F.Gont，“传输协议端口随机化建议”，BCP 156，RFC 6056，2011年1月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 61462011年4月。
[SAM] Despres, R., "Scalable Multihoming across IPv6 Local-Address Routing Zones Global-Prefix/Local-Address Stateless Address Mapping (SAM)", July 2009.
[SAM]Despres，R.，“跨IPv6本地地址路由区域的可扩展多宿主全局前缀/本地地址无状态地址映射（SAM）”，2009年7月。
[UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet Gateway Device (IGD) V 2.0", December 2010, <http://upnp.org/specs/gw/igd2/>.
[UPnP IGD]UPnP论坛，“通用即插即用（UPnP）互联网网关设备（IGD）V2.0”，2010年12月<http://upnp.org/specs/gw/igd2/>.
[Windows-Logo] Microsoft, "Windows Logo Program Requirements and Policies", 2006, <http://www.microsoft.com/whdc/winlogo/ hwrequirements/default.mspx>.
[Windows徽标]微软，“Windows徽标计划要求和政策”，2006年<http://www.microsoft.com/whdc/winlogo/ hwrequirements/default.mspx>。
IP address sharing solutions fall into two classes. Either a service-provider-operated NAT function is introduced and subscribers are allocated addresses from [RFC1918] space, or public IPv4 addresses are shared across multiple subscribers by restricting the range of ports available to each subscriber. These classes of solution are described in a bit more detail below.
IP地址共享解决方案分为两类。要么引入服务提供商操作的NAT功能，从[RFC1918]空间向订户分配地址，要么通过限制每个订户可用的端口范围，在多个订户之间共享公共IPv4地址。下面将更详细地描述这些解决方案类别。
o CGN-based solutions: These solutions propose the introduction of a NAPT function in the service provider's network, denoted also as Carrier Grade NAT (CGN), or Large Scale NAT (LSN) [LSN-REQS], or Provider NAT. The CGN is responsible for translating private addresses to publicly routable addresses. Private addresses are assigned to subscribers, a pool of public addresses is assigned to the CGN, and the number of public addresses is smaller than the number of subscribers. A public IPv4 address in the CGN pool is shared by several subscribers at the same time. Solutions making use of a service provider-based NAT include [NAT444] (two layers of NAT) and [DS-Lite] (a single layer of NAT).
o 基于CGN的解决方案：这些解决方案建议在服务提供商的网络中引入NAPT功能，也称为载波级NAT（CGN），或大规模NAT（LSN）[LSN-REQS]，或提供商NAT。CGN负责将专用地址转换为可公开路由的地址。专用地址分配给订阅者，公共地址池分配给CGN，公共地址的数量小于订阅者的数量。CGN池中的公共IPv4地址由多个订户同时共享。使用基于服务提供商的NAT的解决方案包括[NAT444]（两层NAT）和[DS Lite]（一层NAT）。
o Port-range solutions: These solutions avoid the presence of a CGN function. A single public IPv4 address is assigned to several subscribers at the same time. A restricted port range is also assigned to each subscriber so that two subscribers with the same IPv4 address have two different port ranges that do not overlap. These solutions are called Address+Port [A+P], or Port Range [PORT-RANGE], or Stateless Address Mapping [SAM].
o 端口范围解决方案：这些解决方案避免了CGN函数的存在。一个公共IPv4地址同时分配给多个订户。还为每个订户分配了一个受限端口范围，以便具有相同IPv4地址的两个订户具有两个不重叠的不同端口范围。这些解决方案称为地址+端口[A+P]，或端口范围[Port-Range]，或无状态地址映射[SAM]。
The purpose of sharing public IPv4 addresses is to increase the addressing space. A key parameter is the factor by which service providers want or need to multiply their IPv4 public address space, and the consequence is the number of subscribers sharing the same public IPv4 address. We refer to this parameter as the address space multiplicative factor; the inverse is called the compression ratio.
共享公共IPv4地址的目的是增加寻址空间。一个关键参数是服务提供商希望或需要乘以其IPv4公共地址空间的系数，其结果是共享相同IPv4公共地址的订户数。我们将此参数称为地址空间乘法因子；反之称为压缩比。
The multiplicative factor can only be applied to the subset of subscribers that are eligible for a shared address. The reasons a subscriber cannot have a shared address can be:
乘法因子只能应用于符合共享地址条件的订阅服务器子集。订阅者不能拥有共享地址的原因可能是：
o It would not be compatible with the service to which they are currently subscribed (for example, business subscriber).
o 它将与他们当前订阅的服务（例如，业务订户）不兼容。
o Subscriber CPE is not compatible with the address sharing solution selected by the service provider (for example, it does not handle port restriction for port-range solutions or it does not allow IPv4 in IPv6 encapsulation for the DS-Lite solution), and its replacement is not easy.
o 订户CPE与服务提供商选择的地址共享解决方案不兼容（例如，它不处理端口范围解决方案的端口限制，或者它不允许DS Lite解决方案在IPv6中封装IPv4），并且它的替换不容易。
Different service providers may have very different needs. A long-lived service provider, whose number of subscribers is rather stable, may have an existing address pool that will only need a small extension to cope with the next few years, assuming that this address pool can be re-purposed for an address sharing solution (small multiplicative factor, less than 10). A new entrant or a new line of business will need a much bigger multiplicative factor (e.g., 1000). A mobile operator may see its addressing needs grow dramatically as the IP-enabled mobile handset market grows.
不同的服务提供商可能有非常不同的需求。长期服务提供商（其订户数量相当稳定）可能拥有一个现有地址池，该地址池只需少量扩展即可满足未来几年的需求，前提是该地址池可以重新用于地址共享解决方案（小乘法因子，小于10）。新进入者或新业务线需要更大的乘数（如1000）。随着支持IP的移动手机市场的增长，移动运营商的寻址需求可能会急剧增长。
When the multiplicative factor is large, the average number of ports per subscriber is small. Given the large measured disparity between average and peak port consumption [CGN_Viability], this will create service problems in the event that ports are allocated statically. In this case, it is essential for port allocation to map to need as closely as possible, and to avoid allocating ports for longer than necessary. Therefore, the larger the multiplicative factor, the more dynamic the port assignment has to be.
当乘法因子较大时，每个订户的平均端口数较小。考虑到平均端口消耗量和峰值端口消耗量[CGN_生存能力]之间的巨大测量差异，这将在静态分配端口的情况下产生服务问题。在这种情况下，端口分配必须尽可能接近需要，并避免分配端口的时间过长。因此，乘法因子越大，端口分配就越具有动态性。
Authors' Addresses
作者地址
Mat Ford (editor) Internet Society Geneva Switzerland
Mat Ford（编辑）瑞士日内瓦互联网协会
EMail: ford@isoc.org
EMail: ford@isoc.org
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange-ftgroup.com
EMail: mohamed.boucadair@orange-ftgroup.com
Alain Durand Juniper Networks
阿兰杜兰杜松网络
EMail: adurand@juniper.net
EMail: adurand@juniper.net
Pierre Levis France Telecom 42 rue des Coutures BP 6243 Caen Cedex 4 14066 France
Pierre Levis法国电信公司42 rue des Coutures BP 6243 Caen Cedex 4 14066法国
EMail: pierre.levis@orange-ftgroup.com
EMail: pierre.levis@orange-ftgroup.com
Phil Roberts Internet Society Reston, VA USA
美国弗吉尼亚州莱斯顿菲尔·罗伯茨互联网协会
EMail: roberts@isoc.org
EMail: roberts@isoc.org