Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Draft inbound policy

Andrew Alston Andrew.Alston at
Mon Jun 20 21:19:21 UTC 2016

Hi JP,

See answers in line.

  1) How would the specifics of this policy work?
    a) Are there conditionals on the acceptance? For instance, should AfriNIC or any recipient operators not be able to make full use of a resource (for whichever reason), would a “reversal” be possible?

- A reversal would not be possible - in theory though since the space would then be under AFRINIC, AFRINIC could reclaim the space and put it in the free pool.  The legal side of this may be complex though because the transfer would have been paid for by the recipient (will get to this in a moment).  So we'd need some legal guidance as to what would happen if transferred in space wasn't used according to the plan (I'm sure we can make it so that AFRINIC can reclaim it, but it may require some wording in the MSA or another document)

    b) Does the original owning entity of a resource have any lasting ownership/hold on it beyond the point of transferrence?

- No, once the original entity tells the originating RIR to transfer it, and the transfer happens, they lose any hold on it (unless they illegally hijack it of course, but that can happen anyway)

  2) What would a transfer at this level involve? Do you envision (some) uses of it taking place as part of a commercial arrangement (eg. 
purchasing a remote entity and then transferring their allocation(s) across), or purely a transfer agreement between RIRs?

I definitely see this being a commercial transaction.  The secondary market is very much a commercial market place.  Effectively if you were getting space from a person in another region, expect to be paying them a *LOT* of money to perform the transfer.  This is the reason that people don't want an outbound transfer, they are scared people will "sell" their space to the highest bidder outside.  (Though I actually did a lot of work on the commercial realities here, and anyone who had an active ISP who sold space would be insane, because the revenue generated from having the addresses almost certainly far outweighs what you could "sell" them for)

Either way though, this is inbound, so it’s a case of, if there are people willing to pay the prices on the secondary market elsewhere in the world, let them get their space and pay what they are willing to pay - willing buyer (in Africa) from willing seller (elsewhere in the world)

I do by the way think that an addition to the policy proposal that stopped people onward selling space they bought within a specific time frame may be worthwhile, so that when there is an internal transfer policy (Africa <---> Africa), people can't buy space low on the external markets and then flip it at huge profits to African customers.  Am open to hearing thoughts on this.




On 17 Jun 2016, at 11:09, Andrew Alston wrote:

> Hi All,
> The following has been submitted to policy-submission and I am also 
> posting it here for discussion in the mean time.
> Thanks
> Andrew
> Draft Policy Name: Inbound Transfer Policy Unique Identifier:
> Status: Under Discussion
> Submission Date: 17 June 2016
> Amends: N/A
> Author(s):
> a. Andrew Alston (andrew.alston at b. Christopher 
> Mwangi (Christopher.mwangi at
> 1. Introduction:
> The AfriNIC Service Region has the lowest amount of IPv4 space of any 
> of the RIR defined regions.  As such, when AfriNIC depletes its 
> current space, there will still be a need for further IPv4 addresses 
> on the continent. In addition to this, there may be circumstances 
> where companies wish to use specific v6 resources and ASN’s 
> unavailable on the continent.
> While the community has voiced concerns that enacting a transfer 
> policy will result in the flow of resources off the continent, this 
> policy addresses that by purely catering for inbound transfers, 
> without allowing or affecting transfers flowing out of the continent 
> to other RIR service regions.
> 2. Resources covered under this policy This policy covers the inbound 
> transfer of all IP resources, including ASN’s, both 16bit and 32bit, 
> IPv4 space and IPv6 space
> 3. Details of inbound transfer requirements AfriNIC shall accept all 
> inbound transfers of all resources explicitly referred to in section 2 
> For transfers into the region, the recipient of IP space (v4 or v6) 
> must provide a plan to AfriNIC for the use of at least 50% of the 
> transferred resource within the next 5 years.
> Once received, the space shall form part of the recipient’s normal 
> allocations for the purpose of evaluating the size of the recipient 
> from an AfriNIC membership perspective.
> Should a recipient of transferred space apply for further resources 
> from AfriNIC directly, all space received via transfers shall be 
> included in any evaluation done for further resource allocation by 
> AfriNIC.
> _______________________________________________
> RPD mailing list
> RPD at

More information about the RPD mailing list