IPv6 it is working intermittently or not at all. I presume the routes are the problem.
/ipv6/route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP, v - VPN, g - SLAAC; + - ECMP
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
DST-ADDRESS GATEWAY ROUTING-TABLE DISTANCE
D v ::/0 pppoe-digi main 1
DAg+ ::/0 fe80::7a9a:18ff:fee0:4a89%VLAN78_MGMT main 0
DAg+ ::/0 fe80::f61e:57ff:fe84:ae76%VLAN78_MGMT main 0
DAc ::1/128 lo main 0
DAd 2a02:...:b600::/56 main 1
DAc 2a02:...:b600::/64 bridge main 0
DAc 2a02:...:b601::/64 VLAN80_HOME main 0
DAc 2a02:...:b602::/64 wireguard-server main 0
DAc 2a02:...:b604::/64 VLAN78_MGMT main 0
DAc 2a02:...::/64 bridge main 0
DAc 2a02:.../128 pppoe-digi main 0
DAc fe80::/64 eth2-WAN main 0
DAc fe80::/64 bridge main 0
DAc fe80::/64 pppoe-digi main 0
DAc fe80::/64 wireguard-server main 0
DAc fe80::/64 VLAN78_MGMT main 0
DAc fe80::/64 VLAN80_HOME main 0
DAc fe80::/64 VLAN79_GUEST main 0
The problem is that the correct rule (first one) is inactive (blue in Winbox)
D v ::/0 pppoe-digi main 1
With Disable Link Local Address is disabled in IPv6 Settings ping form router to ipv6.google.com is working as fe80::7a9a:18ff:fee0:4a89%VLAN78_MGMT routes are no longer present, but, off course, the internal equipment does not get a public IPv6 anymore.
I seen in the Routeros 7.23 topic some complaint about ping on IPv6.
If your WAN is provided via PPPoE, then there is no reason to enable "Accept Router Advertisements" in the IPv6 settings. Change that setting back to the default value:
/ipv6 settings
set accept-router-advertisements=yes-if-forwarding-disabled
Still, it appears that you have some other device(s) located in the VLAN78_MGMT annoucing themselves as router. Which will compete with the router itself. It's best two find out which those two devices are and disable Router Advertisement on them if they are no proper routers. Just like you don't want the same layer 2 network having multiple IPv4 DHCP servers active at the same time, you also don't want multiple devices sending out Router Advertisements messages at the same time on the same L2.
One has MAC address 78:9A:18:E0:4A:89 and one has F4:1E:57:84:AE:76 (both are MikroTik devices). Do not enable the advertise flag on those devices under their /ipv6 address assignment.
Some ISPs does RA over PPPoE, and even provide an address (actually a prefix) from another prefix pool. Though in that case, you should limit SLAAC interfaces instead of accepting from all.
That RA is useless for announcing the route, because PPPoE is a point-to-point interface (with only two ends). Even if the RA sent over PPPoE says the router is at fe80::dead:beef for example, then the PPPoE client has only one possible next hop for its route (which is the PPPoE interface itself). It has absolutely no way of to do "I want to send this packet to 2001:4860:4860::8888 using fe80::dead:beef as the gateway / the next hop".
Also, if DHCPv6 is used (to get the prefix) then the received prefix from RA is also unimportant, your router will use addresses assigned from the DHCPv6 pool on any of its interface for communication to the outside internet.
Actually not, in normal configuration, prefix from DHCPv6 pool is assigned on the bridge, and there's no global unicast address on the PPPoE interface. If SLAAC is enabled, then the PPPoE interface has its own address, and the router will use it for output connections, sometimes it's useful. I agree that in most cases it's not, but YMMV.
If your router is routing, then it'll have at least one IPv6 per its L3 interface (e.g. bridge ... or per VLAN interface ... or per physical port if used off bridge). And any of those IPv6 addresses is valid for communication with any of IPv6 hosts (either on LAN or WAN). Yes, it is custonary to use address, assigned to interface leading in "right direction". But when that interface is addressless (as it's most often in case with point-to-point interfaces), router will select some of its addresses (and, again, it doesn't matter which one).
And this is (with nany more words) what @CGGXANNX said by your router will use addresses assigned from the DHCPv6 pool on any of its interface ...
I have an IPv4 setup consisting of multiple IPIP links in a star-shape. None of those links have dedicated IP addresses assigned, rather they have pref-src set (to IP addresses of the most prominent LAN interface) just to see some sensible IP address in traceroute outputs. Without setting pref-src router might select an unsuitable address, possibly WAN IP address (for which remote router uses default route rather than "through VPN tunnel") or another LAN address which is not in the routing table of remote router.
ping ipv6.google.com
Pinging ipv6.l.google.com [2a00:1450:400d:811::200e] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 2a00:1450:400d:811::200e:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
The IPv6 firewall have only default rules. Tried with all rules disabled, to be sure.
Few dozen seconds later:
ping ipv6.google.com
Pinging ipv6.l.google.com [2a00:1450:400d:811::200e] with 32 bytes of data:
Reply from 2a00:1450:400d:811::200e: time=15ms
Reply from 2a00:1450:400d:811::200e: time=15ms
Reply from 2a00:1450:400d:811::200e: time=15ms
Reply from 2a00:1450:400d:811::200e: time=15ms
Ping statistics for 2a00:1450:400d:811::200e:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 15ms, Average = 15ms
C:\Users\Costel>tracert -6 ipv6.google.com
Tracing route to ipv6.l.google.com [2a00:1450:400d:811::200e]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 2a02:2f0c:c309:c104::
2 4 ms 4 ms 3 ms 2a02:2f0c:c3ff:ff00::2
3 3 ms 3 ms 3 ms 2a02:2f0c:c3ff:ff01::1
4 * * * Request timed out.
5 13 ms 13 ms 13 ms 2a02:2f00:8700::10e
6 * * * Request timed out.
7 15 ms 16 ms 16 ms 2001:4860:1:1::17ba
8 15 ms 14 ms 14 ms 2001:4860:0:1::7687
9 16 ms 16 ms 16 ms 2001:4860:0:1::59fb
10 15 ms 15 ms 15 ms lcbuda-ap-in-x0e.1e100.net [2a00:1450:400d:811::200e]
Trace complete.
I think my ISP is also involved in the problems. As, I said: IPv6 it is working intermittently or not at all
Wait to see what happens in the next days.
It will be used if you accept RA on the PPPoE interface, and the advertised address is unicast as you wrote, but for almost all ISP configurations that use PPPoE and provide DHCPv6, it's not necessary to turn on "Accept RA" on the PPPoE interface because:
Default route is already provided by PPPoE.
Prefix and / or address provided by DHCPv6 are routed to you already and:
If you requested address (via DHCPv6), then that address is installed on the PPPoE interface
If you only requested a prefix, then you'd most probably use a part of that on some of the router's interface(s), a bridge or some VLAN interfaces for example. In that case the router will use one of those assigned addresses for outgoing connection, because the PPPoE interface only has a link local (fe80::) address and that will not be used for non-link-local communication.
In my previous post I explicitly wrote:
I won't argue in the case where you completely ignore DHCPv6, if DHCPv6 is not used then of course you need to accept RA to get the non-link-local address.
My routers that run PPPoE clients all have accept RA disabled (either completely or on that PPPoE interface), and on most of them the router will pick the address I assigned to a WireGuard interface as outgoing IPv6 address for its outgoing connections.
Did you also resolve the issue that there are two other devices in the same layer 2 segment also announcing themselves as router? Because if you have 3 devices sending RA messages at the same time then the other clients will have their default gateway jumping around (depending on which one was the last one to claim to be the router, assuming they set the same RA Preference).
With accept-router-advertisements=yes-if-forwarding-disabled your router is no longer affected by the rogue RA sources, but all your other PCs / laptops / phones in the same layer 2 segment are still affected, until you are able to disable sending RA on those two MikroTik devices (disable the advertise flag on the /ipv6 address entries on those devices, also if possible, explicitly create IPv6 -> ND entries for the interfaces (not using the all one) with RA Lifetime cleared).
I believe so. There no other default route than pppoe one:
/ipv6/route/print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, d - DHCP, v - VPN
Columns: DST-ADDRESS, GATEWAY, ROUTING-TABLE, DISTANCE
DST-ADDRESS GATEWAY ROUTING-TABLE DISTANCE
DAv ::/0 pppoe-digi main 1
DAc ::1/128 lo main 0
DAd 2a02:2f0c:c309:c100::/56 main 1
DAc 2a02:2f0c:c309:c100::/64 bridge main 0
DAc 2a02:2f0c:c309:c101::/64 VLAN80_HOME main 0
DAc 2a02:2f0c:c309:c102::/64 wireguard-server main 0
DAc 2a02:2f0c:c309:c104::/64 VLAN78_MGMT main 0
DAc 2a02:2f0c:c309:c105::/64 bridge main 0
DAc 2a02:2f0c:c3ff:ffff::4f77:d4aa/128 pppoe-digi main 0
DAc fe80::/64 eth2-WAN main 0
DAc fe80::/64 bridge main 0
DAc fe80::/64 pppoe-digi main 0
DAc fe80::/64 wireguard-server main 0
DAc fe80::/64 VLAN78_MGMT main 0
DAc fe80::/64 VLAN80_HOME main 0
DAc fe80::/64 VLAN79_GUEST main 0
Disabled IPv6 on secondary Mikrotik devices (hAPax2 and CRS304) with same result - intermittent IPv6 connectivity.
You won't see the bad routes anymore on the main router because you've turn off accept-router-advertisements on it.
You'll need to check on one of the client devices (like a PC) and see which address that device picks as default gateway when it has no internet connection.
Use ipconfig for Windows, ip -6 route for Linux, netstat -rn -f inet6 on macOS, and look for the link-local fe80:: address used as gateway address. You have to make sure that address is always the one of the main router. If not, then extract the MAC address from the address to find the device.
I encountered the same problem. I was able to obtain the IPv6 RA and address normally through PPPoE, and the devices on the LAN port could also obtain the IPv6 address normally. However, data forwarding was ineffective. I couldn't ping any IPv6 addresses, and I couldn't access IPv6 websites. The problem was resolved after reverting to version 7.22.3.
Ah. If the ISPs want to give their customer a prefix larger than /64 then they need DHCPv6. It's a bummer that there are still ISPs that are stingy , and their customers have to use NAT when they need multiple subnets.
Did you try to just set up a DHCPv6 client instance and leave it active? Who knows, one day your ISP might suddenly enable DHCPv6.
My ISP gives /56 on DHCPv6 IA-PD, nothing (address not available) on DHCPv6 IA-NA, and a /64 prefix on RA SLAAC. So while my PPPoE interface itself won't get an address over DHCPv6, disabling SLAAC won't break anything, but enabling it will give the interface an address from a totally different BGP prefix pool, which is useful sometimes.
, and their customers have to use NAT when they need multiple subnets.