Yes but these are also paid one time only. There is no monthly fee! Yes, there is bi-monthly check and extension of the license on the CHR, but no payment for that.
Upgraded from 7.20.8 to 7.21.4. Since the upgrade, IPv6 prefix delegation has started behaving inconsistently.
Immediately after boot, my main LAN receives the expected prefix:
2a01:799:XXXX:8c00:XXXX:XXXX:XXXX:XXXX
However, after some time, the prefix unexpectedly changes to:
2a01:799:XXXX:8c03:XXXX:XXXX:XXXX:XXXX
This setup was completely stable on 7.20.8, with no such behavior.
I currently have three networks configured:
/ipv6 address add address=::1 from-pool=pool6 interface=LAN
/ipv6 address add address=::1:0:0:0:1 from-pool=pool6 interface=BASE
/ipv6 address add address=::2:0:0:0:1 from-pool=pool6 interface=GUEST
Has anything changed in prefix delegation handling in 7.21.4, or is this a known issue?
Yes, prefix handling from pool changed recently (but I don't remember exact ROS version). Setting address=::1 from pool=XYZ doesn't guarantee to return the zeroeth prefix, it'll return some random free prefix.
Thanks, any fix? Have tried:
/ipv6 address add address=::0:0:0:0:1 from-pool=pool6 interface=LAN
This was fixed in 7.23, you can assign the "00" subnet ID.
Or, don't use that subnet/subprefix.
LE: removed "again" because you never could assign a specific subnet ID until 7.21(?).
7.23RC is not for me. Will they fix it soon in the stable/ LTS Branch ?
Since the fix is not backported to even 7.22.2, I don't know.
Depends how soon you expect "soon" to be.
Maybe when 7.23 reaches long-term will it be for you? 
Changed to
add address=::1:0:0:0:1 from-pool=pool6 interface=LAN
add address=::2:0:0:0:1 from-pool=pool6 interface=BASE
add address=::3:0:0:0:1 from-pool=pool6 interface=GUEST
Hoping for no more surprises.
I had the same problem, it is extremely irritating but like you I have surrendered and renumbered my networks to skip the :0: subnet instead of trying to keep track of what versions it has been fixed and what versions not.
Fortunately I was already using address-lists as much as possible and I only had to redo a number of DNS entriesā¦
I seem to have an issue with MAC address learning on RouterOS 7.21.4 on a pair of CRS309s that operate as an MLAG pair.
On RouterOS 7.20.8 I see that a MAC address is neatly migrated from port 2 to port 3 with /interface bridge host print after I live migrate a VM. On RouterOS 7.21.4 the entry won't budge and sticks to port 2 until I reboot both switches.
The issue is immediately resolved when I downgrade to RouterOS 7.20.8.
Are more people dealing with this issue?
Here the :0: subnet is used on the PPPoE interface to my ISP, but it is not listed as used from the pool.
Also it is my experience that IPv6 prefix allocation from a pool was not deterministic for VLAN interfaces in 7.20 and earlier. Prefixes would sometimes change after a reboot, which made the pool created from the ISP supplied IPv6 prefix pretty useless for me. 7.21 makes life easier, but I think you should still not configure the :0: subnet anywhere unless your are certain that this will not cause any conflicts.
Exactly. It wasnāt guaranteed and you could not specify your own subnet, it would just assign them in numerical order usually in the sequence you added the interfaces, it was GREAT that it was modified so you could specify the subnet in the address and it would remain the same. The only unfortunate thing was that the previous system usually used subnets :0: :1: :2: etc and in the new system :0: suddenly was a problem. So the subnet numbers changed for everyone, and when you cared about that (e.g. because there was DNS or firewall entries) it was a problem.
So for once I made a new numbering scheme, and I did not use :0: in that.
7.21.4 BUG (SUP-215681)
After upgrading my RB5009 from RouterOS 7.20.8 long-term to RouterOS 7.21.4 long-term, the WAN Ethernet link on ether8 started to flap repeatedly (82 times in 2 hrs) when connected directly to a Vodafone DOCSIS 3.1 cable modem operating in bridge mode.
The same physical setup was stable on RouterOS 7.20.8. The issue started immediately after the upgrade to 7.21.4.
Update (2026-05-6): The RB5009 ether8 WAN link flapping after upgrading to RouterOS 7.21.4 appears to be resolved by setting all Ethernet interfaces to the new RB5009 default l2mtu=1596.
Update (2026-05-10): The RB5009 ether8 WAN link was stable for several days, but after the last router reboot the link flapping returned without any configuration changes. Case re-oppened.
Upgraded from 7.20.8 and my container stopped working: ācould not load config jsonā. /container/print json shows config-json="".
Update
Fixed by using /container/repull
@EdPa Is there a plan on how often updates appear on long-term, now? In the past there had been huge gaps (number of updates in 2022 and 2024). stable is just a bit too fast, as I have to update 60 devices.
Iād love to see the console improvements (Ctrl+Left/Right/w) from 7.22 on long-term. 
I'm not @EdPa ... but anyhow: due to the nature of "LongTerm", updates occur rarely. They are of two types:
- when new ROS version becomes stable (e.g. 7.22 became stable on 2026-03-09), one version prior (whichever latest patchlevel) eventually becomes long-term (e.g. 7.21.4 became long-term on 2026-04-21 ... while 7.21.3 was stable between 2026-02-12 and 2026-03-09 when it was replaced by 7.22 as stable)
- when there's a grave bug to be fixed ... it can also be thought as "fix backported" from stable and/or development
This happened for 7.20.8, released on 2026-01-30, while 7.20.7 was already long-term (since 2026-01-08)
While #1 happens regularly (depends on development pace, with recent 7.X interval between new stable versions 7.Y (as opposed to 7.Y.z) was anywhere between 2 and 4 months), #2 happens only rarely.
The same "strategy" was in place already in ROS v6 ... where in late age release pace was slowed down considerably as none of development happened in v6 any more. Due to same reason, most of long-term releases were "patch-level" releases, but still spaced at a few moths in between.
So basically there's no fixed schedule to plan for installation of new long-term ROS version.
tl;dr
Releases happen when they happen.
The same issue was observed here, with one additional finding: repull did not work for a container created from a local image file. Such a container needs to be recreated from scratch.
This is exactly my case. Did not have the original image so had to recreate. But then I used /container/repull file= to fix the container.
However, this was not the end of it: while repull fixed missing JSON, it did not affect containerās layers.