[sig-policy] prop-056-v001: IPv4 soft landing

  • To: sig-policy at apnic dot net
  • Subject: [sig-policy] prop-056-v001: IPv4 soft landing
  • From: Toshiyuki Hosaka <hosaka at nic dot ad dot jp>
  • Date: Thu, 24 Jan 2008 15:59:28 +0900
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
  • List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
  • List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
  • List-post: <mailto:sig-policy@lists.apnic.net>
  • List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
  • List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
  • Organization: Japan Network Information Center (JPNIC)
  • User-agent: Thunderbird 2.0.0.9 (Windows/20071031)
    • 
      The proposal 'IPv4 soft landing' has been sent to the Policy SIG for
      review. It will be presented during the Policy SIG sessions at APNIC 25
      in Taipei, Taiwan, 25-29 February 2008.
      
      The proposal's history can be found at:
      
            http://www.apnic.net/policy/proposals/prop-056-v001.html
      
      We invite you to review and comment on the proposal on the mailing list
      before the meeting.
      
      The comment period on the mailing list before an APNIC meeting is an
      important part of the policy development process. We encourage you to:
      
            - Ask the proposer questions if anything in the proposal is
              unclear
            - Point out advantages and disadvantages you see in the proposal
            - State whether you support or oppose the proposal
      
      Mailing list discussions will be taken into account when the proposal
      is discussed at the upcoming APNIC meeting. So please make sure you have
      your say.
      
      APNIC Policy SIG Chairs
      Toshiyuki Hosaka
      Randy Bush
      Jian Zhang
      
      ________________________________________________________________________
      
      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.
      
      (end of document)