Hi,

Is the inclusion of NAT64 and DNS64 support in the Roadmap for RouterOS v5?
I think this would be a great help for ISPs wishing to do a rapid deployment of pure IPv6 without breaking access to IPv4 resources.

dns in RouterOS supports IPv6 address resolving, if you set IPv6 addresses
IPv6 does not have NAT as it is in IPv4

NAT64? you mean, kind of 4-to-6 tunnel, so that IPv4 users can access IPv6 resources?..

if yes - then joining the question, although I'm not familiar with ipv6 yet... =)

NAT64 is for scenarioes where you do not allocate a v4 address to the customer, and instead use a gateway to fetch v4 resources on the internet that is then translated back into v6.

Opensource implementation

Cisco's description

The two are different. 6to4 tunnels the original packet, NAT64 is AFT (address family translation).

NAT64 is a method of giving IPv6 only clients access to IPv4 resources.
http://tools.ietf.org/html/draft-bagnul ... e-nat64-00

There are a few opensource implementations of this, and I've tested http://ecdysis.viagenie.ca/ on a linux gateway, and it works fine.

Its only really useful with DNS64, which is an A record to AAAA "translator" for DNS queries from IPv6 clients.

well, there should be no problem with RouterOS resolving AAAA records.

Yes, I know that RouterOS works with IPv6 accessing IPv6 resources, and IPv4 accessing IPv4 resources, and dual-stack.

But DNS64 is a helper for NAT64.

NAT64 essentially takes IPv6 requests for IPv4 resources, and maps the IPv4 resources into IPv6 space. Then DNS64 assists in this process by taking A records, and coverting them to AAAA responses in the "mapped" IPv6 space.

This allows Pure IPv6 clients access to IPv4 resources.

well, there should be no problem with RouterOS resolving AAAA records.

Sorry to inform, but apparently there are issues with RouterOS resolving AAAA records:
http://forum.mikrotik.com/viewtopic.php ... 12#p211212

we are need it NAT64 ,
http://blog.go6.net/?p=210

waiting for NAT64 on Mikrotik

NAT64 and DNS64 is something thats going to be needed on a large scale when the last v4 ranges are handed out, Currently the only applications floating around are not production ready.

We do really need a way of running pure v6 inside our entire network and only touching v4 on the edge for net connection, RIR's are tightening up their policies on handing out v4 whilst handing out v6 space like its candy. Today if we had to deploy a pure v6 network we couldnt, Basic things like v6 PPPoE are only just coming into a BETA release that wont be stable for a while, We would have to use v4 space and 6to4 tunnels to provide v6 connections which ties up v4 space

NAT64 is in use via Cisco with T-Mobiles mobile v6 trials and is fast becoming the primary transition method, MT's going to have to polish it's v6 stack quite a bit and perhaps even backport some of the critical v6 features like v6 PPPoE and Dhcp6 back to 4.x

mikrotik team , when your ROS support NAT64 ???

Were you seriously expecting a road map in two days over a weekend? Shouting the same thing over and over isn't going to achieve anything.

hha haa haa

i know that ...

Well, since I do think that eventually we will completely run out of IPv4 Resources and will have to go IPv6 only,
any means to let IPv6-only users access the rest of the internet would be very much appreciated

so yes, please implement NAT64 and DNS64

+1 for NAT64 support!

go go go ... NAT64

NAT64 YES!!! A full native IPv6 network accessing IPv4 resources via NAT64 on Mikrotik ROS is all we need nowdays!!!

NAT64 YES!!! A full native IPv6 network accessing IPv4 resources via NAT64 on Mikrotik ROS is all we need nowdays!!!

+1

We must move forward with IPv6!!!

As of this date only 5 percent of IPv4 remains which equals 278 days tell exhaustion:

http://www.potaroo.net/tools/ipv4/

+1 from me too.

I don't vote for NAT64 for one simple reason.
We don't actually need it, at least not yet, I think there are higher priorities.
I would like to see Mikrotik complete the IPv6 stack for things such as Hotspot_v6, DHCPv6, Winbox, ssh etc.

NAT64 / DNS 64 allows clients to be setup in a single stack IPv6 only implementation.
I don't see any real reason why you would want to be so fast to switch form IPv4 to IPv6 overnight without running dual stack as an intermediate step.

I am in favour of IPv6 + NAT44 or IPv6 + NAT444 depending on then network size.

