I have been plagued for a long time with an issue whereby Win10 WiFi clients cannot renew their IPv6 connection, after having first been assigned an address via SLAAC. This problem only affected Win10 laptops connecting via WiFi to a RB951G-2HnD. IPv6 connections via ethernet work as expected, as do Android devices connecting via WiFi. I have a very basic domestic set-up with only a few clients, and a VDSL WAN connection via PPPoE which is assigned a single (Natted) IPv4 address and a single /64 IPv6 prefix out of a /48 available. All IPv4 connections over WiFi work as intended.

After wrestling with firewall and ND settings to no avail, I have recently discovered an emprical solution which I offer for anyone else suffering the same problem.

Fllowing a hint I noticed in this forum, which now escapes me, I changed the multicast-helper option from default to full within the wireless settings on the router. Apparently the default setting is equivalent to disabled. It appears that Win10 clients (over WiFi) during ND renewal negotiation, require responses to be sent to their unicast MAC addresses. As most will notice, I have very little expertease in networking matters and I'm learning as I go along. Perhaps others can explain whether this is an issue either with Routeros or with Microsoft's implementation of IPv6/WiFi, or both, but for now I have no further problems of IPv6 address assignment for any of my clients.

Renfrew, thanks for posting this. I had a similar issue where Windows 10 clients (suddenly) stopped working with SLACC - Android continued to work.
It all has to do with multicast as you observed. I noticed IPv6 assignment works as the Mikrotik is booting and then stops a few seconds later.

In my case, I'm using an RB750Gr3 with bridge and filtered VLANs. On the bridge, IGMP Snooping, Multicast Router: change Temporary to Permanent.