No. Just no. If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before. And dual stack is no issue. But as always the ISP does need to not fuck up and you operating system should follow RFCs.

All these transitions methods are far to expensive and an unnecessary overhead.

> If ISP would have deployed IPv6 early enough in time, like deutsche Telekom had a properly IPv6 network ready in 2012 or even before.

I think you forgot half a sentence here. What was your point?

> And dual stack is no issue.

How can that possibly be so? Having enough address space to comfortably architect gives you room for far superior topologies, meaning that running dual stack at the bare minimum means that either your IPv6 topology is being compromised to map cleanly to your v4 topology, or that you're running two different topologies altogether. You need two times the sets of firewall rules, two times the number of address configurations...everything in your infra roughly 2x.

> All these transitions methods are far to expensive and an unnecessary overhead.

How so? Running 464XLAT on a device with a proper CLAT has minimal overhead, and the PLAT is no worse than running a NAT for IPv4.

Running nat on ipv4 is no worse than running a stateful firewall on ipv6 only, I don't get the complaints about it. Modern firewalls do far more with deep packet inspection, SSL unwrapping etc. NAT is a hardware function on enterprise access switches let alone firewall layers, any home router would have to do firewalling at their router anyway.

Well performance really isn't something I would point to at all. While I believe it can become problematic with great scale (e.g. those expensive CGNAT boxes), it's more the architectural and connectivity aspects that are problems:

Architecturally, dealing with two different address spaces is a complication. A flat address space is easier to reason about and more flexible. This is amplified by the fact that IPv4's RFC1918 address space is very small. Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.

Connectivity-wise, stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used (without rendezvous servers).

> Architecturally, dealing with two different address spaces is a complication

I completely agree, which is why dual stack is terrible.

> Have you ever had to merge IPv4 networks from different companies? It's rarely the case that they don't have overlapping ranges.

Dual stack doesn't solve that

> stateful IPv6 firewalling is very different from NAPT in IPv4 because the applications cannot reason about the ports being used

The source port is ephemeral for almost all applications, and I can't think of a good reason it wouldn't be, just legacy crap

I'd love to have an ipv6 only network with NAT66 at the boundary, at home and at work, but while it still requires ipv4 I don't see the point.

I'm not advocating dual stack either. Like I said in my other reply to you, I am suggesting IPv4-as-a-service using standard translation technologies and architectures.

Dual stack is the problem, we've still got devices which are ipv4 only. I've never seen anything that's ipv6 only.

Even on my standard linux laptop, and corporate windows laptop, with the hack of DNS64, I still have issues with my ipv6 subnet. Yet I have no problem with my ipv4 subnets.

So I don't bother with ipv6 - it's a toy. There is no benefit at all to me, but I can't get rid of IPv4 because some devices won't work with ipv6, and others will work but have bugs.

The ivory towers felt "we know best, everyone will move to us, we don't need backwards compatibility". That arrogance put ipv6 back probably 30 years, maybe more. Building in backward compatibility at the protocol level (so 464 etc) would have removed the need for other hacks (dns64) and allowed a trivial transition.

Yep, agreed on pretty much all counts. The end goal is obviously the same for both dual-stack and translation technologies. But the latter makes things so much lower risk and gives you (the network operator) actual progress and a chance to simplify along the way. Providing IPv4-as-a-service is an actual plausible thing, compared to dual stack's now-draw-the-rest-of-the-owl vision.

> So I don't bother with ipv6 - it's a toy.

Since I can't edit my other comment: I don't agree with this. I agree with the challenges of v6 that wouldn't be there if translation had been prioritized from the start, and with your characterization of DNS64 as a hack.

At work I can't see being able to drop ipv4 for at least 20 years due to applications and hardware which still relies on ipv4 (I've got some endpoints which don't even support igmpv2!)

I still haven't had a single failure for someone who can't reach an ipv4 endpoint.

As such I see it as just a toy.

I'm not suggesting dropping v4 connectivity altogether. I'm suggesting migration to a v6-only core by providing IPv4 as a service via 464XLAT, IPv6-Mostly, or only offering IPv4 to select network segments using SIIT-DC-2xlat: https://nicmx.github.io/Jool/en/intro-xlat.html#siit-dc-dual...