I hadn't thought to check whether v6 traffic was still being received - next time it happens I'll run tcpdump on the Asus and see if I can see v6 Internet traffic arriving. If so I'll see if I can change the default route to the new LL address and get routing back.
Which LL (link-local?) address are you referring to? An interface identifier on the PPPoE WAN interface? IPv6CP does allow
negotiation of this.
Checking on my RB4011:
| Text |
1
23
45
| /ipv6 address print where interface=pppoe-out2
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local # ADDRESS FROM-POOL INTERFACE ADVERTISE
0 G 2001:4d48:XXXX:XX00::1/128 pppoe-out2 no 1 DL fe80::d/64 |
I statically assigned the global IP to the interface, so the (D)ynamic address fe80:: d is probably assigned by the BRAS.
But I don't use any link-local address for routing, I just point default route at the pppoe interface by name (actually just IPv6 unicast space):
| Text |
1
2 | /ipv6 route
add distance=1 dst-address=2000::/3 gateway=pppoe-out2 |
Hmm, I just noticed something very weird:
| Text |
1
23
| /ipv6 neighbor print where interface=pppoe-out2
Flags: R - router 0 address=2a02:68:1::164 interface=pppoe-out2 status="noarp" |
That IPv6 address is ipv6.pingbox1.thinkbroadband.com (i.e. the TBB BQM). I have no idea why it should appear as a direct interface neighbor, but it does hint at a Mikrotik IPv6 bug.
If IPv6 breaks again, I'll check whether any of this has changed.
FWIW, I'm running RouterOS 6.49.11. Mikrotik aren't really supporting v6 any more (I reported a memory leak problem a while ago and they told me to upgrade to 7.10.1 to see if the problem still exists), so I guess I'll be forced to go to 7.x sooner rather than later.