Network Working Group M. Azinger
Internet-Draft Frontier Communications
Intended status: Informational Corporation
Expires: August 5, 2010 L. Vegoda
ICANN
February 1, 2010
Additional Private IPv4 Space Issues
draft-azinger-additional-private-ipv4-space-issues-02
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 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 August 5, 2010.
Copyright Notice
Azinger & Vegoda Expires August 5, 2010 [Page 1]
Internet-Draft Additional Private IPv4 February 2010
Copyright (c) 2010 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 BSD License.
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.2. Unique IPv4 Space Shared by a Group of Operators . . . . . 6
5.3. Potential Consequences of Not Redefining Additional
Unicast Space as Private Address Space . . . . . . . . . . 6
5.4. Redefining Future Use Space as Unicast Address Space . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Azinger & Vegoda Expires August 5, 2010 [Page 2]
Internet-Draft Additional Private IPv4 February 2010
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 August 5, 2010 [Page 3]
Internet-Draft Additional Private IPv4 February 2010
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.
[I-D.davies-reusable-ipv4-address-block] makes one such case.
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 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. 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 August 5, 2010 [Page 4]
Internet-Draft Additional Private IPv4 February 2010
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
use 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 while in 2009
[I-D.davies-reusable-ipv4-address-block] 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
Azinger & Vegoda Expires August 5, 2010 [Page 5]
Internet-Draft Additional Private IPv4 February 2010
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 which is known to be used unofficially is tempting. For
instance, 1.0.0.0/8, which was unallocated until January 2010, was
proposed in [I-D.hain-1918bis] 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 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.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.
This approach has the potential to create an unofficial new private
address range without proper scrutiny.
5.3. 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 24 unallocated IPv4 /8s, so it would not take
many such requests to make a major dent in the available IPv4 address
Azinger & Vegoda Expires August 5, 2010 [Page 6]
Internet-Draft Additional Private IPv4 February 2010
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. [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
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
Azinger & Vegoda Expires August 5, 2010 [Page 7]
Internet-Draft Additional Private IPv4 February 2010
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.davies-reusable-ipv4-address-block]
Davies, G. and C. Liljenstolpe, "Transitional non-
conflicting reusable IPv4 address block",
draft-davies-reusable-ipv4-address-block-00 (work in
progress), November 2009.
[I-D.fuller-240space]
Fuller, V., "Reclassifying 240/4 as usable unicast address
space", draft-fuller-240space-02 (work in progress),
March 2008.
[I-D.hain-1918bis]
Hain, T., "Expanded Address Allocation for Private
Internets", draft-hain-1918bis-01 (work in progress),
February 2005.
[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.
[anoNet] anoNet, "anoNet: Cooperative Chaos",
<http://www.anonet.org/>.
[CYMRU] Greene, B., "The Bogon Reference",
<http://www.team-cymru.org/Services/Bogons/>.
[LEWIS] Lewis, J., "This system has been setup for testing
purposes for 69/8 address space",
<http://69box.atlantic.net/>.
[NANOG] Dickson, B., "1/8 and 27/8 allocated to APNIC", <http://
mailman.nanog.org/pipermail/nanog/2010-January/
017451.html>.
[POTAROO] Huston, G., "IPv4 Address Report",
<http://www.potaroo.net/tools/ipv4/index.html>.
[ripe-351]
Karrenberg, D., "De-Bogonising New Address Blocks",
Azinger & Vegoda Expires August 5, 2010 [Page 8]
Internet-Draft Additional Private IPv4 February 2010
<http://www.ripe.net/ripe/docs/ripe-351.html>.
[RIR-POLICY]
Number Resource Organization, "RIR Comparative Policy
Overview, October 2009, Section 1.3.2 Transfer of
Custodianship",
<http://www.nro.net/documents/comp-pol-200910.html#1-3-2>.
[VEGODA] Vegoda, L., "Awkward /8 Assignments", <http://
www.cisco.com/web/about/ac123/ac147/archived_issues/
ipj_10-3/103_awkward.html>.
[WESSELS] Wessels, D., "Searching for Evidence of Unallocated
Address Space Usage in DITL 2008 Data", <https://
www.dns-oarc.net/files/dnsops-2008/
Wessels-Unused-space.pdf>.
[WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority",
<http://www.wiana.org/>.
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.
Authors' Addresses
Marla Azinger
Frontier Communications Corporation
Vancouver
United States of America
Email: marla.azinger@frontiercorp.com
URI: http://www.frontiercorp.com/
Azinger & Vegoda Expires August 5, 2010 [Page 9]
Internet-Draft Additional Private IPv4 February 2010
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 August 5, 2010 [Page 10]
