Page 1 of 1
Feature Request - NAT64/DNS64 CGN
Posted: Wed Jan 22, 2020 9:39 pm
by andrewe02000
Please implement NAT64/DNS64 persistent Carrier Grade NAT for those of us that would prefer not to buy a giant A10Networks ThunderCGN.
TAYGA is one open source implementation.
http://www.litech.org/tayga/
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Jan 23, 2020 6:18 am
by guipoletto
+1!
Some less hacky CGNAT implementation (Stateless?) would be very welcome!
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon May 04, 2020 6:33 pm
by muetzekoeln
+1
see also:
viewtopic.php?t=110925
viewtopic.php?t=42614
viewtopic.php?t=94291
Internet-Uplinks going IPv6 only. Small IoT devices stick to IPv4.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Apr 05, 2021 9:39 pm
by platini
+1 for NAT64. I can live with DNS64 on the powerdns recursor
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Apr 05, 2021 11:21 pm
by ivantirado
Have you looked at using the web-proxy for this? I haven't tried it but it seems like it can listen on both V6 and V4.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Jun 17, 2021 10:43 pm
by lake6kn
+1 for NAT64. I can live with DNS64 on the powerdns recursor
+1, NAT64 on MikroTik and DNS64 can be done by powerdns or bind
Maybe
JooL (GPLv2) can be an interesting option instead of TAYGA to implement NAT64 or SIIT.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Aug 31, 2021 8:35 pm
by sep
jool would be an awesome addition to mikrotik. it would provide essential and critical functionality that is expected of any decent isp router noways.
NAT64
SIIT
MAP-T
NPTv6
It would also provide the important 464XLAT/PLAT CPE functions, that ISP's are searching for now. CPE support is basically what is stopping most isp's from going ipv6 only on the last mile.
mikrotik + jool with proper TR069 support, and mikrotik could be the most interesting cpe in the space. instead people flash arm mikrotiks with openwrt to get access to features.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Sep 01, 2021 5:00 pm
by buraglio
+1 for NAT64, NPTv6, SIIT. Very, very useful tools for v6 transitioning and new emerging markets. Having to run a NAT64 off to the side is a painful and operationally expensive measure (not to mention the capital cost associated with the commercial options)
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Sep 01, 2021 5:21 pm
by DarkNate
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Oct 12, 2021 7:34 pm
by SirPrikol
+1
In addition to TAYGA, another software for nat64 was found on the Internet
https://www.jool.mx/en/index.html
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Oct 13, 2021 4:02 am
by mducharme
Couldn't you run Jool in Docker now?
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Dec 07, 2021 8:59 pm
by jonah1810
+1 This would be a very handy thing for us to have!
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sat Dec 11, 2021 4:49 pm
by ghostinthenet
Couldn't you run Jool in Docker now?
Jool uses kernel modules to do its magic, so it’s unlikely. Tayga might be doable in a container.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Dec 21, 2021 1:47 pm
by marrold
I'd also love to see NAT64 support, now RouterOS 7 is out it seems like a good opportunity to add it
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Jan 19, 2022 10:50 am
by kalamaja
Now that v7.1 is in stable with new IPv6 stack and IPv6 NAT functionality, could you please add also
NAT64 functionality?
- Movement to NAT64 is clear as Apple has had requirement for this since 2018 for all apps. No need for more complex solutions, these can come later.
- It would help much for re-architecting networks as IPv6 becomes mandatory in different countries.
- It would make it possible to create and manage IPv6-only networks and save from double work of managing dual-stack.
- AWS also recently made big enhancements to it's products to enable IPv6-only networks and services and also added NAT64 functionality to it's gateways.
- As Mikrotik currently supports only DHCPv6-PD and SLAAC, some solution is needed for more meaningful IPv6 DNS-management.
- DNS64 service is already available from CloudFlare and Google, no hurry with this.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Jan 19, 2022 11:31 am
by OlofL
Agree on all points. I would like to add that ipv6 fasttrack is also very much needed!
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sun Jan 30, 2022 4:27 am
by awonglk
+1 to NAT64.
One that will help ipv6 adoption further
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Jun 09, 2022 3:05 pm
by kalamaja
Now that there's new IPv6 stack in place and also NATing features are progressing, how long to also get NATing from IPv6 to IPv4? Very much needed!!
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Jun 09, 2022 8:46 pm
by DarkNate
IPv6 NAT is NAT66 and should be avoided completely. The point of IPv6 is to restore end-to-end principle.
NAT64 and it's better sibling 464xlat are not the same thing as NAT66 aka IPv6 killer:
https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/
Some people must've learnt network engineering from the trash can... Smh
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Jun 20, 2022 7:01 pm
by platini
Kind off topic but still useful to answer
There are some cases were NAT66 is useful. Particularly in SoHo enviroments where your service providers assign dynamic IAPDs. In that case. when you can have internal servers and particularly with internal DNS mappings you dont want to have your IP addresses (prefix) suddenly changing and messing up your communications. Been able to always use fd00::/x and been able to address translate 1:1 to the prefix given by your ISP can have a benefits in simplicity. Of course you can say that you can dual home internal servers with private and public addresses too.
Also there are some benefits on firewall rule managements related to those ipaddresses not chaging.
My 2 cents.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sun Jul 31, 2022 2:57 pm
by emunt6
Is there any update on this ?
I'm looking for something "usable", but I couldn't find any.
I tried "jool", but not suited for my task, prefer something like "integrated" - not something like "kernel hacks/mods".
i'm looking for something simple, example:
iptables -t nat -A PREROUTING -d <ipv4> -j DNAT <ipv6>
iptables -t nat -A POSTROUTING -s <ipv6> -j SNAT <ipv4>
I'm looking for NAT66 with CGNAT ( IPV4 ) solution.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Nov 15, 2022 3:19 am
by jamesharr
i'm looking for something simple, example:
iptables -t nat -A PREROUTING -d <ipv4> -j DNAT <ipv6>
iptables -t nat -A POSTROUTING -s <ipv6> -j SNAT <ipv4>
For what it's worth, when you translate between IP versions, then both source and destination address have to be translated in some way (usually in the same rule). IE if have a packet coming from 2001:db8:aa::1 -> 2001:db8:ff::1 port 80 and I want that to be translated to go to -> 192.0.2.1 port 80, then what should my source address be? The original source IPv6 address can't be used.
It's more complicated than just adding another translation. Especially when you look at different strategies for doing the translation. Going from IPv4 to IPv6 gives you the chance to do it in an entirely stateless way as long as you don't expect the IPv4 world to be able to address the entire IPv6 world, but only a small /96 chunk of it.
ipspace.net has a presentation on an ipv6 only datacenter design that uses this. In most other cases you can't do nat64 or nat46 in an entirely stateless way.
I guess my point is that in this thread people are asking for a number of different solutions. Sometimes the use case presented is clear and sometimes it's not. What kind of network design does a feature like this enable for you? It's easier for the developers if they have a strong use case.
I think pretty much everyone here has a good use case, but some need a more clear description of what they'll get out of their network by having a specific feature.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sun Nov 20, 2022 6:54 pm
by buraglio
There are use cases for NAT66, especially with the absence of NPTv6, and with the dismal state of IPv6-multihoming without BGP. I have used it in rare cases with success - it solved a niche problem. The end to end principle is a lofty goal, and I support it 100%, but making the perfect the enemy of the good is a slippery slope as idealism rarely works out. That said, NAT64 is very much needed for transitional states, and to enable the PLAT part of 464XLAT as per rfc6877 (i.e. you don't really get 464XLAT without NAT64 per rfc6146), so the sooner we get it, the better. FWIW, I do agree that 464XLAT is superior because it allows for but does not require DNS64, which NAT64 alone (i.e. just PLAT) does require.
IPv6 NAT is NAT66 and should be avoided completely. The point of IPv6 is to restore end-to-end principle.
NAT64 and it's better sibling 464xlat are not the same thing as NAT66 aka IPv6 killer:
https://blog.apnic.net/2018/02/02/nat66-good-bad-ugly/
Some people must've learnt network engineering from the trash can... Smh
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Feb 16, 2023 3:28 pm
by buraglio
NAT64, SIIT, SIIT-DC and the translation mechanisms are still very, very important...Please consider implementation.
Use cases can be provided if requested.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sat Apr 01, 2023 2:54 pm
by mikey
+1 we need NAT64. We are in 2023 not 2003.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sat Apr 29, 2023 1:54 pm
by emunt6
i'm looking for something simple, example:
iptables -t nat -A PREROUTING -d <ipv4> -j DNAT <ipv6>
iptables -t nat -A POSTROUTING -s <ipv6> -j SNAT <ipv4>
For what it's worth, when you translate between IP versions, then both source and destination address have to be translated in some way (usually in the same rule). IE if have a packet coming from 2001:db8:aa::1 -> 2001:db8:ff::1 port 80 and I want that to be translated to go to -> 192.0.2.1 port 80, then what should my source address be? The original source IPv6 address can't be used.
It's more complicated than just adding another translation. Especially when you look at different strategies for doing the translation. Going from IPv4 to IPv6 gives you the chance to do it in an entirely stateless way as long as you don't expect the IPv4 world to be able to address the entire IPv6 world, but only a small /96 chunk of it.
ipspace.net has a presentation on an ipv6 only datacenter design that uses this. In most other cases you can't do nat64 or nat46 in an entirely stateless way.
I guess my point is that in this thread people are asking for a number of different solutions. Sometimes the use case presented is clear and sometimes it's not. What kind of network design does a feature like this enable for you? It's easier for the developers if they have a strong use case.
I think pretty much everyone here has a good use case, but some need a more clear description of what they'll get out of their network by having a specific feature.
The IPV6 -> IPV4 mapping would use the CGNAT subnet range ( 100.64.0.0/10 ) as source , overlapping is no problem,
NAT log will hold the "true" IPV6 address from the translation.
This is currently only solvable by using some kind of proxy-application which has both IPV4 and IPV6 address.
Linux based packet-filters can't do it. (Its very sad and disappointing.)
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Oct 16, 2023 11:58 pm
by lion7
I have managed to get Tayga running as a container on my Mikrotik device.
So far it's working just fine out of the box (I only had to cross-compile it to arm, no code changes needed).
My config / steps:
# Tested on a RB4011iGS+5HacQ2HnD running RouterOS 7.11.2
# Note: replace the example '2001:db8:0:ffff/64' IPv6 prefix in this script
# with an unused, public /64 IPv6 prefix that is part of your own assigned range.
# Start with enabling container mode by following the steps at
# https://help.mikrotik.com/docs/display/ROS/Container
# Create interfaces
/interface bridge add name=containers
/interface bridge port add bridge=containers interface=veth1
/interface veth add address=172.17.0.2/24,2001:db8:0:ffff::2/64 gateway=172.17.0.1 gateway6=2001:db8:0:ffff::1 name=veth1
# Setup IPv4 and IPv6 addresses
/ip address add address=172.17.0.1/24 interface=containers
/ipv6 address add address=2001:db8:0:ffff::1 advertise=no interface=containers
# Setup the necessary routes
/ip route add dst-address=172.18.0.128/25 gateway=172.17.0.2
/ipv6 route add dst-address=64:ff9b::/96 gateway=2001:db8:0:ffff::2
# Setup NAT for Tayga's private IPv4 range
/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24
# Setup container config
/container config set registry-url=https://ghcr.io tmpdir=/images
/container envs add key=TAYGA_CONF_IPV4_ADDR name=tayga value=172.17.0.2
/container envs add key=TAYGA_CONF_DYNAMIC_POOL name=tayga value=172.18.0.128/25
/container envs add key=TAYGA_CONF_PREFIX name=tayga value=64:ff9b::/96
/container envs add key=TAYGA_IPV6_ADDR name=tayga value=2001:db8:0:ffff::2
# Create the container
/container add remote-image=ghcr.io/lion7/docker-tayga:linux-arm envlist=tayga interface=veth1 logging=yes start-on-boot=yes
# Optional: configure Google's and CloudFlare's public DNS64 servers
/ip dns set servers=2001:4860:4860::64,2606:4700:4700::64
Some sources with explanation how this works:
http://www.litech.org/tayga/
https://github.com/lion7/docker-tayga/b ... /README.md
https://ipv6-first-guide.hillbrecht.de/ ... with_tayga
Re: Feature Request - NAT64/DNS64 CGN
Posted: Tue Oct 17, 2023 5:52 pm
by DarkNate
The problem with this is, it does not scale, not usable for production pumping 100Gbps traffic per nanosecond. MikroTik needs to add proper CLAT, proper 464xlat and NAT64.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu May 02, 2024 8:26 pm
by GabrielaWAF
+1 nat64/nat46
Re: Feature Request - NAT64/DNS64 CGN
Posted: Thu Aug 01, 2024 8:58 am
by jcsm1998
+1
about to get our asn and ipv6 pool, about to test PPPoe dual stack
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Aug 19, 2024 11:42 am
by minfrin
Would be great to have the IPv4 holdouts not hold the rest of us to ransom.
+1
Re: Feature Request - NAT64/DNS64 CGN
Posted: Wed Aug 21, 2024 12:09 am
by coffeebreak007
+1 nat64/nat46
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sat Sep 07, 2024 10:28 pm
by Damago1
+1` transition mechanisms will be more and more important. We are planning to migrate internal company structure to IPv6. And we will have to decide if to drop Mikrotik or to use some not elegant solution like extra server which is a pain becouse we manged to get rid of servers in many locations.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Sat Oct 26, 2024 6:06 pm
by lbilbao
+1 please!
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Oct 28, 2024 12:39 pm
by moep
+1
IPv6 features are sorely missing right now and transitional method like this are required for many.
At best they should implement 464XLAT, which is the natural extension of NAT64/DNS64.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Mon Oct 28, 2024 3:32 pm
by Larsa
PLAT or CLAT, which runs on the end user’s device, or ROS CLAT for centralized translation, tunneling, or other purposes?
FYI, most pure IPv6 ISPs support MAP-E (RFC 7597), which can be managed by IPIPv6 in Mikrotik ROS.
Re: Feature Request - NAT64/DNS64 CGN
Posted: Fri Nov 01, 2024 1:28 pm
by baskinio2
+1, is very necessary.