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 <[email protected]
<mailto:[email protected]>> wrote:
On Mon, Jul 15, 2019 at 05:01:43PM -0400, [email protected]
<mailto:[email protected]> 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:[email protected] <mailto:email%[email protected]>
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 ([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.
