[arin-ppml] Draft Policy ARIN-2019-10: Inter-RIR M&A - Seeking Community Comments / 2019-04

Tue Jul 16 12:14:44 EDT 2019

Without bringing some numbers and practical data to this discussion it 
becomes harder to find out for example real situations where these 
transfers (in the context of RIPE and APNIC) were a game changer and 
that benefited IPv6, it may just be a wish to have.

I really don't see that allowing these transfers can be a great 
incentive to IPv6 at the point of someone giving up IPv6 deployment 
completely on an **already deployed network** just because of renumber 
is necessary of that is something that may benefit a great portion of 
the community, but only very specific cases who don't wish to have the 
work to renumber.

The fact the technology exists that allows to handle transfers of 
portions of the space to another RIR isn't and can be a justification by 
itself. Everything comes at a cost and it seems the cost in this case is 
not worth, compared to the cost of some individuals having to renumber. 
Again, how many cases we had that found the renumbering a huge issue ? 
Actually even if there weren't that many, what was the overall impact in 
the ecosystem and IPv6 ? I appreciate the effort to bring more content 
to this discussion but we really more data to support this type of change.

I'm sorry to have to repeat this point again, but the whole system was 
never meant to be like that, it was only permitted due to IPv4 shortage, 
so I beg to differ but shortage point is something that stands against 
this change.

Best regards
Fernando

On 16/07/2019 12:49, Job Snijders wrote:
> Dear all,
>
> (Note for the AC - it appears that discussion in context of 2019-04 is
> bleeding over into the 2019-10 thread, please take these comments under
> advisement for 2019-04. I'm sorry there is so much e-mail to plow
> through related to the policy propoals, thank you for your time.)
>
> On Tue, Jul 16, 2019 at 03:18:22AM -0300, Fernando Frediani wrote:
>>> Sure, I believe those are your beliefs. On the flip side, my beliefs
>>> are that it should be possible to transfer IPv6 blocks from one RIR
>>> (ARIN) to another RIR, and vice versa for reasons mentioned in the
>>> last few months.
>> What reasons ? Not have the do the work to renumber ? Or some Virtual
>> Machines moving temporarily in a very hypothetical situation from one
>> continent to another ? Until now I didn't see anything else than
>> those.
> There are a number of reasons why transferability of Internet Number
> Resources benefits our community. We should note that these arguments
> have already been brought up on the mailing list and received supported
> by part of the PPML readership.
>
> 1/ Currently the ARIN RPKI TAL is measurably less deployed than any of
> the other RPKI TAls. This means that ARIN members seeking to use RPKI to
> protect themselves are in worse shape compared to members of other RIRs.
> While operators can improve their IPv4 posture by transfering space to
> other RIRs, they can't do so for IPv6. This means that IPv4 space is
> more valuable from a routing security perspective. A sad state of
> affairs.
>
> 2/ Just like with the transferability of ASNs, there are M&A
> considerations where it would be a shame to go through a renumbering
> excercise just because some folks thought that ARIN's /12 should remain
> "unfractured" (even though the RIRs developed a great system to manage
> DNS delegations, which already supports IPv4 and IPv6). Renumbering
> isn't necessarily a free or cheap excercise. I'm happy for the folks who
> suggest they only deal with '/64s' and can easily do it with 'sed', but
> the majority of service providers will acknolwedge that renumbering is
> annoying at best, painful at worst, and should be avoided when possible.
>
> Anyone with statically numbered links to other networks, numbered from
> their own address space (e.g. pretty much anyone providing ipv6 transit)
> is faced with the choice of co-ordinating with all those parties or
> artificially causing an outage on those links, in order to complete a
> renumbering operation. This is a huge operational burden to impose
> without a very strong technical justification.
>
>> So if I understood correctly in theory someone that has already a
>> fully functional IPv6 environment in place would give up IPv6 if it
>> had to renumber to move from a region to another due to this
>> restriction ?
> Yes, I'm unfortunately aware of at least one example. I'm sure there are
> more if we'd search in our community. Not everyone may want to speak
> openly about the circumstances that led them down a specific path. One
> could perhaps approximately measure which ARIN managed prefixes are
> announced outside the ARIN region, and which non-ARIN managed prefixes
> are announced exclusively within the ARIN region; and from there
> probably conclude that transfers are already happening.
>
> It is absolutely bonkers to me that artifical restrictions exist for
> IPv6 - which are not anchored in real technical constraints. There are
> no technical limitations on inter-RIR transfers. If there were, it
> wouldn't be possible for APNIC & RIPE to have an inter-RIR IPv6 transfer
> mechanism in the first place. There is no way this doesn't harm IPv6
> deployment: you can't promote a replacement protocol that has business
> restrictions that don't exist in the legacy protocol. Legal precedent
> trumps technical limitations.
>
> If there is even the slightest chance that IPv6 transferability makes
> continued IPv6 deployment easier for some organisations, why wouldn't we
> jump on it? We've all acknowledged that there is no good IETF standard
> to seemlessly renumber, this means you'll want to stick to the numbers
> assigned to you, and if those are no longer available; well... you may
> put IPv6 deployment on the backburner.
>
> Kind regards,
>
> Job
> _______________________________________________
> 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.