[ppml] Policy Proposal 2007-16: IPv4 Soft Landing - Revise

[Member Services]

Policy Proposal 2007-16
IPv4 Soft Landing

The ARIN Advisory Council (AC), acting under the provisions of the ARIN
Internet Resource Policy Evaluation Process (IRPEP), determined that
while there is not community consensus in favor of the proposal there is
consensus that the proposal should be revised and discussed further. The
AC made this determination at their meeting at the conclusion of the
ARIN Public Policy meeting on 18 October 2007. The Chair of the AC
reported the results of the AC meeting during the Members Meeting. The
AC Chair's report can be found at:
http://www.arin.net/meetings/minutes/ARIN_XX/mem.html

The AC will work with the author of the proposal to revise the text and
return the proposal to the PPML for further discussion.

The policy proposal text is provided below and is also available at:
http://www.arin.net/policy/proposals/2007_16.html

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

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


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.