Mainly NAT64.

DNS64 in as far as possible.

*) NAT64: https://tools.ietf.org/html/rfc6146
*) DNS64: https://tools.ietf.org/html/rfc6147

Keep up the good work.

Yes agreed. I have a /32 IPv6 I would like to start using.

Yes this feature would be very useful for our future v6 build out.

I would much rather build out dual-stack than an isolated island of V6 with workaround middleboxes making it work.
It's not going to work like full native V6 will work, and will possibly teach wrong habits or even give a bad initial experience using V6. We have used Hurricane Electric's tunnelbroker service with BGP advertising our native IPv6 /32 for years, and it has worked flawlessly.

Just checking, any updates with respect to this? Supported or not?

@ZeroByte:
Dual stack is no longer an option for some of us. ARIN has rejected our last request and given a IPv6 allocation only for our new deployment, we are starting to run short of v4 to give customers.

Allot of services are now available over v6 as well as v4, my expectation is that the usage of the NAT should decrease over time as more migrate to v6 and use the native connection instead of the NAT. Its thankfully easy to convince a customer it is the service they are using when stuff like youtube, facebook, netflix all work properly.

Mainly NAT64.

DNS64 in as far as possible.

*) NAT64: https://tools.ietf.org/html/rfc6146
*) DNS64: https://tools.ietf.org/html/rfc6147

Keep up the good work.

+1 NAT64 & DNS64

Sent from my mobile using Tapatalk

I've seen the light on NAT64 since my earlier post in this thread.

A good deployment of 464XLAT would do us well here at my company, but alas, the Mikrotik would need to support at least stateless NAT64 in order to roll it out. I'm going to discuss this with some of the Mikrotik guys at MUM USA this year.

It would be nice to have it in ROS, but we've got a box with bind9, jool, and quagga running in testing right now and it's working great. I plan to put in more using anycast/ospf which will optimize performance and give us failover.

It would be nice to have it in ROS, but we've got a box with bind9, jool, and quagga running in testing right now and it's working great. I plan to put in more using anycast/ospf which will optimize performance and give us failover.

If you are planning on doing stateful NAT64 with anycast make sure they are distanced or costed consistently for all your clients. You'll want to keep clients going to the same NAT64 box as often as possible to prevent a loss of state from flapping between two.

In a simple network of say a DC and 2 towers, place each unit at the towers instead of in the DC or cost the links in the DC so that one box is preferred over the other for the ::/96.

It would be nice to have it in ROS, but we've got a box with bind9, jool, and quagga running in testing right now and it's working great. I plan to put in more using anycast/ospf which will optimize performance and give us failover.

If you are planning on doing stateful NAT64 with anycast make sure they are distanced or costed consistently for all your clients. You'll want to keep clients going to the same NAT64 box as often as possible to prevent a loss of state from flapping between two.

In a simple network of say a DC and 2 towers, place each unit at the towers instead of in the DC or cost the links in the DC so that one box is preferred over the other for the ::/96.

Yep that's the plan. We have three edge locations and I was looking at putting one at each and adjusting OSPF costs so that the traffic doesn't get split.

Unless Mikrotik implements stateless NAT64, then XLAT464 is not going to be a viable solution for those of us with lots of Mikrotik CPE routers.

I spoke with Janis Megis at MUM USA this year and he is a member of the anti-nat purist camp. I was in that camp myself, but I have come to realize that certain types of NAT are useful and meaningful w/o breaking the end-to-end principle of IPv6. I took his answers to my questions to mean that we shouldn't be holding our breath for any kind of NAT64 implementations in the near future.

In fact, the last time I looked into such things in the pure Linux space, I didn't see any kernel-space solutions for NAT64 either. You have to use extra tools like TAIGA or JOOL to accomplish NAT64 from what I was able to learn. I suspect that this may also be a part of Mikrotik's decision to forego any NAT64 implementation in RouterOS.

Another option for you to look into is DS-Lite. Mikrotik can do what's necessary at the CPE (B4) side. You could configure your Linux appliances as AFTR device(s) and get your NAT64 functionality that way. This is a route I'm currently investigating for my company's IPv6 deployment.

Sadly, I see this still in enterprise. A fair number of people I talk to that are still waiting to see others use IPv6. Their view is it works for me. As mobile continues to disrupt and migrate to IPv6 I expect that view to either change or people will just stick their heads further in the sand as native IPv6 offers more performance over ever increasing layers of NAT. This statement is more about increasing global usage of IPv6 but ...