Clients can be allocated a Private IPv4 address (such as is done on corporate networks) + a public IPv6 address.
Servers would need to be allocated Public IPv4 + IPv6 native or IPv4 + 6to4 IPv6 addresses.
Since there is a lot more clients than servers the client problem needs to be addressed first.

NAT64 / DNS64 is a way to get rid of the IPv4 stack on the client side; and it's not the only way of acheiving this.
DS Lite AP and NAT IVI are alternate methods and of the three I actual prefer the IVI method used for the last few years by CERTNET in China.

Also, I would like to see a stable implementation of NAT64 on Linux Netfilter that Mikrotik can base their work on.
Does anyone know if this is available or has tested this?

I don't vote for NAT64 for one simple reason.
We don't actually need it, at least not yet, I think there are higher priorities.

I agree with you, NAT64/DSN64 will not be indispensable until the address space is exhausted, in the meantime it it more important to have full support for dual-stack features (DHCPv6, prefix delegation, prefix labels, services over IPv6, etc..).

However it has to be ready (and tested) by the time the address space is exhausted otherwise we are in deep s....

This is MT, If they start it in the next 3-4 months it'll only be stable by v4 exhaustion

Is there a working implementation of this on Linux or *BSD that we can play with?
Is there an RFC?
Or is this just a Cisco Proprietory thing?

It's a work in progress.
http://tools.ietf.org/html/draft-ietf-b ... tateful-12

Is there a working implementation of this on Linux or *BSD that we can play with?
Is there an RFC?
Or is this just a Cisco Proprietory thing?

Its an spec, Cisco in CGv6, MS is UAG Direct Access and linux is Ecdysis.

Linux is a PoC code, Only one DNS request at a time etc

However it has to be ready (and tested) by the time the address space is exhausted otherwise we are in deep s....

Why can't you run Dual Stack?

Dual stacking only works when you have v4 space to dual stack with, If you dual stack with private v4 space you run into double nat issues, NAT64 is a way around this for some but not all applications

Dual stacking only works when you have v4 space to dual stack with, If you dual stack with private v4 space you run into double nat issues, NAT64 is a way around this for some but not all applications

What problems does it solve? I don't see how it's any better, and considering it's not well tested I expect it would in fact be worse!

Double-Natting in a dual stack private v4 setup. I'd hate to be an ISP running that and handling client requests for port forwards!

I don't see how it solves that problem. It's not like there is a NAT46 and DNS46 as well.


We are already an ISP doing Double NAT and we want to get an IPv6 Stack to allow customers to support incoming connections more easily. I don't see how NAT64 can help us. Currently customers have to use UPNP to get an incoming connection. Some applications support UDP hole punching (eg skype) and that seems to work just as well through double NAT as through single NAT.

Whether hole punching works or not has more to do with how many users there are than how many layers of NAT.

I see DNS64/NAT64 as a way of getting rid of Dual Stack.
It means that a client can have a single IPv6 Stack and connect to IPv6 directly and IPv4 through NAT.
Incoming connections must be made to IPv6 address. Outbound connections (to IPv4 anyway) must use the provided DNS.

If you have dual stack Public IPv6 and Private IPv4 you end up acheiving exactly the same result.
Difference is
1. That the NAT44 or NAT444 is tried and tested
2. That there are two stacks to contend with.

As I see it, the only real benefit is NAT64/DNS64 is the saving of having a single IP stack.

Why can't you run Dual Stack?

When the address space is exhausted what IPv4 address would you use? There will not be any even if you want to NAT everything on a single one.

And no, double NAT is neither acceptable nor legal here in Italy for ISPs.

Bye,

double NAT is neither acceptable nor legal here in Italy for ISPs.

You can legislate all you like, but once there is no more IPv4 space to go around thats the end of the game.

I still don't see how NAT64 solves this problem especially if the ISP is not allowed to use NAT.

It's a work in progress.
http://tools.ietf.org/html/draft-ietf-b ... tateful-12

I think I like this one better.
http://tools.ietf.org/html/draft-xli-behave-ivi-07
Translates both ways not just IPv6 to IPv4.
Stateless, so no NAT timeouts.
Has been in production for some time at CERTNET in China.
Download Linux implementation http://linux.ivi2.org/impl/

double NAT is neither acceptable nor legal here in Italy for ISPs.

You can legislate all you like, but once there is no more IPv4 space to go around thats the end of the game.

I still don't see how NAT64 solves this problem especially if the ISP is not allowed to use NAT.

Because there is no port NAT only address NAT, Its not like what your used to, v6 address port 1000 maps to v4 address port 1000 but then the next connection on port 2000 can map to another v4 address, Its not port natting where you have a couple of hundred users behind a single v4 address and once someone takes port 1000 nobody else can use it, with NAT64 if another user wants to use port 1000 it will map to another v4 address

double NAT is neither acceptable nor legal here in Italy for ISPs.

You can legislate all you like, but once there is no more IPv4 space to go around thats the end of the game.

I still don't see how NAT64 solves this problem especially if the ISP is not allowed to use NAT.

Because there is no port NAT only address NAT, Its not like what your used to, v6 address port 1000 maps to v4 address port 1000 but then the next connection on port 2000 can map to another v4 address, Its not port natting where you have a couple of hundred users behind a single v4 address and once someone takes port 1000 nobody else can use it, with NAT64 if another user wants to use port 1000 it will map to another v4 address

What a load on nonsense. If NAT64 worked like that it would be a huge waste of IPv4 address space
and besides,
if you wanted NAT44 to work like that then it's pretty easy to do in iptables or ROS.

The IPv4 address pool is a set of IPv4 addresses, normally a prefix
assigned by the local administrator. Since IPv4 address space is a
scarce resource, the IPv4 address pool is small and typically not
sufficient to establish permanent one-to-one mappings with IPv6
addresses. So, except for the static/manually created ones, mappings
using the IPv4 address pool will be created and released dynamically.
Moreover, because of the IPv4 address scarcity, the usual practice
for NAT64 is likely to be the binding of IPv6 transport addresses
into IPv4 transport addresses, instead of IPv6 addresses into IPv4
addresses directly, enabling a higher utilization of the limited IPv4
address pool. This implies that NAT64 performs both address and port
translation.

What a load on nonsense. If NAT64 worked like that it would be a huge waste of IPv4 address space
and besides,
if you wanted NAT44 to work like that then it's pretty easy to do in iptables or ROS.

The IPv4 address pool is a set of IPv4 addresses, normally a prefix
assigned by the local administrator. Since IPv4 address space is a
scarce resource, the IPv4 address pool is small and typically not
sufficient to establish permanent one-to-one mappings with IPv6
addresses. So, except for the static/manually created ones, mappings
using the IPv4 address pool will be created and released dynamically.
Moreover, because of the IPv4 address scarcity, the usual practice
for NAT64 is likely to be the binding of IPv6 transport addresses
into IPv4 transport addresses, instead of IPv6 addresses into IPv4
addresses directly, enabling a higher utilization of the limited IPv4
address pool. This implies that NAT64 performs both address and port
translation.

I suggest you gain access to NAT64 devices a v6 client accessing v4 space will use the same port on v4 that the v6 address is attempting to use thus its normal mode is only to address translate and will port translate only when the v4 pool assigned to the NAT64 box is exhausted for the v6 side port

I suggest you gain access to NAT64 devices a v6 client accessing v4 space will use the same port on v4 that the v6 address is attempting to use thus its normal mode is only to address translate and will port translate only when the v4 pool assigned to the NAT64 box is exhausted for the v6 side port

NAT44 will also keep the port the same if it can. However it will always change the port in preference to changing the address. The reason for this is to do with the RELATED state. Firewall hole punching requires the IP Addresses to match to work, If you start changing the address while keeping the port the same, then hole punching will cease to work and it will break heaps of applications.

See http://en.wikipedia.org/wiki/Hole_punching for more information.

You dont need hole punching unless the application your attempting to use sends the IP contact info within the packet i.e SIP/RTP/FTP etc

NAT44 is not a solution that helps us, NAT64 does it and much more like allowing pure v6 CPE users to access the v4 world, But perhaps this is a tech that should be kept in the big boys league of Cisco/Juniper as those that will actually run into the NAT44 issues will have the money to buy them

You dont need hole punching unless the application your attempting to use sends the IP contact info within the packet i.e SIP/RTP/FTP etc

I think you're confusing Hole Punching with ALG (Application Layer Gateway) kernel modules.

allowing pure v6 CPE users to access the v4 world, But perhaps this is a tech that should be kept in the big boys league of Cisco/Juniper as those that will actually run into the NAT44 issues will have the money to buy them

Finally we actually agree on something. Although I was not aware that Juniper had a NAT64 offering!

