Then you are good. I can't see the need for any Customer side translation to make ipv4 external resources available over ipv6. I can see a need to make ipv6 external resources available over ipv4 where the ISP is stuck on ipv4, but only as a stop gap. Even now, I think it is becoming a black mark on an ISP not to support ipv6.
The biggest issue for me, as an ISP, is the CPE devices have a mismash of IPv6 support. Unless I control every aspect of the customer’s experience (as in force everyone to use one vendor for WiFi etc.), IPv6 hardly makes into the customer’s house because the router vendors each do something different by default (RA/ND vs. DHCPv6 vs. 6rd vs. 6to4, etc.). I’d spend an extra half hour or so getting IPv6 working at a customer’s house, even if it was a MikroTik router I supplied. All to have maybe 5% of my traffic using it.
I had it all working dual-stack for a while, then eventually just disabled it at the edge. Zero peeps from customers with it off (and in some cases, fewer complaints), so that’s where I left it a year or so ago.
It’ll all get turned back up eventually…
The critical issue is there is a finite number of public IPv4 addresses. For example, mobile devices rarely get a public IPv4 address, most use CGNAT today. And even new services like Starlink, charge for a public IPv4 address since it's a finite resources. Some mobile providers are only IPv6 and relay on DNS64, which generally works since app store testing explicity checks for IPv6 DNS64/NAT64 compatibility.
The net result today is public IPv4 addresses have a cost, whether it's borne by provider or charged as add-on to consumer...point is they are not "free". And, there are other costs to end-to-end dual-stack stack network, since you're essentially managing two networks at all points within the infrastructure. So IPv4 translation at the edges of the network has potential to reduce costs.
Flip side, as a consumer of internet services, obviously getting both a public IPv4 and IPv6 prefix has a lot of benefit since you can access either network. But similar to providers... the end-user now still left managing two networks, and particularly needs to manage two sets of firewall rules, etc. In a simple, flat home LAN (e.g. no VLAN, one LAN segment), dual stack is pretty automatic. But once you start adding VLANs, managing dual-stack becomes non-trivial.
Anyway...the problem/request here is in a pure IPv6 networking RouterOS lacks any translation tools like NAT64/464XLAT/MAP-T/etc. this make using anything but a dual-stack architecture impossible.
In germany, the biggest mobile provider ‘Deutsche Telekom’ started to use IPv6 only, if you want to use 5G SA you must use the IPv6 only APN.
Note: 5G NSA still supports their dual stack APN, public IPv6, CGNAT IPv4. But long term, it looks like, that the dual stack APN may be gone in future.
While they provide DNS64+NAT64 on their end, this works well for mobile devices and IPv6 enabled clients. But legacy IPv4 clients or retro clients won’t be able to use such connection with devices like Chateau 5G R17 ax. Or IPv6 clients cannot connect directly to IPv4 addresses, if no DNS entry is present.
While modern devices like Android, iOS or Windows 11 have buildin CLAT, it’s still a client option. It would much help, if MikroTik would support NAT64/DNS64/XL464 to provide support for such mentioned legacy ipv4 only devices on ROS instead on relying to have support on client.
My current workaround is a wireguard tunnel from ROS to a small VPS, where all IPv4 traffic is being routed through.
Looks like a good reason to avoid DT for 5GSA in Germany, certainly as a fixed mobile option. Do their competition offer dual stack?
And I’m still talking about this at conferences and writing about it on Medium:
pero mikrotik no ha sacado una respuesta oficial sobre compatibilidad de clat para el 464 XLAT y para cuando eso está disponible?
And another bump …
Anyone who thinks IPv6 only is the future needs their head checked. IPv4 is never going away because IPv6 is incredibly unintuitive, confusing and provides no benefit for small operators. Its design all but ensures IPv4 will never go away
That said, yes I want translation mechanisms. I run a IPv4 only ISP network and have NEVER, not once, ever had anyone request IPv6 in a decade. I do however have a use for it internally but surprise surprise.... with IPv4 devices ergo need a translation layer. Containerized options are not a good solution, doesn't work on MIPS hardware (have hundreds of HEX out there) nor TILE and is just jank...
Really hoping this does happen. Oh can they throw SRv6 in while they're at it? kthnx
There's an irony worth pointing out, though. 464XLAT isn't a way of keeping IPv4 alive alongside IPv6. It's the mechanism that lets an operator run an IPv6-only network and deliver IPv4 as a service over it. That's how the large mobile networks do it, including Telstra's here in Australia. SRv6 is IPv6 all the way down as well. So the wishlist in this post amounts to an IPv6-only transport with IPv4 at the edges, which is pretty much what the "IPv6-only is the future" crowd have been describing.
On "no customer has ever asked for it": no customer has ever asked for IPv4 either. They ask for the internet to work. Close to half of the traffic to the big content networks already runs over v6. Your subscribers' phones and smart TVs would use it from day one, and none of them would ever notice or say thanks. Demand for a protocol never shows up as a support ticket.
The benefit for small operators shows up on the cost side. That means not buying more v4 at tens of dollars an address, not scaling CGNAT boxes, and not keeping port-block logs to meet retention obligations. Every flow that leaves on v6 is one your CGNAT doesn't have to handle.
I'll grant "unintuitive". It's different, and a lot of the pain comes from unlearning NAT-shaped habits rather than from the protocol itself. But if this feature lands, a v4-only network could start moving to a v6-only core without throwing away the hEX fleet. That seems like the best argument for MikroTik to build it.
I use a Calyx Sprout SIM as my main internet connection on a MikroTik Chateau 5G R17. Calyx uses T-Mobile towers. Interestingly I'm in NYC rather than a rural area.
Unlike the R16, the R17 only uses IPv6 after the first boot. I get away since I use a L2TP VPN to access the internet and could move to L2TP-over-IPv6. For an average user T-Mobile US won't work with a R17.
If 464XLAT worked the R17 would work wonders with T-Mobile.
I was close to asking with my previous wireless ISP, but then I realised fibre [with IPv6] was coming on a shorter timescale then I could ever expect any action on the wireless.
So you might never find out if a customer wanted it, particularly if they perceived that finding another solution was a much more likely bet than making a request to the ISP. I doubt that I would now ever make the request for IPv6. I would just rule out ISP's who did not offer it.