[arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers

[Owen DeLong]

Timeline is a bit off…

Originally there was Jon Postel’s notebook. That passed to SRI and later evolved into InterNIC.

RIPE and APNIC were created and handed parts of the responsibility prior to the formation of ARIN.

ARIN remained “registry of last resort” until the formation of LACNIC and later AfriNIC.

The ERX and other transfer processes were a bit more complicated, but essentially you have the right general idea.

I think that statement 4 is likely not entirely historically accurate.

Early distribution of IPv4 addresses was significantly more generous than later distribution (companies like Apple and HP, Universities like MIT, and others easily got /8s just for the asking, organizations of any significant size could easily request and receive /16s, etc.).

Otherwise, I think you generally have it right.

Owen

> On Sep 6, 2017, at 15:10 , hostmaster at uneedus.com wrote:
> 
> Now that discussion reveals that "IPv4 Inventory", refers to the total number of IPv4 addresses that a specific RIR has under its management, and not the amount of IPv4 addresses remaining for assignment, I will state the problems I see with the proposal.  However, I remain open minded and am asking questions in order to make up my mind.
> 
> If any of the history of numbering management that I state below is wrong, please let me know, as it might change my viewpoint.
> 
> 1) Originally there was effectively only one RIR worldwide.
> 
> 2) This original RIR's Resources were placed under control of ARIN.
> 
> 3) When each of the RIR's other than ARIN were formed, all resources that were assigned to entities within the region of the new RIR, that were under management of ARIN, or the RIR which previously managed the space (RIPE to AFRINIC in that case) were transfered to the new RIR.
> 
> 4) The Previous RIR's who controled resources before the formation of LACNIC or AFRINIC did not have a policy in place that discriminated against any portion of the world, and would if presented with a request for IPv4 resources, would process that request using the same policy that was used for resources assigned in the remaining portions of that RIR's Territory.
> 
> With each of these things said, I now draw some conclusions. Specifically, it is not North America's or ARIN's fault that LACNIC and AFRINIC has less resources under management than ARIN or RIPE or APNIC. Had networks needing resources existed during this time, and all the way past their formation up until that date that IANA ran out of /8's, that RIR could have received IPv4 addresses from the free pool on an equal basis.  While the original Class A networks were given out a lot more loosely than ARIN's standards, this did not change the fact that IANA had a free pool after these original Class A networks were assigned, and did provide additional /8's to any RIR who could show that they had exhausted their free pool below the standard that was applied to all 5 RIR's.
> 
> In my opinion the only reason that LACNIC and AFRINIC did not have as many /8's, was the growth in the APNIC region compared to all other regions, which during that time exceeded every other RIR, including ARIN.  In fact, it was APNIC's request for more space that triggered the exhaustion of the free pool.  Technically, when LACNIC and AFRINIC received their final /8, it was not totally fair to the other RIR's with more addresses under management.  In fact, this final non proportional oversupply at AFRINIC is likely the only reason that AFRINIC is the only RIR with a general free pool.  Instead of a full /8 to each region, maybe this should have been done more proportional to each region's total address space under management.
> 
> For a market based solution to IPv4 addresses, addresses need to be able to flow both ways.  AFRINIC and LACNIC can argue that we are the small guys, and we need to be protected against transfers out.  However, I can just as easily argue that ARIN is being used as a worldwide piggy bank of IPv4 addresses and should also adopt an anti-transfer out policy.  As long as things move both ways, we can argue that the market effect is important, but for this to work, it must be bidirectional everywhere. While ARIN is the leader in supplying directed transfer addresses, market conditions could change worldwide, causing more transfers from another RIR.  For an example, say if China were to require ALL internet to use IPv6, and forbid the use of IPv4 in their country, a large number of IPv4 addresses allocated to China would suddenly be available on the transfer market.
> 
> Some similar event that is now unknown could drive the IPv4 addresses of the LACNIC and AFRINIC into the market, and if this policy were adopted would be unfair to the markets that would be forbidden from these addresses being in the market because of the lack of a bidirectional transfer rule.
> 
> My gut tells me that noone should get a pass on bidirectional transfers, and I am leaning NO at this time, but could be convinced otherwise for the proper reason.  I do not think "Past Discrimination" is that reason.  The true past problem was lack of past network growth, vs other regions.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> 
> On Wed, 6 Sep 2017, ARIN wrote:
> 
>> The following has been revised:
>> 
>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers
>> 
>> Revised text is below and can be found at:
>> https://www.arin.net/policy/proposals/2017_4.html
>> 
>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:
>> 
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>> 
>> The PDP can be found at:
>> https://www.arin.net/policy/pdp.html
>> 
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/policy/proposals/index.html
>> 
>> Regards,
>> 
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>> 
>> 
>> 
>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers
>> 
>> Version Date: 6 September 2017
>> 
>> Problem Statement:
>> 
>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region.
>> 
>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context).
>> 
>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that:
>> 
>> - network operators in AFRINIC in LACNIC have need to obtain space in the market;
>> 
>> - have reasons they think are important to not allow two-way transfers; and
>> 
>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does.
>> 
>> Policy statement:
>> 
>> Add the following sentence after the first sentence of NRPM 8.4:
>> 
>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs.
>> 
>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement.
>> _______________________________________________
>> 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.
>> 
> _______________________________________________
> 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.