If I may add a point:
- As with everything ipv6, it's extremely non-standardized.
I mean that there are standards, but which exactly, which part of them, and how exactly they are used differs significantly.
Also, the number of fixup/stopgap measures with “6” and “4” in the name is already astonishing. And every time something gets implemented and deployed, a new one is invented that should work better.
I don’t think that’s the case this time. A number of things are coming together:
- Mobile operators have been iterating on IPv6-only networking for more than a decade now. The protocols are mature now. There is industry consensus that IPv6-mostly and IPv6-only networks are the way forward. NAT64 is a key component of both standards.
- All major operating systems support the “IPv6-mostly” standard (see RFC 8925). And every popular OS will fully support the IPv6-only standard in 2026. MacOS already supports this and it’s mature. All mobile OSs (iOS + Android) support this. The main holdouts are Windows and to a lesser degree Linux. Windows has this in preview. Linux has been able to do this with clatd + tayga for years but it’s becoming consumer friendly, automatic and seamless (just take a look at NetworkManager 1.57 as it now includes a CLAT that can interface with NAT64 endpoints).
- The IETF engineers behind these most recent technologies have drawn upon the experience of all the previous transition technologies
The IPv6-only and IPv6-mostly network designs use NAT64 + PREF64 + maybe DNS64… IPv6-mostly networks support all of that along with DHCPv4 Option 108.
If mikrotik doesn’t want to implement this, it’s probably because implementing NAT64 is incredibly difficult. I think service providers might end up needing a dedicated NAT64 box in many cases… Maybe Mikrotik routers can re-use open source NAT64 implementations. There are a few good ones. But I’m not sure.
1 Like