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

Fri Sep 8 23:17:57 EDT 2017

> On Sep 7, 2017, at 12:23 , hostmaster at uneedus.com wrote:
> 
> The reason that those early class A holders received such a large block was simply the fact that CIDR did not exist at the time, and therefore there were only 3 possible values of address blocks you could receive, /8, /16 and /24.  Clearly most of the original class A holders had plans to (and many still do) have more than 65536 devices, therefore being too large for a class B.  In these days neither NAT or CIDR were a thing.

I wasn’t making value judgments about the reasoning of the time, simply stating the historical fact of the matter.

I lived much of this history and am not in any way condemning the choices of the time. Each and every one made sense at the time in the environment as it existed, including typing passwords into devices in clear text via telnet.

Things are definitely different today in many ways.

> You state that 4) is not entirely accurate, but I can find nothing that actually stated in policy that certain regions of the world were to receive less IPv4 resources than other portions. Of course since there were not large entities in Latin America or Africa requesting resources similar to MIT and others, we really do not know if resources would have been given out on the same basis.  Had an actual request been made, and denied, that is a different story than we have here.

I believe that ARIN and APNIC did, in fact, refer entities in the portions of the future LACNIC and/or AfriNIC regions that they didn’t serve at the time to the appropriate RIR at the time. While there was no policy to deny the requests, there were different territorial definitions and the policies for obtaining address space did vary from RIR to RIR. Some of the minima that existed for some time in ARIN made it quite difficult for entities in Africa and the Caribbean to qualify for address space from ARIN as an example. While it wasn’t geographical, there was size-based discrimination that had a stronger impact on some geographies than others.

> In any case, had there been any large networks from these regions, they could have received address space they could justify from the free pool until it went away in 2011.  However, like today these areas are clearly less served than other regions like ARIN and APNIC, and connectivity is often an issue as well.

Should you have to be a large network to qualify for space from an RIR? Even if you are a network operating in a region where the economics of network operations and the region at the time precluded any such possibility?

> I believe that the only way the market of "highest and best use" for IPv4 addresses in a free market until everyone finally goes 100% to IPv6 is if all IPv4 addresses are subject to that market.  I think that ARIN should not release addresses from this region to any region that has a one way policy, as it prevents the market of addresses from working.  I also see a limit on how high address cost can go, as at some price point someone will simply say, "forget it, lets go v6”.

On this, we agree. If we can determine that price, then I vote we immediately make that the minimum RIR charge for a transfer and move on. ;-)

Owen

> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Thu, 7 Sep 2017, Owen DeLong wrote:
> 
>> 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.
>> 