With feedback like you've gotten it makes me wonder if that is MikroTik's viewpoint as well. No matter what happens we are still years away from waking up in an IPv6 only world, transition tech will be needed for a long time. This means their is a market and it isn't fleeting. It would be sad to see MikroTik to miss an opportunity to make or at least keep themselves in a leadership position in the magic quadrant because of this view that IPv6 and the transition tech around it isn't important. This will rapidly become about moving widgets, in my experience business leaders like to move widgets far more than they like to sign paychecks of stubborn technologists. Hopefully it doesn't come to that, by then MikroTik will have slipped further in the magic quadrant and that can be very difficult to recover from. Especially with price point equivalent competition from Ubiquiti. Whichever develops the features will serve that market based on cost better than Cisco and Juniper can which already have these features for the core or at least POP installs.

I believe that NAT64 and DNS64 are transition technologies. But, I also don't make the mistake thinking that are too fleeting to warrant use. It wasn't too long ago in reality that NAT for IPv4 became mainstream. MikroTik, choose to lead in technology don't wait until you have to chase the market.

The reason I feel we're going to see increased pressure to go IPv6 is it is a demonstrated capability, both Microsoft and Cisco are running buildings worth of users on it. They cite reasons like single stack bringing reduced complexity and more manageable security policing along with features like globally unique addressing to due to RFC1918 exhaustion. Yes, MS specifically cited that. They were running out of RFC1918 addressing in their enterprise. Crazy. Additionally address use overlap during acquisitions was painful to deal with. This is the most common one I see in enterprise. They buy a competitor who is using the same random chunks of 10.0.0.0/8. Now they are re-addressing services. Fun.

If IPv6 in a single stack configuration will continue to grow we'll increased use of NAT64 boxes. Thankfully this centralizes past the CPE much better while still having distributed, redundant, capabilities. With limited support this may be the deployment model people like ZeroByte are forced to go with. They then either maintain Linux boxes running the NAT64 or a handful of Cisco routers capable of doing the same. Whether it's a Linux box running on top of a Dell server or a Cisco box it only equals a lost sale to MikroTik. Seems like a wonderful reason for me to buy one of those pretty CCRs, oh wait, it's missing the features I need ...

The problem with this is identifying routers your customers can plug into their home that will work without a problem. Gone are the days of grabbing literally any Netgear off the shelf. That'll likely change as more ISPs want to eliminate more and more transition tech and go to single stack IPv6 but it's the problem we have here and now. As ZeroByte hinted, DS-Lite can be used to alleviate this by pushing NAT responsibilities for IPv4 to IPv4 as well as IPv6 to IPv4 onto the ISP. At least this has an address space available.

Another option for you to look into is DS-Lite. Mikrotik can do what's necessary at the CPE (B4) side. You could configure your Linux appliances as AFTR device(s) and get your NAT64 functionality that way. This is a route I'm currently investigating for my company's IPv6 deployment.

Do you have any pointers on where to read about this setup specifically with RouterOS? I know Linksys routers also support DS-lite out of the box, I believe this is what Comcast is using for its v6 deployment. I cannot find any information about how to NAT IPv4 on the router to IPv6 out the WAN in RouterOS. What menu should I be in / what feature should I be using?

Edited to add: Looking at the link below, I see another problem with RouterOS. It appears the recommended method for supplying the AFTR information to the client is an option (AFTR_NAME) for DHCPv6. AFAIK there's nowhere to supply this in RouterOS. Correct?

https://www.isc.org/blogs/ds-lite-archi ... iguration/

Well, having not yet installed an AFTR to play with, I haven't yet kicked the tires on the necessary B4 settings on ROS, but essentially, the B4 device is just doing a 4-in-6 tunnel to some remote IPv6 address (which can be well-known within your network) - the B4 device does not perform any NAT whatsoever. It simply forwards IPv4 to a default GW route which is reachable via a tunnel. The AFTR device is the one with the NAT smarts because in addition to the typical NAT44 behavior where the "inside IP:port+remote host IP:port" is what is used to build the translation table, DS-Lite adds the tunnel's src-ipv6-address.

E.g.:
2001:db8:ace:cafe::1 | 192.168.1.44:TCP:12345 | 172.217.11.142:TCP:443

where 2001:db8:ace:cafe::1 is the B4's public IPv6 address that it uses when making the tunnel to the AFTR device. (incidently, the other LAN devices can just use native IPv6 to reach the Internet directly w/o going through this tunnel)
192.168.1.44 would be the customer's actual device's internal IPv4 address, and the public IP at the right is www.youtube.com's IP address at the moment I wrote this example.
So the B4 doesn't NAT and therefore the AFTR needs some unique-per-customer key to differentiate between many many LANs who all use the same IP range internally (192.168.1.0/24)

Anyway - as a basic 101-level experiment, I was just going to build a tunnel and make it work. After that comes the next level of dealing with AAA, security, etc.

What sort of tunnel? RouterOS has a 6to4 tunnel capability but I cannot find a way to do 4to6.

I can manually setup an ipipv6 tunnel and pass ipv4 over it, but what a PITA to do that for every v6-only client.

