Policy Proposal: IPv4 Soft Landing

Member Services info at arin.net
Fri May 18 10:17:18 EDT 2007


On 17 May 2007 the ARIN Advisory Council (AC) reviewed "IPv4 Soft
Landing" and did not accept it at this time as a formal policy proposal.
The AC will work with the author prior to taking further action.

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)



Member Services wrote:
> 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
> 





More information about the Info mailing list