Internet Draft T.Hain Document: draft-hain-1918bis-01.txt Cisco Systems Expires: July 2005 January 2005 Expanded Address Allocation for Private Internets Status of this Memo "By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668." 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. Abstract This document updates RFC 1918 and identifies additional IPv4 address space for use in private networks. Table of Contents Introduction......................................................2 Example cases.....................................................2 Private Address Space.............................................5 IANA Considerations...............................................5 Security Considerations...........................................5 References........................................................5 Author's Addresses................................................5 Expires - July 2005 [Page 1] Expanded Address Allocation for Private Internets Jan 2005 Introduction A number of organizations have expanded their autonomous private networks to the point of exhausting the address space identified in RFC 1918, in addition to the publicly routed space that has been assigned to them. Given the policies for acquiring additional public space it is not reasonable for them to acquire such space for use in their private networks. While it is tempting to tell them to just switch to IPv6, that is not realistic from application availability, and transition timeframe standpoint. They need additional IPv4 space to continue to grow during the transition period. That space should be formally allocated rather than simply taken on the assumption it will not be publicly allocated before they complete a transition to IPv6. Any deployment will be gated by the following factors: - Product availability - Budget availability - Acquisition timeframe - Operations training - Testing / interoperability assurance window - Deployment window To the degree that the organization uses the normal life-cycle replacement approach to minimize any explicit IPv6 budget items, the acquisition timeframe by itself could be 5 years or more. In any event, the organization has typical timeframes for the period between product / service availability and when they consider that to be operationally deployed. This document points out that those deployment timeframes extend well beyond the point where they will have exhausted the space defined in RFC 1918. Example cases A global organization, with over 5000 existing facilities, allocates a /21 to each from 10/8 (consolidating multiple disjoint /24's that evolved in the older facilities). They have allocated /16's to the set of data center facilities from 172.16/12, along with a number of globally routed /16's for their public facing systems. Internal infrastructure has consumed the 192.168/16 space. This organization is growing at about 1.1% per month. For several years the number of devices on the network is growing at 3 times that rate, not counting the pending entry-level deployment of 100,000 IP phones. At their current size this requires a /12 per year, deployed as approximately 40 new /21 facilities per month (~ three /17's). While there is still a little room in the private space allocated through RFC 1918, barring a sudden new demand on addresses their compounded annual Hain Expires - July 2005 [Page 2] Expanded Address Allocation for Private Internets Jan 2005 growth rate can only be sustained for another 36 months. Faced with the limitations of the RFC 1918 address pool, they are being forced to modify business processes by deploying major new applications in address space that overlaps between facilities. The resulting sub- optimal economics of the unnatural business process will eventually drive a migration to IPv6. Unfortunately even in a best case scenario this migration will take longer than their run rate on the remaining 1918 pool. Their IPv6 deployment plan ... Availability of router software & hardware - 2004 Deployment of updated router software or hardware - + 3 Availability of other network devices (DNS, Firewall, etc) - ???? Deployment of other network devices - + 2 Availability of IPv6 service from ISP's - ???? Deployment of IPv6 service from ISP's - + 1 Availability of network management applications & tools - ???? Deployment of network management applications & tools - + 2 Availability of desktop OS from vendor - 2004 Deployment of updated desktop OS - + 3 Availability of primary business applications from vendors - ???? Deployment of primary business applications - + 3 Availability of other business applications from vendors - ???? Deployment of other business applications - + 4 Availability of embedded appliance stack update from vendor - ???? Deployment of embedded appliance stack update - + 5 Even if all products and services were available with an IPv6 equivalent today, they would require *n* years to work through their normal acquisition, testing, and deployment process. Given that very few application vendors have even announced that IPv6 is on their development roadmap, the actual useful deployment date is easily more than 3 years from now. Several Internet access providers have deployed private address space across the upstream side of their CPE for management purposes. With dynamic customer count per aggregation point coupled with multiple Hain Expires - July 2005 [Page 3] Expanded Address Allocation for Private Internets Jan 2005 addressable entities per CPE device, to manage operational logistics they have reached the point where they need to reuse some address ranges. This overlap creates a burden on operations as they attempt to maintain accurate accounting records and ensure the correct configuration is applied to the overlapped devices. To illustrate the problem; Address utilization efficiency for large numbers decreases with topology hierarchies (RFC 3194). For a typical 60% efficiency, 6 million customer devices requires 10 million of the available 16 million in 10.x. With business partner uses in the neighborhood of 4 million, and additional internal services/losses in the neighborhood of 3 million addresses, these providers have already exceeded the capability of the existing space defined in RFC 1918. Their IPv6 deployment plan ... Availability of router software & hardware - 2004 Deployment of updated router software or hardware - + 3 Availability of other network devices (DNS, Firewall, etc) - ???? Deployment of other network devices - + 2 Availability of network management applications & tools - ???? Deployment of network management applications & tools - + 2 Availability of accounting applications from vendors - ???? Deployment of accounting applications - + 2 Availability of server OS from vendor - 2004 Deployment of updated server OS - + 3 Availability of business partner network IPv6 peering - ???? Deployment of business partner network IPv6 peering - + 2 Availability of CPE devices from vendors - 2007 Deployment of CPE devices - + 4 Even if all products and services were available with an IPv6 equivalent today, they would require *n* years to work through their normal acquisition, testing, service development, and deployment process. Since the standards process to include IPv6 support to the CPE devices has not even started at the end of 2004, it will be at least 2 years before standards based versions of those products will be widely available in the market. The actual deployment rate of those CPE devices could take many years beyond availability as that activity is frequently gated by the end customer. Hain Expires - July 2005 [Page 4] Expanded Address Allocation for Private Internets Jan 2005 Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following blocks of the IPv4 address space for private internets: x.0.0.0 /8 y.0.0.0 /8 z.0.0.0 /8 IANA Considerations IANA should select additional IPv4 /8's for this purpose from those least likely to be allocated for public use. The prefix 1 /8 is a prime candidate as the author is aware of multiple networks that have historically used that one for private use. Another candidate, 223 /8 was recently returned to IANA due to conflicts with RFC 3330. Security Considerations While product marketing frequently confuses the use of private address space with security, there are no such claims being made or validated by this document. References Author's Addresses Tony Hain Cisco Systems 500 108th NE, Bellevue, Wa. 98004 Email: alh-ietf@tndh.net "Copyright (C) The Internet Society 2004. This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights." "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE Hain Expires - July 2005 [Page 5] Expanded Address Allocation for Private Internets Jan 2005 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Hain Expires - July 2005 [Page 6]