Re: [sig-policy] prop-086: Global policy for IPv4 allocations by the IAN

  • To: Owen DeLong <owen at delong dot com>, Louis Lee <louie at louie dot net>
  • Subject: Re: [sig-policy] prop-086: Global policy for IPv4 allocations by the IANA post exhaustion
  • From: "Hannigan, Martin" <marty at akamai dot com>
  • Date: Wed, 25 Aug 2010 21:29:23 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: Philip Smith <pfs at cisco dot com>, Policy SIG <sig-policy at apnic dot net>
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • In-reply-to: <C31CE56D-49B6-41F9-8AC8-E6796ADBBAC7 at delong dot com>
  • 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>
  • Reply-to: "Hannigan, Martin" <marty@akamai.com>
  • Thread-index: ActEvWDuirT6HiFwStyu990mQJaRNQAALv9U
  • Thread-topic: [sig-policy] prop-086: Global policy for IPv4 allocations by the IANA post exhaustion
  • User-agent: Microsoft-Entourage/13.6.0.100712
    • 
      
      On 8/25/10 7:32 PM, "Owen DeLong" <owen at delong dot com> wrote:
      
      >> 
      >>>>      The Reclamation Pool will be divided on CIDR boundaries
      >>>>      and distributed evenly to all eligible RIRs. Any
      >>> 
      >>> So each time when, say ARIN, pushes the button for the policy,
      >>> and gets a /19, the other 4 RIRs will each get a /19 as
      >>> well? Even if they don't need it? This seems an unusual method
      >>> of address space distribution - maybe we should have thought
      >>> about this at the start of IPv4 20+ years ago. ;-)
      >>> 
      >>> It also means that the RIRs who have actually implemented
      >>> runout policies (eg APNIC) for the final /8 will start
      >>> stockpiling extra address space. Remind me what the incentive
      >>> was for returning unused address space to IANA? This seems like
      >>> a contradiction.
      >> 
      >> Ya know, that's not all that different from dividing the last
      >> five IANA /8s evenly.  And that's triggered when only 1 RIR
      >> has demonstrated need while the other 4 have address space. :)
      >> 
      >> In your example, only when an RIR is considered to have exhausted
      >> its address space will it be considered to be eligible for the
      >> /19.  So if an RIR doesn't need the space, they won't get it.
      >> 
      > I think the real scenario will be more along the lines of:
      > 
      > IANA runs out, last 5 /8s go to RIRs.
      > RIR A runs out of their remaining space.
      > RIR A pushes the button (as you called it above)
      > RIR A receives full reclamation pool
      > RIR B runs out, pushes button
      > RIR C runs out, pushes button
      > Some amount of space is returned to IANA
      > Returned space is divided evenly between B and C
      > RIRs A, B, and C run out and push button.
      > RIR D runs out and pushes button.
      > RIR E runs out and pushes button.
      > The world transitions to IPv6.
      > IPv4 space starts flying in to IANA and is distributed evenly
      > amongst the 5 RIRs.
      > 
      > The exact specifics may vary and the timeline of the above is
      > left to the imagination of the reader. However, the point is that
      > I think there will only be one or two rounds of returned space
      > effected by this policy and the first round will be winner take
      > all for the first RIR to exhaust their address space.
      > 
      > The way the policy is currently worded, any RIR which has
      > a set-aside policy or a rationing policy for the last /8 will
      > be disadvantaged compared to RIRs which have no such
      > limitations.
      
      
      I don't think that this is the case at all. It will incentivize our
      communities to establish responsibly sized carve outs and to use them. There
      should be no carve out so large that it should prevent an RIR from
      exhausting at some point.
      
      
      
      >>>> 5.6 No Transfer Rights
      >>>> 
      >>>>      Address space assigned from the Reclamation Pool may be
      >>>>      transferred if there is either an ICANN Board ratified
      >>>>      global policy or globally coordinated RIR policy
      >>>>      specifically written to deal with transfers whether
      >>>>      inter-RIR or from one entity to another. Transfers must
      >>>>      meet the requirements of such a policy. In the absence
      >>>>      of such a policy, no transfers of any kind related to
      >>>>      address space allocated or assigned from the reclamation
      >>>>      pool is allowed.
      >>> 
      >>> The reason for banning transfers is...?
      > 
      > In the case of an RIR with a transfer policy that does not require
      > a needs-based justification, this becomes a giant sucking hole
      > through which all addresses can drain:
      > 
      > Party A has need, gets space from RIR.
      > Party A sells space to party B which has no need, just money.
      > Party A again has need, gets more space from RIR.
      > 
      > Lather, rinse, repeat.
      
      But more importantly, transfers were not banned.
      
      >Address space assigned from the Reclamation Pool may be
      >transferred if there is either an ICANN Board ratified
      >global policy or globally coordinated RIR policy
      >specifically written to deal with transfers whether
      >inter-RIR or from one entity to another.
      
      
      Best,
      
      -M<