ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF considerations)

[ARIN]

ARIN-prop-154 Shared Space for IPv4 Address Extension (w/IETF 
considerations)

ARIN received the following policy proposal and is posting it to the
Public Policy Mailing List (PPML) in accordance with the Policy
Development Process.

The ARIN Advisory Council (AC) will review the proposal at their next
regularly scheduled meeting (if the period before the next regularly
scheduled meeting is less than 10 days, then the period may be extended
to the subsequent regularly scheduled meeting). The AC will decide how
to utilize the proposal and announce the decision to the PPML.

The AC invites everyone to comment on the proposal on the PPML,
particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

The ARIN Policy Development Process can be found at:
https://www.arin.net/policy/pdp.html

Mailing list subscription information can be found
at: https://www.arin.net/mailing_lists/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##

Policy Proposal Name: Shared Space for IPv4 Address Extension (w/IETF 
considerations)

Proposal Originator: William Herrin

Proposal Version: 1

Date: 6/30/2011

Proposal type: new

Policy term:

This policy shall remain in effect until publication of an RFC that
implements the expectations for the /10 address block this policy
describes. Upon RFC publication, ARIN shall cede the /10 to IANA
for use with the RFC and then strike this policy from the NRPM.

  Policy statement:

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.

ARIN shall advise the IETF of the /10 reserved and shall request that
the IETF determine issues associated with using the /10 as described,
set appropriate constraints on the use of the block and publish an RFC
documenting the block's recommended use. ARIN shall make manpower and
other resources available to the IETF as necessary to facilitate such
activity.

ARIN constituents are strongly discouraged from using the reserved /10
until an RFC is published as there are expected to be technical
issues where software makes assumptions about NAT based on the IP
address assigned to the machine.

Rationale:

This policy proposal is substantively identical to ARIN draft policy 2011-5
which achieved consensus and was recommended to the Board of Trustees for
adoption in May 2011. The Internet Architecture Board was asked to comment
on the draft policy and expressed concern that the IETF may be the
appropriate vehicle for assigning addresses to a new use case rather
than to a registrant.

In order to act on such a proposal, the IETF will require addresses from
an RIR. An insufficient supply of such addresses remains available to
them from IANA. As the ARIN community wishes the IETF to create a
shared ISP space, it must enact policy which provides the necessary
addresses.

As modified from proposal 2011-5, this proposal allocates the needed
block of addresses and then asks the IETF to develop the appropriate
technical rules of use.

Because the world marches on and Internet Service Providers have an
immediate and pressing need to begin their NAT444 and similar deployments,
ARIN region users are discouraged but not prohibited from using the
reserved /10 while the IETF works through the process.

Note that this policy anticipates successful completion of the IETF process
and publication of an RFC. It intentionally includes no provision for 
revoking
the reservation should discussion within the IETF stall. Any such 
revocation
will require discussion within the ARIN policy community of the IETF's
findings followed by new policy proposals.

The first paragraph of this proposal was copied verbatim from draft 2011-5
in the hopes of maintaining the consensus that draft achieved.  The
remainder of this rationale is also copied verbatim from draft 2011-5:

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: immediate