Hi,
I’m looking to start IPv6 deployment to my customers. I found a problem that Mikrotik don’t have support and no implementation for IPv6 transition mechanism. It’s any prevision to implement in ROS 464XLAT or MAP?
I don’t have any free IPv4 free and I need to implement the IPv6 ASAP, also is the future I can’t undersant why Mikrotik don’t have it yet.
BR
Mikrotiks support IPv6 tunneling via several mechanisms, such as tunnelbroker.net and public 6to4 relays, but these require a stable IPv4 address.
Of course you could just route native, working IPv6 to your customers and do GCNat on the IPv4 side of the house.
Furthermore, if you want to provide a Nat64 relay into IPv4 space with DNS-masq, you could set this up on one router and one DNS server and use that to serve your whole operation. If you have LOTS of traffic, then a few such relays in strategic locations would work - stateless NAT doesn’t require a super beast of a router/firewall to implement.
Hi @ZeroByte
tunneling is not a IPv6 transition mechanism because you need a dual stack in each client, and also we can’t offer a comercial products via tunneling in others companys, it’s not a professional solution.
With GCNAT you can have problems with some aplications and also with the legal requeriments to save the IP for the police.
I’m studing for a few weeks the IPv6 migration and the 2 most popular mechanisms and also works better is 464XLAT or MAP
Thanks for your reply
I’m heavily involved in IPv6 training, consultancy and deployment for customers since 2001, and recently looked into MikroTik for some customers, so let’s try to clarify a bit on this topic.
There are 3 kinds of transition mechanisms:
When we started developing IPv6 and transition techniques in IETF, it was expected that we will deploy it before we run out of addresses, so Dual-stack was the way, and tunneling to transport IPv6 in IPv4 networks.
We developed NATPT as a translation to allow IPv4-only web sites to be available with IPv6, but many folks started using it in the wrong way, so it was deprecated.
On February 2011, the world run out of IPv4 addresses. So it was needed to develop new transition mechanism. Some like CGN (NAT444) aren’t mean for IPv6 deployment, just for artificially extending IPv4 life, but it means several levels of NAT, which means breaking applications, not scaling, requiring further logging for legal data interception, etc., etc. You can use it together with dual-stack, but is the worst solution.
So we developed new tunneling mechanisms such as softwires (L2TP for IPv6 tunneling), DS-LITE, LW4o6, which allow to go away from IPv4, by making the ISP network IPv6-only and tunneling IPv4 in IPv6, so as more IPv6 traffic is available, less overhead. LW4o6 will be very interesting in many cases.
In many other cases we need other solutions. The one more useful for cellular networks as well as many other networks is 464XLAT, which basically is stateful NAT64 (PLAT) at the ISP side and NAT46 (CLAT) at the CPE. This allows any application, despite using “hard encoded IPv4 addresses” or using old socks/apis, etc., to work perfectly. This is being used in millions of cellular customers in US and some EU countries, probably many more in other regions. Android and Windows support this (CLAT) at their cellular OSs.
Apple has decided an alternative strategy: They mandate since June 1st 2016 (announced a 4th May 2016)), all the Apps to WORK with IPv6, which is much better, because it means they don’t need to do any translation at the cellular phone (power saving, speed), but enforces the developers to recompile and some times modify their apps to support IPv6.
Another alternative, which is available in many CPEs is MAP-E (Encapsulation) or MAP-T (Translation). I think this one is better which are a kind (very very short and not “precise” explanation) of mix among 464XLAT and encoding the IPv4 address and ports into the IPv6 address. But this is not supported in mobile phones. This requires a very simple configuration at the ISP network which is called the Border Relay setup, and you basically split a given number of ports among “n” customers sharing a pool of IPv4 public addresses (while in 464XLAT all ports are available from a given IP address from a given pool of them).
So specially if you have different kind of access networks, it may be more convenient 464XLAT, unless you want to run simultaneously several transition protocols in the same “ISP core”.
The code for both 464XLAT and MAP is very very very simple, and is available (source), as has been developed for OpenWRT. Many vendors are using this code for their own implementations, for example cable modems from Technicolor, etc.
Both of those mechanism, as well as DS-LITE and lw4o6, look into a future, by using only IPv6 in the access network, making this transition and coexistence very simple and making the cost much lower. As much IPv6 traffic is there, less overhead, less state in the network, etc., etc.
I think MikroTik has a unique opportunity here to include at least at the CPE side, the CLAT and the MAP code, and at the ISP side the NAT64 (stateful) and the BR function. I think it will take just a few hours, even not a complete day to do so.
Otherwise, many MikroTik customers will need to use alternatives, even using OpenWRT instead, which is not a good thing, I guess.
Hopefully this can be worked out and very very very soon.
By the way, is very wrong, and confusing, calling 6to4 to 6in4 tunnels as MikroTik is doing. Yes, they use the same encapsulation, but is a totally different type of tunnel.
Look into NAT64 as another alternative - and it need not be on-site at the customer’s location.
I think you’re going to be hard-pressed to find a customer who’s willing to go full-bore v6-only on their own site. If they are dual-stack internally, then their network is going to try to forward v4 traffic through your network, so you’re probably going to need to look at CGNat anyway.
Even a protocol-translating “NAT” gateway is going to require you to keep logs of who did what via this gateway, unless you have enough IPv4 address to map to your customers 1:1 anyway… which obviously you don’t or else you wouldn’t be shopping for solutions.
Nat64 is simple enough - map all of the IPv4 internet into a single /96 prefix on your network - and then use dns64 to form AAAA responses to queries that don’t have any natural ones. The big issue with NAT64 is that protocols such as SIP and FTP which signal IPv4 addresses in-band will require protocol helpers to function properly. Otherwise, the users will need to be educated that if they want to reach a certain “IP address” they do it by reaching the “special:prefix::ffff:a.b.c.d”
NAT64 is broken because many apps such as Skype, don’t use the right libraries or use literal IPv4 addresses, so they got broken by using just NAT64, that’s why 464XLAT is the right solution.
I’ve posted an explanation on all this, but has not been yet been published, not sure why.
If you use 464XLAT or MAP or DS-LITE or lw4o6, customers still have dual stack in the LANs, with private IPv4 addresses, same as now, and nothing get broken, so customers don’t need to notice or even know. With other solutions, there are many chances of breaking thinks.
Of course, if your customers need to export services, then they need full dual-stack, but anyway, those customers have stable IPv4 addresses which probably are paying for, so is a different case. Of course, we also have some transition mechanisms for avoiding that, mainly considering data centers, but it is a different topic … we can talk about this in another thread.
So solution is install other routers (not mikrotik) in network to do NAT64?, Isn’t RouterOS a Network operating system?
An OS that is focused on networking should support as more transition mechanism as possible, not only two or three.
I can’t defend Mikrotik against other Network operative systems if Mikrotik don’t take in account thinks like that seriously.
IPv6 support isn’t as far along in Mikrotik as it needs to be in my opinion. It does work, and it was a viable IPv6 router long before DD-WRT, Linksys, Netgear, et.al. were, but there hasn’t been much advancement in that arena for a while. (the IPv6 module still defaults to being disabled!)
Even if the feature were built into ROS directly, I’d still opt for a distribution of gateways on the network as opposed to on-site translation if I didn’t have enough IPv4 addresses to spread around. If they’re going to interwork 6->4 on-site, then their router is going to need a working IPv4 address to do that part of the job.
I’ll try to explain it better: First to implement advanced transition mechanism like 464XLAT or MAP-E, MAP-T will take the money from people wich need urgently buy expensive IPv4 addresses right now.
You need to be the first this time Mikrotik, don’t let Ubiquiti take advantage as usual. I’m sure they are not crossing arms with this easy question.
Good point @Boretto:
Ubnt has internal “alphas” that uses several transition mechanism such xlat, MAP-E/T . Those versions are not public released yet, but… who knows.. maybe they will be out for all in few months. EdgeRouter haven’t the best routing operating system NOW, but it is growing up in every release.
I was hoping they might announce ROSv7 at MUM but so far, no luck.
Honestly, in my book, the #1 single functionality that’s missing in ROS for IPv6 isn’t interworking functions, but sheer, simple stateless dhcpv6 beyond the hidden functionality of handing out DNS based on things you can’t configure or really control very well. The inability to configure dhcpv6 options to hand out to clients is quite a limitation to using it on a production network as a simple network router analogous to the functionality you get from the IPv4 version.
I’m confused here. DHCPv6 is stateful, not stateless. According to the Mikrotik Wiki, the ROS supports both DHCPv6 client (for Prefix Delegation) and server. So what is missing there. May be isn’t supporting DHCPv6-PD server ? This is important, of course, but not a big trouble as you can run a server with ISC DHCPv6 for that.
Also you need to keep running in the CPEs SLAAC, because Android doesn’t support DHCPv6 and according to the developers, is not going to be supported, no plans at all.
Hello,
The IPv4 limit is a real problem. Buy new IPv4 ranges are more and more expensive each day. This is a real problem for Internet providers, so is time to start to use (no migrate to) IPv6.
Using double stack is a temporary solution, but really, let’s be honest, this is a “bad solution”. The goal will be use more IPv6 than IPv4 a few time, setting a double stack network now, it’s a waste of time, and we will need to spend more effort in the future for sure in order to setting real pure IPv6 networks.
The future is IPv6, and we need to prepare our networks and systems for the future using the smartest way possible.
We have a lot of transitions strategies, and is time to study. Here, we are speaking about the “464XLAT” and “MAP” transitions mechanisms. We are studying some mechanisms for our ISP, and I’d like join to this request, at this moment I think, “464XLAT” it’s the best solution in order to use only IPv6 in our networks supporting also IPv4 access at the same time.
464XLAT should be specifically easy to deploy. We are using RouterOS in our networks, and Mikrotik should consider support CLAT for CPEs, and PLAT (NAT64 and DNS64). RouterOS is a Linux based O.S., so it should not be difficult to implement. We have a lot of resources in order to deploy this mechanism, we only need to check some solutions like:
https://www.jool.mx/en/index.html
https://github.com/toreanderson/clatd
I hope Mikrotik keep in mind a good support for transitions mechanisms like this, we will be happy to help in any beta version for testing in our networks.
Thank for your support.
King regards,
David
Please, be aware of this: Migrate means COMPLETELY DISABLE IPv4.
I guess you want do keep dual stack at the customer LANs, which is transition and coexistence.
Is a very bad idea to take out IPv4 from the LANs.
What we should do it, in typical ISP networks, keep IPv6 only in the access, some times even in the core, but dual stack at the customer LANs (even with private IPv4 behind the user CPE NAT).
Hello Jordi,
I was refering to our ISP networks, using IPv6 there and dual stack (private IPv4, an global IPv6) in the CPE LAN. Obviously, in the BR, we will need double stack in order to use PLAT.
King regards,
David
Got it, then we are talking about transitioning, not migration. Migration is only the case when you disable completely IPv4 in ALL the network.
There are no “migration” mechanism, is probably impossible right now to do that, you always need some way of coexistence, that why we designed at IETF “transition and coexistence” mechanisms.
It seems Mikrotik didn’t have read IETF RFC’s about transition mechanisms, yet…
Ok, understood, I was using erroneously “migration”, is “transition”. I hope everybody here understand better now.
Waiting for news about this from Mikrotik…
DHCPv6 comes in many flavors:
prefix delegation and address delegation are both stateful mechanisms.
there is also stateless dhcp which was (if I recall correctly) the first mode that was developed. It’s like a bulletin board - any hosts can go request the scope options, but they’re not asking for address leases - hence the stateless part. You would use it to inform devices of the DNS servers, domain name, time servers, tftp servers, etc - anything that’s in the IPv4 scope options.
The “extra information available” flag in RA messages informs SLAAC devices that they need to go find a DHCP server because there’s more information available. SLAAC is pretty much just a mechanism to automatically configure the IP address and default gateway. Putting DNS information into RA was a good idea - because how useful is an address without a DNS server for an end-user device?
In the current state of affairs, you need to support both SLAAC and stateless-dhcpv6 in order to make 100% of devices happy and useable because while Android has sworn a blood oath to never use dhcpv6, Microsoft has sworn a blood oath to require it and to ignore DNS information in SLAAC. Those of us who just want everything to work must support both.
And yes, you can definitely run a virtual dhcpv6 box, or configure the function on an appliance, or set up the service on an existing server or run a dedicated server. DHCP functionality has been built in to network appliances for a long time now, and having to make a work-around in the IPv6 side of the house is a bit distasteful (but obviously necessary if you want to use Mikrotik right now). Note that there is also no relay functionality for dhcpv6 so the server would need to have an interface in EVERY lan segment…
DHCPv6 has never been stateless. It is true that “some” parameters (very few) are stateless, but the DHCPv6 itself is stateful for the most important parameters. The way it has been described in the RFC may be confusing, you need to read several documents about IPv6 and DHCPv6 to get it correctly, but this is always true for most of the IETF work 
The stateless way is SLAAC, which means that using ND/ICMPv6 with the RA (Router Advertisment). You can get here:
It most of the cases, SLAAC is sufficient. You need to keep RA working for the default gateway, which is never provided by the DHCPv6 server.
You can run just SLAAC, or together with DHCPv6, there are several options, but the DHCPv6 part is always stateful.
As I know, tested in MANY real networks, which we deploy for customers, because you keep dual stack in the LANs, etc, all the OS (Windows, Android, Mac OSX, iOS, Linux flavours, etc.) will just “work” with only SLAAC. If you need a more granular control, then you can add DHCPv6. This is from the perspective of the enterprise or residencial user.
From the point of view of an ISP, actually the BEST option is to use an IPAM (IP address management), which can also be a DNS server and DHCPv6 server, all for both IPv4 and IPv6. Otherwise, you split functions in the router and the IPAM which makes them working together more complex. There are both, commercial and open source solutions. This way you can also have DHCPv6-PD + RA, which allows the automatic configuration of the customers CPEs.