Please support NAT64&DNS64 as soon as possible

RouterOS General
1

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, service providers will only be able to receive IPv6 ranges. There will be no /24 /26 or /28 provided to members, especially new members.

That also means that new servers will only have IPv6.
So NAT64/DNS64 will be mandatory in systems until the transition period ends (APNIC's estimate is 2032, which is extremely long).
Cisco Layer 3 Switch lines will soon be equipped with this feature. This feature seems to be available on newer cisco routers. As confirmed by Cisco representative in the event.
I did not find Mikrotik representative in the event, it seems you guys did not attend.
So I hope Mikrotik Team can consider because small service providers like me are using mikrotik (CCR2116 - CCR2216) for routing and BGP to reduce costs. Mikrotik not supporting it may force us to consider more expensive devices from Cisco and Juniper.

1 Like
2

Hi,

Think that you should contact directly with Mikrotik: https://mikrotik.com/support

3

Not asking as a mikrotik resresentative, just curious, why is dual stack not a solution? should it not acceleerate migration to ipv6 for everyone? NAT64 just delays everhing again

4

Hello. Dual Stack is only available when you have Ipv4 address space (public address, leased from APNIC, ARIN,...). Starting from 2026, APNIC will not provide IPv4 space to members, instead members will receive IPv6 space. I also cannot lease from other regions because the data centers in my region do not accept IP ranges outside of APNIC.

You may wonder about the NAT solution with local IP (192.168.x.x,...), it is not suitable for public server environment as well as BGP Peering infrastructure.

The NAT64/DNS64 solution has been around for a long time, Google and Cloudflare have built DNS64 services, just need NAT64 to use immediately.

https://developers.google.com/speed/public-dns/docs/dns64
https://developers.cloudflare.com/1.1.1.1/infrastructure/ipv6-networks/

5

ok but the same ISP will also give IPv6 to the end users. So if servers are IPv6, and end users are IPv6, the only concern is serving IPv4 users from other, less developed countries (in IPv6 sense), is that correct?

6

No, without NAT64 support, servers aren't IPv6, not all (or too many) services that the user wants to access is out of (this small, new, not getting IPv4 allocation...) ISP's control.

With NAT64 support on RouterOS, used with DNS64 services publicly available, the whole IPv4 Internet could be mapped to a IPv6 network space, allowing the user to access nearly any service they want.

7

For end users who provide their own equipment (not using GPON/XGPON equipment from the network operator). Whether they configure IPv6 or not is up to them (but usually not) but the network operators already have their NAT46 solution, we don't care much. I mainly need IPv6 because a lot of international and domestic services we currently only use IPv4 (especially github, they will not support IPv6 in the near future, They confirmed in the tickets). IPv6 VPS will not be able to access these services if they don't have NAT64

1 Like
8

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 their customers IPv4 access by allocating addresses from the 100.64.0.0/10 block? All customer devices support dual stack anyway?

9

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 perform Routing actions, but not enough to distribute to individual clients.
The rack here is a 42-48U server cabinet

10

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 for Home or ISP purposes

11

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 same number of packets!

  • Both are stateful and require the individual connections to be tracked, keeping track of the mapping between private source addresses & ports and public address(es) and ports (5-tuple that includes the protocol). However, the mapping in NAT64 is consumes more RAM simply because IPv6 addresses are 4x as big as IPv4 addresses.

  • Both have the same contention, regarding the number of private source addresses and ports being significantly larger than the available public IPv4 addresses and ports that need to be shared. This includes algorithm to pick the public IPv4 addresses and ports from the limited available pool.

  • The NAT in CGNAT is significantly simpler and more efficient: after the matching entry has been found in the conntrack table, a simple in-place swap operation of the 32 bit address and 16 bit port fields is needed, plus a quick, incremental update to the packet's checksums.

  • NAT64 on the other hand needs to perform protocol translation. It must create an entirely new IPv4 packet based on the information in the IPv6 packet for the 6 -> 4 direction, or the reverse, create a new IPv6 packet based on the IPv4 packet for the 4 -> 6 direction. That's additional memory allocation and copy operations.

    • New header needs to be synthesized from the information stored in the packet with the other protocol.
    • For 6 -> 4: extract IPv4 address from the 64:ff9b::/96 prefix, for 4 -> 6: copy the 128 bit address from the connection state table.
    • Packet checksums have to be recalculated from scratch, which is more intensive because the underlying IP-level information has fundamentally changed.

  • This probably applies less to MikroTik devices, because they either have no or with only limited number of connections support when having NAT hardware offload. But hardware offloaded NAT44 are much more widely supported compared to NAT64.

  • You don't need DNS64 with CGNAT. And very often, only translating A to AAAA record is not enough. There are many other protocols that need to put hardcoded IP addresses in the record content (TXT for SFP, or ipv4hint in the new HTTPS RR).

  • Same with DNS. Many applications, like games, might have hardcoded addresses in their internal protocols, for those, no address conversion with DNS64 can be performed and your customers have no connectivity.

Again, when you repeat other people saying that CGNAT are resource intensive, they are talking about when millions of customers that mostly only use IPv4 (have no IPv6) need to be served. When your usage is only as fallback for a IPv6 (where most of the traffic is IPv6 and you only need NAT to access some IPv4 only resources), and when having to support the same number of connections and amount of traffics to IPv4 remote destinations, CGNAT uses much less resources than NAT64, and has fewer issues with application protocols.

1 Like
12

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 (exactly eBGP IPv4/IPv6) with 4 channels with quite complex rules. And at the moment IPv4 is very very important to me. You cannot deploy both BGP IPv4 and CGNAT IPv4 on the same device or pair of devices, they will be messed up if not tested carefully and affect current customers.
  • In the near future we will focus on IPv6 Only (currently only dual stack option), so we only need 1 intermediate channel to handle v4-only requests with a small number. So I need a simple solution, operating at the Core Network layer, so personally I find NAT64/DNS64 is a perfect solution as they have little impact on the BGP infrastructure and little impact on customers.
    This is my personal opinion
13

In RouterOS, it's mostly normal NAT, with some modification for the Subnet range and mapping (enable Endpoint Independent NAT for UDP). You can follow this guide here:

Edge Router & BNG Optimisation Guide for ISPs – Daryll Swer

14

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 problems" because at the moment the whole interesting part of Internet is accessible via IPv4 anyway, so adding IPv6 does not add value. And as there always is a risk (and cost) for any change in the network, the most profitable way is to postpone IPv6 again.

15

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 sort of peculiar fancy of some.

1 Like
16

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 think the NAT64/DNS64 solution will be better than CGNAT. CGNAT is suitable for large ISPs where the IPv4 needs of end customers are still very high. On the Server, things will be quite different from the end users.

My infrastructure is divided into many vlans, deploying CGNAT will also not be suitable.

I will research more about Cisco. With Cisco's Nexus Switch series that will support nat64 in the near future and activating nat64 on cisco with just a few command lines makes me quite interested.

1 Like
17

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 here.

The ultimate goal in IPv6 rollout is to go IPv6-only and retire IPv4. I know that's a ways off, but realistically why would anyone want to run two network protocols forever?

Why use 464xlat? Well, it lets you deliver IPv4 as a service over an IPv6-only network. The typical scenario I work with is with a CLAT on a client device. The CLAT lets a client "think" it has an IPv4 address, and it can route that IPv4 traffic over an IPv6 network, through a NAT64 to get to the IPv4 internet.

For example, most CLATs will assign each client device 192.0.0.1 and "well known" NAT64 prefix is 64:ff9b::/96. If you were to open up a command line and ping 1.2.3.4, the CLAT will translate the destination address to 64:ff9b::1.2.3.4 (this is shorthand for 64:ff9b::102:304 -- it embeds the 32 bits of the IPv4 address into the last 32 bits of that IPv6 prefix).

That traffic then can transit an IPv6-only network to a NAT64 appliance (sometimes called a PLAT in the 464xlat standards) which will examine that destination address of 64:ff9b::102:304 and extract the destinations IPv4 address of 1.2.3.4 and send that packet on its way. The NAT64 appliance will probably pick a source address out of a pool, similar to what a CGNAT device does.

Returning back to the "why"... This lets a network run largely IPv6-only without sacrificing connectivity to the IPv4 internet. The only IPv4 that needs to be deployed is to that NAT64 appliance. There are some caveats and it requires CLAT support in the client device, but this is rapidly becoming "the path forward to IPv6-only"

In fact, T-Mobile already runs their network this way and has for 10+ years; I wouldn't be surprised if other 5G networks go this way. Operating systems like Android, iOS, macOS have a functioning CLAT. Windows 11 is getting a CLAT (it had one already, but was only active on cellular interfaces). [1]

Additionally, there's a new DHCPv4 option nicknamed IPv6-mostly (option 108). It effectively tells an OS to turn off IPv4 for some period of time. This is typically paired with CLAT support in the OS along with support for a way to configure the CLAT (usually PREF64). If a device doesn't understand option 108, it ignores it and continues to use IPv4 or dual-stack. If it supports dhcpv4-option108, then it should also have CLAT support and can operate in an IPv6-only mode.

I've run all of this in a lab setting and it works remarkably well. I know some network engineers who are required to run 80% IPv6-only by the end of 2025 by US government mandate (M-21-07), and they use this same tech pretty heavily.

So that's why one would want to use NAT64. Most "enterprise" gear that supports NAT44 will support NAT64 (Juniper SRX, PaloAlto Networks, F5 & A10 load balancers, and I'm guessing Cisco firepower supports it), Linux has a couple means to implement nat64 (jool, the nat64 kernel module, ebpf tools like cilium).

I think another use-case for CLAT+NAT64 is for ISPs. Instead of an ISP deploying CGNAT, it might actually be able to use a CLAT in the CPE device (home wifi router) and give users access to IPv4 that way. The main benefit to this deployment is that the NAT64 appliance only needs to be sized to handle translated traffic; untranslated traffic can bypass that appliance. With CGNAT, you need to size the appliance to handle ALL traffic, including transalted & untranslated traffic. For this reason, I'd also like to see CLAT support in RouterOS.

References: