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 ([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.
_______________________________________________
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.