You dont need hole punching unless the application your attempting to use sends the IP contact info within the packet i.e SIP/RTP/FTP etc

I think you're confusing Hole Punching with ALG (Application Layer Gateway) kernel modules.

Maybe I am Its late where I am

Can anyone who has a NAT64/DNS64 setup try a couple of tests for me.

http://66.102.11.104/

And how well does skype work?

And how well does skype work?

Or MSN ?

Has anyone had a look at this?

http://www.isc.org/software/aftr

AFTR (Address Family Transition Router) is the latest product in ISC's family of open source Internet infrastructure products. Developed in concert with Comcast, AFTR 1.0 is intended to ease the transition from IPv4 to IPv6 by allowing legacy IPv4 end sites such as home PCs to interact with IPv4 content providers and services over an IPv6 carrier infrastructure. As with ISC's other products, as the Dual Stack Lite protocol evolves, AFTR will strive to remain an up to date reference implementation as well as a robust enterprise grade router technology.

I've added NAT64 and DNS64 to the unofficial Feature Request page.

http://wiki.mikrotik.com/wiki/RouterBOA ... re_Request

Feel free to add your votes and move it up the list

I've added NAT64 and DNS64 to the unofficial Feature Request page.

http://wiki.mikrotik.com/wiki/RouterBOA ... re_Request

Feel free to add your votes and move it up the list

Isn't that list just for "hardware"? Thought NAT64 was a "software" implementation... Although Ive seen other soft ones in there. *bump*

For software requests, here is the current wiki page:
http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests

Good Point.

I see its on that page too. I've added my name to the list.

I am fully supporting idea of NAT64.
Until dual stack is active, administrator will keep forcing IPv4 due its simplicity and short form of ip address that is easy to remember.
Only way to accelerate improvement process by transferring completely to IPv6 is to transfer small networks and become prepared for WAN IPv6 transfer.

We would not be ready do deploy IPv6 until we give up IPv4. This is legacy rule !

HI, Just returned from the IPv6 Forum Conference in Melbourne, Australia and the current advice is.

Dual Stack where you can.
Tunnel where you can't
Use NAT if you have a gun to your head.

What conference was that? Most SIG's are saying Translation like NAT64 is the best path since Dual-Stack only works when you have v4 space left to hand out, then its onto Dual-Stack with NAT444 on the v4 side which as you've pointed out - Would need a gun to your head

I would think that NAT444 + Dual Stack would work much better than NAT64/DNS64.
If you would need a gun to your head to do NAT444 then you'll need an even bigger gun to do NAT64.

If you think NAT64 will solve any of your problems think again.
Heaps of stuff doesn't work with NAT64.
About the only thing broken with NAT444 is UPnP, and that can be resolved with Manual Port Forwarding.

Do you really think manual port forwarding at the ISP level is ever going to work?? I doubt we'll see NAT64 in ROS but the big players are deploying it, It will likely end up another transition step after large scale ISP's find that NAT444 is just not worth the hassle.

Have you actually used NAT64 before? Its quite nice, There is a liveCD floating around, Very fun turning off v4 on your computer and having everything keep working

Do you really think manual port forwarding at the ISP level is ever going to work?? I doubt we'll see NAT64 in ROS but the big players are deploying it, It will likely end up another transition step after large scale ISP's find that NAT444 is just not worth the hassle.

Have you actually used NAT64 before? Its quite nice, There is a liveCD floating around, Very fun turning off v4 on your computer and having everything keep working

Did you try it with Windows XP? Mac OS X?

When you say everything keeps working? What did you test? I'm sure outbound connections would work but what about P2P applications?
Skype?
What about http://66.102.11.104/
Or inbound connections can you remote desktop to an XP computer through NAT64?
How do inbound connections work from the IPv4 Internet?

I can see some benefit of NAT64 for some of the Mobile phone providers in countries like India and China that are turning on new mobile devices at a staggering rate. Some newer mobile devices do support IPv6 quite well and they need access to legacy web servers on IPv4 and that is a good reason to use NAT64, so yes I agree the big players will role it out, but I doubt they will use RouterOS.

Do you really think manual port forwarding at the ISP level is ever going to work?? I doubt we'll see NAT64 in ROS but the big players are deploying it, It will likely end up another transition step after large scale ISP's find that NAT444 is just not worth the hassle.

