Internet Engineering Task Force (IETF) M. Azinger
Request for Comments: 6319 Frontier Communications
Category: Informational Corporation
ISSN: 2070-1721 L. Vegoda
ICANN
July 2011
Internet Engineering Task Force (IETF) M. Azinger
Request for Comments: 6319 Frontier Communications
Category: Informational Corporation
ISSN: 2070-1721 L. Vegoda
ICANN
July 2011
Issues Associated with Designating Additional Private IPv4 Address Space
与指定其他专用IPv4地址空间相关的问题
Abstract
摘要
When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.
当专用网络或互联网络变得非常大时，有时不可能使用专用IPv4地址空间寻址所有接口，因为没有足够的地址。本文档描述了这些网络面临的问题、可用选项以及分配新的专用IPv4地址空间块所涉及的问题。
While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered.
虽然本信息性文件没有提出行动建议，但它记录了围绕已考虑的各种方案的问题。
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/rfc6319.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6319.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . . 3
3.1. Subscriber Use Network Address Translation . . . . . . . . 3
3.2. Carrier-Grade Network Address Translation . . . . . . . . 4
4. Available Options . . . . . . . . . . . . . . . . . . . . . . 4
4.1. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . 4
4.1.2. Unique Local IPv6 Unicast Addresses . . . . . . . . . 5
4.2. IPv4 Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Address Transfers or Leases from Organizations
with Available Address Space . . . . . . . . . . . . . 5
4.2.2. Using Unannounced Address Space Allocated to
Another Organization . . . . . . . . . . . . . . . . . 5
4.2.3. Unique IPv4 Space Registered by an RIR . . . . . . . . 6
5. Options and Consequences for Defining New Private Use Space . 6
5.1. Redefining Existing Unicast Space as Private Address
Space . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 7
5.3. Potential Consequences of Not Redefining Existing
Unicast Space as Private Address Space . . . . . . . . . . 8
5.4. Redefining Future Use Space as Unicast Address Space . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . . 3
3.1. Subscriber Use Network Address Translation . . . . . . . . 3
3.2. Carrier-Grade Network Address Translation . . . . . . . . 4
4. Available Options . . . . . . . . . . . . . . . . . . . . . . 4
4.1. IPv6 Options . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . 4
4.1.2. Unique Local IPv6 Unicast Addresses . . . . . . . . . 5
4.2. IPv4 Options . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Address Transfers or Leases from Organizations
with Available Address Space . . . . . . . . . . . . . 5
4.2.2. Using Unannounced Address Space Allocated to
Another Organization . . . . . . . . . . . . . . . . . 5
4.2.3. Unique IPv4 Space Registered by an RIR . . . . . . . . 6
5. Options and Consequences for Defining New Private Use Space . 6
5.1. Redefining Existing Unicast Space as Private Address
Space . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 7
5.3. Potential Consequences of Not Redefining Existing
Unicast Space as Private Address Space . . . . . . . . . . 8
5.4. Redefining Future Use Space as Unicast Address Space . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
[RFC1918] sets aside three blocks of IPv4 address space for use in private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. These blocks can be used simultaneously in multiple, separately managed networks without registration or coordination with IANA or any Internet registry. Very large networks can find that they need to number more device interfaces than there are available addresses in these three ranges. It has occasionally been suggested that additional private IPv4 address space should be reserved for use by these networks. Although such an action might address some of the needs for these very large network operators, it is not without consequences, particularly as we near the date when the IANA free pool will be fully allocated.
[RFC1918]留出三块IPv4地址空间用于专用网络：192.168.0.0/16、172.16.0.0/12和10.0.0.0/8。这些块可以在多个单独管理的网络中同时使用，无需注册或与IANA或任何互联网注册中心协调。非常大的网络可能会发现，它们需要的设备接口数量超过这三个范围内的可用地址数量。偶尔有人建议，应为这些网络保留额外的专用IPv4地址空间。尽管这样的行动可能会满足这些大型网络运营商的一些需求，但也并非没有后果，特别是在我们即将完全分配IANA免费池的时候。
The overall conclusion is that allocating additional address space to be used as private address space has severe problems and would, for instance, impact any software or configuration that has built-in assumptions about private address space. However, it is also well understood that cascading Network Address Translation (NAT) deployments in the existing private address space will cause different types of severe problems when address spaces overlap. At this point, there is no clear agreement of the likelihood of various problems or the respective trade-offs.
总体结论是，分配额外的地址空间用作专用地址空间存在严重问题，例如，会影响任何对专用地址空间有内置假设的软件或配置。然而，众所周知，当地址空间重叠时，现有私有地址空间中的级联网络地址转换（NAT）部署将导致不同类型的严重问题。在这一点上，对于各种问题的可能性或各自的权衡没有明确的一致意见。
The main categories of very large networks using private address space are: cable operators, wireless (cell phone) operators, private internets, and VPN service providers. In the case of the first two categories, the complete address space reserved in [RFC1918] tends to be used by a single organization. In the case of private internets and VPN service providers, there are multiple independently managed and operated networks and the difficulty is in avoiding address clashes.
使用专用地址空间的大型网络的主要类别有：有线电视运营商、无线（手机）运营商、专用互联网和VPN服务提供商。在前两种情况下，[RFC1918]中保留的完整地址空间往往由单个组织使用。就私人互联网和VPN服务提供商而言，存在多个独立管理和运营的网络，困难在于避免地址冲突。
The address space set aside in [RFC1918] is a finite resource that can be used to provide limited Internet access via NAT. A discussion of the advantages and disadvantages of NATs is outside the scope of this document, but an analysis of the advantages, disadvantages, and architectural implications can be found in [RFC2993]. Nonetheless, it must be acknowledged that NAT is adequate in some situations and not in others. For instance, it might technically be feasible to use NAT or even multiple layers of NAT within the networks operated by
[RFC1918]中预留的地址空间是有限的资源，可用于通过NAT提供有限的互联网访问。关于NAT优缺点的讨论不在本文档的范围内，但是关于NAT优缺点和体系结构含义的分析可在[RFC2993]中找到。尽管如此，必须承认NAT在某些情况下是足够的，而在其他情况下则不行。例如，在由网络运营的网络中使用NAT甚至多层NAT在技术上可能是可行的
residential users or corporations where only limited Internet access is required. A more detailed analysis can be found in [RFC3022]. Where true peer-to-peer communication is needed or where services or applications do not work properly behind NAT, globally unique address space is required. In other cases, NAT traversal techniques facilitate peer-to-peer like communication for devices behind NATs.
仅需要有限互联网接入的住宅用户或公司。更详细的分析见[RFC3022]。如果需要真正的对等通信，或者NAT后的服务或应用程序不能正常工作，则需要全局唯一的地址空间。在其他情况下，NAT穿越技术有助于NAT后面设备的对等通信。
In many cases, it is possible to use multiple layers of NAT to re-use parts of the address space defined in [RFC1918]. It is not always possible to rely on Customer Premises Equipment (CPE) devices using any particular range, however. In some cases, this means that unorthodox workarounds including assigning CPE devices unallocated address space or address space allocated to other network operators are feasible. In other cases, organizations choose to operate multiple separate routing domains to allow them to re-use the same private address ranges in multiple contexts. One consequence of this is the added complexity involved in identifying which system is referred to when an IP address is identified in a log or management system.
在许多情况下，可以使用多层NAT来重用[RFC1918]中定义的部分地址空间。然而，使用任何特定范围的客户场所设备（CPE）设备并不总是可能的。在某些情况下，这意味着非正统的解决方法，包括分配CPE设备未分配的地址空间或分配给其他网络运营商的地址空间是可行的。在其他情况下，组织选择运行多个单独的路由域，以允许它们在多个上下文中重复使用相同的专用地址范围。这样做的一个后果是，当在日志或管理系统中标识IP地址时，标识引用哪个系统会增加复杂性。
Another option is to share one address across multiple interfaces and in some cases, subscribers. This model breaks the classical model used for logging address assignments and creates significant risks and additional burdens, as described in [CLAYTON] and more fully discussed in [FORD], and as documented in [DS-LITE].
另一种选择是跨多个接口共享一个地址，在某些情况下，还包括订阅者。该模型打破了用于记录地址分配的经典模型，并产生了重大风险和额外负担，如[CLAYTON]中所述，并在[FORD]中进行了更全面的讨论，如[DS-LITE]中所述。
When a network operator has exhausted the private address space set aside in [RFC1918] but needs to continue operating a single routing domain, a number of options are available. These are described in the following sections.
当网络运营商耗尽[RFC1918]中预留的专用地址空间，但需要继续运行单个路由域时，可以使用许多选项。以下各节将对其进行说明。
Using unique, globally scoped IPv6 unicast addresses is the best permanent solution as it removes any concerns about address scarcity within the next few decades. Implementing IPv6 is a major endeavor for service providers with millions of consumers and is likely to take considerable effort and time. In some cases, implementing a new network protocol on a very large network takes more time than is available, based on network growth and the proportion of private space that has already been used. In these cases, there is a call
使用唯一的、全球范围的IPv6单播地址是最好的永久解决方案，因为它消除了对未来几十年内地址稀缺的任何担忧。对于拥有数百万消费者的服务提供商来说，实施IPv6是一项重大努力，可能需要花费大量的精力和时间。在某些情况下，基于网络增长和已经使用的私有空间比例，在非常大的网络上实施新的网络协议所需的时间比可用的时间要长。在这些情况下，有一个电话
for additional private address space that can be shared by all network operators. [DAVIES] makes one such case.
可供所有网络运营商共享的额外专用地址空间。[戴维斯]提出了这样一个例子。
Using the unique, local IPv6 unicast addresses defined in [RFC4193] is another approach and does not require coordination with an Internet registry. Although the addresses defined in [RFC4193] are probabilistically unique, network operators on private internets and those providing VPN services might not want to use them because there is a very low probability of non-unique locally assigned global IDs being generated by the algorithm. Also, in the case of private internets, it can be very challenging to coordinate the introduction of a new network protocol to support the internet's continued growth.
使用[RFC4193]中定义的唯一本地IPv6单播地址是另一种方法，不需要与Internet注册表协调。尽管[RFC4193]中定义的地址在概率上是唯一的，但私人互联网上的网络运营商和提供VPN服务的网络运营商可能不想使用这些地址，因为该算法生成非唯一本地分配的全局ID的概率非常低。此外，在私人互联网的情况下，协调引入新的网络协议以支持互联网的持续增长可能是非常具有挑战性的。
4.2.1. Address Transfers or Leases from Organizations with Available Address Space
4.2.1. 从具有可用地址空间的组织进行地址传输或租用
The Regional Internet Registry (RIR) communities have recently been developing policies to allow organizations with available address space to transfer such designated space to other organizations [RIR-POLICY]. In other cases, leases might be arranged. This approach is only viable for operators of very large networks if enough address space is made available for transfer or lease and if the very large networks are able to pay the costs of these transfers. It is not possible to know how much address space will become available in this way, when it will be available, and how much it will cost. However, it is unlikely to become available in large contiguous blocks, and this would add to the network management burden for the operator as a significant number of small prefixes would inflate the size of the operators routing table at a time when it is also adding an IPv6 routing table. These reasons will make address transfers a less attractive proposition to many large network operators. Leases might not be attractive to some organizations if both parties cannot agree to a suitable length of time. Also, the lessor might worry about its own unanticipated needs for additional IPv4 address space.
区域互联网注册（RIR）社区最近一直在制定政策，允许拥有可用地址空间的组织将此类指定空间转移给其他组织[RIR-POLICY]。在其他情况下，可以安排租赁。只有在提供足够的地址空间用于传输或租赁，并且超大网络能够支付这些传输成本的情况下，这种方法才适用于超大网络的运营商。不可能知道以这种方式有多少地址空间可用，何时可用，以及需要多少成本。然而，它不太可能在大的连续块中可用，这将增加运营商的网络管理负担，因为大量小前缀会在同时添加IPv6路由表时扩大运营商路由表的大小。这些原因将使地址传输对许多大型网络运营商来说不再具有吸引力。如果双方不能商定适当的时间长度，租约对某些组织可能没有吸引力。此外，出租人可能会担心自己对额外IPv4地址空间的意外需求。
4.2.2. Using Unannounced Address Space Allocated to Another Organization
4.2.2. 使用分配给其他组织的未通知地址空间
Some network operators have considered using IP address space that is allocated to another organization but is not publicly visible in BGP routing tables. This option is very strongly discouraged as the fact that an address block is not visible from one view does not mean that it is not visible from another. Furthermore, address usage tends to
一些网络运营商考虑使用分配给另一个组织但在BGP路由表中不公开的IP地址空间。强烈反对使用此选项，因为地址块在一个视图中不可见并不意味着它在另一个视图中不可见。此外，地址的使用倾向于
leak beyond private network borders in e-mail headers, DNS queries, traceroute output and other ways. The ambiguity this causes is problematic for multiple organizations. This issue is discussed in [RFC3879], Section 2.3.
通过电子邮件头、DNS查询、跟踪路由输出和其他方式泄漏到专用网络边界之外。这导致的模糊性对于多个组织来说是有问题的。[RFC3879]第2.3节讨论了该问题。
It is also possible that the registrant of the address block might want to increase its visibility to other networks in the future, causing problems for anyone using it unofficially. In some cases, there might also be legal risks involved in using address space officially allocated to another organization.
地址块的注册人也可能希望在将来增加其对其他网络的可见性，这会给任何非官方使用它的人带来问题。在某些情况下，使用正式分配给另一个组织的地址空间也可能涉及法律风险。
Where this has happened in the past, it has caused operational problems [FASTWEB].
在过去发生这种情况的地方，它导致了运营问题[FASTWEB]。
RIRs' policies allow network operators to receive unique IP addresses for use on internal networks. Further, network operators are not required to have already exhausted the private address space set aside in [RFC1918]. Nonetheless, network operators are naturally disinclined to request unique IPv4 addresses for the private areas of their networks, as using addresses in this way means they are not available for use by new Internet user connections.
RIRs的政策允许网络运营商接收在内部网络上使用的唯一IP地址。此外，网络运营商不需要已经耗尽[RFC1918]中预留的专用地址空间。尽管如此，网络运营商自然不愿意为其网络的专用区域请求唯一的IPv4地址，因为以这种方式使用地址意味着新的Internet用户连接无法使用这些地址。
It is likely to become more difficult for network operators to obtain large blocks of unique address space as we approach the point where all IPv4 unicast /8s have been allocated. Several RIRs already have policies about how to allocate from their last /8 [RIR-POLICY-FINAL-8], and there have been policy discussions that would reduce the maximum allocation size available to network operators [MAX-ALLOC] or would reduce the period of need for which the RIR can allocate [SHORTER-PERIODS].
当我们接近所有IPv4单播/8都已分配的点时，网络运营商可能更难获得大块的唯一地址空间。一些RIR已经制定了关于如何从其最后/8[RIR-POLICY-FINAL-8]分配的政策，并且已经进行了政策讨论，以减少网络运营商可用的最大分配大小[MAX-ALLOC]，或者减少RIR可以分配的需求周期[更短周期]。
It is possible to re-designate a portion of the current global unicast IPv4 address space as private unicast address space. Doing this could benefit a number of operators of large networks for the short period before they complete their IPv6 roll-out. However, this benefit incurs a cost by reducing the pool of global unicast addresses available to users in general.
可以将当前全局单播IPv4地址空间的一部分重新指定为专用单播地址空间。这样做可以让许多大型网络运营商在完成IPv6推出前的短时间内受益。然而，这一好处由于减少了一般用户可用的全局单播地址池而产生了成本。
When discussing re-designating a portion of the current global unicast IPv4 address space as private unicast address space, it is important to consider how much space would be used and for how long it would be sufficient. Not all of the large networks making full
当讨论将当前全局单播IPv4地址空间的一部分重新指定为专用单播地址空间时，考虑使用多少空间以及多长时间就足够了。并不是所有的大型网络都能充分利用
use of the space defined in [RFC1918] would have their needs met with a single /8. In 2005, [HAIN] suggested reserving three /8s for this purpose, while in 2009 [DAVIES] suggested a single /10 would be sufficient. There does not seem to be a consensus for a particular prefix length nor an agreed basis for deciding what is sufficient. The problem is exacerbated by the continually changing needs of ever expanding networks.
使用[RFC1918]中定义的空间可以通过单个/8满足他们的需求。2005年，[HAIN]建议为此保留三个/8，而2009年[DAVIES]建议只保留一个/10就足够了。对于特定的前缀长度似乎没有达成共识，也没有一个商定的基础来决定什么是足够的。不断扩大的网络不断变化的需求加剧了这一问题。
A further consideration is which of the currently unallocated IPv4 unicast /8 blocks should be used for this purpose. Using address space that is known to be used unofficially is tempting. For instance, 1.0.0.0/8, which was unallocated until January 2010, was proposed in [HAIN] and is known to be used by a number of different users. These include networks making use of HIP LSIs [RFC4423], [WIANA], [anoNet], and others. There is anecdotal [VEGODA] and research [WESSELS] evidence to suggest that several other IPv4 /8s are used in this fashion. Also there have been discussions [NANOG] about some sections of these /8's being carved out and filtered, therefore unofficially enabling the use of these sections for private use.
进一步考虑的是，应使用当前未分配的IPv4单播/8块中的哪一个用于此目的。使用已知非官方使用的地址空间很诱人。例如，1.0.0.0/8在[HAIN]中被提出，直到2010年1月才被分配，并且已知被许多不同的用户使用。这些包括使用HIP LSI[RFC4423]、[WIANA]、[anoNet]和其他设备的网络。有传闻[VEGODA]和研究[WESSELS]证据表明，其他几种IPv4/8也以这种方式使用。此外，还讨论了[NANOG]关于这些/8的某些部分被分割和过滤的问题，因此非正式地允许将这些部分用于私人用途。
Although new IPv4 /8s are allocated approximately once a month, they are not easy to bring into use because network operators are slow to change their filter configurations. This is despite long-running awareness campaigns [CYMRU] [LEWIS] and active work [ripe-351] to notify people whose filters are not changed in a timely fashion. Updating code that recognizes private address space in deployed software and infrastructure systems is likely to be far more difficult as many systems have these ranges hard-coded and cannot be quickly changed with a new configuration file.
尽管新的IPv4/8大约每月分配一次，但它们不容易投入使用，因为网络运营商更改过滤器配置的速度很慢。尽管有长期的宣传活动[CYMRU][LEWIS]和积极的工作[Crime-351]，通知那些过滤器没有及时更换的人，这一点仍然存在。更新识别已部署软件和基础设施系统中的私有地址空间的代码可能要困难得多，因为许多系统都对这些范围进行了硬编码，并且无法使用新的配置文件快速更改。
Another consideration when redefining existing unicast space as private address space is that no single class of user can expect the space to stay unique to them. This means that an ISP using a new private address range cannot expect its customers not to already be using that address range within their own networks.
在将现有单播空间重新定义为专用地址空间时，另一个需要考虑的问题是，任何一类用户都不能期望该空间对他们来说是唯一的。这意味着，使用新的专用地址范围的ISP不能期望其客户不在其自己的网络中使用该地址范围。
Where a group of networks find themselves in a position where they each need a large amount of IPv4 address space from an RIR in addition to that defined in [RFC1918], they might cooperatively agree to all use the same address space to number their networks. The clear benefit to this approach is that it significantly reduces the potential demand on the pool of unallocated IPv4 address space. However, the issues discussed in Sections 4.2.2 and 5.3 are of concern here, particularly the possibility that one operator might
如果一组网络发现自己处于这样的位置，除了[RFC1918]中定义的地址空间外，它们还需要RIR提供大量IPv4地址空间，则它们可能会合作同意所有网络都使用相同的地址空间对其网络进行编号。这种方法的明显好处是，它显著降低了对未分配IPv4地址空间池的潜在需求。然而，第4.2.2节和第5.3节中讨论的问题在这里值得关注，特别是一个操作员可能
decide to use the address space to number customer connections, rather than private infrastructure.
决定使用地址空间对客户连接进行编号，而不是对私有基础设施进行编号。
Nonetheless, this approach has the potential to create an unofficial new private address range without proper scrutiny.
尽管如此，这种方法有可能在没有适当审查的情况下创建一个非官方的新私人地址范围。
5.3. Potential Consequences of Not Redefining Existing Unicast Space as Private Address Space
5.3. 不将现有单播空间重新定义为专用地址空间的潜在后果
If additional private address space is not defined and the large network operators affected by this problem are not able to solve their problems with IPv6 address space or by segmenting their networks into multiple routing domains, those networks will need unique IPv4 addresses. It is possible and even likely that a single network could consume a whole IPv4 /8 in a year. At the time this document is being written, there are just 24 unallocated IPv4 /8s, so it would not take many such requests to make a major dent in the available IPv4 address space. [POTAROO] provides an analysis of IPv4 address consumption and projects the date on which the IANA and RIR pools will be fully allocated.
如果未定义额外的专用地址空间，并且受此问题影响的大型网络运营商无法通过IPv6地址空间或将其网络分割为多个路由域来解决其问题，则这些网络将需要唯一的IPv4地址。单个网络可能甚至可能在一年内消耗整个IPv4/8。在编写本文档时，只有24个未分配的IPv4/8，因此不需要太多这样的请求就可以大大减少可用的IPv4地址空间。[POTAROO]提供IPv4地址消耗分析，并预测IANA和RIR池完全分配的日期。
There have also been proposals to re-designate the former Class E space (240.0.0.0/4) as unicast address space. [WILSON] suggests that it should be privately scoped while [FULLER] does not propose a scope. Both proposals note that existing deployed equipment may not be able to use addresses from 240.0.0.0/4. Potential users would need to be sure of the status of the equipment on their network and the networks with which they intend to communicate.
还有人提议将以前的E类空间（240.0.0.0/4）重新指定为单播地址空间。[WILSON]建议应该私下确定范围，而[FULLER]没有提出范围。两项提案都指出，现有部署的设备可能无法使用240.0.0.0/4中的地址。潜在用户需要确定其网络上设备的状态以及他们打算与之通信的网络。
It is not immediately clear how useful 240.0.0.0/4 could be in practice. While [FULLER] documents the status of several popular desktop and server operating systems, the status of the most widely deployed routers and switches is less clear, and it is possible that 240.0.0.0/4 might only be useful in very large, new green field deployments where full control of all deployed systems is available. However, in such cases it might well be easier to deploy an IPv6 network.
目前还不清楚240.0.0.0/4在实践中有多有用。虽然[FULLER]记录了几种流行的桌面和服务器操作系统的状态，但部署最广泛的路由器和交换机的状态不太清楚，而且240.0.0.0/4可能只在非常大的新绿地部署中有用，在这些部署中，可以完全控制所有部署的系统。然而，在这种情况下，部署IPv6网络可能更容易。
This document has no security implications.
本文件不涉及安全问题。
[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月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[CLAYTON] Clayton, R., "Practical mobile Internet access traceability", January 2010, <http://www.lightbluetouchpaper.org/ 2010/01/13/practical-mobile-internet-access-traceability/>.
[CLAYTON]CLAYTON，R.，“实用移动互联网接入可追溯性”，2010年1月<http://www.lightbluetouchpaper.org/ 2010/01/13/实用移动互联网接入可追溯性/>。
[CYMRU] Greene, B., "The Bogon Reference", <http://www.team-cymru.org/Services/Bogons/>.
[CYMRU]Greene，B.，“Bogon参考”<http://www.team-cymru.org/Services/Bogons/>.
[DAVIES] Davies, G. and C. Liljenstolpe, "Transitional non-conflicting reusable IPv4 address block", Work in Progress, November 2009.
[DAVIES]DAVIES，G.和C.Liljenstolpe，“过渡的非冲突可重用IPv4地址块”，正在进行的工作，2009年11月。
[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.
[DS-LITE]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈LITE宽带部署”，正在进行的工作，2010年8月。
[FASTWEB] Aina, A., "41/8 announcement", May 2006, <http://www.afnog.org/archives/2006-May/002117.html>.
[FASTWEB]Aina，A.，“41/8公告”，2006年5月<http://www.afnog.org/archives/2006-May/002117.html>.
[FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2010.
[FORD]福特，M.，布卡代尔，M.，杜兰德，A.，利维斯，P.，和P.罗伯茨，“IP地址共享问题”，正在进行的工作，2010年3月。
[FULLER] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 as usable unicast address space", Work in Progress, March 2008.
[FULLER]FULLER，V.，Lear，E.，和D.Meyer，“将240/4重新分类为可用单播地址空间”，正在进行的工作，2008年3月。
[HAIN] Hain, T., "Expanded Address Allocation for Private Internets", Work in Progress, January 2005.
[HAIN]HAIN，T.，“私人互联网的扩展地址分配”，正在进行的工作，2005年1月。
[LEWIS] Lewis, J., "This system has been setup for testing purposes for 69/8 address space", March 2003, <http://69box.atlantic.net/>.
[LEWIS]LEWIS，J.，“该系统是为测试69/8地址空间而设置的”，2003年3月<http://69box.atlantic.net/>.
[MAX-ALLOC] Spenceley, J. and J. Martin, "prop-070: Maximum IPv4 allocation size", January 2009, <http://www.apnic.net/policy/proposals/prop-070>.
[MAX-ALLOC]Spenceley，J.和J.Martin，“第070号提案：最大IPv4分配大小”，2009年1月<http://www.apnic.net/policy/proposals/prop-070>.
[NANOG] Dickson, B., "1/8 and 27/8 allocated to APNIC", January 2010, <http://mailman.nanog.org/ pipermail/nanog/2010-January/017451.html>.
[NANOG]Dickson，B.，“分配给APNIC的1/8和27/8”，2010年1月<http://mailman.nanog.org/ pipermail/nanog/2010年1月/017451.html>。
[POTAROO] Huston, G., "IPv4 Address Report", <http://www.potaroo.net/tools/ipv4/index.html>.
[POTAROO]Huston，G.，“IPv4地址报告”<http://www.potaroo.net/tools/ipv4/index.html>.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.
[RFC3879]Huitema，C.和B.Carpenter，“不推荐现场本地地址”，RFC 3879，2004年9月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423]Moskowitz，R.和P.Nikander，“主机身份协议（HIP）体系结构”，RFC 4423，2006年5月。
[RIR-POLICY] Number Resource Organization, "RIR Comparative Policy Overview, October 2009, Section 1.3.2 Transfer of Custodianship", <http://www.nro.net/rir-comparative-policy-overview/ rir-comparative-policy-overview-2009-03#1-3-2>.
[RIR-POLICY]数字资源组织，“RIR比较政策概述，2009年10月，第1.3.2节保管权转让”<http://www.nro.net/rir-comparative-policy-overview/ rir-comparative-policy-overview-2009-03#1-3-2>。
[RIR-POLICY-FINAL-8] Number Resource Organization, "RIR Comparative Policy Overview, October 2009, 2.6. Use of Final Unallocated IPv4 Address Space", October 2009, <http://www.nro.net/ rir-comparative-policy-overview/ rir-comparative-policy-overview-2009-03>.
[RIR-POLICY-FINAL-8]数字资源组织，“RIR比较策略概述，2009年10月，2.6.最终未分配IPv4地址空间的使用”，2009年10月<http://www.nro.net/ rir比较政策概述/rir-comparative-policy-overview-2009-03>。
[SHORTER-PERIODS] Karrenberg, D., O'Reilly, N., Titley, N., and R. Bush, "RIPE Policy Proposal 2009-03", April 2009, <http://www.ripe.net/ripe/policies/ proposals/2009-03>.
[短期]Karrenberg，D.，O'Reilly，N.，Titley，N.，和R.Bush，“2009-03年成熟的政策提案”，2009年4月<http://www.ripe.net/ripe/policies/ 提案/2009-03>。
[VEGODA] Vegoda, L., "Awkward /8 Assignments", September 2007, <http://www.cisco.com/web/about/ac123/ac147/ archived_issues/ipj_10-3/103_awkward.html>.
[VEGODA]VEGODA，L.，“尴尬/8任务”，2007年9月<http://www.cisco.com/web/about/ac123/ac147/ 已存档的问题/ipj_10-3/103_.html>。
[WESSELS] Wessels, D., "Searching for Evidence of Unallocated Address Space Usage in DITL 2008 Data", June 2008, <https://www.dns-oarc.net/files/dnsops-2008/ Wessels-Unused-space.pdf>.
[WESSELS]WESSELS，D.“在DITL 2008数据中搜索未分配地址空间使用的证据”，2008年6月<https://www.dns-oarc.net/files/dnsops-2008/ Wessels Unused space.pdf>。
[WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority", <http://www.wiana.org/>.
[WIANA]WIANA，“无线互联网分配号码管理局”<http://www.wiana.org/>.
[WILSON] Wilson, P., Michaelson, G., and G. Huston, "Redesignation of 240/4 from "Future Use" to "Private Use"", Work in Progress, September 2008.
[WILSON]WILSON，P.，Michaelson，G.，和G.Huston，“将240/4从“未来使用”重新指定为“私人使用”，正在进行的工作，2008年9月。
[anoNet] anoNet, "anoNet: Cooperative Chaos".
[anoNet]anoNet，“anoNet:合作混沌”。
[ripe-351] Karrenberg, D., "De-Bogonising New Address Blocks", October 2005, <http://www.ripe.net/ripe/docs/ripe-351>.
[RIME-351]Karrenberg，D.，“去Bogonising新地址块”，2005年10月<http://www.ripe.net/ripe/docs/ripe-351>.
The authors would like to thank Ron Bonica, Michelle Cotton, Lee Howard, and Barbara Roseman for their assistance in early discussions of this document and to Maria Blackmore, Alex Bligh, Mat Ford, Thomas Narten, and Ricardo Patara for suggested improvements.
作者感谢Ron Bonica、Michelle Cotton、Lee Howard和Barbara Roseman在本文件早期讨论中提供的帮助，并感谢Maria Blackmore、Alex Bligh、Mat Ford、Thomas Narten和Ricardo Patara提出的改进建议。
Authors' Addresses
作者地址
Marla Azinger Frontier Communications Corporation Vancouver, WA United States of America
Marla Azinger Frontier Communications Corporation美利坚合众国华盛顿州温哥华
EMail: marla.azinger@ftr.com
URI: http://www.frontiercorp.com/
EMail: marla.azinger@ftr.com
URI: http://www.frontiercorp.com/
Leo Vegoda Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States of America
利奥·维戈达互联网公司，地址：美国加利福尼亚州马里纳·德雷市海军部路4676号330室，邮编：90292
Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/
Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/