Search RPD Archives
[AfriNIC-rpd] Fwd: [ppml] Policy Proposal: IPv4 Soft Landing
Adiel A. Akplogan
adiel at afrinic.net
Sun May 13 17:21:08 UTC 2007
Below is a policy proposed on ARIN PPML which I think
require our attention.... specially for those who where
at AfrINIC-6 and attend the IPv4 exhaustion BOF (the
report of the BoF will be send soon).
- a.
>Delivered-To: ppml at lists.arin.net
>Date: Fri, 11 May 2007 04:14:31 -0400
>From: Member Services <info at arin.net>
>To: ppml at arin.net
>Subject: [ppml] Policy Proposal: IPv4 Soft Landing
>
>
>ARIN received the following policy 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 AC will review this proposal and may decide to:
>
>1. Accept the proposal as a formal policy proposal as it is presented;
>
>2. Work with the author to:
> a) clarify the language or intent of the proposal;
> b) divide the proposal into two (2) or more proposals; or
> c) combine the proposal with other proposals; or,
>
>3. Not accept the proposal as a formal policy proposal.
>
>The AC will review this proposal at their next regularly scheduled
>meeting. If their meeting is within ten days, then the review may be
>extended to the subsequent meeting. If the AC accepts the proposal, then
>it will be posted as a formal policy proposal to PPML and it will be
>presented at a Public Policy Meeting. If the AC does not accept the
>proposal, then the AC will explain that decision; and at that time 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 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/index.html
>
>Regards,
>
>Member Services
>American Registry for Internet Numbers (ARIN)
>
>
>## * ##
>
>
>Policy Proposal Name: IPv4 Soft Landing
>
>Author: David Conrad
>
>Proposal Version: 1.0
>
>Submission Date: 2007-05-02
>
>Proposal type: New
>
>Policy term: Permanent
>
>Policy statement:
>
>30 days after specified thresholds in the amount of address space
>remaining in the IANA IPv4 free pool are crossed, the requirements
>necessary for ISPs to obtain additional IPv4 address space are made
>more stringent and requesters must demonstrate efforts both to utilize
>scarce IPv4 address space more efficiently, set up IPv6 infrastructure
>services, and eventually offer production IPv6 connectivity.
>
>The proposed thresholds and the requirements to justify an allocation
>of new IPv4 address space from ARIN are:
>
>Phase 0
>Threshold N/A
>Requirements
>
>Requesters must demonstrate:
>
>* No requirements to document IPv6 infrastructure services or IPv6
> connectivity services.
>
>* 80% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Downstream immediate requirement: 25%
>
>* Downstream requirement after 1 year: 50%
>
>Phase 1
>Threshold 40 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented plans for availability of production IPv6 infrastructure
> services within 6 months
>
>* Documented plans for availability of production IPv6 service within
> 1 year
>
>* 85% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Downstream immediate requirement: 33%
>
>* Downstream requirement after 1 year: 66%
>
>Phase 2
>Threshold 30 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented availability of production IPv6 infrastructure services
>
>* Documented plans for availability of production IPv6 service within
> 6 months
>
>* 90% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Current 3rd-party auditors report of IPv4 address space utilization
>
>* Downstream immediate requirement: 50%
>
>* Downstream requirement after 1 year: 75%
>
>Phase 3
>Threshold 20 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented availability of production IPv6 infrastructure services
>
>* Documented availability of production IPv6 connectivity service
>
>* A migration plan for all internal infrastructure to either IPv6 or
> private addressing
>
>* 92% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Current 3rd-party auditors report of IPv4 address space utilization
>
>* Downstream immediate requirement: 60%
>
>* Downstream requirement after 1 year: 80%
>
>Phase 4
>Threshold 15 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented availability of production IPv6 connectivity services
>
>* Initiation of migration of internal infrastructure to either IPv6 or
> private addressing
>
>* 94% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Current 3rd-party auditors report of IPv4 address space utilization
>
>* Downstream immediate requirement: 70%
>
>* Downstream requirement after 1 year: 85%
>
>Internal infrastructure can be used in justification for IPv4 address
>space only in special circumstances
>
>Phase 5
>Threshold 10 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented availability of production IPv6 connectivity services
>
>* Recycling of 25% of (non-private) IPv4 address space formerly used
> for internal infrastructure
>
>* 96% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Current 3rd-party auditors report of IPv4 address space utilization
>
>* Downstream immediate requirement: 75%
>
>* Downstream requirement after 1 year: 90%
>
>Internal infrastructure can no longer be used in justification for
>IPv4 address space
>
>Phase 6
>Threshold 5 /8s
>Requirements:
>
>Requesters must demonstrate:
>
>* Documented availability of production IPv6 connectivity services
>
>* Recycling of 75% of IPv4 address space formerly used for internal
> infrastructure
>
>* 98% utilization in all customer assignments as reflected in
> SWIP/rwhois reassignments
>
>* Current 3rd-party auditors report of IPv4 address space utilization
>
>* Downstream immediate requirement: 80%
>
>* Downstream requirement after 1 year: 95%
>
>Internal infrastructure can no longer be used in justification for
>IPv4 address space
>
>Note that for the purposes of this proposal, the following definitions
>apply:
>
>* Downstream: entities to which the ISP may assign address space.
>
>* IPv6 infrastructure services: services such as DNS, WWW, FTP,
> etc. accessible via IPv6.
>
>* IPv6 connectivity: IP connectivity service provided over IPv6
> transport, either natively or via an IPv6 tunnel.
>
>* Internal infrastructure: routers, switches, servers, etc., that are
> not normally visible or directly accessed by the ISP customers.
>
>Phase 0 reflects current allocation requirements. Subsequent phases
>of this policy 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.
>
>Rationale:
>
>The rationale for this proposal is threefold:
>
>* to prolong the availability of IPv4 addresses to 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 making the allocation of IPv4 both more difficult and
>contingent on the ISP demonstrating both support for IPv6 as well as
>more efficient use of the IPv4 address space they administer. 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 reuse of
>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 utilization of customer
>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 breaking 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.
>
>The requirement to provide a current third-party auditors report of
>utilization is intended to deter fraudulent justification data used to
>support IPv4 allocations in the absence of actual need.
>
>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. This policy anticipates ARIN staff will make use of
>auditor reports to verify appropriate use of IPv4 addresses in
>internal infrastructure.
>
>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 their 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.
>
>Timetable for implementation:
>
>Immediately upon approval of this policy by the ARIN Board of Trustees.
>
>
>
>_______________________________________________
>This message sent to you through the ARIN Public Policy Mailing List
>(PPML at arin.net).
>Manage your mailing list subscription at:
>http://lists.arin.net/mailman/listinfo/ppml
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Free Edition.
>Version: 7.5.467 / Virus Database: 269.6.6/794 - Release Date:
>08/05/2007 14:23
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.467 / Virus Database: 269.7.0/803 - Release Date: 13/05/2007 12:17
More information about the RPD
mailing list