[ppml] Policy Proposal: IPv4 Soft Landing
Member Services
info at arin.net
Tue Jul 24 14:56:12 EDT 2007
On 19 July 2007, the ARIN Advisory Council (AC) postponed their decision
regarding the proposal titled "IPv4 Soft Landing" in order to work with
the author. The AC will work with the author to clarify, combine or
divide the proposal. At the next regularly scheduled AC meeting, the AC
will make their decision to accept or not accept the proposal as a
formal policy proposal.
The proposal text is below and can be found at:
http://www.arin.net/policy/proposals/submission_archive.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 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
>
More information about the ARIN-PPML
mailing list