I know that providing NAT64/DNS64 is just a temporary solution but for our region this is a huge problem. If you are in the APNIC region like us, you must have known that in the APNIC60 event, providing IPv4 to members as part of the IPv6 Only process was rejected, which also means that from 2026, …

But the routers of the service provider providing NAT64 support all need IPv4 connectivity to the internet. And I assume you want to run RouteOS on such devices, hence the ask for MikroTik to implement NAT64 support. BUT: What hinders those routers to provide CGNAT-like services instead, giving the…

The datacenter will provide /30 or /28 Public IP on each rack (depending on the provider) for customers renting Rack at the center. They can be used for various purposes (Direct use, participating in BGP routing or both). I can use them for BGP and NAT purposes at the same time. They are enough to …

[image] CGGXANNX: CGNAT CGNAT is not suitable in my environment because it is resource intensive (CPU/RAM). This amount of resources should be used for eBGP purposes which are also very resource intensive. I use Mikrotik for BGP routing. providing public server services to customers and not …

[image] minhpro: because it is resource intensive (CPU/RAM) And how do you think NAT64 work? If you understand how both techs work, you would see that NAT64 requires MORE CPU and RAM resources than CGNAT when you have to track the same number of connections and perform the translation on the …

I agree with you but I have a few comments: CGNAT is deployed at the ISP level with a large number of users (>10000 users). I am just a small provider (<1000 users) and my customers are actually servers. Deploying a CGNAT system is too much. My current infrastructure works as I mentioned is BGP (e…

[image] minhpro: CGNAT is deployed at the ISP level with a large number of users (>10000 users). I am just a small provider (<1000 users) and my customers are actually servers. Deploying a CGNAT system is too much. In RouterOS, it's mostly normal NAT, with some modification for the Subnet ran…

Of course, having end-users that only have IPv6 and not access to IPv4 will in the end be beneficial for everyone, because it will finally put some pressure on the providers that still do not have IPv6. As it is now, for many of them there is no incentive to deploy IPv6. "it can only cause problem…

I would just add that I think cloud providers bear at least some of the blame around this. Many (most?) services today are served by virtual servers or load balancers of some sort, and sadly many providers still treat ipv6 as a second class citizen, or even when they support it, it's treated as some…

Regarding this (maybe it's my fault), as I said above, our network infrastructure is BGP with 4 channels (with 4 independent ISPs). And the main gateway is Mikrotik. Since Mikrotik is running BGP, we don't want to create more load for them even though it's a pair of CCR2216. Also, in the long run, …

I'm replying a little late, but NAT64 is one tool in a toolbox to deploy IPv6-only/IPv6-mostly networks to client devices. Information about these networks can be found by googling 464xlat as well, though 464xlat covers quite a much broader set of options than just what I think is being talked about…

Please support NAT64&DNS64 as soon as possible

RouterOS General

Amm0 October 18, 2026, 11:47pm 27

NAT64 (XLAT/etc/etc) situation is unchanged as of 7.26beta1. Dual stack, means "dual firewalls" and "dual paths to troubleshoot", both sucks.

The main "NAT64" complaint thread is here: