This has been bugging me for a while. IPv6 on all devices, including the router itself will stop working. The only way to fix it is to either reboot the mikrotik, or to go into the DHCP6 client and manually hit "renew". Nothing changes after hitting renew except that IPv6 starts working. I checked all the routes, addresses, the DHCP lease itself, etc. All of it looks fine and identical before/after renewing. The DHCP6 lease from the ISP looks fine, it still has 6 days left, the prefix is correct, the addresses are correct, the default route is correct, I have no idea what the problem is. Maybe it's not the mikrotik at all, and instead is something wrong on the ISP side? Anyone else seeing this?

Probably ISP do not asign static IPv6 etc. etc. etc.

Paste this on terminal and reboot, see if solve on long term.

terminal code

/ipv6 nd
set [ find default=yes ] hop-limit=64
/ipv6 nd prefix default
set preferred-lifetime=45m valid-lifetime=1h30m

When "IPv6 stops working", can you ping the default route gateway from the router?

Probably ISP do not asign static IPv6 etc. etc. etc.

Paste this on terminal and reboot, see if solve on long term.

terminal code

/ipv6 nd
set [ find default=yes ] hop-limit=64
/ipv6 nd prefix default
set preferred-lifetime=45m valid-lifetime=1h30m

OP has clearly stated that "nothing changes", which (if true of course) rules out the possibility that the local hosts would stick with an old prefix while the ISP would issue a new one (which is a scenario your code seems to address if I read it properly).

So to me it either looks like a Mikrotik bug (which I cannot confirm or deny by my own experience as my ISP still pretends IPv6 does not exist and all the other few ones I work with just do not use DHCPv6), or as if the ISP network was "forgetting", due to some intermittent failure, some routing information that gets created while processing a DHCPv6 request from the client. So once that happens, it stops delivering traffic to the client until the client sends a DHCPv6 request, which would happen spontaneously but in hours or days, once the lifetime of the lease would expire.

If the latter is the case, the solution is to talk to the ISP and describe the situation, and the temporary workaround is to configure a /tool/netwatch item that will keep pinging some resilient IPv6 address and spawn the DHCPv6 renew if it stops receiving responses. If it turns out that the workaround needs to be permanent, a scheduled script will give better results than netwatch, as netwatch would only try once after each failure whereas the scheduled script can retry every N minutes while the connection is down and can monitor multiple canary addresses to avoid false positives.

There is also one more possibility if "nothing changes" is only "almost true". The DHCPv6 client has an add-default-route parameter which, however, works different than the same parameter of IPv4 DHCP client - whereas the IPv4 DHCP server explicitly indicates the address of a gateway element (router), a DHCPv6 server doesn't, so RouterOS takes an assumption that the DHCPv6 server is also the router and uses the address of the DHCPv6 server as the default IPv6 gateway. So if there are multiple devices in the ISP network that serve as both routers and DHCPv6 servers and one of them fails, the DHPCv6 renewal comes from another one and the gateway of the IPv6 default route changes.

Nothing changes after hitting renew

The default 30d / 7d are > of default 3d on server side (not MikroTik problem, are default RFC values...)

So for internal network the IPv6 expires 4 day later of what is already expired...

The default 30d / 7d are > of default 3d on server side (not MikroTik problem, are default RFC values...)

So for internal network the IPv6 expires 4 day later of what is already expired...

`
Sorry, but unless I'm missing something, this theory makes no sense.

Even if what you said is true that the ISP is handing out 3d leases which is 4 days shorter than the MikroTik default Preferred Lifetime value in the router advertisements, the fact is that the DHCPv6 client on the MT should be automatically renewing the lease at the halfway point (1.5d), just like DHCP works on IPv4.

If the ISP's DHCPv6 server does not honor or respond to lease renewal, and expires the lease prematurely and/or offers a different prefix (dynamic), this also should be no problem, since MikroTik finally added RFC9096 support to RouterOS in 7.9:
`

*) ipv6 - send out RA packet with "preferred-lifetime" set to "0" when IPv6 address is deactivated;

`
So old SLAAC prefix advertisement will be properly deprecated on the user's LAN, and new RA with new prefix will take its place. This means that RA Preferred Lifetime does not have to exactly match DHCP server lease time. The two times can be out of sync & the RA lifetime longer than the DHCP lease time, and yet things should still work properly.

Also, as has already been pointed out, OP stated nothing else changes. When he manually triggers lease renewal, the ISP is NOT offering some other different prefix. The IP address does not change. Traffic just starts flowing again.

Finally, your theory that the ISP is using a 3d lease time is contradicted by the original post itself, which CLEARLY shows "6d4h58m20s" remained on the lease at the moment the problem happened to him in that particular instance.

Based on this, I can only conclude that in this case, absent possible additional detail that we are still missing, the problem is actually on the ISP side. It sounds like the ISP stops routing the DHCPv6-PD customer prefix before the lease has expired. I would guess that manually renewing the lease causes this issue to clear up on the ISP side, presumably because the DHCP server triggers some kind of re-propagation of the prefix/route on their end.

If the original poster can narrow down that this problem seems to almost always happen exactly after X time has passed, he could work around the problem by adding a scheduled task on the router that manually renews the DHCP lease, say, every 6 hours (or whatever).

(I suppose one thing that would be interesting for OP to check would be to see if maybe the ::/0 default route is disappearing out of his MikroTik's IPv6 route table, and is maybe coming back whenever manual lease renewal is triggered? THAT could certainly also explain the described symptoms, and also might just be an actual ROS bug, though it's one I haven't seen happen myself so more testing will be needed to determine exact conditions necessary to trigger it...)