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:
+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 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-behave-v6v4-xlate-stateful-12
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
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
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
- That the NAT44 or NAT444 is tried and tested
- 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.
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,
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.
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/
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.
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