[ppml] Policy Proposal: IPv4 Soft Landing (version 2.0)
Azinger, Marla
marla.azinger at frontiercorp.com
Wed Aug 22 17:12:02 EDT 2007
Here are my two cents:
-I don't support this.
-Let it run out. Write a policy figuring out what ARIN does once contiguous requests cant be met.
-If we do this and other RIR's don't we are just holding ourselves back from more allocations from IANA while others continue to receive more.
-This is similar to another proposal. We should combine Decreasing Exponential Rationing of IPv4 IP Addresses with this one if we want to look at an approach like this.
Cheers!
Marla Azinger
Frontier Communications
-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
Member Services
Sent: Tuesday, August 14, 2007 3:01 PM
To: ppml at arin.net
Subject: [ppml] Policy Proposal: IPv4 Soft Landing (version 2.0)
This proposal is in the Initial Review stage of the ARIN Internet
Resource Policy Evaluation Process. On 17 May 2007 the ARIN Advisory
Council (AC) reviewed 'IPv4 Soft Landing (version 1.0)' and decided to
postpone their decision regarding the proposal in order to work with the
author. The author submitted the following revised version of the
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 ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:
1. Accept the proposal as a formal policy proposal as written. If the
AC accepts the proposal, it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting.
2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.
3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision. If a proposal is not accepted, then
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 AC shepherd for this proposal is Bill Darte. The AC invites everyone
to comment on this 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.
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/
Regards,
Member Services
American Registry for Internet Numbers (ARIN)
## * ##
Policy Proposal Name: IPv4 Soft Landing
Author: David Conrad
Proposal Version: 2.0
Submission Date: 2007-08-14
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.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.
More information about the ARIN-PPML
mailing list