From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6319.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc6319.txt (limited to 'doc/rfc/rfc6319.txt') diff --git a/doc/rfc/rfc6319.txt b/doc/rfc/rfc6319.txt new file mode 100644 index 0000000..f03008d --- /dev/null +++ b/doc/rfc/rfc6319.txt @@ -0,0 +1,675 @@ + + + + + + +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 + +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. + + 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. + + 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. + + + + + + + + + + + + +Azinger & Vegoda Informational [Page 1] + +RFC 6319 Additional Private IPv4 July 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + + +Azinger & Vegoda Informational [Page 2] + +RFC 6319 Additional Private IPv4 July 2011 + + +1. Introduction + + [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. + + 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. + +2. Large Networks + + 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. + +3. Non-Unique Addresses + +3.1. Subscriber Use Network Address Translation + + 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 + + + +Azinger & Vegoda Informational [Page 3] + +RFC 6319 Additional Private IPv4 July 2011 + + + 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. + + 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. + +3.2. Carrier-Grade Network Address Translation + + 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]. + +4. Available Options + + 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. + +4.1. IPv6 Options + +4.1.1. Unique Globally Scoped IPv6 Unicast Addresses + + 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 + + + + +Azinger & Vegoda Informational [Page 4] + +RFC 6319 Additional Private IPv4 July 2011 + + + for additional private address space that can be shared by all + network operators. [DAVIES] makes one such case. + +4.1.2. Unique Local IPv6 Unicast Addresses + + 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. + +4.2. IPv4 Options + +4.2.1. Address Transfers or Leases from Organizations with Available + Address Space + + 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. + +4.2.2. Using Unannounced Address Space Allocated to Another + Organization + + 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 + + + +Azinger & Vegoda Informational [Page 5] + +RFC 6319 Additional Private IPv4 July 2011 + + + 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. + + 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]. + +4.2.3. Unique IPv4 Space Registered by an RIR + + 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. + + 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]. + +5. Options and Consequences for Defining New Private Use Space + +5.1. Redefining Existing Unicast Space as Private Address Space + + 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. + + 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 + + + +Azinger & Vegoda Informational [Page 6] + +RFC 6319 Additional Private IPv4 July 2011 + + + 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. + + 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. + + 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. + + 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. + +5.2. Unique IPv4 Space Shared by a Group of Operators + + 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 + + + + +Azinger & Vegoda Informational [Page 7] + +RFC 6319 Additional Private IPv4 July 2011 + + + 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 + + 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. + +5.4. Redefining Future Use Space as Unicast Address Space + + 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. + + 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. + +6. Security Considerations + + This document has no security implications. + + + + + + + + +Azinger & Vegoda Informational [Page 8] + +RFC 6319 Additional Private IPv4 July 2011 + + +7. References + +7.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., + and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC2993] Hain, T., "Architectural Implications of NAT", + RFC 2993, November 2000. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network + Address Translator (Traditional NAT)", RFC 3022, + January 2001. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + +7.2. Informative References + + [CLAYTON] Clayton, R., "Practical mobile Internet access + traceability", January 2010, + . + + [CYMRU] Greene, B., "The Bogon Reference", + . + + [DAVIES] Davies, G. and C. Liljenstolpe, "Transitional + non-conflicting reusable IPv4 address block", Work + in Progress, November 2009. + + [DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, + "Dual-Stack Lite Broadband Deployments Following IPv4 + Exhaustion", Work in Progress, August 2010. + + [FASTWEB] Aina, A., "41/8 announcement", May 2006, + . + + [FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. + Roberts, "Issues with IP Address Sharing", Work + in Progress, March 2010. + + + + + + + + +Azinger & Vegoda Informational [Page 9] + +RFC 6319 Additional Private IPv4 July 2011 + + + [FULLER] Fuller, V., Lear, E., and D. Meyer, "Reclassifying + 240/4 as usable unicast address space", Work + in Progress, March 2008. + + [HAIN] Hain, T., "Expanded Address Allocation for Private + Internets", Work in Progress, January 2005. + + [LEWIS] Lewis, J., "This system has been setup for testing + purposes for 69/8 address space", March 2003, + . + + [MAX-ALLOC] Spenceley, J. and J. Martin, "prop-070: Maximum IPv4 + allocation size", January 2009, + . + + [NANOG] Dickson, B., "1/8 and 27/8 allocated to APNIC", + January 2010, . + + [POTAROO] Huston, G., "IPv4 Address Report", + . + + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol + (HIP) Architecture", RFC 4423, May 2006. + + [RIR-POLICY] Number Resource Organization, "RIR Comparative Policy + Overview, October 2009, Section 1.3.2 Transfer of + Custodianship", + . + + [RIR-POLICY-FINAL-8] + Number Resource Organization, "RIR Comparative Policy + Overview, October 2009, 2.6. Use of Final Unallocated + IPv4 Address Space", October 2009, . + + [SHORTER-PERIODS] + Karrenberg, D., O'Reilly, N., Titley, N., and R. Bush, + "RIPE Policy Proposal 2009-03", April 2009, + . + + + + + + +Azinger & Vegoda Informational [Page 10] + +RFC 6319 Additional Private IPv4 July 2011 + + + [VEGODA] Vegoda, L., "Awkward /8 Assignments", September 2007, + . + + [WESSELS] Wessels, D., "Searching for Evidence of Unallocated + Address Space Usage in DITL 2008 Data", June 2008, + . + + [WIANA] WIANA, "The Wireless Internet Assigned Numbers + Authority", . + + [WILSON] Wilson, P., Michaelson, G., and G. Huston, + "Redesignation of 240/4 from "Future Use" to "Private + Use"", Work in Progress, September 2008. + + [anoNet] anoNet, "anoNet: Cooperative Chaos". + + [ripe-351] Karrenberg, D., "De-Bogonising New Address Blocks", + October 2005, . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Azinger & Vegoda Informational [Page 11] + +RFC 6319 Additional Private IPv4 July 2011 + + +Appendix A. Acknowledgments + + 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. + +Authors' Addresses + + Marla Azinger + Frontier Communications Corporation + Vancouver, WA + United States of America + + 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 + + Phone: +1-310-823-9358 + EMail: leo.vegoda@icann.org + URI: http://www.iana.org/ + + + + + + + + + + + + + + + + + + + + + + + + +Azinger & Vegoda Informational [Page 12] + -- cgit v1.2.3