Community discussions

MikroTik App
 
User avatar
andrewe02000
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 69
Joined: Tue Aug 28, 2012 6:33 am
Location: Canton, OH
Contact:

Feature Request - NAT64/DNS64 CGN

Wed Jan 22, 2020 9:39 pm

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/
 
guipoletto
Member Candidate
Member Candidate
Posts: 195
Joined: Mon Sep 19, 2011 5:31 am

Re: Feature Request - NAT64/DNS64 CGN

Thu Jan 23, 2020 6:18 am

+1!

Some less hacky CGNAT implementation (Stateless?) would be very welcome! :)
 
muetzekoeln
Member Candidate
Member Candidate
Posts: 167
Joined: Fri Jun 29, 2018 2:34 pm

Re: Feature Request - NAT64/DNS64 CGN

Mon May 04, 2020 6:33 pm

+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.
 
platini
just joined
Posts: 7
Joined: Wed Mar 07, 2018 10:19 pm

Re: Feature Request - NAT64/DNS64 CGN

Mon Apr 05, 2021 9:39 pm

+1 for NAT64. I can live with DNS64 on the powerdns recursor
 
ivantirado
just joined
Posts: 20
Joined: Sun May 12, 2019 4:58 am

Re: Feature Request - NAT64/DNS64 CGN

Mon Apr 05, 2021 11:21 pm

+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.
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.
 
lake6kn
just joined
Posts: 8
Joined: Thu Jun 17, 2021 10:25 pm
Location: Lake Constance, central Europe

Re: Feature Request - NAT64/DNS64 CGN

Thu Jun 17, 2021 10:43 pm

+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.
 
sep
newbie
Posts: 25
Joined: Thu Nov 28, 2013 2:34 pm

Re: Feature Request - NAT64/DNS64 CGN

Tue Aug 31, 2021 8:35 pm

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.
 
buraglio
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Aug 10, 2015 5:59 pm
Location: +1 (217)
Contact:

Re: Feature Request - NAT64/DNS64 CGN

Wed Sep 01, 2021 5:00 pm

+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)
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 998
Joined: Fri Jun 26, 2020 4:37 pm

Re: Feature Request - NAT64/DNS64 CGN

Wed Sep 01, 2021 5:21 pm

 
User avatar
SirPrikol
newbie
Posts: 28
Joined: Wed Oct 11, 2017 12:36 pm

Re: Feature Request - NAT64/DNS64 CGN

Tue Oct 12, 2021 7:34 pm

+1

In addition to TAYGA, another software for nat64 was found on the Internet

https://www.jool.mx/en/index.html
 
mducharme
Trainer
Trainer
Posts: 1777
Joined: Tue Jul 19, 2016 6:45 pm
Location: Vancouver, BC, Canada

Re: Feature Request - NAT64/DNS64 CGN

Wed Oct 13, 2021 4:02 am

Couldn't you run Jool in Docker now?
 
jonah1810
Frequent Visitor
Frequent Visitor
Posts: 98
Joined: Tue Jul 30, 2019 10:19 pm

Re: Feature Request - NAT64/DNS64 CGN

Tue Dec 07, 2021 8:59 pm

+1 This would be a very handy thing for us to have!
 
User avatar
ghostinthenet
newbie
Posts: 31
Joined: Sun Apr 04, 2021 1:36 pm
Location: Niagara-on-the-Lake, Canada
Contact:

Re: Feature Request - NAT64/DNS64 CGN

Sat Dec 11, 2021 4:49 pm

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.
 
marrold
Member
Member
Posts: 427
Joined: Wed Sep 04, 2013 10:45 am

Re: Feature Request - NAT64/DNS64 CGN

Tue Dec 21, 2021 1:47 pm

I'd also love to see NAT64 support, now RouterOS 7 is out it seems like a good opportunity to add it
 
kalamaja
Member Candidate
Member Candidate
Posts: 112
Joined: Wed May 23, 2018 3:13 pm

Re: Feature Request - NAT64/DNS64 CGN

Wed Jan 19, 2022 10:50 am

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.
 
OlofL
Member Candidate
Member Candidate
Posts: 113
Joined: Mon Oct 12, 2015 2:37 pm

Re: Feature Request - NAT64/DNS64 CGN

Wed Jan 19, 2022 11:31 am

Agree on all points. I would like to add that ipv6 fasttrack is also very much needed!
 
awonglk
newbie
Posts: 33
Joined: Sat Oct 31, 2015 3:43 pm

Re: Feature Request - NAT64/DNS64 CGN

Sun Jan 30, 2022 4:27 am

+1 to NAT64.
One that will help ipv6 adoption further
 
kalamaja
Member Candidate
Member Candidate
Posts: 112
Joined: Wed May 23, 2018 3:13 pm

Re: Feature Request - NAT64/DNS64 CGN

Thu Jun 09, 2022 3:05 pm

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!!
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 998
Joined: Fri Jun 26, 2020 4:37 pm

Re: Feature Request - NAT64/DNS64 CGN

Thu Jun 09, 2022 8:46 pm

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
 
platini
just joined
Posts: 7
Joined: Wed Mar 07, 2018 10:19 pm

Re: Feature Request - NAT64/DNS64 CGN

Mon Jun 20, 2022 7:01 pm

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.
 
emunt6
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Fri Feb 02, 2018 7:00 pm

Re: Feature Request - NAT64/DNS64 CGN

Sun Jul 31, 2022 2:57 pm

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.
 
jamesharr
just joined
Posts: 6
Joined: Sun Sep 19, 2021 5:18 pm

Re: Feature Request - NAT64/DNS64 CGN

Tue Nov 15, 2022 3:19 am

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.
 
buraglio
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Aug 10, 2015 5:59 pm
Location: +1 (217)
Contact:

Re: Feature Request - NAT64/DNS64 CGN

Sun Nov 20, 2022 6:54 pm

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
 
buraglio
Frequent Visitor
Frequent Visitor
Posts: 70
Joined: Mon Aug 10, 2015 5:59 pm
Location: +1 (217)
Contact:

Re: Feature Request - NAT64/DNS64 CGN

Thu Feb 16, 2023 3:28 pm

NAT64, SIIT, SIIT-DC and the translation mechanisms are still very, very important...Please consider implementation.

Use cases can be provided if requested.
 
mikey
newbie
Posts: 26
Joined: Mon Dec 20, 2021 1:11 pm

Re: Feature Request - NAT64/DNS64 CGN

Sat Apr 01, 2023 2:54 pm

+1 we need NAT64. We are in 2023 not 2003.
 
emunt6
Frequent Visitor
Frequent Visitor
Posts: 87
Joined: Fri Feb 02, 2018 7:00 pm

Re: Feature Request - NAT64/DNS64 CGN

Sat Apr 29, 2023 1:54 pm

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.)
 
lion7
just joined
Posts: 1
Joined: Mon Oct 16, 2023 11:43 pm

Re: Feature Request - NAT64/DNS64 CGN

Mon Oct 16, 2023 11:58 pm

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
 
DarkNate
Forum Veteran
Forum Veteran
Posts: 998
Joined: Fri Jun 26, 2020 4:37 pm

Re: Feature Request - NAT64/DNS64 CGN

Tue Oct 17, 2023 5:52 pm

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.

Who is online

Users browsing this forum: evellin and 22 guests