IPsec VTI would make me VERY VERY happy 
I see, ok dream on the wait continues if my LTS dream did come true after waiting for years I think I can only hope this will also come there’s a saying patience is a virtue for those who wait hahaha, seriously this feature is non optional now a days, I hope MT will see this feature as another trick on their sleeve and can potentially generate additional sales for them
when RouterOS become statefull dhcpv6?
Is there a specific setup you have that doesn’t work with SLAAC? Why do you want stateful DHCPv6?
Regardless, I’ve been able to setup a stateful DHCPv6 server in version 7.22rc1 by creating a subpool from the ::/56 prefix assigned by my ISP and pointing my DHCPv6 server’s address pool to it:
/ipv6 pool
add from-pool=site-prefix-pool name=prefixlen128-1 prefix=0:0:0:10::/60 prefix-length=128
/ipv6 dhcp-server
add address-pool=prefixlen128-1 interface=bridge name=dhcpv6-server1 prefix-pool=site-prefix-pool
Some people think in IPv6 it should work like in IPv4: assign individual addresses using DHCP with a pool for the subnet and possibility to make leases static etc.
While I think that would have been the best (and SLAAC should never have been developed), that is in the past and DHCPv6 for address assignment will never be the generally used method anymore. So support for it will likely be lacking.
Lacking general support for registering IPv6 address with DNSv6 (I guess there are some solutions but not applicable everywhere), using some random IPv6 addresses even for typical workstations can be cumbersome (e.g. to offer support for users by remote connections). In such cases stateful DHCPv6 server comes handy (and systems, supporting DHCPv6, mostly support also SLAAC for the anonymity cases).
Yes, support will be lacking, e.g. google is rejecting DHCPv6 on android (only SLAAC is supported), but personally I don't care about android devices. But I do care about "serious" desktop OSes, such as Windows and linux (macOS probably falls into same category, but I don't have to deal with devices running it).
Still reproducible in v7.22rc:
IPv4 connected route over ipipv6 interface remains DIc and never becomes ACTIVE.
As a result, IPv4 default route via ipipv6 stays inactive (immediate-gw="").
This is not DS-Lite specific.
It also occurs with a plain /interface ipipv6 tunnel.
Reference:
(SUP-209458)
i wouldnt say thats correct.
Yeah, wait another 30 years. 
I agree with @KiwiGuy , ipv6 suffers from a perfectionist design. The original problem statement around ipv4 was lack of total address space, a simple enough problem with a simple enough solution. But the solution provided decided to completely re-work the architecture fundementals and other aspects that I think no one was expecting. Hence why ISPs are moving more and more towards CGNAT. Apartment complexes (at least here in the US) and probably abroad are all moving towards some style of CGNAT central provider paradigm where you can’t even sign up for internet your self it is just part of the rent. I’m sure it won’t be long before HOA and single family home divsions adopt something similar. I highly doubt ipv6 will ever become 100%.
I've never used any form of NAT (except on the customers LAN, of course) with customers.
NAT is shameful and causes more problems than benefits.
Activating IPv6 took me a moment, all the products in my "routing network" are MikroTik-only,
and now about 85% of the traffic on my clients' networks is IPv6...
Very few accesses to IPv4 services anymore...
I've always operated 1 IP = 1 user
Even companies.
Actually, especially companies.
If only everyone had done it, and withdrawn the randomly given /8 blocks...
If they need more than 1 IP (and there must be a truly valid reason), they'll receive counted IPs,
not throwing away 8 (or even 10) public IPs to use only 2 (or maybe just 1), as "the others" usually do...
And, aside from that, everyone has an MTU of 1500, no less (and no more, towards the Internet)...
My developing country has the adoption rate listed at 60%, and if I look at the fasttrack counters of the router at my parents' house, with two old non-technical people, since the upgrade to 7.21.3 over a week ago:
IPv6 traffic already clearly outweighs IPv4 for "normal" people in my country.
IPv4 traffic will consist of acess to services and webpages that are IPv4-only. All else goes over IPv6. That sets the ratio.
Ok but that just means NZ is backward, not that IPv6 is not a thing.
I happened to check today and at work over 2/3 of the network traffic is IPv6.
Well, that is in fact what happened. E.g. “fragmentation”, a technique that was in IPv4 to fit larger (1500 byte usually) packets into networks with a smaller packet size limit was not taken over into IPv6, because it causes load on routers and other problems.
But I agree with you and others that SLAAC was a terrible solution for a non-problem. DHCPv6 should have been used for address assignments all the time. Remember that in the beginning SLAAC provided only the router address and a hint to assign a station address, nothing else. Do you require a DNS resolver? You are on your own. Later that was extended but that would have been the time to forget about SLAAC altogether. And then it was found that it wasn’t clever to generate a station address from the MAC address in a world where companies wanted to track users. Requiring another kludge.
No, SLAAC is terrible. But it is a passed station (as they say here) and we are stuck with it. That isn’t going to change while you wait implementing IPv6.
I like SLAAC and I also like the idea/intention behind it. I don't understand the hate against it. But maybe it's because I don't have to administer enterprise networks. 
What's new in 7.22rc3 (2026-Feb-26 10:37):
- ! certificate - added support for multiple ACME certificates (services that use a previously generated certificate need to be reconfigured after the certificate expires) (additional fixes);
- ! device-mode - added option to configure device-mode via Netinstall or FlashFig using a “mode script” (additional fixes);
- app - added health check for apps, which automatically rewrites the composed YAML;
- app - clean the backup directory after container repull;
- app - fixed element that was failing to start;
- app - fixed potential port collisions between apps;
- app - show DNS URL for app only if it has a reverse-proxy (additional fixes);
- bgp - make remote.address parameter optional;
- bridge - added local and static MAC synchronization for MLAG (additional fixes);
- bridge - added MLAG support per bridge interface (/interface/bridge/mlag menu is moved to /interface/bridge; configuration is automatically updated after upgrade; downgrading to an older version will result in MLAG configuration loss) (additional fixes);
- bridge - fixed performance regression in complex setups with vlan-filtering (introduced in v7.20);
- bth - use separate Let's Encrypt certificate for file-share;
- container - automatically stop/repull/start the container on repull or remote-image change;
- device-mode - removed authorized-public-key-hash property;
- dhcpv6-relay - fixed link-layer address inconsistency with the original link-layer address in relay-forward packets (additional fixes);
- fetch - fixed fetch treating relative paths from redirects as hostnames;
- health - added CPU temperature monitoring to L009 with ARM64;
- ip - added reverse-proxy (additional fixes);
- ipsec - improved aes256-ctr stability on L009;
- isis - improved stability and fixed a small memory leak;
- l3hw - fixed missing VLAN counters on reboot (introduced in v7.21);
- l3hw - improved system stability when enabling VLAN offloading under active traffic (introduced in v7.21);
- leds - fixed WiFi LEDs on hAP AX S (introduced in v7.22rc1);
- poe-out - firmware update for CRS354-48P-4S+2Q+ (the update will cause a brief power interruption to poe-out interfaces);
- poe-out - fixed controller-error for CRS354-48P-4S+2Q+;
- route - do not set blackhole flag for synthetic routes;
- route - fixed connected routes sometimes not working (introduced in v7.22rc1);
- route - removed preset rules and use routing/settings policy-rules (introduced in v7.22beta1);
- routerboard - allow changing /system/routerboard/settings via Netinstall or FlashFig using a "mode script" (additional fixes);
- system - improved upgrade service stability when the server is unreachable;
- user - properly apply login delay (introduced in v7.20);
- wifi - improved stability of interfaces in station mode during roaming;
- wifi - improved support for 802.11be access points (additional fixes);
- winbox - added missing route flags;
- winbox - added route ISIS tab;
- winbox - show MPLS tab only to relevant routes;
Sorry, but why do you have to answer every question with another question?
I have several challenges here where I need DHCPv6 stateful. That's just how it is. Thanks.