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

[Job Snijders]

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