Re: [sig-policy] prop-050: IPv4 address transfers

  • To: sig-policy at lists dot apnic dot net
  • Subject: Re: [sig-policy] prop-050: IPv4 address transfers
  • From: Scott Leibrand <sleibrand at internap dot com>
  • Date: Wed, 01 Aug 2007 22:34:07 -0700
  • Delivered-to: sig-policy at mailman dot apnic dot net
  • List-archive: <>
  • List-help: <>
  • List-id: APNIC SIG on resource management policy <>
  • List-post: <>
  • List-subscribe: <>, <>
  • List-unsubscribe: <>, <>
  • User-agent: Thunderbird (Windows/20070509)
    • Geoff et. al.,
      Having seen a link to prop-050 on the ARIN public policy mailing list, and considering the implications of several forms of markets in IPv4 addresses, I thought I'd provide some perspective and input on the policy from a perspective somewhere on the ARIN side of global.
      The premise of this policy proposal, and a fairly reasonable one, is that transfers of IPv4 addresses will occur regardless, and that it is best for APNIC to keep track of such transfers, place some limits on them, and constrain the parties to the transfer to continue abiding by APNIC policies. It also provides a mechanism by which organizations can continue to acquire IPv4 addresses after APNIC's free pool is exhausted.
      However, this policy proposal abandons at least two important goals of RIR stewardship: aggregation and hierarchical assignment. By allowing the complete deaggregation (down to /24) of any APNIC allocation or direct assignment, and registering the transfer of each individual /24 to a different organization, this policy would leave the world no choice but to accept /24 announcements of APNIC-managed space or withdraw from the DFZ.
      A much better course, in my opinion, would be to allow the complete and total transfer only of entire allocations or direct assignments. This would preserve aggregation, and continue to give operators across the globe the option of filtering prefixes longer than APNIC's minimum allocation size without completely destroying reachability.
      Now it is obvious to me that as we exhaust the IPv4 free pool, some deaggregation will be necessary to allow us to increase the number of networks using IPv4 space. That deaggregation, however, need not be complete: it can be hierarchical. For example, consider a large IP space holder with a /8 who begins transitioning their existing customers to IPv6 and reduces or eliminates their need for IPv4 space. Say this organization then wanted to transfer some of that freed space to another APNIC account holder. One way to do that would be as Geoff proposes. If they do not wish to transfer the entire /8, however, a better way (for the Internet as a whole) would be to lease (re-allocate) portions of the IP space to recipient organizations. The /8 could still be announced, and the source organization could provide some form of connectivity (probably a tunnel) to the recipient organization. This would ensure full reachability for the recipient organization, while preserving the rest of the Internet's ability to filter out more-specific deaggregates outside their sphere of usefulness (possibly with as-pathlimit). Even though such filtering is not necessary or common now, we must preserve our ability to filter, as there is a very real possibility that the growth of the IPv4 routing table after IPv4 free pool depletion will accelerate beyond the ability of affordable routers to keep up.
      If, at some future date APNIC wants to further liberalize the IPv4 transfer policy to allow transfer of smaller blocks (perhaps down to /20 or the then-current minimum allocation size), that is always possible. However, if prop-050 is adopted as written, APNIC (and the world) will lose the ability to reverse the deaggregation, and we'll be stuck with a "swamp" much bigger than that created by the allocation of Class C's.
      I hope the members of the APNIC policy-making community will consider the goals of aggregation and hierarchical assignment when considering prop-050, and will only adopt it as policy if it is modified to preserve our future ability to effectively deal with deaggregates.