Strange - advertise=yes shouldn’t make a difference, you should not need router advertisements for this to work. They must be somehow working around an underlying issue.
I didn’t quite say that. I said we offer IPv6 over VPLS tunnels, but there is no BGP involved in the way we provision services - we bridge the customer at one end to a VPLS tunnel, and the other end of the tunnel has their gateway IP bound. We do L2VPN, not L3VPN.
As you state the advertise option is not needed and was most probably only effecting a change by it flapping the IPv6 address when applying the change. Problem resurfaces if the layer 2 VPLS tunnels re-establish and automatically get removed and added to the bridge, thereby changing its MAC address. I assume a deeper bug relating to the link local address not updating properly to track the interface’s MAC so I simply set a static MAC address on the ‘bridge-ipv6-mpls’ interfaces to avoid the quirk.
Recap:
R1:
/interface bridge set [ find name=bridge-ipv6-mpls ] auto-mac=no admin-mac=00:14:F2:00:00:01
R5:
/interface bridge set [ find name=bridge-ipv6-mpls ] auto-mac=no admin-mac=00:14:F2:00:00:05
RR1:
/interface bridge set [ find name=bridge-ipv6-mpls ] auto-mac=no admin-mac=00:14:F2:00:00:06
Yes, I have seen issues like this as well. In cases where a port leaves a bridge with auto-mac and rejoins, the link local shown in IPv6->Addresses doesn’t always match the link-local that the router responds on, which leads to all kinds of other issues. Setting an admin MAC is the safest workaround.
I think this is still not right in 6.44.1 the date is 2019:04:03 feels like a really bad April fools joke?!
Maybe this problem I am having is unrelated but similar.
http://forum.mikrotik.com/t/ipv6-passthrough-rules/129116/1
I think this thread is ten years old!? this can’t still be waiting for version 7 can it?
Original poster here 
I am both shocked and amazed that this issue is still present in current day RouterOS v6.44.1 even though I reported it back in the days of RouterOS v4.x.
Regards,
Terry Froy
Spilsby Internet Solutions
#funfact a little over three years ago we were teased about the working solution with ROSv7 and we were shown a printout on how it behaves, but that’s about it I guess…
actually I guess that’s one main reason we use MTs for layer2-setups and as CPEs, the core is and probably will be junipers and ciscos for the foreseeable future 
MT need to rebrand: “Routing the legacy world”
We’ve been running IPv6 since September last year without issues. Multiprotocol IPv4 BGP sessions set next hop as the router’s loopback IPv4 or IPv6 addresses and IPv6 is MPLS switched between routers, avoiding route lookups at each hop. Core routers don’t run BGP, only IPv4 with MPLS so reconvergence is quick.
Recap:
Maybe it could help in a few small cases…
http://forum.mikrotik.com/t/fake-ipv6-recursive-nexthops/131915/1
This bug still seems to be present in 6.48.3.
This feature is added in ROS v7, v6 will stay as it is.