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