[arin-ppml] Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A

[hostmaster at uneedus.com]

As far as I can tell, this is the most current policy for allocation of 
IPv6 Blocks to Regional Internet Registries:

https://www.icann.org/resources/pages/allocation-ipv6-rirs-2012-02-25-en

There is nothing in it regarding transfering control of portions of these 
blocks to a different RIR.  In fact, based on the formulas contained 
therein, if a RIR were to transfer enough of its space out, it would be 
unable to obtain more, as transfered space is not accounted for in the 
formulas.

This policy was ratified in 2006.  At that time I doubt there was any 
real discussion about allowing transfers of IPv6 between RIRs.

Reading the policy it also does not seem to allow interRIR transfers.

This is the list of currently assigned IPv6 blocks:

https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

Even here, I see nothing granting consent by IANA or otherwise to the 
transfer to another RIR of portions of Blocks contained on this list.

Even if ARIN is permitted to allow it, I do not think it to be a good 
idea.  Right now, without a policy change I can look at that list and know 
that 100% of each Block of IPv6 addresses is managed by the RIR listed. 
That allows for clean filter lists in IPv6 for those that choose to filter 
out abuse routes from other RIR's.  Allowing transfers will eliminate that 
clean fixed line that currently exists.  Also, return and renumbering has 
always been part of the policy since the beginning of IPv6 and should be 
enforced.

Also as pointed out by others, if we want to allow interRIR transfers, I 
think the global policy needs to be changed to allow it.  Otherwise 
without global consensus, I think IPv6 transfers should NOT be permitted.

Albert Erdmann
Network Administrator
Paradise On Line Inc.

On Mon, 14 Oct 2019, Owen DeLong wrote:

> You have the control relationship backwards. IANA is a function performed by  PTI under a contract controlled by the NRO (Number Resource Organization). The NRO is the five RIRs and they tell ICANN how to perform the IANA function, not the other way around.
>
> I’m still on the fence about allowing this, but the argument that it is not permitted by IANA/ICANN/PTI is completely hollow.
>
> Owen
>
>
>> On Oct 14, 2019, at 13:00, hostmaster at uneedus.com wrote:
>>
>> The process of IPv6 is that IANA, which is a function of ICANN provides blocks of IPv6 numbers to the RIR's for allocation and assignment.
>>
>> Due to the shortage of IPv4 numbers and 16 bit ASN numbers, ICANN and IANA has permitted inter RIR transfers to happen with these resources.  However this consent has never extended to IPv6 addresses.
>>
>> I am unaware that IANA/ICANN has EVER voted to permit ARIN or any other RIR to give control of portions of the blocks of IPv6 numbers assigned to ARIN to a different RIR, which is what an inter-RIR transfer of IPv6 resources is.
>>
>> In the IPv6 space there are no legacy addresses.  Every Block of IPv6 space was assigned to a specific RIR.  That includes every address within that block.  Transfers would require a policy at IANA/ICANN to permit these actions.  Does such permission exist, and can anyone point me towards it?
>>
>> In any case, even if it is possible, does not mean that it is a good idea. I still maintain that every IPv6 registrant knew the rules of the road when they received their block.  Those rules were that they were not transferable between RIR's.  If they later choose a different RIR, I say let them renumber.
>>
>> Albert Erdmann
>> Network Administrator
>> Paradise On Line Inc.
>>
>>> On Mon, 14 Oct 2019, William Herrin wrote:
>>>
>>> On Mon, Oct 14, 2019 at 7:50 AM Fernando Frediani <fhfrediani at gmail.com> wrote:
>>>> On 12/10/2019 13:58, William Herrin wrote:
>>>>> On Sat, Oct 12, 2019 at 6:29 AM <hostmaster at uneedus.com> wrote:
>>>>>>> I agree.  The only reason for this transfer thing was the shortage of IPv4
>>>>>>> addresses and 16 bit ASN numbers.  There is no shortage of IPv6 addresses
>>>>>>> or 32 bit ASN.
>>>>>
>>>>>> Therefore, I agree that IPv6 transfers and 32 bit ASN transfers should not
>>>>>> be permitted, even for M&A.
>>>>
>>>>> I have almost exactly the opposite opinion. No shortage means no cause to game the system. No gaming of the system means the transfer is requested for
>>> reasonable, pragmatic causes. Like avoiding renumbering pain. Why should this be prevented?
>>>>
>>>> Because this is not a strong enough reason to allow IPV6 and 32-bit ASN be moved from one region to another. Although there are costs to do renumbering
>>> this is part of the business and anyone in such situation must be prepared to do so.
>>> Respectfully, I think you have it backwards. We shouldn't need a reason to allow something, we should need a reason to prevent it. Maybe not a great reason
>>> (that probably sets the bar too high) but at least a plausible reason.
>>>> The type of scenario that is being proposed here is not something that happens so frequently, in some cases may be very specific and is not very
>>> productive to change such an important thing like allowing IPv6 and 32-bits ASN to be moved between regions with the impacts it causes in the whole global
>>> registering system just to accomplish the need of a few which have workable plausible option available. Therefore the need of a few cannot overcome the
>>> interest of the whole system.
>>> Like what? What malfunctions or functions inefficiently if with the receiving registry's consent we allow a registrant to move their IPv6 addresses and AS
>>> numbers from ARIN to a different registry?
>>> Regards,
>>> Bill Herrin
>>> --
>>> William Herrin
>>> bill at herrin.us
>>> https://bill.herrin.us/
>> _______________________________________________
>> ARIN-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:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>
>