[ppml] Policy Proposal: IPv4 Soft Landing (version 2.0)
David Conrad
drc at virtualized.org
Tue Aug 14 18:08:26 EDT 2007
Hi,
As you'll see, this pass attempts to simplify the proposal somewhat:
- fewer phases
- remove the requirement for auditing/auditors
I tried to address the comments people provided to me on the last go
around, but I'm sure I missed a few for which I apologize.
Regards,
-drc
On Aug 14, 2007, at 3:00 PM, Member Services wrote:
> 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