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

[Fernando Frediani]

I think regardless there would be an increase in the IPv6 routing table 
Inter-RIR transfers should not be allowed at all for the other given 
reasons as such:

- Fracturing of Reverse DNS zone
- Complication of management of each /12
- No shortage of IPv6
- IPv6 migration and readdressing is much easier than IPv4 specially 
with the use of tools (everything ends up in a /64)
- Readdressing is part of the business and not something prohibitive

The point about moving Virtual Machines I don't think is something 
enough that can justify. If the machine is moved for a certain period of 
time to exist in another region there is no need to transfer the space 
permanently, if there is anycast involved there is no need to transfer 
either and if the machine is to be transferred permanently then a 
planned renumbering can be done with time.

Fernando

On 15/07/2019 18:38, David Farmer wrote:
>
>
> On Mon, Jul 15, 2019 at 4:07 PM Job Snijders <job at ntt.net 
> <mailto:job at ntt.net>> wrote:
>
>     On Mon, Jul 15, 2019 at 05:01:43PM -0400, hostmaster at uneedus.com
>     <mailto:hostmaster at uneedus.com> wrote:
>     > I understand that we allow this in IPv4 only because of the
>     shortage.
>     > Further, changing IPv6 addresseses is not as big of hardship as
>     it was
>     > in IPv4 land, since both networks can exist during a changeover
>     > period. Also, each segment always uses a /64, allowing easy
>     changes of
>     > the first 64 bits with automated tools in most Operating Systems.
>     > There is NO shortage of IPv6 addresses, so why should we cause
>     > unneeded expansion of the routing tables just to prevent a single AS
>     > from having to renumber their single IPv6 network?
>
>     Can you demonstrate how the routing tables will expand? This
>     "argument"
>     has been brought up a few times, but it is not clear to me how an
>     administrative transfer from one RIR to another RIR has anything to do
>     with the BGP tables.
>
>
> I don't believe that simply allowing Inter-RIR M&A transfers of IPv6 
> will result in any significant growth in the IPv6 BGP routing table. 
> Especially, if whole blocks are transferred, which seems to be the 
> primary intent of this policy. In theory, there is a potential for a 
> small increase due to the fact that it may be possible for the 
> original RIR to expand a prefix in place, while any expansion from the 
> new RIR will likely be a separate new block. However, the real 
> pressure on the BGP table will come from TE, end-user direct 
> assignments (PI), and other sources. Inter-RIR M&A transfers of IPv6 
> is likely to provide only minimal pressure on the BGP table, 
> nevertheless, it is not zero, but it doesn't seem like it should be a 
> big worry either.
>
> I believe there should be some limited mechanism for Inter-RIR M&A 
> transfers of IPv6, but not full transfers for almost any reason like 
> we have for IPv4 and ASNs.  This and the related policies seem to foot 
> that bill in my opinion.
>
> Thanks.
>
> -- 
> ===============================================
> David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer at umn.edu>
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: 612-626-0815
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190715/657c34c3/attachment.htm>