[ppml] 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 ARIN-PPML
mailing list