Have you actually used NAT64 before? Its quite nice, There is a liveCD floating around, Very fun turning off v4 on your computer and having everything keep working

Did you try it with Windows XP? Mac OS X?

When you say everything keeps working? What did you test? I'm sure outbound connections would work but what about P2P applications?
Skype?
What about http://66.102.11.104/
Or inbound connections can you remote desktop to an XP computer through NAT64?
How do inbound connections work from the IPv4 Internet?

Web browsing worked fine, never ran into an issue. Skype worked for voice but I didnt try video (Never had a need) Existing NAT-busting methods used in alot of software works fine but will run into issues in a NAT444 setup. SIP and FTP had issues due to IP info carried inside the application level data. Some form of ALG ala NAT-PT will help with this

NAT444 is already in place by a lot of MT users, I believe our resident forum troll here doesnt supply his clients with a public v4 so ROS demand for it will be low. The skill needed to put in place and debug something as complex as NAT64 will rule out most ROS users. I really dont think it will be worth MT's time to put something like this in place, NAT64 is a small bridge for those of us who will deploy v6 before the crunch, NAT444 will be clung onto by users who dont know how or who wont deploy v6

Web browsing worked fine, never ran into an issue. Skype worked for voice but I didnt try video (Never had a need) Existing NAT-busting methods used in alot of software works fine but will run into issues in a NAT444 setup. SIP and FTP had issues due to IP info carried inside the application level data. Some form of ALG ala NAT-PT will help with this

Sorry to keep on about this, but what OS did you try this on?

XP SP3

If i may jump into conversation.
From what i notices MikroTik really loves when feature description is set in stone - so there are actual "Internet Standard".

From what i was able to find on this topic is:

a) http://tools.ietf.org/id/draft-bagnulo- ... t64-03.txt
"This Internet-Draft will expire on September 8, 2009"

b) http://tools.ietf.org/html/draft-ietf-b ... tateful-00
"This Internet-Draft will expire on January 5, 2010"

So, it is not even "Proposed Standard" not talking about "Draft Standard" and "Internet Standard"...

IF i'm missing something, please, provide me proper links

There is a liveCD floating around

Ok, so I found the CD, downloaded it, had a play. Read the specs.,

It's really only designed to allow IP6 only clients to access IPv4 legacy servers.
It's not meant for Ipv4 to Ipv6 connections and not designed to do P2P applications.

It might allow for Hole Punching in the way that firewalls allow reverse connections in RELATED state, but that's all.

So once they get the ALG's written, it will catch up to where NAT44 is now and you'll be able to move on from Dual Stack to IPv6 Only Stack.

Its PoC code, Meant as a simple demo. I'm not even sure the linux code is being actively worked on. Anyway this topic is pointless as MT will never put something like NAT64 into ROS and alot of people around here already do NAT444.

If i may jump into conversation.
From what i notices MikroTik really loves when feature description is set in stone - so there are actual "Internet Standard".

From what i was able to find on this topic is:

a) http://tools.ietf.org/id/draft-bagnulo- ... t64-03.txt
"This Internet-Draft will expire on September 8, 2009"

b) http://tools.ietf.org/html/draft-ietf-b ... tateful-00

"This Internet-Draft will expire on January 5, 2010"

So, it is not even "Proposed Standard" not talking about "Draft Standard" and "Internet Standard"...

IF i'm missing something, please, provide me proper links

http://tools.ietf.org/html/rfc6146

