It depends on if this is PI or PA space.
In the case of PI space, you may be right, one route removed, one route
added - net change likely zero. However in the long run, PI space is
going to make the IPv4 routing tables look small when everyone has their
own route, rather than a combined route with your upstream in the DFZ.
In the case of PA space, the default route leads to the upstream of the
block, and breaking out a portion to be routed differently clearly adds
routes.
This is one place that the IETF has let us down. IPv6 was supposed to
allow multiple routers, each with its own upstream. I do this, but it
requires hacks that should not be needed. According to the specs it is
supposed to be possible to multihome in IPv6 using only your provider(s)
provided PA space. The problem is that many OS's do not deal well with
more than one router, so people are getting PI space and using BGP
sessions to get around the shortcomings of what was supposed to be
automatic multihoming and renumbering. When this is fixed, the need for
PI space will be greatly reduced.
With the sheer volume of IPv6 addresses at some point the growth of the
routing tables because of PI addresses will not be sustainable, and some
providers might even black hole them.
I have had to renumber in the past, and at least in Linux, sed is your
friend. It really is not that hard.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Mon, 15 Jul 2019, Job Snijders wrote:
On Mon, Jul 15, 2019 at 05:01:43PM -0400, [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.
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.
