NAT64 and DNS64

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

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

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

Maybe I am :slight_smile: 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?

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/RouterBOARD_Feature_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_RouterOS/Feature_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 :slight_smile:

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.

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