I’d just like to add my plea that this get fixed, soon.
I just recently emailed support about this, being unaware of this forum thread, and got the (apparently common) “known issue, will be fixed in the future” response.
I need to know if this is going to be near future, or far future, as this is a show-stopper for us, and the age of this thread has me rather worried.
Same here. We’d like to have full IPv6 support in 2014. We might have to abandon our mikrotik gear and buy something else.
Any idea if this bug has been resolved ?
I was working on a lab this morning attempting to implement this very scenario and ran into the same problem. I would like to see the fix for this issue implemented as this thread is now over three years old.
The workaround of using incoming filters to manually set a link-local hop is not very scalable at all and breaks a number of built-in redundancy features should otherwise be available in this type of setup.
Please, can we get a firm commit from MK staff to resolve this?
Thanks!
This is becoming an increasingly serious problem.
And here we are… Deploying IPv6 using static routes… Who would have thought?!
I’m having the exact same issues. What I don’t understand is, why if the router has a valid route to the Loopback of its neighbor can it not use that route to figure out a path to the neighbor for a BGP route to that Loopback? This really needs to be fixed. For all intents and purposes the router knows how to reach the loopback of its neighbor. You can prove that by pinging. Why can’t it see that the BGP route is reachable by that address? Fix this quickly please. As others have mentioned OSPFv3 shouldn’t even be a feature if it’s not going to play nice with BGP.
I’m running out of IPv4 addresses. 
Hope this will get fixed soon.
+1
+1
ETA please Mikrotik
Sent from my SM-G900F using Tapatalk
This feature most likely will be implemented in version 7.
Good to hear Maris.
Will the (related) OSPFv3 /128/LA-Bit bug also be fixed?
Will be fixed also in v7.
Obvious question.. 
When can we expect v7 ?
Great question!
Can someone explain the LA-bit bug briefly? Is it related to ospfv3 not importing LSAs with the LA-bit set?? i.e. /128 loopbacks from other vendors?
If so, what are you doing in the meantime? /127s or redistributing connected?
cheers!
thanks for the laught 
Yes. sadly, static routes, sometimes multiple ones with check-gateway with differing metrics to hopefully capture the most likely failure scenarios. But alas, when there is a hiccup somewhere, most of our routeros devices in the affected part of the topology just drop off the network (on IPv6) until the situation is resolved (alternatively someone could go manually update the static routes).
If you have ciscos you can force the loopback link type to point-to-point and get them to advertise /64’s (assuming you used /64’s). We have another vendor though that that workaround isn’t available, and they insist (as per the RFC requirements) on advertising their loopbacks as /128’s with the LA bit set. I’ve thought about seeing if I could get them to also advertise the companion /64 (perhaps with a redistribute or policy), but I’m hoping this will be fixed before I have to resort to that (or making sure there are no RouterOS devices in the relevant pathways when we get IPv6 connectivity requests).
You could also possibly see if you could strip off the LA-bit on the originating devices.
Great question… ping timeout!