Mikrotik recommended SSTP when I asked about this at MUM.
I haven't played with it yet, but this appears to be more profile-driven than just a basic IPIP6 tunnel would be.

If you're using Mikrotik as the SSTP server, then this will not help much because it won't be able to perform DS-Lite NAT64 (no IPv6 NAT / NAT64 at all, let alone the DS-Lite style NAT64). However, they were suggesting using this as a way to do v6-only transport with a centralized IPv4 delivery scheme over the SSTP. This would work as well, and you could just tunnel routable V4 addresses or utilize CGNAT over the tunnels with 100.64.0.0/10 space.

Mikrotik recommended SSTP when I asked about this at MUM.
I haven't played with it yet, but this appears to be more profile-driven than just a basic IPIP6 tunnel would be.

If you're using Mikrotik as the SSTP server, then this will not help much because it won't be able to perform DS-Lite NAT64 (no IPv6 NAT / NAT64 at all, let alone the DS-Lite style NAT64). However, they were suggesting using this as a way to do v6-only transport with a centralized IPv4 delivery scheme over the SSTP. This would work as well, and you could just tunnel routable V4 addresses or utilize CGNAT over the tunnels with 100.64.0.0/10 space.

In my experience sstp does not provide the most stable of connections.

Hence why my interest is more focused on IPv6 single stack to the customer with NAT64 to handle named (DNS) IPv4 resources. The key is going to be CPE verification. I already know the cheapest of units will not work and you will need either Linux servers to do the NAT64 and DHCPv6 (address assignment not prefix assignment necessarily). Alternatively, Cisco 1841's (~30 bucks on ebay) can function as NAT64 boxes and you can use Google's DNS64 service.

At some point I'll have to formally right up my NAT64 lab and post the details of the consumer grade routers I've tested. The only feature it doesn't provide is literal IPv4 resource access (meaning http://132.132.254.254 or something like that and the fix is to just create an A record).

The only feature it doesn't provide is literal IPv4 resource access (meaning http://132.132.254.254 or something like that and the fix is to just create an A record).

Of course, until Mikrotik implements at least stateless NAT64 in RouterOS, this is all a pipe dream, but to illustrate why it would be great - here's an example of how 464XLAT makes life great.

If you've deployed 464XLAT, you can crack that nut with stateless NAT64 in the CPE. (except for IPv6-only hosts in the LAN - see end of post)

Suppose each CPE has multiple /64 blocks to play with (which is recommended practice anyway) - let's say /60 for the sake of argument using the longest nibble-boundary prefix shorter than 64.
Let's say you have 2001:db8:cafe::/60 assigned to a CPE.
You could easily designate a /96 for local 4->6 stateful nat outbound.
to avoid conflict with any LANs, earmark the entire ....F::/64 block.
ergo: 2001:db8:cafe:f::/64 is NAT64
More specifically, any internal IPv4 addresses behind the router would be mapped to:
2001:db8:cafe:f::aabb:ccdd (where a,b,c,d ~ hex of the IPv4's 4 octets)

On the ISP side, you would have a similar dedicated stateful NAT64 prefix. You could use a ULA prefix, or even burn one from your public block if you're worried about customer firewalls blocking fd::/8 as a destination prefix... suppose you mapped 2001:db8:64::/96 on the ISP side as the "Internet"
On each CPE, you'd have stateless NAT64 as follows:
DSTNAT64 a.b.c.d -> 2001:db8:64::aabb:ccdd
SRCNAT64 a.b.c.d -> 2001:cafe:f::aabb:ccdd

On the carrier side, you'd route 2001:db8:64::/96 to your CGNAT box(es), and they would statefully SRCNAT to some public IPv4 address in their pool for 64 translation. Replies would automatically be directed to whatever CPE device had originated the socket - the original src would be 2001:db8:cafe:f::aabb:ccdd - and the CPE would statelessly map this back to the private IP.

With this in place, the CPE would allow dual-stacked devices on the LAN to reach IPv4 literals w/o any need for DNS64 (or even legacy devices w/o any IPv6 support whatsoever). At this point, DNS64 is only required for IPv6-only hosts in the LAN which need to reach IPv4-only hosts on the Internet - DNS64 would map into that same 2001:db8:64::/96 space. Obviously a 6-only host would not be able to reach an IPv4 literal (as you stated in your post) - but given this 464XLAT scenario, there's no reason not to dual-stack behind the CPE router.

Yes, either are definitely valid solutions. Each operator will have to weigh the complexity of each against the equipment they own as well as make a determination of whether or not it's ok to lose IPv4 literal access.

In my mind dual stacking IPv4 in shared address spaces is a lot easier than 464xlat. That said I really like single stack IPv6 from a maintenance and security perspective. Which leads me down the NAT64 path as it's a more available implementation within a MikroTik ecosystem (it's easier to add NAT64 routers / servers).