[sig-policy] Proposal [prop-052]: Cooperative distribution of the end of

  • To: sig-policy at apnic dot net
  • Subject: [sig-policy] Proposal [prop-052]: Cooperative distribution of the end of the IPv4 free pool
  • From: Toshiyuki Hosaka <hosaka at nic dot ad dot jp>
  • Date: Wed, 28 Nov 2007 13:49:56 +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 (Windows/20071031)
      The proposal "Cooperative distribution of the end of the IPv4 free pool"
      has been sent to the Policy SIG for review. It will be presented at the
      Policy SIG at APNIC 25 in Taipei, Taiwan, 25-29 February 2008. You are
      invited to review and comment on the proposal on the mailing list before
      the meeting.
      The proposal's history can be found at:
      prop-052-v001: Cooperative distribution of the end of the IPv4 free pool
      Author:     Tony Hain
                   alh-ietf at tndh dot net
      Version:    1
      Date:       30 October 2007
      1.  Introduction
      This policy will establish a process for RIR-to-RIR redistribution of
      the tail-end of the IPv4 pool, taking effect after the IANA Reserve is
      exhausted. Each redistribution Allocation will be triggered by the
      recipient RIR depleting its reserve to a 30 day supply, and will result
      in up to a 3 month supply being transferred from the RIR with the
      longest remaining time before it exhausts its own pool.
      2.  Summary of current problem
      This policy will establish a mechanism for the Allocation of IPv4
      address blocks between RIR's, but will not go into effect until the IANA
      pool has been depleted.
      It is really bizarre to watch the maneuvering as the global RIR
      community grapples with 'fairness' of distributing the last few IANA
      Reserve /8 blocks. On one level this just appears to be petty sibling
      rivalry, as people are bickering over who gets the last cookie and
      whimpering about 'fairness'. At the same time, each RIR is chartered to
      look after the interests of its membership so it is to be expected that
      they will each want to get as much as possible to meet the needs of
      their respective membership.
      Existing practice requires RIRs to acquire blocks from IANA, which
      leads to the current round of nonsense about optimal distribution of
      the remaining pool based on elaborate mathematical models.
      This globally submitted policy proposal attempts to resolve the issue by
      shifting to an RIR-to-RIR Allocation model after the IANA pool is
      depleted. This policy would effectively result in each RIR becoming a
      virtual LIR member of all of the other RIR's for the sole purpose of
      managing the tail-end of the IPv4 pool.
      3.   Situation in other RIRs
      This proposal has been submitted to all RIRs.
      4.   Details of the proposal
      At the point when any given RIR is within 30 days of depleting its
      remaining IPv4 pool, a survey will be taken of the other 4 to determine
      the remaining time before each of them exhausts their pool (including
      both member use and recent redistribution allocations to other RIRs).
      The one with the longest window before exhausting its pool will be
      designated as the source RIR. The recipient RIR will follow procedures
      for an LIR in the source RIR region to request a block that is expected
      to be sufficient for up to 3 months, but is no larger than 1/8th of the
      source RIR's remaining pool. At the point where no RIR can supply a
      block that is less than 1/8th of their remaining pool that will sustain
      the recipient RIR for 30 days, the recipient RIR will collect its
      requests each week, and forward those individual requests to the source
      RIR designated that week.
      Timetable for implementation:     Before 1/1/2009
      5.   Advantages and disadvantages of the proposal
      Advantages: Allows the RIRs to focus on management of the space rather than
      squabble over who gets the last block. Distributes the workload to the
      requesting regions rather than the delegating region.
      Disadvantages: Precludes one RIR from possessing the 'last' block,
      potentially reducing its ability to gain new members from other regions.
      6.   Effect on APNIC members
      If APNIC was not the last RIR with free space, this proposal would allow for
      operations to continue with only a minor modification in process or delay
      until all the RIRs were out.
      If APNIC was the last RIR with free space, this proposal would have APNIC
      members competing with the rest of the world over the last few addresses.
      7.   Effect on NIRs
      See 6.
      APNIC Policy SIG Chairs
      Toshiyuki Hosaka
      Randy Bush
      Jian Zhang