[ppml] Policy Proposal 2007-16 - Staff Assessment

[Member Services]

Policy Proposal 2007-16
IPv4 Soft Landing

ARIN Staff Assessment

The assessment of this proposal includes comments from ARIN staff and
the ARIN General Counsel. It contains analysis of procedural, legal, and
resource concerns regarding the implementation of this policy proposal
as it is currently stated. Any changes to the language of the proposal
may necessitate further analysis by staff and Counsel.

I. Proposal

Policy Proposal is available as Annex A below and at:
http://www.arin.net/policy/proposals/2007_16.html

II. Understanding of the proposal

The proposal "aims to provide for a defined transition away from IPv4
address space towards IPv6 address space by imposing increasingly
stricter requirements for new address allocations."

III. Comments

   A. ARIN Staff

General Comments –

1.  The policy seems to apply only to the general IPv4 ISP policy. Does
this policy also apply to the other ISP additional policies like
multiple discreet networks (NRPM 4.5) and cable (NRPM 4.2.6)?

2.  Does this policy supersede the ISP additional request policy and any
other ISP additional request policies? If so, this should be clearly stated.

3.  In the policy statement, the author discusses utilization rates and
refers to swip and rwhois.  These terms should be removed because they
are not necessarily relevant to all customers (those that assign smaller
than /28s or orgs that manage dynamic address pools, Voip, etc…).

4.  In the policy statement, the author refers to specific fields in the
template.  This should be removed since template fields will change over
time.

5.  A general question of fairness comes up when you consider that ISP’s
will now be faced with much more difficulty in obtaining IP address
space from ARIN while end users will feel no effect or change at all.

Phase 0: No comments.

Phase 1: No comments

Phase 2:  No comments

Phase 3: No comments

6. Author indicated placement in the NRPM. All the text from "begin
modification" to "end modification" would be placed in Section 4.2.4.1.
Subsections would be created. The title of the section would be changed
to "Utilization Requirements". We would strike the "80%" reference in
4.2.3.4.1.

   B. ARIN General Counsel

   Counsel does not see any legal implications with this policy.

Resource Impact – Moderate
The resource impact of implementing this policy is moderate. Barring any
unforeseen resource requirements, this policy could be implemented
within 3-6 months from the date of the ratification of the policy by the
ARIN Board of Trustees It will require the following:

- Significant staff training
- Template changes
- New Registration Services tools
- Guidelines changes
- Significant increase in processing time

Respectfully submitted,

Member Services
American Registry for Internet Numbers (ARIN)


##*##


Annex A

Policy statement

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.