Network Working Group S. Barber
Internet-Draft Cox Communications
Intended status: Informational O. Delong
Expires: January 5, 2012 Hurricane Electric
C. Grundemann
CableLabs
V. Kuarsingh
Rogers Communications
B. Schliesser
Cisco Systems
July 4, 2011
ARIN Draft Policy 2011-5: Shared Transition Space
draft-bdgks-arin-shared-transition-space-00
Abstract
This memo encourages the reservation of a Shared Transition Space, an
IPv4 prefix designated for local use within service provider networks
during the period of IPv6 transition. This address space has been
proposed at various times in the IETF, and more recently by the ARIN
policy development community.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 5, 2012.
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
Barber, et al. Expires January 5, 2012 [Page 1]
Internet-Draft ARIN Shared Transition Space July 2011
(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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. CGN . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Extranet . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. SP Services . . . . . . . . . . . . . . . . . . . . . 5
2.1.3.1. Private Intranet . . . . . . . . . . . . . . . . . 5
2.2. Alternatives . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Globally Unique . . . . . . . . . . . . . . . . . . . 6
2.2.2. Private . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Class E . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. Prefix Squatting . . . . . . . . . . . . . . . . . . . 7
2.2.5. Regional Re-use of Allocated Prefix . . . . . . . . . 8
2.2.6. Consortium . . . . . . . . . . . . . . . . . . . . . . 8
3. Analysis of Benefits . . . . . . . . . . . . . . . . . . . . . 9
3.1. Continued Operation Post-exhaustion . . . . . . . . . . . 9
3.2. Delayed Need for CGN Deployment . . . . . . . . . . . . . 9
3.3. Recovery of Existing Addresses . . . . . . . . . . . . . . 9
3.3.1. Re-deployment Where Needed . . . . . . . . . . . . . . 9
3.3.2. Return or Transfer . . . . . . . . . . . . . . . . . . 9
3.4. Impact on Allocations / RIR Inventory . . . . . . . . . . 10
3.5. Benefit of Standardization . . . . . . . . . . . . . . . . 10
3.6. IPv6 Deployments . . . . . . . . . . . . . . . . . . . . . 10
4. Analysis of Detractors' Arguments . . . . . . . . . . . . . . 11
4.1. It Breaks . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. NAT is Bad . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Breaks Bad Host Assumptions . . . . . . . . . . . . . 11
4.1.3. Potential Misuse as Private Space . . . . . . . . . . 11
4.2. It's Not Needed . . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Nobody Will Use It . . . . . . . . . . . . . . . . . . 12
4.2.2. ISPs Are Not Actually Growing . . . . . . . . . . . . 12
4.2.3. RIR IPv4 Inventory is Not Actually Exhausted . . . . . 12
4.2.4. ISP IPv4 Inventory is Not Actually Exhausted . . . . . 13
4.3. Address Inventory . . . . . . . . . . . . . . . . . . . . 13
4.3.1. Shared Transition Space Uses Up Address Inventory . . 13
4.3.2. /10 is not Enough . . . . . . . . . . . . . . . . . . 13
4.3.3. It Won't Delay RIR Exhaustion . . . . . . . . . . . . 13
4.4. IPv6 Arguments . . . . . . . . . . . . . . . . . . . . . . 14
4.4.1. Use IPv6 Instead . . . . . . . . . . . . . . . . . . . 14
4.4.2. Delay of IPv6 Deployment . . . . . . . . . . . . . . . 14
Barber, et al. Expires January 5, 2012 [Page 2]
Internet-Draft ARIN Shared Transition Space July 2011
4.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. ARIN Draft Policy 2011-5 . . . . . . . . . . . . . . . . . . . 15
5.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Policy Text . . . . . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Barber, et al. Expires January 5, 2012 [Page 3]
Internet-Draft ARIN Shared Transition Space July 2011
1. Introduction
As the Internet community approaches exhaustion of unallocated IPv4
numbers, the value of globally unique addresses is becoming manifest.
More than ever network operators recognize the need to transition to
the IPv6 address family. However, the immediate necessity of
continued IPv4 connectivity poses a near-term challenge - without
adequate IPv4 resources, most network operators must deploy more
efficient addressing architectures and many must deploy address-
sharing technologies.
In order to facilitate these operators' need for near-term IPv4
connectivity, [I-D.weil-shared-transition-space-request] proposes the
reservation of a /10 IPv4 prefix for use in Service Provider (SP)
networks. Referred to as Shared Transition Space, this address block
would facilitate SP deployment of non-unique address plans that do
not conflict with traditional Private [RFC1918] address space. By
using the Shared Transition Space operators may deploy CGN
[I-D.ietf-behave-lsn-requirements] internal networks, extranet
[RFC4364] communities, and/or SP-local services without consuming
globally unique addresses.
However, given the Feb 2011 depletion of the IANA Free Pool inventory
[NRO-IANA-exhaust] it is not currently possible for the IANA to
reserve an IPv4 /10 prefix as recommended in
[I-D.weil-shared-transition-space-request]. Thus the ARIN community
has proposed in Draft Policy [ARIN-2011-5] the reservation of a
Shared Transition Space from the ARIN inventory of unallocated IPv4
numbers. After much discussion by the ARIN community, [ARIN-2011-5]
was recommended by the ARIN Advisory Council for approval by the ARIN
Board of Trustees.
Essentially similar to [I-D.weil-shared-transition-space-request],
Draft Policy [ARIN-2011-5] is currently pending ARIN Board approval.
The ARIN Board has asked for IAB clarification with regard to
responsibilities outlined in [RFC2860] and has received a response
[IAB-response] indicating that the IETF holds responsibility for the
reservation of specialized address blocks. Thus, this memo is a
discussion of the merits of a Shared Transition Space, and is a call
for consensus between the IETF and RIR communities that such an
address reservation should be made.
2. Background
Barber, et al. Expires January 5, 2012 [Page 4]
Internet-Draft ARIN Shared Transition Space July 2011
2.1. Applicability
There are a number of use-cases for the Shared Transition Space.
This section discusses the primary scenarios envisioned at the time
of this writing.
2.1.1. CGN
A primary use-case for the Shared Transition Space will be deployment
in CGN internal networks, as described in
[I-D.ietf-behave-lsn-requirements]. A key benefit of CGN is the
ability to share a smaller number of Globally Unique Addresses (GUA)
amongst a larger number of end-sites.
In one CGN deployment scenario sometimes referred to as NAT444
[I-D.shirasaki-nat444-isp-shared-addr], the CGN internal network is
numbered with IPv4 addresses that are not globally routed while the
end-sites are numbered with Private [RFC1918] addresses. In this
scenario the Shared Transition Space will be used to provide
contextually unique IPv4 addresses to end-site CPE devices and
intermediate infrastructure.
2.1.2. Extranet
Another use-case for the Shared Transition Space is in building
private Extranet community networks. In these networks, multiple
end-sites administered by different organizations are connected
together via VPN technology. Because different organizations may be
using Private address space internally, an Extranet addressing plan
is often unable to effectively use Private address space without
conflicting. The Shared Transition Space will provide an alternative
to the use of GUA space in such a scenario.
2.1.3. SP Services
In networks that contain local services (such as nameservers, content
repositories or caches, etc) the Shared Transition Space will offer
an alternative to GUA. For instance, video content servers that are
available only to customers directly connected to the SP network
might be addressed from the Shared Transition Space, preserving GUA
for services that require global connectivity.
2.1.3.1. Private Intranet
Many service providers have deployed a hierarchical network using
Private [RFC1918] space, which has served them well for many years.
Due in large part to the explosive growth of new services they have
run out of available private space. While it is possible to re-
Barber, et al. Expires January 5, 2012 [Page 5]
Internet-Draft ARIN Shared Transition Space July 2011
engineer internal networks, such activity is customer impacting and
operationally complex. Making more private space available for
service providers allows for a manageable transition to IPv6 without
significant impact to customers.
2.2. Alternatives
A number of possible alternatives to Shared Transition Space have
been proposed and/or discussed by the Internet community. See, for
instance, [I-D.azinger-additional-private-ipv4-space-issues] for a
discussion of alternatives and potential issues. This section
outlines these possible alternatives and briefly discusses their
applicability.
2.2.1. Globally Unique
Every discussion of the Shared Transition Space begins with an
assumption that Globally Unique Addresses (GUA) are a preferable
choice for numbering. This is almost always technically true.
However, given the fundamental driver of IPv4 address exhaustion, GUA
is not a pragmatic alternative to the Shared Transition Space.
Additionally, if various organizations use various GUA ranges to
number CGN zones, it will be difficult for other networks and/or
systems to deterministically know if the endpoints are using true
internet reachable IPs, or if the source network may be using them as
CGN zone space. This situation would likely lead to additional
technical issues during various leakage conditions, filter rule
issues (routing) and for CDN or other third party providers who may
be present within the source network, to name a few.
2.2.2. Private
In each of the use-cases for Shared Transition Space, it may be
possible to instead use Private [RFC1918] address space. In
situations where all endpoints in the network are managed by a single
organization, this may be a viable option. However when end-sites
are administered by different organizations and/or individuals, the
possibility of address conflict becomes a significant risk to
operations.
A study of DNS traffic [v6ops-msg06187] has shown that effectively
all of the existing Private [RFC1918] address space is currently
being used by end-sites attached to the Internet. While individual
network environments may vary in this regard, most SP operators face
the risk that their use of Private address space will conflict with
their customer end-sites.
Barber, et al. Expires January 5, 2012 [Page 6]
Internet-Draft ARIN Shared Transition Space July 2011
In the event of conflict, it is possible that the end-site CPE will
fail and/or not function correctly. Some CPE implementations are
known to support overlapping addresses on the "inside" and "outside"
interfaces, however many others are known to fail under such
circumstances. For SP operators, the Shared Transition Space offers
a less risky alternative to GUA that retains the benefit of non-
conflict.
Also, the use of Private [RFC1918] address space on interfaces and
hosts often causes default behaviours on such hosts which may not be
desirable when the endpoint is actually connected to the Internet.
There are often behavioural expectations for Internet connected
endpoints, regardless of them being subject to a NAT.
Incorrect affiliation of the WAN side interface being in a
"protected" zone and/or on a trusted network may not be desirable.
With NAT444 deployments, it is important that the endpoint (i.e.
CPE) behave like any other internet node. One example of this from
our testing was observed behaviours where some CPEs did not filter
and/or firewall correctly when Private [RFC1918] address space was
used on both WAN and LAN interfaces.
2.2.3. Class E
One proposed alternative to Shared Transition Space is the re-
classification and use of the 240.0.0.0/4 "Class E" address space as
unicast. This has been proposed, for instance, by
[I-D.fuller-240space] and [I-D.wilson-class-e]. While this
alternative might be possible in tightly constrained environments,
where all of the network elements are known to support Class E
address space, it is not generally useful in the use-cases described
above. At this time, a significant number of IPv4 stack
implementations treat the Class E address space as reserved and will
not route, forward, and/or originate traffic for that range.
2.2.4. Prefix Squatting
An unfortunate alternative to the Shared Transition Space is "prefix
squatting", in which the operator re-uses another organization's IPv4
allocation for their own numbering needs. When this approach results
in the other organization's prefix being announced globally by the
"squatting" operator, it is often referred to as "prefix hijacking".
However, this discussion is focused on scenarios in which the prefix
is not announced globally but is, rather, used for internal numbering
only.
In this scenario, the allocation may not be routed globally by the
legitimate address holder, making it attractive for such purposes.
Barber, et al. Expires January 5, 2012 [Page 7]
Internet-Draft ARIN Shared Transition Space July 2011
Or it may be routed but "uninteresting" to the SP network's
endpoints. In either case there is a potential for conflict in the
event that any end-site actually wishes to communicate with the
legitimate address holder. As such, this alternative is to be
discouraged with prejudice.
It is important to note that there are no behavioural advantages to
using "squat space" over using assigned "shared space". Both options
subject the CPE to the same general behaviours (GUA space, but not
globally reachable). The only real difference is the negative
impacts of squatting (as noted above) and the advantages of a
community coordinated and standardized prefix.
The primary reason that any network would be likely to adopt "prefix
squatting" is if they are faced with the operational realities of CGN
before/without the allocation of a shared transition space.
2.2.5. Regional Re-use of Allocated Prefix
Similar to "Prefix Squatting" but significantly less dangerous, this
alternative involves the reuse by an operator of their own address
allocations. In this scenario, a network operator might use the same
prefix for multiple "regions" and/or extranet communities. For
instance, in CGN deployments the operator might reuse the same GUA
prefix across multiple geographic regions (e.g. without announcing it
globally).
Here again, it is important to note that there are no behavioural
advantages gained over a "shared space" but there is the added
community cost of each network having to dedicate a unique block of
addresses to this purpose, consuming far more resources than a single
block of "shared space".
2.2.6. Consortium
In the event that the Internet community doesn't set aside an IPv4
prefix for Shared Transition Space, it is possible that a number of
SP operators can come together and designate an address block to be
"shared" amongst them for an identical purpose. This would have the
same technical merits as an IETF and/or RIR sponsored Shared
Transition Space, however it would lack the efficiency of a community
coordinated and standardized prefix for such purposes, gain no
behavioural advantages, remove the deterministic nature of managing a
single range and also subjects the Internet (users of the space) to
additional risk since any member of the consortium who has
contributed space could later pull out and potentially cause
disruptions in multiple networks.
Barber, et al. Expires January 5, 2012 [Page 8]
Internet-Draft ARIN Shared Transition Space July 2011
3. Analysis of Benefits
3.1. Continued Operation Post-exhaustion
Availability of a Shared Transition Space helps SPs continue to meet
the demands of IPv4 address and/or connectivity post exhaustion. For
environments where CGN in a NAT444 scenario is necessary, addresses
from this space can be used to provide intermediary network
addressing assisting in provided IPv4 flow continuity for new or
migrating customers.
In other circumstances, the shared transition space allows SPs to
number devices in the network which do not require globally
reachablity without the need for fulfillment thorough an RIR.
3.2. Delayed Need for CGN Deployment
If operators are required to us their individually allocated GUA
where "shared space" would have applied, they will face exhaustion
sooner and thus be forced to deploy CGN sooner as well. Operators
can postpone this deployment of CGN by using "shared space" for
internal uses, because that allows more efficient use of their
remaining GUA in places where global uniqueness is truly mandatory.
3.3. Recovery of Existing Addresses
The shared transition space can also be used to number and reclaim
IPv4 addresses within provider networks which do not require global
reachability. This option can be used by many networks worldwide, it
provides an option for using currently assigned space much more
efficiently.
3.3.1. Re-deployment Where Needed
Operators can re-deploy recovered addresses for customers that need
them (including new / static / GUA customers), hosted servers, etc.
or to facilitate other efforts that might provide even more efficient
use of GUA space within the network. The freed addresses can be
assigned to endpoints which require IPv4 global reachablity and thus
help delay and/or remove the need for CGN.
3.3.2. Return or Transfer
In cases where the operator doesn't need the recovered addresses,
they can be made available to others that do need them. This may be
through voluntary return the RIR, or through transfer to another
network operator (perhaps via a market mechanism).
Barber, et al. Expires January 5, 2012 [Page 9]
Internet-Draft ARIN Shared Transition Space July 2011
If an SP determines that the space recovered is not needed, the space
can be returned or transferred through those mechanisms already in
place with the RIRs. For example, in the ARIN region, there are such
mechanisms already defined in the ARIN NRPM section 8.3
[ARIN-NRPM-8.3].
3.4. Impact on Allocations / RIR Inventory
While making "shared space" available to the community, may or may
not lessen the demand on the RIRs for allocations, it will help
ensure that the address resources which remain in inventory are used
most efficiently, maximizing the use of that inventory for services
that require global routability.
BENSON: note that I changed this to "may or may not" because I think
it's arguable either way... If an SP doesn't need globally unique
space to continue numbering (with a CGN) then that might slow the
rate of allocation. On the other hand, unless RIRs police it, the
SP's interest is aligned with continuing to make requests and "bank"
them for later, so that wouldn't change the rate of allocation at
all.
3.5. Benefit of Standardization
Standardizing on a single block will help the community develop
standard ways of selecting, routing, filtering and managing shared
space. This task would be much more difficult or impractical for any
of the alternative options.
Standard internal routing policy and filtering can be applied
uniformly inside network environments. Additionally, exchange points
between networks can have standard policies applied allowing
operators to protect each other from CGN zone IPs leaking between
networks. This may not be possible with squat space since many
operators will not divulge what space may be used and with Private
[RFC1918] address space where each operator may only be able to free
up certain portions of the space which are not likely to be
consistent between networks.
3.6. IPv6 Deployments
Operators will need to grapple with the need to provide IPv4 based
flow continuity to customers post exhaustion. By removing the burden
of operators needing to find adequate IPv4 address space to meet the
needs that a shared transition space can fulfill, they can
concentrate on the real task at hand: Deploying IPv6.
Endless cycles can be avoided where operators squat, free up space
Barber, et al. Expires January 5, 2012 [Page 10]
Internet-Draft ARIN Shared Transition Space July 2011
and/or segment networks in an effort to find valid IPv4 space. The
saved effort, time and cost can be re-directed to provided quality
IPv6 connectivity therefore expiditing the removal of the overall
need for IPv4 addresses and connectivity.
4. Analysis of Detractors' Arguments
4.1. It Breaks
4.1.1. NAT is Bad
NAT is understood to be less then optimal [RFC6269], especially when
implemented as CGN [I-D.donley-nat444-impacts]. That said, it is a
necessary technology for many networks and cannot be completely
avoided. Since the number of IPv4 internet endpoints will exceed the
number of IPv4 addresses which are available for Internet
connectivity, NATs are needed.
While the authors agree that "NAT is bad", it must also be understood
that shared transition space does not change the fundamental problems
with NAT and so those problems will not be discussed at length here.
4.1.2. Breaks Bad Host Assumptions
The use of GUA space (non-RFC1918) does in some circumstances break
some functions. The most commonly cited function is 6to4. Although
6to4 can break, it's not commonly turned on by default. 6to4 can also
be "repaired" in some instances when used behind a CGN (NAT66) or
managed by the network operator. Since the volume of impacted
endpoints will be very low, operators can likely manage the disabling
of 6to4 when needed.
4.1.3. Potential Misuse as Private Space
The value of a Shared Transition Space may be diminished if misused
by end-sites as generic Private addresses. Thus, the reservation
must be clearly designated for use by SPs that are providing
infrastructure as described herein.
This is not a technical issue. As with any technology, the
opportunity exists for a misuse. This however should not shroud the
strong benefits of the shared address space option. Many
technologies in use today can be used correctly or misused. This
does not prevent the community from introducing those technologies
since the good far outweighs the bad.
As an example, the use of DiffServ [RFC2475] can result in punitive
Barber, et al. Expires January 5, 2012 [Page 11]
Internet-Draft ARIN Shared Transition Space July 2011
measures for some hosts in a network while favouring others bad on
illegitimate rules. This however is not a good argument on why not
to permit DiffServ.
4.2. It's Not Needed
4.2.1. Nobody Will Use It
This argument is simply incorrect. Post IPv4-exaustion, any SP that
wishes to continue providing IPv4 connectivity will necessarily
deploy network architectures and technologies that require such an
address space.
In absense of a designated Shared Transition Space, operators will
use GUA space in essentially the same ways described in this memo,
with or without IETF acknowledgement. The industry needs to
recognize this and work in the best interests of the "real customer".
4.2.2. ISPs Are Not Actually Growing
While customer growth for some ISPs has slowed, for many service
providers new services are growing at a faster rate than has been
anticipated. Wireline voice customers for example require two-way
communication paths to allow them to function properly. IP enabled
televisions is another example of devices that support video and
voice services and require IP addresses. In many cases the protocols
that allow these devices to work have embedded IP addresses that do
not work with NAT. The only way to maintain these services, which in
many cases are considered lifeline, is to provide them with an IP
address that is unique with the service provider network.
Likewise, growth continues to exist in some geographical regions.
While some areas have slower growth, as a result of significant
penetration of Internet access, there are still many areas with unmet
needs, growing populations, or both.
4.2.3. RIR IPv4 Inventory is Not Actually Exhausted
With the IANA inventory essentially exhausted [NRO-IANA-exhaust] it
is only a matter of time before each of the RIRs are unable to
satisfy requests for IPv4 addresses. [GIH-When] In fact, the APNIC
has already allocated all but their final /8 of inventory
[APNIC-final-slash8] and is no longer making allocations larger than
a /22 prefix. Each of the other RIRs is on a trajectory toward
exhaustion in the near future.
Barber, et al. Expires January 5, 2012 [Page 12]
Internet-Draft ARIN Shared Transition Space July 2011
4.2.4. ISP IPv4 Inventory is Not Actually Exhausted
While some SPs have existing inventory that will outlast the RIR
inventories, this is not universally true. In fact, the distribution
of IPv4 number resources amongst operators is highly variable (based
on size, history, etc) and in the worst cases is already becoming
problematic.
4.3. Address Inventory
4.3.1. Shared Transition Space Uses Up Address Inventory
While true that the Shared Transition Space will consume some
unallocated inventory, the impact is no greater than would be seen if
individual SPs continue to request allocations of GUA for the
scenarios described herein. It is possible, rather, that the Shared
Transition Space might alleviate some near-term demand on RIR
inventories. However, even if the RIR inventories are exhausted at
the current rate, the reservation of a Shared Transition Space will
enable continued deployment of IPv4 connectivity by SP networks - a
clear benefit.
4.3.2. /10 is not Enough
There are many ISP networks that may require greater or lesser
amounts of IPv4 number resources, as a Shared Transition Space.
While a larger prefix (such as a /8) would allow for expanded
applicability, to larger ISP networks, it is generally thought that a
/10 will be adequate for a large number of network deployments.
Likewise, a /10 seems to be appropriate given the current
technological constraints and operational considerations of CGN
deployment. On the other hand, a smaller prefix might not be large
enough to apply in many modern network deployments. Thus, a /10
prefix for Shared Transition Space is considered an appropriate
compromise.
4.3.3. It Won't Delay RIR Exhaustion
It remains to be seen whether the reservation of a Shared Transition
Space will delay the impending exhaustion of RIRs' IPv4 inventory.
Certainly, the availability of this Shared Transition Space will
satisfy a number of demands that would otherwise become requests for
GUA resources. However, whether this translates to an actual
reduction in requests is up to the RIRs and requesting organizations.
Barber, et al. Expires January 5, 2012 [Page 13]
Internet-Draft ARIN Shared Transition Space July 2011
4.4. IPv6 Arguments
4.4.1. Use IPv6 Instead
Although IPv6 is the strategic long term answer fro IPv4 address
exhaustion, it does not immediately solve IPv4 connectivity
requirements. There is an entire eco-system which exists on the
Internet which is not IPv6 ready at this time. IPv4 flow continuity
will be required for a long period of time.
Many businesses have long procurement and fulfilment cycles which
will need to be used to upgrade networks to support IPv6. Also, the
consumer (home) space is years away from being all IPv6 capable.
Many homes are filled with IPv4 only consumer electronics, computers,
TVs, accessories and other systems.
There are still a number of products that are either not IPv6
compliant, or for which the necessary criteria for being "IPv6
compliant" is unclear or undefined. Some examples include security
products (IDS/IPS in particular), a large number of software
applications (MySQL is one example), and there are still production
systems (both inside companies and as products) being rolled out that
are not IPv6 aware (until very recently, this included all Linksys
routers).
The whole Internet needs to get to IPv6 more or less at the same time
in order to avoid significant deployment of transition technologies.
This proposal may help delay some transition technology deployment
while IPv6 deployments move ahead. More IPv6 should mean less
transition technology.
4.4.2. Delay of IPv6 Deployment
Although IPv6 is the strategic long term answer for IPv4 address
exhaustion, it does not immediately solve IPv4 connectivity
requirements. There is an entire eco-system which exists on the
Internet today and is not IPv6 ready at this time. IPv4 flow
continuity will be required for a long period of time.
Many businesses have long procurement and fulfilment cycles which
will need to be used to upgrade networks to support IPv6. Also, the
consumer (home) space is years away from being fully IPv6 capable.
Many homes are filled with IPv4-only consumer electronics, computers,
TVs, accessories and other systems.
BENSON: Note: "cite arkkois drafts about operating in IPv6-only mode
for evidence that this is not actually workable yet"
Barber, et al. Expires January 5, 2012 [Page 14]
Internet-Draft ARIN Shared Transition Space July 2011
4.5. History
The proposal for additional Private space in order to survive IPv6
transition dates back to [I-D.hain-1918bis] in April 2004, and more
recently as Shared Transition Space [I-D.shirasaki-isp-shared-addr]
in June 2008 where a proposal to set aside "ISP Shared Space" has
been made. During discussion of the more recent proposals many of
the salient points where commented on including challenges with
RFC1918 in the ISP NAT Zone, Avoidance of IP Address Conflicts, and
challenges with 240/4.
This effort was followed up by
[I-D.weil-opsawg-provider-address-space] in July 2010 which was re-
worked in November 2010 as
[I-D.weil-shared-transition-space-request]. The latter two efforts
continued to point out the operators need for Shared Transition
Space, with full acknowledgement that challenges may arise with
NAT444 as per [I-D.donley-nat444-impacts].
Most recently, following exhaution of the IANA's /8 pool
[NRO-IANA-exhaust], this proposal has been discussed by various RIR
policy participants. As described herein, the body of ARIN policy
development participants has recommended a Shared Address Space
policy for adoption [ARIN-2011-5].
This history has shown that operators and other industry contributors
have identified the need for a Shared Transition Space assignment
based on clearly identified reasons. The previous work has also
described the awareness of the challenges of this space, but points
to this option as the most manageable and workable solution for IPv6
transition space.
5. ARIN Draft Policy 2011-5
5.1. History
The following is a brief history of ARIN Draft Policy 2011-5.
o ARIN-prop-127 - Shared Transition Space for IPv4 Address Extension
[ARIN-prop-127]
* Proposal Originator: Chris Donley, CableLabs
* Date: 20 January 2011
* AC Shepherds: Stacy Hughes and Chris Morrow
Barber, et al. Expires January 5, 2012 [Page 15]
Internet-Draft ARIN Shared Transition Space July 2011
o ARIN-2011-5 - Formal introduction on PPML on 3 February 2011
[ARIN-2011-5]
o ARIN XXVII - 12 April 2011 - San Juan, Puerto Rico - Participant
Vote on 2011-5 [ARIN27.2011-5]
* Total Participants: 116
* In favor: 30
* Opposed: 15
o AC moves to Last Call - 13 April 2011 [ARIN-2011-5-AC]
o Last Call - 18 April through 2 May 2011 [ARIN-2011-5-LC]
o AC recommended adoption - 24 May 2011 [ARIN-2011-5-Rec]
* The motion carried via roll call with 7 in favor, 5 against,
and 3 abstentions
5.2. Policy Text
Draft Policy ARIN-2011-5
Shared Transition Space for IPv4 Address Extension
Date: 20 January 2011
Policy statement:
Updates 4.10 of the NRPM:
A second contiguous /10 IPv4 block will be reserved to facilitate
IPv4 address extension. This block will not be allocated or assigned
to any single organization, but is to be shared by Service Providers
for internal use for IPv4 address extension deployments until
connected networks fully support IPv6. Examples of such needs
include: IPv4 addresses between home gateways and NAT444 translators.
Rationale:
The Internet community is rapidly consuming the remaining supply of
unallocated IPv4 addresses. During the transition period to IPv6, it
is imperative that Service Providers maintain IPv4 service for
devices and networks that are currently incapable of upgrading to
IPv6. Consumers must be able to reach the largely IPv4 Internet
after exhaustion. Without a means to share addresses, people or
Barber, et al. Expires January 5, 2012 [Page 16]
Internet-Draft ARIN Shared Transition Space July 2011
organizations who gain Internet access for the first time, or those
who switch providers, or move to another area, will be unable to
reach the IPv4 Internet.
Further, many CPE router devices used to provide residential or
small-medium business services have been optimized for IPv4
operation, and typically require replacement in order to fully
support the transition to IPv6 (either natively or via one of many
transition technologies). In addition, various consumer devices
including IP-enabled televisions, gaming consoles, medical and family
monitoring devices, etc. are IPv4-only, and cannot be upgraded.
While these will eventually be replaced with dual-stack or IPv6
capable devices, this transition will take many years. As these are
typically consumer-owned devices, service providers do not have
control over the speed of their replacement cycle. However,
consumers have an expectation that they will continue to receive IPv4
service, and that such devices will continue to have IPv4 Internet
connectivity after the IPv4 pool is exhausted, even if the customer
contracts for new service with a new provider.
Until such customers replace their Home Gateways and all IPv4-only
devices with IPv6-capable devices, Service Providers will be required
to continue to offer IPv4 services through the use of an IPv4 address
sharing technology such as NAT444. A recent study showed that there
is no part of RFC1918 space which would not overlap with some IPv4
gateways, and therefore to prevent address conflicts, new address
space is needed.
Service providers are currently presented with three options for
obtaining sufficient IPv4 address space for NAT444/IPv4 extension
deployments: (1) Request allocations under the NRPM; (2) share
address space with other providers (this proposal); or (3) use
address space allocated to another entity (i.e. 'squat'). Of the
three options, option 2 (this proposal) is preferable, as it will
minimize the number of addresses used for IPv4 extension deployments
while preserving the authority of IANA and RIRs.
Timetable for implementation: immediately
6. Acknowledgements
The authors would like to thank Jeffrey Finkelstein for his
significant contributions.
The authors would also like to thank Chris Donley, Wes George, and
Richard Von Scherr for their review, comments, and support.
Barber, et al. Expires January 5, 2012 [Page 17]
Internet-Draft ARIN Shared Transition Space July 2011
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
This memo makes reference to a number of deployment scenarios that
have unique security considerations, and the reader is advised to
investigate these independently.
While this memo does not introduce any specific technical issues that
may be subject to detailed security considerations, it does
reccommend the reservation of a new IPv4 address space that might
have unique properties when deployed. As such, all implementors of
this Shared Transition Space are encouraged to consider carefully the
best practices associated with the use of this space, including
considerations relating to filtering, routing, etc.
9. Informative References
[APNIC-final-slash8]
APNIC, "APNIC IPv4 Address Pool Reaches Final /8",
Apr 2011,
<http://www.apnic.net/publications/news/2011/final-8>.
[ARIN-2011-5]
ARIN, "Draft Policy ARIN-2011-5: Shared Transition Space
for IPv4 Address Extension", 2011,
<https://www.arin.net/policy/proposals/2011_5.html>.
[ARIN-2011-5-AC]
ARIN, "Minutes: Meeting of the ARIN Advisory Committee -
13 Apr 2011", Apr 2011,
<https://www.arin.net/about_us/ac/ac2011_0413.html>.
[ARIN-2011-5-LC]
ARIN, "ARIN-2011-5: Shared Transition Space for IPv4
Address Extension - Last Call", Apr 2011, <http://
lists.arin.net/pipermail/arin-ppml/2011-April/
020808.html>.
[ARIN-2011-5-Rec]
ARIN, "Advisory Council Meeting Results - May 2011",
May 2011, <http://lists.arin.net/pipermail/arin-ppml/
2011-May/022331.html>.
Barber, et al. Expires January 5, 2012 [Page 18]
Internet-Draft ARIN Shared Transition Space July 2011
[ARIN-NRPM-8.3]
ARIN, "ARIN Number Resource Policy Manual, section 8.3 -
Transfers to Specified Recipients", Jul 2011,
<https://www.arin.net/policy/nrpm.html#eight3>.
[ARIN-prop-127]
Donley, C., "ARIN-prop-127: Shared Transition Space for
IPv4 Address Extension", Jan 2011, <http://lists.arin.net/
pipermail/arin-ppml/2011-January/019278.html>.
[ARIN27.2011-5]
ARIN, "ARIN XXVII Meeting - Participant Vote on 2011-5",
Apr 2011, <https://www.arin.net/participate/meetings/
reports/ARIN_XXVII/ppm2_transcript.html#anchor_6>.
[GIH-When]
"When?", Sep 2010,
<http://www.potaroo.net/ispcol/2010-10/when.html>.
[I-D.azinger-additional-private-ipv4-space-issues]
Azinger, M. and L. Vegoda, "Additional Private IPv4 Space
Issues",
draft-azinger-additional-private-ipv4-space-issues-04
(work in progress), April 2010.
[I-D.donley-nat444-impacts]
Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
and V. Ganti, "Assessing the Impact of NAT444 on Network
Applications", draft-donley-nat444-impacts-01 (work in
progress), October 2010.
[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),
January 2005.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 2011.
[I-D.shirasaki-isp-shared-addr]
Barber, et al. Expires January 5, 2012 [Page 19]
Internet-Draft ARIN Shared Transition Space July 2011
Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "ISP Shared Address",
draft-shirasaki-isp-shared-addr-05 (work in progress),
September 2010.
[I-D.shirasaki-nat444-isp-shared-addr]
Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444 addressing models",
draft-shirasaki-nat444-isp-shared-addr-05 (work in
progress), January 2011.
[I-D.weil-opsawg-provider-address-space]
Weil, J., Kuarsingh, V., and C. Donley, "IANA Reserved
IPv4 Prefix for IPv6 Transition",
draft-weil-opsawg-provider-address-space-02 (work in
progress), September 2010.
[I-D.weil-shared-transition-space-request]
Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA Reserved IPv4 Prefix for Shared
Transition Space",
draft-weil-shared-transition-space-request-01 (work in
progress), November 2010.
[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.
[IAB-response]
IAB, "IAB responds to ARIN request for guidance regarding
Draft Policy ARIN-2011-5", Jun 2011, <http://www.iab.org/
2011/06/
iab-responds-to-arin-request-for-guidance-regarding-draft-
policy-arin-2011-5/>.
[NRO-IANA-exhaust]
NRO, "Free Pool of IPv4 Address Space Depleted", Feb 2011,
<http://www.nro.net/news/ipv4-free-pool-depleted>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
Barber, et al. Expires January 5, 2012 [Page 20]
Internet-Draft ARIN Shared Transition Space July 2011
[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.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
[v6ops-msg06187]
WIDE, "Re: [v6ops] IETF 79 Meeting minutes - Draft",
Nov 2010, <http://www.ietf.org/mail-archive/web/v6ops/
current/msg06187.html>.
Authors' Addresses
Stan Barber
Cox Communications
Email: stan.barber2@cox.com
Owen Delong
Hurricane Electric
Email: owen@delong.com
Chris Grundemann
CableLabs
Email: c.grundemann@cablelabs.com
Victor Kuarsingh
Rogers Communications
Email: victor.kuarsingh@rci.rogers.com
Benson Schliesser
Cisco Systems
Email: bschlies@cisco.com
Barber, et al. Expires January 5, 2012 [Page 21]