Draft Policy ARIN-2011-5: Shared Transition Space for IPv4 Address Extension [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
**Status: Abandoned
Note from the Board: “Noting the success working with the IETF on this matter, the ARIN Board recommends that the ARIN AC consider abandoning Draft Policy 2011-5 as duplicative.”
The AC provided the following in regards to ARIN-2011-5: “After much debate, the proposal in question was sent forward to the Board for implementation, this resulted in conversations with the IETF and the publishing of RFC 6598, which requested the space be allocated via IANA. This has been done, and therefore policy action by ARIN is no longer necessary. The board referred the policy back to the AC, and the AC hereby abandons the policy to successfully conclude its policy life-cycle. The AC thanks the community for its support in this endeavor.”
NetRange 100.64.0.0 - 100.127.255.255
CIDR 100.64.0.0/10
Name SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED
Network record availabe at: http://whois.arin.net/rest/net/NET-100-64-0-0-1
See also: http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
**
Tracking Information
Discussion Tracking
Mailing List:
Formal introduction on PPML on 3 February 2011
Origin - ARIN-prop-127
Draft Policy - 3 February 2011 (with staff assessment)
Additional staff assessment - 14 February 2011
Last Call - 18 April through 2 May 2011
AC reccomended adoption - 24 May 2011
Remanded to the AC by the Board - 13 March 2012
Abandoned by the AC - 30 April 2012
ARIN Public Policy Meeting:
ARIN XXIX
ARIN Advisory Council:
AC Shepherds:
Stacy Hughes and Chris Morrow
- 28 Jan 2011
- 17 Feb 2011
- 17 March 2011
- 13 April 2011
- 19 May 2011
- 25 April 2012
ARIN Board of Trustees:
Revisions:
Implementation:
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 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
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.