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

[rpd] Draft inbound policy

Scott Leibrand scottleibrand at
Tue Jun 21 16:37:03 UTC 2016

I can't speak for ARIN, but my recollection when we discussed this previously was that the current ARIN policy would require a bidirectional (reciprocal) transfer policy to be considered compatible. It would therefore require a policy change in the ARIN region to support unidirectional transfers to AfriNIC or LACNIC. I would support such a policy change in the ARIN region of necessary, but would also suggest the AfriNIC policy community consider an inter-RIR transfer policy that becomes bidirectional once the AfriNIC free pool is exhausted (with appropriate restrictions on transfer of space recently received from AfriNIC). That would ensure that, if ARIN's policy is not changed by the time inbound transfers become the only way to get addresses in AfriNIC, transfers are still available from all RIRs. Until then, anyone who for some reason can't get space from the AfriNIC free pool can still transfer it from RIPE, likely at a slightly higher price. 


On Tue, Jun 21, 2016 at 8:57 AM -0700, "Mike Burns" <mike at> wrote:

Hi Owen,

Thanks for that. Like you, I think that the word "reciprocal" in ARIN's policy would prevent outbound transfers to AFRINIC should AFRINIC pass a one-way transfer policy. The comma placement seems to indicate that.

Still I am not certain. It would be nice if ARIN could chime in like Tore did, so that the AFRINIC community could make their considerations with all the relevant facts at hand.


-----Original Message-----
From: Owen DeLong [mailto:owen at] 
Sent: Tuesday, June 21, 2016 11:43 AM
To: Mike Burns 
Cc: Tore Anderson ; rpd List 
Subject: Re: [rpd] Draft inbound policy


Since I cannot remember what fraction of the discussions you ask about were within the context of an AC meeting and what were public, I won’t comment here about those discussions at risk of violating my ARIN AC NDA.

I will say that it is my personal opinion that a one-way policy does not constitute an implementation of a “reciprocal, compatible, needs-based policy”.

However, I must be clear that in this case, I speak only for myself and do not represent or speak for the AC, the ARIN community, the ARIN staff, or ARIN as an organization.

I am not aware of any decision which contradicts my opinion in the matter.


> On Jun 21, 2016, at 08:01 , Mike Burns  wrote:
> I support the one-way policy although I would prefer it to be two-way.
> I understand the fears that addresses would flow out of the region; 
> the LACNIC community expressed the same fears when considering a 
> two-way policy last year.  Many members actually feared that ISPs in 
> Latin America would voluntarily impose CGN just so they could sell their addresses!
> I have experience with inter-regional transfers, I brokered the first 
> one back in 2012 and have done hundreds of them since.
> I have brokered the odd APNIC to RIPE, or RIPE to APNIC, but the vast 
> majority of these addresses flow from the address-rich regions of ARIN 
> (and to a lesser extent RIPE) out to APNIC.
> In areas with larger supplies of available IPv4, prices are lower. So 
> in almost every case the lowest price is for addresses sourced in the 
> ARIN region. This drives addresses out of ARIN as buyers from 
> out-of-region choose the lowest priced addresses.
> By all means I think AFRINIC should avoid a strictly in-region 
> transfer policy, although that beats no transfer policy at all.  We 
> are seeing issues with the newly implemented intra-regional-only 
> policy in LACNIC related to lack of supply. Our fear is this will 
> naturally cause prices to rise in that region, or in any region where supply is constrained.
> ARIN does require reciprocity for inter-regional transfers but I am 
> not certain if the implementation of the policy language would 
> actually prevent one-way transfers. We know that RIPE would support a 
> one-way transfer policy, thanks to Tore.
> Owen do you remember if the one-way option was ever brought up with 
> the ARIN staff or community and if so what the response was?  Was the 
> word "reciprocal" associated with two-way traffic, or was "reciprocal" 
> associated with a needs-test requirement by the recipient RIR?
> Regards,
> Mike Burns
> -----Original Message-----
> From: Tore Anderson [mailto:tore at]
> Sent: Tuesday, June 21, 2016 3:18 AM
> To: Owen DeLong 
> Cc: rpd List 
> Subject: Re: [rpd] Draft inbound policy
> * Owen DeLong
>> I am thoroughly opposed to this policy.
>> It is not fair in that it is a one-way (inbound-only) policy. If 
>> AfriNIC wants to participate in the inter-RIR transfer process, then 
>> it should do so as a full citizen on an equal footing.
> Speaking as a member of the RIPE community (but obviously not on 
> behalf of the RIPE community), I do not consider this proposed policy 
> as being unfair at all.
> The RIPE community passed an Inter-RIR transfer policy that 
> deliberately does *not* require the other RIR's policy to be two-way.
> Thus, if the AfriNIC community wants to open the door for one-way 
> transfers from the RIPE region, then that is totally fine as far as 
> the RIPE community's policies are concerned.
> Should we change our mind about this later, it is of course possible 
> for us to change our Inter-RIR transfer policy at any point in the 
> future, e.g., by starting to demand reciprocity (like the ARIN community already does).
> The proposed policy merely extends an invitation to the other four regions.
> It is up to them to decide whether to accept it (like RIPE) or decline 
> it (like ARIN); the AfriNIC community simply does not have the power 
> to unilaterally force an unfair Inter-RIR transfer arrangement onto 
> another region.
> Tore (who neither supports nor objects to the proposed policy; I 
> believe AfriNIC policy should be for the AfriNIC community to decide)
> _______________________________________________
> RPD mailing list
> RPD at

RPD mailing list
RPD at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list