One document matched: draft-bdgks-arin-shared-transition-space-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-bdgks-arin-shared-transition-space-00"
ipr="trust200902" submissionType="independent">
<front>
<title abbrev="ARIN Shared Transition Space">ARIN Draft Policy 2011-5:
Shared Transition Space</title>
<author fullname="Stan Barber" initials="S." surname="Barber">
<organization>Cox Communications</organization>
<address>
<email>stan.barber2@cox.com</email>
</address>
</author>
<author fullname="Owen Delong" initials="O." surname="Delong">
<organization>Hurricane Electric</organization>
<address>
<email>owen@delong.com</email>
</address>
</author>
<author fullname="Chris Grundemann" initials="C." surname="Grundemann">
<organization>CableLabs</organization>
<address>
<email>c.grundemann@cablelabs.com</email>
</address>
</author>
<author fullname="Victor Kuarsingh" initials="V." surname="Kuarsingh">
<organization>Rogers Communications</organization>
<address>
<email>victor.kuarsingh@rci.rogers.com</email>
</address>
</author>
<author fullname="Benson Schliesser" initials="B." surname="Schliesser">
<organization>Cisco Systems</organization>
<address>
<email>bschlies@cisco.com</email>
</address>
</author>
<date year="2011" />
<area>Operations</area>
<workgroup></workgroup>
<keyword></keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>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.</t>
<t>In order to facilitate these operators' need for near-term IPv4
connectivity, <xref
target="I-D.weil-shared-transition-space-request"></xref> 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 <xref target="RFC1918"></xref> address
space. By using the Shared Transition Space operators may deploy CGN
<xref target="I-D.ietf-behave-lsn-requirements"></xref> internal
networks, extranet <xref target="RFC4364"></xref> communities, and/or
SP-local services without consuming globally unique addresses.</t>
<t>However, given the Feb 2011 depletion of the IANA Free Pool inventory
<xref target="NRO-IANA-exhaust"></xref> it is not currently possible for
the IANA to reserve an IPv4 /10 prefix as recommended in <xref
target="I-D.weil-shared-transition-space-request"></xref>. Thus the ARIN
community has proposed in Draft Policy <xref
target="ARIN-2011-5"></xref> the reservation of a Shared Transition
Space from the ARIN inventory of unallocated IPv4 numbers. After much
discussion by the ARIN community, <xref target="ARIN-2011-5"></xref> was
recommended by the ARIN Advisory Council for approval by the ARIN Board
of Trustees.</t>
<t>Essentially similar to <xref
target="I-D.weil-shared-transition-space-request"></xref>, Draft Policy
<xref target="ARIN-2011-5"></xref> is currently pending ARIN Board
approval. The ARIN Board has asked for IAB clarification with regard to
responsibilities outlined in <xref target="RFC2860"></xref> and has
received a response <xref target="IAB-response"></xref> 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.</t>
</section>
<section anchor="Background" title="Background">
<section title="Applicability">
<t>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.</t>
<section title="CGN">
<t>A primary use-case for the Shared Transition Space will be
deployment in CGN internal networks, as described in <xref
target="I-D.ietf-behave-lsn-requirements"></xref>. 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.</t>
<t>In one CGN deployment scenario sometimes referred to as NAT444
<xref target="I-D.shirasaki-nat444-isp-shared-addr"></xref>, the CGN
internal network is numbered with IPv4 addresses that are not
globally routed while the end-sites are numbered with Private <xref
target="RFC1918"></xref> 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.</t>
</section>
<section title="Extranet">
<t>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.</t>
</section>
<section title="SP Services">
<t>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.</t>
<section title="Private Intranet">
<t>Many service providers have deployed a hierarchical network
using Private <xref target="RFC1918"></xref> 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-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.</t>
</section>
</section>
</section>
<section title="Alternatives">
<t>A number of possible alternatives to Shared Transition Space have
been proposed and/or discussed by the Internet community. See, for
instance, <xref
target="I-D.azinger-additional-private-ipv4-space-issues"></xref> for
a discussion of alternatives and potential issues. This section
outlines these possible alternatives and briefly discusses their
applicability.</t>
<section title="Globally Unique">
<t>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.</t>
<t>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.</t>
</section>
<section title="Private">
<t>In each of the use-cases for Shared Transition Space, it may be
possible to instead use Private <xref target="RFC1918"></xref>
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.</t>
<t>A study of DNS traffic <xref target="v6ops-msg06187"></xref> has
shown that effectively all of the existing Private <xref
target="RFC1918"></xref> 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.</t>
<t>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.</t>
<t>Also, the use of Private <xref target="RFC1918"></xref> 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.</t>
<t>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 <xref
target="RFC1918"></xref> address space was used on both WAN and LAN
interfaces.</t>
</section>
<section title="Class E">
<t>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 <xref
target="I-D.fuller-240space"></xref> and <xref
target="I-D.wilson-class-e"></xref>. 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.</t>
</section>
<section title="Prefix Squatting">
<t>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.</t>
<t>In this scenario, the allocation may not be routed globally by
the legitimate address holder, making it attractive for such
purposes. 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Regional Re-use of Allocated Prefix">
<t>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).</t>
<t>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".</t>
</section>
<section title="Consortium">
<t>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.</t>
</section>
</section>
</section>
<section anchor="Analysis" title="Analysis of Benefits">
<section title="Continued Operation Post-exhaustion">
<t>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.</t>
<t>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.</t>
</section>
<section title="Delayed Need for CGN Deployment">
<t>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.</t>
</section>
<section title="Recovery of Existing Addresses">
<t>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.</t>
<section title="Re-deployment Where Needed">
<t>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.</t>
</section>
<section title="Return or Transfer">
<t>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).</t>
<t>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 <xref target="ARIN-NRPM-8.3"></xref>.</t>
</section>
</section>
<section title="Impact on Allocations / RIR Inventory">
<t>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.</t>
<t>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.</t>
</section>
<section title="Benefit of Standardization">
<t>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.</t>
<t>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 <xref
target="RFC1918"></xref> 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.</t>
</section>
<section title="IPv6 Deployments">
<t>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.</t>
<t>Endless cycles can be avoided where operators squat, free up space
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.</t>
</section>
</section>
<section title="Analysis of Detractors' Arguments">
<section title="It Breaks">
<section title="NAT is Bad">
<t>NAT is understood to be less then optimal <xref
target="RFC6269"></xref>, especially when implemented as CGN <xref
target="I-D.donley-nat444-impacts"></xref>. 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.</t>
<t>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.</t>
</section>
<section title="Breaks Bad Host Assumptions">
<t>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.</t>
</section>
<section title="Potential Misuse as Private Space">
<t>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.</t>
<t>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.</t>
<t>As an example, the use of DiffServ <xref target="RFC2475"></xref>
can result in punitive 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.</t>
</section>
</section>
<section title="It's Not Needed">
<section title="Nobody Will Use It">
<t>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.</t>
<t>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".</t>
</section>
<section title="ISPs Are Not Actually Growing">
<t>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.</t>
<t>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.</t>
</section>
<section title="RIR IPv4 Inventory is Not Actually Exhausted">
<t>With the IANA inventory essentially exhausted <xref
target="NRO-IANA-exhaust"></xref> it is only a matter of time before
each of the RIRs are unable to satisfy requests for IPv4 addresses.
<xref target="GIH-When"></xref> In fact, the APNIC has already
allocated all but their final /8 of inventory <xref
target="APNIC-final-slash8"></xref> 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.</t>
</section>
<section title="ISP IPv4 Inventory is Not Actually Exhausted">
<t>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.</t>
</section>
</section>
<section title="Address Inventory">
<section title="Shared Transition Space Uses Up Address Inventory">
<t>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.</t>
</section>
<section title="/10 is not Enough">
<t>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.</t>
</section>
<section title="It Won't Delay RIR Exhaustion">
<t>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.</t>
</section>
</section>
<section title="IPv6 Arguments">
<section title="Use IPv6 Instead">
<t>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.</t>
<t>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.</t>
<t>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).</t>
<t>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.</t>
</section>
<section title="Delay of IPv6 Deployment">
<t>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.</t>
<t>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.</t>
<t>BENSON: Note: "cite arkkoís drafts about operating in IPv6-only
mode for evidence that this is not actually workable yet"</t>
</section>
</section>
<section title="History">
<t>The proposal for additional Private space in order to survive IPv6
transition dates back to <xref target="I-D.hain-1918bis"></xref> in
April 2004, and more recently as Shared Transition Space <xref
target="I-D.shirasaki-isp-shared-addr"></xref> 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.</t>
<t>This effort was followed up by <xref
target="I-D.weil-opsawg-provider-address-space"></xref> in July 2010
which was re-worked in November 2010 as <xref
target="I-D.weil-shared-transition-space-request"></xref>. 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 <xref
target="I-D.donley-nat444-impacts"></xref>.</t>
<t>Most recently, following exhaution of the IANA's /8 pool <xref
target="NRO-IANA-exhaust"></xref>, 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 <xref target="ARIN-2011-5"></xref>.</t>
<t>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.</t>
</section>
</section>
<section anchor="Policy" title="ARIN Draft Policy 2011-5">
<section title="History">
<t>The following is a brief history of ARIN Draft Policy 2011-5.</t>
<t><list style="symbols">
<t>ARIN-prop-127 - Shared Transition Space for IPv4 Address
Extension <xref target="ARIN-prop-127"></xref> <list
style="symbols">
<t>Proposal Originator: Chris Donley, CableLabs</t>
<t>Date: 20 January 2011</t>
<t>AC Shepherds: Stacy Hughes and Chris Morrow</t>
</list></t>
<t>ARIN-2011-5 - Formal introduction on PPML on 3 February 2011
<xref target="ARIN-2011-5"></xref></t>
<t>ARIN XXVII - 12 April 2011 - San Juan, Puerto Rico -
Participant Vote on 2011-5 <xref target="ARIN27.2011-5"></xref>
<list style="symbols">
<t>Total Participants: 116</t>
<t>In favor: 30</t>
<t>Opposed: 15</t>
</list></t>
<t>AC moves to Last Call - 13 April 2011 <xref
target="ARIN-2011-5-AC"></xref></t>
<t>Last Call - 18 April through 2 May 2011 <xref
target="ARIN-2011-5-LC"></xref></t>
<t>AC recommended adoption - 24 May 2011 <xref
target="ARIN-2011-5-Rec"></xref> <list style="symbols">
<t>The motion carried via roll call with 7 in favor, 5
against, and 3 abstentions</t>
</list></t>
</list></t>
</section>
<section title="Policy Text">
<t>Draft Policy ARIN-2011-5</t>
<t>Shared Transition Space for IPv4 Address Extension</t>
<t>Date: 20 January 2011</t>
<t>Policy statement:</t>
<t>Updates 4.10 of the NRPM:</t>
<t>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.</t>
<t>Rationale:</t>
<t>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
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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>Timetable for implementation: immediately</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Jeffrey Finkelstein for his
significant contributions.</t>
<t>The authors would also like to thank Chris Donley, Wes George, and
Richard Von Scherr for their review, comments, and support.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This memo makes reference to a number of deployment scenarios that
have unique security considerations, and the reader is advised to
investigate these independently.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4364.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2860.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-behave-lsn-requirements-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-donley-nat444-impacts-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-weil-shared-transition-space-request-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-weil-opsawg-provider-address-space-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-isp-shared-addr-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-shirasaki-nat444-isp-shared-addr-05.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-azinger-additional-private-ipv4-space-issues-04.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-fuller-240space-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wilson-class-e-02.xml"?>
<reference anchor="ARIN-prop-127"
target="http://lists.arin.net/pipermail/arin-ppml/2011-January/019278.html">
<front>
<title>ARIN-prop-127: Shared Transition Space for IPv4 Address
Extension</title>
<author fullname="Chris Donley" initials="C." surname="Donley">
<organization>CableLabs</organization>
</author>
<date day="20" month="Jan" year="2011" />
</front>
</reference>
<reference anchor="ARIN27.2011-5"
target="https://www.arin.net/participate/meetings/reports/ARIN_XXVII/ppm2_transcript.html#anchor_6">
<front>
<title>ARIN XXVII Meeting - Participant Vote on 2011-5</title>
<author>
<organization>ARIN</organization>
</author>
<date day="12" month="Apr" year="2011" />
</front>
</reference>
<reference anchor="ARIN-2011-5"
target="https://www.arin.net/policy/proposals/2011_5.html">
<front>
<title>Draft Policy ARIN-2011-5: Shared Transition Space for IPv4
Address Extension</title>
<author>
<organization>ARIN</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ARIN-2011-5-LC"
target="http://lists.arin.net/pipermail/arin-ppml/2011-April/020808.html">
<front>
<title>ARIN-2011-5: Shared Transition Space for IPv4 Address
Extension - Last Call</title>
<author>
<organization>ARIN</organization>
</author>
<date day="18" month="Apr" year="2011" />
</front>
</reference>
<reference anchor="ARIN-2011-5-Rec"
target="http://lists.arin.net/pipermail/arin-ppml/2011-May/022331.html">
<front>
<title>Advisory Council Meeting Results - May 2011</title>
<author>
<organization>ARIN</organization>
</author>
<date day="24" month="May" year="2011" />
</front>
</reference>
<reference anchor="ARIN-2011-5-AC"
target="https://www.arin.net/about_us/ac/ac2011_0413.html">
<front>
<title>Minutes: Meeting of the ARIN Advisory Committee - 13 Apr
2011</title>
<author>
<organization>ARIN</organization>
</author>
<date month="Apr" year="2011" />
</front>
</reference>
<reference anchor="ARIN-NRPM-8.3"
target="https://www.arin.net/policy/nrpm.html#eight3">
<front>
<title>ARIN Number Resource Policy Manual, section 8.3 - Transfers
to Specified Recipients</title>
<author>
<organization>ARIN</organization>
</author>
<date day="1" month="Jul" year="2011" />
</front>
</reference>
<reference anchor="IAB-response"
target="http://www.iab.org/2011/06/iab-responds-to-arin-request-for-guidance-regarding-draft-policy-arin-2011-5/">
<front>
<title>IAB responds to ARIN request for guidance regarding Draft
Policy ARIN-2011-5</title>
<author>
<organization>IAB</organization>
</author>
<date day="27" month="Jun" year="2011" />
</front>
</reference>
<reference anchor="NRO-IANA-exhaust"
target="http://www.nro.net/news/ipv4-free-pool-depleted">
<front>
<title>Free Pool of IPv4 Address Space Depleted</title>
<author>
<organization>NRO</organization>
</author>
<date day="3" month="Feb" year="2011" />
</front>
</reference>
<reference anchor="v6ops-msg06187"
target="http://www.ietf.org/mail-archive/web/v6ops/current/msg06187.html">
<front>
<title>Re: [v6ops] IETF 79 Meeting minutes - Draft</title>
<author fullname="Akira Kato">
<organization>WIDE</organization>
</author>
<date day="16" month="Nov" year="2010" />
</front>
</reference>
<reference anchor="GIH-When"
target="http://www.potaroo.net/ispcol/2010-10/when.html">
<front>
<title>When?</title>
<author fullname="Geoff Huston">
<organization></organization>
</author>
<date month="Sep" year="2010" />
</front>
</reference>
<reference anchor="APNIC-final-slash8"
target="http://www.apnic.net/publications/news/2011/final-8">
<front>
<title>APNIC IPv4 Address Pool Reaches Final /8</title>
<author>
<organization>APNIC</organization>
</author>
<date day="15" month="Apr" year="2011" />
</front>
</reference>
<reference anchor="I-D.hain-1918bis">
<front>
<title>Expanded Address Allocation for Private Internets</title>
<author fullname="Tony Hain" initials="T" surname="Hain">
<organization></organization>
</author>
<date month="January" year="2005" />
</front>
<seriesInfo name="Internet-Draft" value="draft-hain-1918bis-01" />
<format target="http://www.ietf.org/internet-drafts/draft-hain-1918bis-01.txt"
type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:57:27 |