________________________________________________________________________ prop-056-v001: IPv4 soft landing ________________________________________________________________________ Author: David Conrad Version: 1 Date: 24 January 2008 1. Introduction ---------------- This is a proposal to tighten the criteria for receiving subsequent IPv4 allocations from APNIC. 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. 2. Summary of current problem ------------------------------ Under current policies, the administrative cost of obtaining IPv4 addresses will not track the scarcity of that resource. As IPv4 becomes increasingly scarce, the lack of an increased administrative (or financial) cost in obtaining addresses will likely result in increased pressure on the resource that could have negative implications (e.g., "land rush" behavior). At the same time, IPv6 has not gained significant traction in deployment. Since the IETF community has determined that the best course moving forward to avoid constraining Internet growth is to deploy IPv6, efforts should be undertaken to encourage IPv6 deployment. 3. Situation in other RIRs ---------------------------- This proposal has been submitted in the ARIN region and will be submitted in the other regions in the near future. 4. Details of the proposal ---------------------------- 4.1 Overview of proposal It is proposed that APNIC institute 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 an ISP requests additional IPv4 address space from APNIC: 1. ISPs must meet the utilization requirements of the IPv4 address allocation phase APNIC was in when the request was submitted. 2. Depending on the IPv4 address allocation phase APNIC was in when the request was submitted, the requestor may need to meet additional requirements. Additional requirements include 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. 3. APNIC can begin the process of approving a request for additional addresses after all requirements are met and the requester's prior utilization is verified to meet the requirements specified in the IPv4 address allocation phase in which the request was received. 4.2 IPv4 allocation phases The proposal creates a set of IPv4 address allocation "phases" that are triggered when number of remaining /8s in the IANA free pool reach certain thresholds. The four phases require the requester to demonstrate increasingly efficient utilisation of previously allocated IPv4 address space, including all space reassigned to their customers. The allocation phases will move through phase 0 to 3 based on the number of /8s that are at or below the threshold specified for each phase. Phase 0 ------- Threshold: Greater than 40 /8s Requirements: Requesters must: 1. Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. 2. 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: 1. Provide a response to a survey (individual responses to be held in confidence by APNIC staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by APNIC. 2. Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. 3. For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization 4. 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: 1. Provide a response to a survey (individual responses to be held in confidence by APNIC staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by APNIC. 2. Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. 3. For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization 4. Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. 5. 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. 6. 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: 1. Provide a response to a survey (individual responses to be held in confidence by APNIC staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by APNIC. 2. Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. 3. For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization 4. Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. 5. 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. 6. Demonstrate availability of production IPv6 infrastructure and connectivity services. 4.3 Timetable for implementation This would be implemented immediately upon the endorsement of the APNIC Executive Council. 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 are 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. - 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. 5. Advantages and disadvantages of the proposal ------------------------------------------------- Advantages: This proposal: - Provides for a smoother transition away from IPv4 towards IPv6; - Encourages the deployment of IPv6; - Increases the efficiency of utilization of the IPv4 address space; - Reduces the likelihood of a "run" on the remaining free pool of IPv4 address space; - Encourages migration of internal infrastructure to either IPv6 or private (e.g., RFC 1918) thereby reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. Disadvantages: This proposal: - May make it difficult for some ISPs to obtain IPv4 addresses earlier than would be the case if there was no change in IPv4 allocation policy. 6. Effect on APNIC members ---------------------------- This proposal should result in encouraging APNIC members to migrate to IPv6 if they require additional IPv4 addresses. 7. Effect on NIRs ------------------- See "Effect on APNIC members". Appendix: rationale for this proposal ------------------------------------- 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. APNIC 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 APNIC 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 APNIC 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.