This might be an ISP issue, but I don't know how to diagnose it. The issue is that there is no IPv6 traffic to or from the LAN to the WAN. I know there used to be about a week ago and I have not changed the configuration. The router has gotten an IPv6 address and prefix for LAN delegation. The clients are getting a prefix and can communicate among themselves with link local address or delegated address. I picked some IPv6 address from the DNS cache and tried to ping them. These fail due to no route to host. The neighbor list only has LAN or link local addresses. The route list has WAN and LAN prefix addresses. The WAN addresses have ether1 as the gateway address which is correct. At the top of the route list are two unreachable entries for ::/0 with a gateway address of one of the IPv6 WAN addresses. At first I thought the problem was related to v7.2 which installed overnight. I downgraded to 7.1.2 but it did not solve the problem. At this point I am out of ideas.

Update:
I noticed that the gateway for the unreachable ::/0 routes was not one of the WAN address. It was a mashup of two address. I added ::/0 entries for each of the 4 WAN address in the list with those addresses as gateways. One of those addresses must have been the secret because I now have LAN-WAN IPv6 traffic. Does this look like an ISP issue? Does the router just use the gateway address for ::/0 routes as given to it by the ISP?

It depends on what your configuration was previously, it may be incorrect and just happened to work accidentally.

In particular DHCPv6 has no mechanism to obtain or provide a default gateway. The Mikrotik DHCPv6 clientadd-default-route=yesis a hacky bodge, it uses the address of the DHCPv6 server from which the address/prefix/other information was received - this works if the DHCPv6 server and the default gateway are the same host, but otherwise fails so in general setadd-default-route=no.

If the WAN connection is IPoE the correct method is to use received router advertisments (RA) which unfortunately are not displayed by RouterOS, as discussed in other forum posts, and was completely broken in earler releases of RouterOS v7. The default IPv6 settings includeforward=yesandaccept-router-advertisements=yes-if-forwarding-disabled, so as you are forwarding you need to setaccept-router-advertisements=yes.

If the WAN connection is PPPoE you can either set the PPPoE clientadd-default-route=yes, as this works on point-to-point links, or use router advertisments.

It looks like it was previously working by luck. I had the DHCP client add a default route and as you said, it was using the DHCP server address as the address. I also had forwarding set but not accepting router advertisements. Both have been fixed and all looks good after a router reboot. Thanks.

我有一个类似的问题,我想知道它might be my recent upgrade from 7.1.3 to 7.2.3. ipv6 used to work, and it's not that set-default-route=yes mistake in the DHCP client. I had to set it to no to get it working in the first place. I get no route to host when trying to ping an ipv6 address on the Internet from the lan unless I have a ping running or recently had one running from my RB5009. If there's a ping going I can reach whatever I'm pinging, even get a score of 17/20 from ipv6-test.com. I lose 3 for icmp being filtered and no DNS entries for ipv4 or ipv6. Go figure, it's a consumer internet connection from Comcast. Looking at the packet sniffer it's apparent that the RB5009 is sending the no route to host replies to my pings from the lan.

I'm wondering if maybe I have some corrupt configuration. Apparently it's been an issue with recent RouterOS 7 upgrades. I found something really weird in the used prefixes in the IPv6 Pool. /70 prefixes. Is that even supposed to be possible? I thought /64 was the smallest you could go. I should have taken a screen shot. I deleted the pool and hit the renew button in the DHCP client settings and the /70s are gone. I'm thinking my next step is to just reset the configuration and set things up again.

Any prefix length is possible but the vast majority of host operating systems will only work dynamically with a /64 and SLAAC without any other modification.

/64 is definitely what you should be using on a home LAN even though it's technically possible to have other prefix lengths.