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

  • To: "Hannigan, Martin" <marty at akamai dot com>
  • Subject: Re: [sig-policy] prop-086: Global policy for IPv4 allocations by the IANA post exhaustion
  • From: Owen DeLong <owen at delong dot com>
  • Date: Wed, 25 Aug 2010 18:40:13 -0700
  • 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: <C89B3BB3.DF36%marty at akamai 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>
  • References: <C89B3BB3.DF36%marty@akamai.com>
    • On Aug 25, 2010, at 6:29 PM, Hannigan, Martin wrote:
      
      > 
      > 
      > 
      > 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.
      > 
      I think that the way the policy is currently defined, set-asides would
      prevent some RIRs from exhausting during any meaningful  portion of
      this policy unless the set-aside doesn't actually function as a set-aside.
      
      Since so long as an RIR has a single /24 under current policies and
      potentially as little as a single /28 under proposed policy(ies),
      they are not considered to be at exhaustion, I don't see how
      you can expect a reasonable and functioning set-aside to do
      anything less than prevent qualification under "exhaustion".
      
      I think for this policy to be functional, set-asides up to a certain size
      must be exempted from the exhaustion criteria.
      > 
      > 
      >>>>> 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.
      > 
      Transfers of space received under this policy are banned by
      this policy. Transfers in general are not banned. That ban
      could be lifted by subsequent global policy action, but, absent
      an additional  global policy change, yes, this proposal would
      ban such transfers.
      
      Owen