Policy Proposal 2007-16: IPv4 Soft Landing [Archived]

Status: Withdrawn by author

Tracking Information

Discussion Tracking

Mailing List:

Formal introduction on PPML on 28 August 2007

Staff assessment - 14 October 2007
AC to revise with author - 23 October 2007
Withdrawn by author - 22 February 2008Public Policy Mailing List

ARIN Public Policy Meeting:

ARIN XX

ARIN Advisory Council:

AC Shepherds:
Bill Darte and Paul Andersen

19 July 2007
23 August 2007
20 September 2007
18 October 2007
15 November 2007
20 December 2007
17 January 2008
21 February 2008

ARIN Board of Trustees:

Revisions:

Implementation:

Author(s):

David Conrad

Policy Proposal 2007-16
IPv4 Soft Landing

Author: David Conrad

Proposal type: New

Policy term: Permanent

Policy statement:

This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of:

— begin modification — 4.2.4.1

In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation “phases” that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent.

When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc.

The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses.

IPv4 Allocation Phases

The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section.

Phase: 0 Threshold: Greater than 40 /8s Requirements:

Requesters must:

* Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation.

* For downstream customers:

• Demonstrate an immediate requirement of 25% utilization

• Demonstrate a one year requirement of 50% utilization

Phase: 1 Threshold: 40 /8s Requirements:

Requesters must:

* Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN.

* Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation.

* For downstream customers:

• Demonstrate an immediate requirement of 25% utilization

• Demonstrate a one year requirement of 50% utilization

* Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used.

Phase: 2 Threshold: 25 /8s Requirements:

Requesters must:

* Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN.

* Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation.

* For downstream customers:

• Demonstrate an immediate requirement of 50% utilization

• Demonstrate a one year requirement of 75% utilization

* Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used.

* Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate.

* Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request.

Phase: 3 Threshold: 10 /8s Requirements:

Requesters must:

* Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN.

* Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation.

* For downstream customers:

• Demonstrate an immediate requirement of 75% utilization

• Demonstrate a one year requirement of 90% utilization

* Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing.

* Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing.

* Demonstrate availability of production IPv6 infrastructure and connectivity services.

Notes:

* Phase 0 reflects current allocation requirements.

* Phases 1 through 3 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 at the time of the request.

— end modification —

Rationale:

The rationale for this proposal is threefold:

* to prolong the availability of IPv4 addresses for 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 over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. 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 documentation or reuse of public 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 conformance to the specified 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 offering an opportunity to break 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. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement.

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. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration.

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 the RIR’s 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.

Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a “reasonable” amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase.

Timetable for implementation:

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