If you deploy IPv6, you might not deploy CGNAT, but unless you are dual stacking, something functionally equivalent is required.
As to scaling costs, IPv6 offload isn’t a 1:1 replacement for IPv4 or CGNAT capacity. You need enough capacity to carry the IPv6 traffic over IPv4 in case your IPv6 transport, transit or peers fail. Again, not optional.
Thus in a properly designed network these are not optional costs.
The failure mode for your v6 failing is the same as it is for v4 failing in a v4-only ISP: stuff breaks. If you want to fix that you need a redundant failover setup, which is the same thing you need in v4 except cheaper because it doesn't need to do CGNAT.
Surely you need enough IPv6 capacity incase your IPv4 transit fails as well. If JIO could have built enough IPv4 capacity to run their network over IPv4, they would have, but they can't, so they've been pushing IPv6 hard.
I’m not familiar with JIO’s setup, but that’s an interesting question. If their IPv6 was down, would their network still be able to deliver? Would they run out of CGNAT capacity or IPv4 translations?
IPv6 is no longer optional for them. I suspect it's not optional for T-Mobile USA either. Or Facebook/Google/Netflix.
Or have I been living with Canadian ISPs too long and that sort of thing doesn't happen in the rest of the world?
Improved latency mean improved responsiveness, and that in turn has companies claiming improved user retention and sales.
If you need an argument to support ipv6, those seems like good reasons to support ipv6.
What I want to know is do all these studies take into consideration the “happy eyeballs” algorithm that prefers IPv6 over IPv4 in web browser requests, thus delaying the IPv4 request?
Route aggregation or selection does not impact forwarding performance on a router.
In practice this is only a small part of final performance, so you need to do end-to-end measurements to get a proper idea of what people will experience. Both Facebook[1] and Apple[2] have done that, showing 10% faster page loads and 40% faster connection establishment respectively on v6. Even if that was solely down to routing policies, it's still a measurable difference.
[1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv...
[2] https://www.sidn.nl/en/news-and-blogs/apple-connections-esta...
In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:
Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).
Geoff’s article on TCAM exhaustion is almost 10 years old. No BGP router in the default free zone has had a 512k route limit in years. Modern routers typically scale to millions of routes.
The incident in question was the result of misconfiguration and/or ISPs trying to run old routers past their usable life.
The whole thing was completely avoidable and not related to IPv4 vs IPv6 forwarding performance.
As to the IPv6 latency article, it can best be summarized as IPv6 sometimes has lower latency than IPv4, except when it doesn’t.
In no shape, way or form does the article claim that IPv6 forwarding performance is better than IPv4 forwarding performance.
There’s some hand waving about NAT, but it also notes that increasing the number of NAT levels improved latency!
The simplest explanation is that the differences come down to different routing policies in IPv4 and IPv6. Thus it depends on where you stand as to what you see.