[arin-ppml] Draft Policy 2011-1 - Inter-RIR Transfers - Shepherd's Inquiry

[Scott Leibrand]

On Jun 21, 2011, at 9:25 AM, "Joe St Sauver" <joe at oregon.uoregon.edu> wrote:

> Regarding "Draft Policy 2011-1: Inter-RIR Transfers"
>
> and the proviso that:
>
>   "Address resources may be transferred.... in or out of the ARIN region
>   to those who demonstrate need and plan to deploy them for a networking
>   purpose within 3 months. Such transfers will take place between RIRs who
>   share compatible, needs-based policies on behalf of entities agreeing to
>   the transfer and which otherwise meet both RIR's policies. Transferred
>   resources will become part of the resource holdings of the recipient RIR
>   unless otherwise agreed by both RIRs."
>
> I am opposed to inter-RIR transfer policies, including this one. Let me
> mention just a few reasons why.
>
>
> I. Resource Firebreak Issues.
>
> In thinking about this and similar policies, consider where addresses would
> likely come from and where addresses would probably go given current
> circumstances (and assuming that all RIRs agreed to participate in the
> policy).
>
> RIRs with remaining IPv4 address resources ("supplier RIRs")
>
> -- AFRINIC
> -- LACNIC
>
> RIRs with a likely immediate-term demand for additional IPv4 addresses
> ("consumer RIRs"):
>
> -- APNIC
> -- RIPE NCC
> -- ARIN
>
> Thus the flow of address space would thus likely be *from* the developing
> nations of the southern hemisphere (except Australasia) *to* the developed
> nations of the northern hemisphere.
>
> Countries in the southern hemisphere (which have historically been handicapped
> by the high price of connectivity) have just recently begun to see improved
> fiber access and a resulting drop in market prices. With their large areas
> and large populations, they will likely have a substantial demand for number
> resources in most forseeable medium-term scenarios. If the critical resources
> they will eventually require will have been "exported" piece meal to Asia,
> Europe, or North America, our southern-hemisphere neighbors will find it hard
> to realize their full potential as Internet citizens.
>
> The existing region-based RIR system thus serves as a "firebreak" of sorts,
> protecting each RIR's resources from being treated as one common comingled
> pool that can be (effectively) drawn down in its entirity by any region
> willing to do so.
>
> I don't want to see that "firebreak," small though it may be, breached. I
> think it serves an important purpose when it comes to protecting resources
> in developing regions such as AFRINIC and LACNIC.


Adopting an inter-RIR transfer policy in the ARIN region would not
allow transfers from (or to) AfriNIC or LACNIC unless they passed
similar policy. As you mention, that looks unlikely. AfriNIC seems to
support a policy to prevent usage of their resources out of region.
LACNIC is discussing a similar proposal, but it's much further from
consensus.

If we pass an inter-RIR transfer policy that allows it, the most
likely effect would be transfers from ARIN to APNIC.

-Scott


>
>
> II. Additional Resources Should Not Be Allowed to Potential Feed Regions
> with Unchecked Abuse Issues.
>
> Some have also argued that RIRs vary substantially when it comes to
> their interest in policing number resource misue and abuse. An interesting
> exercise when it comes to measuring one dimension of that issue is to go to
> Spamhaus and see how many SBL listings are associated with each of
> the RIRs. At the time I checked just now:
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=afrinic
>   4 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=apnic
>   18 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=lacnic
>   28 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=arin
>   250 listings
>
> -- http://www.spamhaus.org/sbl/listings.lasso?isp=ripe
>   I quote, "has far too many records to list. This ISP has an extremely
>   serious spam problem."
>
> Although I've looked at a LOT of SBL listings over the years, this is
> absolutely the first and ONLY time I've EVER seen a "too many to list"
> response from the Spamhaus by-ISP SBL listings.
>
> Thus, I would also oppose inter-RIR transfers if those transfers might
> potentially serve to enable further messaging abuse by supplying "raw
> materials" to areas where number resources are apparently experiencing
> rampant abuse. (If all or many of those issues have been taken care of,
> and Spamhaus is just running behind on removals, my apologies)
>
>
> III. Tracking and Documenting Address Usage Becomes Harder.
>
> Currently it is possible to track address usage because we know (at
> a /8 granularity) which regions have a given block. If we suddenly
> begin allowing /16s here and /19s there to be carved off and transfer
> out or transfered in, our ability to track usage by region will quickly
> be lost (or become a tiresome and highly granular bookkeeping exercise).
>
> Moreover, IP whois currently relies on that assignment by /8s to
> direct IP whois queries to an appropriate RIR whois server. If inter
> region transfers are allowed, whois queries will now potentially need
> to support still more redirection, and protection against whois
> redirection loops will likely even become necessary. And do we want
> the RIRs to need to update their whois to deal with (redirect) thousands
> or tens of thousands of tiny blocks that may be transfered out of region?
> Jeez, again, what a bookkeeping mess!
>
>
> For all these and other reasons, I oppose inter-RIR transfers, including
> the current proposed policy.
>
> Thanks for considering these comments,
>
> Regards,
>
> Joe
>
> Disclaimer: all opinions expressed are strictly my own and do not
> necessarily represent the opinion of any other organization or entity.
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.