[ppml] Policy Proposal: IPv4 Soft Landing

[Member Services]

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The AC will review this proposal and may decide to:

1. Accept the proposal as a formal policy proposal as it is presented;

2. Work with the author to:
       a) clarify the language or intent of the proposal;
       b) divide the proposal into two (2) or more proposals; or
       c) combine the proposal with other proposals; or,

3. Not accept the proposal as a formal policy proposal.

The AC will review this proposal at their next regularly scheduled
meeting. If their meeting is within ten days, then the review may be
extended to the subsequent meeting. If the AC accepts the proposal, then
it will be posted as a formal policy proposal to PPML and it will be
presented at a Public Policy Meeting. If the AC does not accept the
proposal, then the AC will explain that decision; and at that time the
author may elect to use the petition process to advance their proposal.
If the author elects not to petition or the petition fails, then the
proposal will be closed.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/index.html

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: IPv4 Soft Landing

Author: David Conrad

Proposal Version: 1.0

Submission Date: 2007-05-02

Proposal type: New

Policy term: Permanent

Policy statement:

30 days after specified thresholds in the amount of address space
remaining in the IANA IPv4 free pool are crossed, the requirements
necessary for ISPs to obtain additional IPv4 address space are made
more stringent and requesters must demonstrate efforts both to utilize
scarce IPv4 address space more efficiently, set up IPv6 infrastructure
services, and eventually offer production IPv6 connectivity.

The proposed thresholds and the requirements to justify an allocation
of new IPv4 address space from ARIN are:

Phase  	    	0
Threshold    	N/A
Requirements

Requesters must demonstrate:

* No requirements to document IPv6 infrastructure services or IPv6
   connectivity services.

* 80% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Downstream immediate requirement: 25%

* Downstream requirement after 1 year: 50%

Phase	     1
Threshold    40 /8s
Requirements:

Requesters must demonstrate:

* Documented plans for availability of production IPv6 infrastructure
   services within 6 months

* Documented plans for availability of production IPv6 service within
   1 year

* 85% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Downstream immediate requirement: 33%

* Downstream requirement after 1 year: 66%

Phase	     2
Threshold    30 /8s
Requirements:

Requesters must demonstrate:

* Documented availability of production IPv6 infrastructure services

* Documented plans for availability of production IPv6 service within
   6 months

* 90% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Current 3rd-party auditors report of IPv4 address space utilization

* Downstream immediate requirement: 50%

* Downstream requirement after 1 year: 75%

Phase	     3
Threshold    20 /8s
Requirements:

Requesters must demonstrate:

* Documented availability of production IPv6 infrastructure services

* Documented availability of production IPv6 connectivity service

* A migration plan for all internal infrastructure to either IPv6 or
   private addressing

* 92% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Current 3rd-party auditors report of IPv4 address space utilization

* Downstream immediate requirement: 60%

* Downstream requirement after 1 year: 80%

Phase	     4
Threshold    15 /8s
Requirements:

Requesters must demonstrate:

* Documented availability of production IPv6 connectivity services

* Initiation of migration of internal infrastructure to either IPv6 or
   private addressing

* 94% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Current 3rd-party auditors report of IPv4 address space utilization

* Downstream immediate requirement: 70%

* Downstream requirement after 1 year: 85%

Internal infrastructure can be used in justification for IPv4 address
space only in special circumstances

Phase	     5
Threshold    10 /8s
Requirements:

Requesters must demonstrate:

* Documented availability of production IPv6 connectivity services

* Recycling of 25% of (non-private) IPv4 address space formerly used
   for internal infrastructure

* 96% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Current 3rd-party auditors report of IPv4 address space utilization

* Downstream immediate requirement: 75%

* Downstream requirement after 1 year: 90%

Internal infrastructure can no longer be used in justification for
IPv4 address space

Phase	     6
Threshold    5 /8s
Requirements:

Requesters must demonstrate:

* Documented availability of production IPv6 connectivity services

* Recycling of 75% of IPv4 address space formerly used for internal
   infrastructure

* 98% utilization in all customer assignments as reflected in
   SWIP/rwhois reassignments

* Current 3rd-party auditors report of IPv4 address space utilization

* Downstream immediate requirement: 80%

