While RouterOS has supported IPv6 for years now, I think we can all say that the capabilities of ROS in this protocol are pretty vanilla when compared with the rich functionality available in IPv4.
Whenever a new RC is announced here, the thing I scan for first is ipv6 features / bugfixes, because our organization has a heavy deployment of Mikrotiks as CPE, and it's still my opinion that ROS is lagging behind in IPv6 to the point where I'm having to plan our production roll-out of the protocol based heavily on the behavior of Mikrotik.
Obviously, there are a million potential features that we could all wish for / fixes we may need, but time is money, and effort spent on IPv6 functionality is effort taken away from other enhancements / fixes that we may be waiting for as well. To that end, I would like to post a list of what I feel are the features which are glaringly missing / under-developed in order to improve the functionality of the Mikrotik platform, allowing it to be more useful in a wider variety of scenarios, focusing on (seemingly) simple enhancements and new features which shouldn't require tons of effort, but would make life a lot better in the IPv6 universe for Mikrotik users.
Here is my list of IPv6 enhancements that I feel would benefit the most users, regardless of whether I would use them personally or professionally at my current company.
(In no particular order)
DHCPv6 stateful host addressing server
Stateful host leasing: For those who wish to have full control over each and every LAN client, SLAAC is a freakin' nightmare scenario. My former boss would rather be punched in the face every second for a year than let all devices join the network at their own will without any kind of audit trail as to who they are, when they joined, when they left, etc. He is far from being alone in this regard.
Stateless DHCPv6 server
Stateless DHCP is equally important because there are some vendors (*cough* Microsoft *cough*) whose paradigm is DHCP primarily because of enterprise customers who share my former boss's view of network management. To that end, they have not (to my knowledge) yet, nor do they intend to implement the feature of learning DNS server address or domain suffix list from SLAAC. Besides this, there are other devices which we may wish to migrate to v6-only, and it sure would be nice to not need to stay dual-stack on these devices when the only need for IPv4 is for good ol' reliable DHCPv4 to hand out info options such as TFTP server, NTP server, DNS server, etc... ESPECIALLY when many of these cannot even specify IPv6 addresses using DHCPv4. Can we live without stateless? yeah, but when this is the last shingle to finish the roof over basic LAN assignment mechanisms, it would be great to have it completely working for all paradigms.
Dynamic host<-->IPv6 DNS cache entries for DHCPv6 clients
If driving stateful client addressing with IPv6, it could be an easy option to auto-add the client's hostname to the DNS cache so that a rudimentary LAN naming space is accomplished - because it sure is hard to remember all 16 nibbles of your devices' host-IDs while allowing them to remain dynamically configured.
Add AAAA record support to DynDNS updater client
Okay - so this isn't really a "high priority" triage type of feature, but it seems like something that would be almost effortless to implement, and would allow us poor souls doomed to having dynamic IPv6 prefixes to find our routers whenever we're away from home and have IPv6 access... or be able to run servers from home with dynamic IPv6 space... etc.
Without NAT66, being a client to RA seems a low priority for a router, but there is value that these messages bring to the table other than being a component of SLAAC address configuration. RA may be the only mechanism that an ISP assigns default GW / DNS information (ahem - Mikrotik routers? lol). Even without NAT, Mikrotik could implement RA client as a sort of "IPv6 dynamic routing protocol" - You could add/disable/remove/edit the interfaces and set administrative distance to enable an RA listener which will assign the highest-priority router's link-local address as a default GW with the distance determined in the above configuration. RA could be utilized on links as a straight replacement for VRRP with this one simple feature. Furthermore, if the ISP is statically routing blocks to clients, but wants to use RA to provide automatic redundancy, it sure would be nice if Mikrotik routers could play ball in that arena.
RA send on link-local-only segments
As for sending, ROS should be able to send RA messages onto links with only link-local addressing. (where it is not also configured as an RA listener). I'm participating in another thread where it was found that some consumer-grade routers require learning their IPv6 default GW via RA messages. If planning to use link-local-only attachment circuits for customers, this becomes much more important if customers may also BYOD...
Configurable DNS/domain suffix delivery to SLAAC clients
There has been a great proposal in another recent thread here whereby "advertise DNS" is not just a checkbox - it should be at the very least accompanied by another checkbox "advertise self as DNS server" and ideally accompanied by a list-box where you can specify one or more IPv6 resolver hosts / domain suffixes to advertise.
Manually-configurable link-local address on an interface
Manipulating the MAC address of an interface to kinda-sorta assign the fe80:: address is NOT good enough, especially if you want your router to be fe80::1 on all interfaces....
NAT66 prefix translation
We're not all lucky enough to have forward-thinking ISPs willing to statically assign our address blocks to us. Some of us have a different routing prefix every other day, and it sure sucks if your print driver has a static IPv6 address for a network-attached printer, and that address becomes invalid every other Tuesday. Prefix translation would be immensely useful for users in this boat, as well as those who wish to multi-home their connection. As things stand today with Mikrotik, multihoming is impossible on IPv6 unless you use BGP - and I dare say that I couldn't qualify for my own personal /48 to take with me the rest of my life, and I 100% certainly will never get any ISP to offer me BGP routing on a broadband service. They don't even want end users running websites out of their houses. And it's obviosuly insane to think we could unleash the public onto the global BGP table... No, some other mechanism must be available, and until MPTCP, SCTP, etc make significant penetration (routers would only need policy routing in this case), Prefix-translation NAT is the immediately-obvious choice. Furthermore, NAt66-PT is stateless, so it will not break as many things as stateful NAT does.
Ability to specify which interfaces get which subnets assigned to them from a pool of IPv6 space
I have not found a way to do this - e.g. if I were to receive a /56 from dhcpv6-pd, it would be nice to say: "MyPool:ff::1/64 -> GuestBridge"
If this is doable, I'd love to know how.
Fixed major routing protocol glitches in IPv6.
IPArchitects could better speak to these glitches than I can because it's been a while since I've read threads reporting bugs in these, but I recall seeing some definite show-stoppers from my ever deploying a CCR in a core IPv6 routing capacity until they're fixed. (OSPFv3 adjacencies not forming with other vendors' gear due to certain flags not being set in SAs on their loopback interfaces, recursive next-hop lookup failure crippling iBGPv6, etc). I understand that these are most likely in the "fixed in v7" category, but for those who cannot deploy IPv6 until those glitches are fixed, or at least cannot use Mikrotik at the core of their IPv6 topology until fixed - well, that's a problem that might be well addressed sooner rather than later for both customers and Mikrotik themselves alike.
With the exception of this last one, I feel that these features should not be hard to implement or improve in RouterOS 6.x and I feel that these few enhancents would go a long way to improving the experience those of us who're adopting IPv6 have with RouterOS, and make the platform more useful going forward.
Oh, and finally....
Enable the protocol by default
This one fact alone (IMO) shows Mikrotik's lack of priority handling for IPv6. Google has almost reached 20% utilization via IPv6 (the peak was 19.76% on June 27 as of this writing).
When given a spoon,
you should not cling to your fork.
The soup will get cold.