The default sample code (which everybody is going to copy without reading about the consequences) could only slightly increase the V4 space instead of doubling it which we'll hopefully never need as V6 is going to grow much more quickly now (again: hopefully)
It does not harm IPv6 growth. Even years from now IPv4 will be larger than IPv6. IPv6 routes are huge so even just taking a small chunk of that allocated space for IPv4 will help.
That's not a workaround - but yes, these things need to be upgraded. They're probably unmaintained anyway since good networking departments don't want to be working with super old gear.
> So whatever happened internally at Verizon caused aggregation for these prefixes to fail which resulted in the introduction of thousands of new /24 routes into the global routing table. This caused the routing table to temporarily reach 515,000 prefixes and that caused issues for older Cisco routers.
Verizon might very well be running current hardware. They have announced too many routes which in turn let the global table grow too big which was causing problems with routers all over the place.
The connectivity issue was caused by the routing table to grow too big for old routers used all over the place.
The routing table grew too big because of a mistake by Verizon which might or might not have been running old routers.
It might not have even been Verizon's mistake. When you peer with an ISP it is the customer's router that announces the routes. Announcing all of your networks individually is literally a one line change in most router configs so it's an easy mistake to make. If the ISP is being defensive, and good ones are, they filter incoming routes to make sure they belong to the customer. But they may not have a filter that mandates that they're aggregated since that usually isn't a problem.
I agree that it would be better not to harm IPv6 growth. But if the alternative is to break the IPv4 internet then the choice seems obvious.