aside NAT64 relevant things - 6877 https://tools.ietf.org/html/rfc6877 was apprently common as say wiukd 6rd, DS, DS-lite or other things from that list https://en.wikipedia.org/wiki/IPv6_tran ... mechanisms
(in which - ANY thing make sense and important).
from proprietary stuff among it perhaps MAP by CISCO was imprtant(rest, including ommited from article - not so much, perhaps. or even known at all).
fron "unemplemented yet" not finalised things i personally would care about IPv6 to IPv6 NAT(some would say "it make no sense", but sadly it is. already

v6 should be end to end connection. But if mikrotik released this feature that should be +10.

i second this, need NAT64 support.

v6 should be end to end connection. But if mikrotik released this feature that should be +10.

not really. it "should" not.
and for that reasons both 4-to-6, 4-to-6 and even 6-to-6 NAT exist, just like 4-to-4 before. but implementation yet sporadic and incomplete, yet(to use "straight away/now").

Google just made a public DNS64 server, NAT64 gateway is more relevant then ever.
https://developers.google.com/speed/pub ... docs/dns64

Here's to hoping IPv6 on Mikrotik will take a leap forward and become a more complete solution. With the IPv6 certification now available from Mikrotik, I'm crossing fingers they will press forward with an IPv6 implementation that is more usable.

Google just made a public DNS64 server, NAT64 gateway is more relevant then ever.
https://developers.google.com/speed/pub ... docs/dns64

We really need NAT64. And also IPv6 NAT (not IPv6 masqureade, just NAT).

Is anything new about NAT64? Maybe some new RouterOS version?

If not, maybe this could be useful (at least for testing): http://www.internetsociety.org/deploy36 ... in-go6lab/

Dear MT, Please consider NAT64!

Bump ........
Is there anything new on this? As IPV4 addresses get in shorter demand?

Hi,

Any progress with nat64 and dns64?

Now in russia is actual, our internet regulator starting blocking sitews by IPv6 ...

+1.

As I see from the forum, request for NAT64 support has been up for last 9 years already. Maybe the time wasn't right then, but it definitely is now.

Adding NAT64 support would not be about NATing IPv6, but NATing the IPv4 hell out of the way to get rid of it faster, so it would definetly be engineering for the future.

Some arguments for NAT64:
1) All the main content providers and CDNs have switched over to IPv6 already, so NAT64 would be declining, not increasing service
2) DNS64 for Well-Known Prefix 64:ff9b::/96 is offered by both Google and CloudFlare, so no actual need for own DNS64 server, but no problem to configure it for Bind or others
3) AppStores have had compatibility requirements for IPv6-only and NAT64 networks for several years now, so there's no actual problems with recent apps and applications. For old applications there are other mechanisms available as NAT64 is subset of XLAT464.
4) There will never be the time when all the internet services support IPv6, so we should NOT wait endlessly but start getting rid of IPv4 at our networks NOW.

At the moment stateless NAT64 takes two routing lines in edge router and external NAT64 device to get rid of IPv4. If Mikrotik would support NAT64, then it would take about two lines without the need for external NAT64 translation device.

Let NAT64 become a new NAT44!

Skype has been mentioned as a service that does not work in NAT64 enviroment, but it definitely works now.

Feature Request:

I wish Mikrotik would have NAT64. Im building a large wireless ISP for potential millions of users and IPv4 is something we would like to avoid completely and go directly to IPv6 only (there are no addresses available anyway). Doing NAT44 instead means a lot of more work to give out private IP addresses to every customer as well. This complicates things. We need to supply IPv6 anyway. So having only one infrastructure to deal with makes life simpler. If Mikrotik doesn't do it, we need to put some Linux servers for that aside. The DNS64 part is easy (just a bind9 option).

I think MTik is not ready for ipv6 so isn’t the world. My ISP is not offering ipv6 and my hope is that ipv8 is ready before ipv6 is largely used.
The absence of NATing in ipv6 is my main concern.

I'm not sure on which world you are living in but in the places I am active (Europe & Africa), IPv6 is available everywhere on every backbone. And frankly if you start any ISP business now, you must be lucky if you can even get a /22 IPv4 range. In Europe you can't. IPv4 addresses are traded at 25€ per IP by now (used to be 7€ a couple of years back). So it is clear that IPv6 has arrive in the mainstream. There is no other option anymore. If you still try to stick with IPv4 only, you shoot yourself into your foot.

NAT64 is a solution to build on top of IPv6 a clean infrastructure, while having backwards compatibility to the old broken world.
IPv6 is here to stay. IPv4 is here to disappear sometimes in the future. And that future is not so far away.

If I'm building a new network from scratch, I rather use NAT64 at the edge to be backwards compatible to the old world, than to plan dual stack + NAT44 everywhere. It adds complexity in routing (two routing protocols instead of one), address management (having to deal with all the private IP address space), potential conflicts (customers might also use the same IP ranges in their LAN), memory consumption (more routes), bandwidth (more routing messages), cpu load.

In a small application this might not matter but if you plan to serve millions of users, this does have a big effect.

We need NAT64.

(DNS64 can be used from Google)

Why is not implemented yet

Wow 9 years in the making !

+1 that need NAT64

+1 that need NAT64

https://developers.google.com/speed/pub ... docs/dns64

