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
<Hain> 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]