Sorry, but I see it differently. DHCPv6 (stateful/stateless) is still needed. Sure, it works differently than IPv4, but that doesn't change its necessity. Stateless, in particular, is required in many cases. DNS via SLAAC alone is sometimes insufficient, for example, with SIP phones.
You can assign address via SLAAC and still assign DNS via DHCPv6. Just configure it without a pool and with option 23 to assign DNS. That works fine here.
So BGP+BFD is not yet fixed? (introduced in rc1)
I’ll skip it then, thank you.
Thank you very much! The two big issues that I had, the one with the accumulated failed ACME certificates after every reboot, and the one with the routing rules export have been resolved with rc3.
Your answers to the questions might open up other ways of approaching the issue?
Even if there are no mentions of the BGP+BFD issues, I just tried rc3 and it seems to be working ok (at least the BGP peers stay connected - I haven’t tested any further for other issues).
So much for “every change is always mentioned in the changelog”…
every change is in the changelog, problems with BFD were not directly related to BFD, it could happen with any other ip traffic.
Which changelog line describes the fix? Then maybe we can locate the changelog that introduced it…
Under /system/device-mode/update, it was previously possible to set a property called authorized-public-key-hash. This option had been available for several versions, but there was no official documentation for it.
Recently, I contacted support to ask about its purpose. They informed me that it is a feature currently still under development.
I assume that, until it is fully ready, it has now been removed. Alternatively, it is possible that a different solution is currently being developed.
this change in rc1 introduced the problem:
route - fixed routes when scope was less than 10;
Can I get a little more info on this? I just upgraded a whole fleet of CRS3xx switches to 7.20.8/long-term and I’d like to know when/if I’m hitting this bug.
Most likely it will not affect you.
The performance regress was visible (system delay, not able to print/export interface, single CPU-core running 100%) on complex systems with thousands of interfaces. For example, a thousand of VLANs configured on vlan-filtering bridge. Or thousand bridge interfaces all running vlan-filtering with couple of bridged VLANs.
I know right!?? How dare I ask a question in the post that actually contains the answer and solution to the question you asked!
Also, since my reply to your post was my very first post on the Mikrotik Forum there’s no possible way for you to determine that I “always” answer a question with another question. But triggering an ungrateful troll with my first post is an achievement I can definitely be proud of. 
I spoke to soon, about 5 minutes after the reboot, a new log entry and a broken certificate appears:
I did another reboot, and about a little bit over 5 minutes after the reboot, another certificate entry appears, this time with the correct domain:
However, of course such attempt will never succeed. Although at this point the router already had internet connectivity, the www service on the router is disabled, and the firewall blocks access to TCP 80. The red error message does say "Timeout during connect (likely firewall problem)", this is correct.
But the fact that the router automatically tries to create the certificate entry and perform the challenge on it at reboot is not correct. I want to have control over this process (when to enable www and loosen the firewall). Or at least it should clean up the bogus certificates when the automatic attempts failed.
Ok thanks. I updated one router and indeed it now connects OK.
There is still an issue with the “automatic blackhole routes”. Now it automatically inserts a route of type “Dn” for advertised networks, distance 255 but no longer blackhole. It is not affected by the .blackhole setting.
I’m not having this issue. Do you have anything in add acme certificate?
Mine is all blank.
Run on RBRB5009UPr+S+
Maybe you can export your system config and see it you see anything out of the ordinary.
@MIKROTIK : can you add the device identify in body and subject for mail notification ?
The BGP-VPN4 redistribute other BGP multihop problem has not yet been fixed in this release.
Hi @edpa, when and in which version will this problem be included?