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 ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
