> While true, neither of those are relevant in context (and I even explicitly acknowledged your first bullet in my comment above).

Yeah, I just mentioned that because P2P networking is used a lot more than most people think these days, since even things like Zoom that look like typical client–server web browsing actually use P2P networking internally.

> It was suggested that a website operator deploying IPv6 would somehow improve the end user experience by virtue of avoiding CGNAT and I was questioning that.

Reliability and latency will be marginally better with IPv6 than with CGNAT, but this is so minor that I doubt that most people will notice this. And many CGNATs will RST connections that last too long, but most protocols have some sort of automatic retry/reconnect built in, so this shouldn't cause issues very often either.

IPv6 addresses are quite a bit cheaper than IPv4 addresses in most clouds, but since most servers still need to support IPv4, this doesn't help you directly. Supporting IPv6 means that others using the cheaper IPv6-only cloud services will be able to connect to your server, but this doesn't matter for consumer-only services.

So yeah, you're probably right that enabling IPv6 server-side won't have (m)any benefits.

> I do of course appreciate that going via CGNAT to a clueless operator that eagerly adds IPv4 bans can be problematic but that's more a question of why you as a consumer might want IPv6 connectivity not why a service provider would want to deploy it.

Being able to ban IP addresses without worrying about collateral damage is a pretty big benefit to the service provider though, for certain applications at least.

If you're using a cloud you'll probably find it useful to have ipv6 on every server and ipv4 only on the front end gateway