To take the next step of the transition to IPv6 and deploy IPv6-only networks, network operators must still preserve access to IPv4-only networks and services. There are several transition mechanisms to provide IPv6 access to IPv4; an increasingly popular choice with many network operators is NAT64. Using a NAT64 gateway with IPv4-IPv6 translation capability lets IPv6-only clients connect to IPv4-only services via synthetic IPv6 addresses starting with a prefix that routes them to the NAT64 gateway.

DNS64 is a DNS service that returns AAAA records with these synthetic IPv6 addresses for IPv4-only destinations (with A but not AAAA records in the DNS). This lets IPv6-only clients use NAT64 gateways without any other configuration. Google Public DNS64 provides DNS64 as a global service using the reserved NAT64 prefix 64:ff9b::/96.

It would be nice if my Hex router had the "NAT64" voodoo.

+1 For NAT64
Currently using this in my Network https://www.jool.mx/en/index.html

I need IPv6-only network and NAT64 for this, please make NAT64 in Mikrotik?

+1 For NAT64 and DNS64

With global 34.2%, almost 50% in US and more than 50% in Germany there's no need to proove that IPv6 is now, networks won't get smaller, NATs won't get simpler and streaming content won't decline, so there's growing need for IPv6-only networks. Please be the company that ignites the affordable way to start phasing out IPv4 from internal networks by allowing NAT64. NAT64 must be the new NAT44 that should be helper, not fact for networking.

+1 for NAT64. I can live with DNS64 on the powerdns recursor

Can anybody with more knowledge into latest addition of IPv6 NAT to 7.1RC confirm that NAT64 now possible?
I read actions they have right now are masquerade, dst-nat, and redirect.

Mobile operator EE in the UK are now issuing IPv6 only SIM cards so this is becoming more and more important, even urgent since I can now longer tell a client to get a SIM card and then go put LHG-LTEx dish on his roof and get him some decent internet.

Lots of clients have IPv4 only devices at home so cant move to IPv6 only LANs

I have so far drawn a blank how to do this without adding extra boxes which is awful solution given the power available in RouterOS

DNS64 is incompatible with DNSSEC. As both Android & iOS have supported 464XLAT for a number of years I would expect this approach, a Stateless IP/ICMP Translator (SIIT) at the client and NAT64 at the provider, to become more widespread so Mikrotik support for this would be good.

i opened SUP-79815 for this and the response was:

We do not have any plans to add such a feature at the moment, but if more users will request it, we will see how this can be implemented.

so, i hope other people interested in NAT64 will also request it. (i also mentioned 464XLAT in my request, so i assume that response applies to both.)

i hope container support will help to solve this and many other needs

+1 for nat64

DNS64 is incompatible with DNSSEC. As both Android & iOS have supported 464XLAT for a number of years I would expect this approach, a Stateless IP/ICMP Translator (SIIT) at the client and NAT64 at the provider, to become more widespread so Mikrotik support for this would be good.

PLAT is pretty much a required standard for many providers at this point. NAT64 would be a step toward better IPv6 adoption, and is a pretty gaping hole in Mikrotik ROS right now - I get asked about it frequently, and when the answer to Mikrotik customers is "yank out the CPE (for CLAT support) and the routers (for PLAT), you can probably guess the response.

Hey Mikrotik, gentle reminder that NAT64 is still pretty important and should be added ASAP. CLAT client would be pretty useful too....just sayin'.

+1 made 100 posts...waiting for NAT64

Can anyone explain the current possibilities for NAT64 in Mikrotik?

I see there's parameter in IPv6 ND, but no clues anywhere else or example on how to use this:
pref64-prefixes (unspecified | ipv6 prefixes; Default: unspecified) Specify IPv6 prefix or list of prefixes within /32, /40. /48, /56, /64, or /96 subnet that will be provided to hosts as NAT64 prefixes.


I know the way to run tayga inside a container, but maybe there are more already built in?

Can anyone explain the current possibilities for NAT64 in Mikrotik?

I see there's parameter in IPv6 ND, but no clues anywhere else or example on how to use this:
pref64-prefixes (unspecified | ipv6 prefixes; Default: unspecified) Specify IPv6 prefix or list of prefixes within /32, /40. /48, /56, /64, or /96 subnet that will be provided to hosts as NAT64 prefixes.


I know the way to run tayga inside a container, but maybe there are more already built in?

The ND pref64 is different, this is a protocol option in IPv6 RA that allows you to inform the client of your NAT64 prefix.

Your NAT64 prefix can run on a Linux box for example with Jool