Network Working Group M. Azinger Internet-Draft Frontier Communications Intended status: Informational Corporation Expires: March 12, 2010 L. Vegoda ICANN September 8, 2009 Additional Private IPv4 Space Issues draft-azinger-additional-private-ipv4-space-issues-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 12, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract When a private network or internetwork grows very large it is Azinger & Vegoda Expires March 12, 2010 [Page 1] Internet-Draft Additional Private IPv4 September 2009 sometimes not possible to address it using private IPv4 address space. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Large Networks . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Network Address Translation . . . . . . . . . . . . . . . . . . 3 4. Available Options . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Unique Globally Scoped IPv6 Unicast Addresses . . . . . . . 4 4.2. Unique Locally Scoped IPv6 Unicast Addresses . . . . . . . 4 4.3. Address Transfers or Leases From Organizations with Available Address Space . . . . . . . . . . . . . . . . . . 4 4.4. Using Unannounced Address Space Allocated to Another Organization . . . . . . . . . . . . . . . . . . . . . . . 5 4.5. Unique IPv4 Space Registered by an RIR . . . . . . . . . . 5 5. Options and Consequences for Defining New Private Use Space . . 5 5.1. Redefining Additional Unicast Space as Private Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1.1. Unique IPv4 Space Shared by a Group of Operators . . . 6 5.2. Potential Consequences of Not Redefining Additional Unicast Space as Private Address Space . . . . . . . . . . 6 5.3. Redefining Future Use Space as Unicast Address Space . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Azinger & Vegoda Expires March 12, 2010 [Page 2] Internet-Draft Additional Private IPv4 September 2009 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 connect more interfaces than the number of addresses available 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. 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. Network Address Translation The address space set aside in [RFC1918] is a finite resource which can be used to provide limited Internet access via Network Address Translation (NAT). A discussion of the advantages and disadvantages of NATs is outside the scope of this document. Nonetheless, it must be acknowledged that NAT is adequate in some situations and not in others. For instance, it is often technically feasible to use NAT or even multiple layers of NAT within the networks operated by residential users or corporations where peer to peer communication is not needed. Where peer to peer communication is needed or where services or applications do not work properly behind NAT, globally unique address space is required. In many cases it is possible to use multiple layers of NAT to re-use parts of the address space defined in [RFC1918]. In particular, the tendency for low-cost CPEs to use 192.168.0.0/16 as the default address range for the LAN allows providers to make full use of 172.16.0.0/12 and 10.0.0.0/8. Azinger & Vegoda Expires March 12, 2010 [Page 3] Internet-Draft Additional Private IPv4 September 2009 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 include: 4.1. Unique Globally Scoped IPv6 Unicast Addresses Using unique, globally scoped IPv6 unicast addresses is the preferred option as it removes any concerns about address scarcity. 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 for additional private address space that can be shared by all network operators. 4.2. Unique Locally Scoped IPv6 Unicast Addresses Using the unique, locally scoped 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.3. Address Transfers or Leases From Organizations with Available Address Space The Regional Internet Registries (RIRs) have recently been developing policies to allow organizations with available address space to transfer such designated space to other organizations. 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. For these reasons, address transfers will not be an attractive proposition to many large network operators. Leases might not be attractive to some organizations if both parties cannot agree a suitable length of time. Also, the leasor might worry about its own unanticipated needs for additional IPv4 address space. Azinger & Vegoda Expires March 12, 2010 [Page 4] Internet-Draft Additional Private IPv4 September 2009 4.4. Using Unannounced Address Space Allocated to Another Organization Some network operators have considered using IP address space which is allocated to another organizatiobn 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. 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. 4.5. Unique IPv4 Space Registered by an RIR The policy framework shared by the RIRs does not discriminate based on what an address is used to do, just on how efficiently the assigned addresses are used. Unique IPv4 addresses registered by an RIR are potentially available to organizations whose networks have used all the addresses set aside in [RFC1918]. Nonetheless, network operators are naturally disinclined to request unique IPv4 addresses for a purpose that could be met with private addresses were it not for the size of the network. Addresses assigned in this way are not available for anyone else to use and so their registration denies them to new entrants, including potential customers. 5. Options and Consequences for Defining New Private Use Space 5.1. Redefining Additional Unicast Space as Private Address Space It would be 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 network 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 end users. When considering 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 of of the space defined in [RFC1918] would have their needs met with a single /8. In 2005, [I-D.hain-1918bis] suggested reserving three /8s for this purpose. A further consideration is which of the currently unallocated IPv4 unicast /8 blocks should be used for this purpose. Using address space which is known to be used unofficially is tempting. For Azinger & Vegoda Expires March 12, 2010 [Page 5] Internet-Draft Additional Private IPv4 September 2009 instance, 1.0.0.0/8, which was proposed in [I-D.hain-1918bis] 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. 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 recognises 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. 5.1.1. 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. This approach has the potential to create an unofficial new private address range without proper scrutiny. 5.2. Potential Consequences of Not Redefining Additional 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 of writing there are just 28 unallocated IPv4 /8s, so it would not take many such requests to make a major dent in the available IPv4 address space. 5.3. 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. [I-D.wilson-class-e] suggests that it should be privately scoped while [I-D.fuller-240space] does not propose a scope. Both proposals note that existing deployed equipment may not be able to use addresses Azinger & Vegoda Expires March 12, 2010 [Page 6] Internet-Draft Additional Private IPv4 September 2009 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 [I-D.fuller-240space] 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 greenfield 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. 7. IANA Considerations This document makes no request of IANA. 8. References 8.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. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. 8.2. Informative References [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [I-D.hain-1918bis] Hain, T., "Expanded Address Allocation for Private Internets", draft-hain-1918bis-01 (work in progress), February 2005. Azinger & Vegoda Expires March 12, 2010 [Page 7] Internet-Draft Additional Private IPv4 September 2009 [I-D.wilson-class-e] Wilson, P., Michaelson, G., and G. Huston, "Redesignation of 240/4 from "Future Use" to "Private Use"", draft-wilson-class-e-02 (work in progress), September 2008. [I-D.fuller-240space] Fuller, V., "Reclassifying 240/4 as usable unicast address space", draft-fuller-240space-02 (work in progress), March 2008. [WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority", . [anoNet] anoNet, "anoNet: Cooperative Chaos", . [VEGODA] Vegoda, L., "Awkward /8 Assignments", . [WESSELS] Wessels, D., "Searching for Evidence of Unallocated Address Space Usage in DITL 2008 Data", . [CYMRU] Greene, B., "The Bogon Reference", . [LEWIS] Lewis, J., "This system has been setup for testing purposes for 69/8 address space", . [ripe-351] Karrenberg, D., "De-Bogonising New Address Blocks", . Appendix A. Acknowledgments The authors would also like to thank Ron Bonica, Michelle Cotton, Lee Howard and Barbara Roseman for their assistance in early discussions of this document. Azinger & Vegoda Expires March 12, 2010 [Page 8] Internet-Draft Additional Private IPv4 September 2009 Authors' Addresses Marla Azinger Frontier Communications Corporation Vancouver United States of America Email: marla.azinger@frontiercorp.com URI: http://www.frontiercorp.com/ Leo Vegoda Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey 90292 United States of America Phone: +310-823-9358 Email: leo.vegoda@icann.org URI: http://www.iana.org/ Azinger & Vegoda Expires March 12, 2010 [Page 9]