* Downstream requirement after 1 year: 95%

Internal infrastructure can no longer be used in justification for
IPv4 address space

Note that for the purposes of this proposal, the following definitions
apply:

* Downstream: entities to which the ISP may assign address space.

* IPv6 infrastructure services: services such as DNS, WWW, FTP,
   etc. accessible via IPv6.

* IPv6 connectivity: IP connectivity service provided over IPv6
   transport, either natively or via an IPv6 tunnel.

* Internal infrastructure: routers, switches, servers, etc., that are
   not normally visible or directly accessed by the ISP customers.

Phase 0 reflects current allocation requirements.  Subsequent phases
of this policy are to be implemented 30 days after IANA allocates
address space from the IPv4 free pool that reduces that free pool to a
number of /8s that are at or below the threshold specified.  If
multiple thresholds should be crossed within a 30 day period, the
requirements from the last threshold crossed will be applied to
requesters for additional address space.

Rationale:

The rationale for this proposal is threefold:

* to prolong the availability of IPv4 addresses to requesters who can
   provide sufficient justification;

* to encourage the deployment of IPv6 as an alternative to IPv4 by
   making the requirements to justify IPv4 allocations increasingly
   stringent over time;

* to promote the more efficient use of increasingly scarce IPv4
   resources.

As the lack of significant deployment of IPv6 can attest, the cost of
deploying IPv6 currently outweighs the benefits that protocol would
appear to provide.  This proposal aims to encourage the deployment of
IPv6 by making the allocation of IPv4 both more difficult and
contingent on the ISP demonstrating both support for IPv6 as well as
more efficient use of the IPv4 address space they administer.  The
goal of these measures is to rebalance the IPv6 deployment
cost/benefit ratio thereby encouraging greater uptake of IPv6 before
the IPv4 free pool is exhausted.

The "IPv4 Soft Landing" policy aims to provide for a smoother
transition away from IPv4 towards IPv6 by imposing increasingly strict
requirements for new address allocations as the amount of address
space available in the IANA unallocated IPv4 address pool decreases.
These increased requirements include both more stringent reassignment
and utilization percentages as well as requiring documented IPv6
infrastructure services and connectivity provision and the reuse of
IPv4 address space used for internal infrastructure.

The increased stringency in the allocation requirements is intended
both to increase the efficiency of utilization of the IPv4 address
space and to reduce the likelihood of a "run" on the remaining free
pool of IPv4 address space.  ARIN staff would be expected to use the
same mechanisms in use today to verify utilization of customer
requirements.

The requirements for demonstration of IPv6 infrastructure services and
connectivity are intended to motivate ISPs to provide those services
before the only address space they can offer their customers is IPv6,
thereby breaking the "chicken-and-egg" problem limiting significant
IPv6 deployment.  Verification of these requirements can be done by
ARIN staff by using IPv6 transport to connect to published services of
the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping
to identified addresses internal to the ISP.

The requirement to provide a current third-party auditors report of
utilization is intended to deter fraudulent justification data used to
support IPv4 allocations in the absence of actual need.

The requirements to migrate internal infrastructure to either IPv6 or
private (e.g., RFC 1918) addressing are intended to improve the
efficiency of utilization of IPv4 address space, reserving the scarce
IPv4 resources for purposes for which IPv6 or private addresses are
not suitable.  These requirements acknowledge that pragmatically, the
use of IPv4 is absolutely essential only for servers in client-server
architectures, machines engaged in peer-to-peer applications, and
entry points for NAT/ALG devices.  As such, use of IPv4 for purposes
such as router interface numbering, client-only devices, and devices
which should not be available from external networks should be
discouraged.  This policy anticipates ARIN staff will make use of
auditor reports to verify appropriate use of IPv4 addresses in
internal infrastructure.

The time for transition between phases of this policy are not fixed,
rather they depend on the rate of consumption of IPv4 address space
from the IANA free pool. Current RIR operational procedure is to
request 2 /8s from the IANA when their current pool of free IPv4
address space is depleted.  This procedure should ensure transitions
between phases will have some lead-time, so organizations can prepare
for the next phase of IPv4 address allocation.

Timetable for implementation:

Immediately upon approval of this policy by the ARIN Board of Trustees.