This is a joke, not an allocation.
I think by default doesn't have any preference and will just ask a prefix.
It doesn't make much difference if you setup the tunnel over v4 or v6.
I think it is more like a warning than anything serious.
These are link locals.
People keep saying that. Either way, 18,446,744,073,709,551,616 hosts is enough for my modest home. And short of filling a 19 inch rack, I doubt I have enough switch ports for it.
I do believe I read somewhere that /64 is considered common for residential connections.
Correct, it is set to auto. At which point the ISP's modem gives OpenWRT an address in the /64 range (or allow it to pick one, since it is stateless) and provides a /60 range to play with.
I figured IPv6 was a more resilient and efficient protocol, allowing for better negotiation and larger packets. Although I suppose since all hardware is still working dual-stack, it's still limited to 1500. To my annoyance, even an IPv6 tunnel still generates them nasty AEAD errors in OpenVPN as all my packets get fragmented.
Either way, this is what I've got now and I have to find a way to make it work. My home network has been disconnected for days now while I'm trying to get the VPN to work well.
So it's not that the router doesn't know if it should send a packet over the WAN or the TUN because they both exist in the same range?
I still would love to suppress them if it is fine this way. They are polluting a perfectly decent log.
I know. Which is why I said there was little to do about them. The vpn-policy-routing package loves them too when it creates a firewall table for the WAN.
I already disabled all the extra IP's that Windows makes by default. It's crazy to do an ipconifg and be confronted with at least 6 different IPv6 addresses.
In completely unrelated news, my VPN provider asked me to switch from UDP to TCP because of all my AEAD errors. If I establish the VPN tunnel on my PC while connected to the router, I reach 100Mbit, if I establish it on the router I reach 60Mbit. At that point the router is "only" using about 30% CPU. Odd.
That is incorrect, you might have enough plain IPv6 addresses - but you don't have prefixes to route or segment your network. The smallest prefix possible (without breaking SLAAC and more) is a /64, and if you need to route (such as in your case right now), you need at least two /64 prefixes (yes, that means one is wasted with just 1 active device, but that's still the nature of routing). of those.
Therefore recommendation for residential connections is at least /56, up to /48 on request (but without any justification needed). As trendy mentioned, an ISP only handing out a single /64 is a bad joke, be it because their mandatory router doesn't support DHCPv6-PD properly or because they've messed up their configuration, it makes it virtually impossible to use IPv6.
If you say so, I obviously have a lot to learn about IPv6. I guess I'll have to make it work, and right now as soon as I tell the VPN provider to give me an IPv6 endpoint, I lose my route to said endpoint. But if I disable WAN6, I lose my ability to set up a tunnel over IPv6 (or get to sites running on 6 outside of the tunnel). If there is a way to make it work, I would love to learn.
That is not exactly true. You can have jumbo frames regardless of the IP protocol.
But this is not your issue here.
The router knows where to send the packet, don't worry about that.
Unless there is an issue, I don't think you are going to read the logs. This could be suppressed if you reduced the logging verbosity.
I'm an IT infra admin, I love reading logs. 
Unfortunately, my CCNA is a bit... outdated.
So, to get back to the issue. The problem exists the instant my VPN provider gives me an IPv6 address as an exit point. At that point OpenWRT is no longer able to reach anything, thus also unable to reach the VPN server to renew its keys. A few minutes later, the tunnel is gone. Barely enough time to test anything.
As far as the Jumbo frames go, I do believe the IPv6 frames can go a teensy bit higher compared to IPv4. But it's a moot point if everything in between uses 1500. It's the main reason I haven't turned them on in my home network. I don't know what the performance impact is if OpenWRT has to fragment all those packages every time my computers want to talk to the Internet.
Normally the OpenVPN should create a static route for the destination IP of the endpoint via the wan interface.
Is that created? I don't see it in the routing table.
This may be because the OpenVPN server is using the –redirect-gateway local
Better ask your VPN provider before we think of a workaround on that.
Sorry it took a while to get back to you. I'm in the middle of a software migration at work and needed my connection to remain stable.
Just checking the PUSH message I see redirect-gateway without the local, so I'm assuming that's good:
PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,redirect-gateway ipv6 def1 bypass-dhcp,dhcp-option DNS 10.18.121.1,dhcp-option DNS6 fde6:7a:7d20:e63::1,tun-ipv6,route-gateway 10.18.121.1,topology subnet,ping 10,ping-restart 60,ifconfig-ipv6 fde6:7a:7d20:e63::101d/64 fde6:7a:7d20:e63::1,ifconfig 10.18.121.31 255.255.255.0,peer-id 0,cipher AES-256-GCM'
Isn't this the redirect?
add_route_ipv6(::/3 -> fde6:7a:7d20:e63::1 metric -1) dev tun0
/sbin/route -A inet6 add ::/3 dev tun0
add_route_ipv6(2000::/4 -> fde6:7a:7d20:e63::1 metric -1) dev tun0
/sbin/route -A inet6 add 2000::/4 dev tun0
add_route_ipv6(3000::/4 -> fde6:7a:7d20:e63::1 metric -1) dev tun0
/sbin/route -A inet6 add 3000::/4 dev tun0
add_route_ipv6(fc00::/7 -> fde6:7a:7d20:e63::1 metric -1) dev tun0
/sbin/route -A inet6 add fc00::/7 dev tun0
Can somebody please help me get this thing up and running? My Linux systems won't update anymore because they're preferring to go over IPv6, which doesn't route out.
did you follow this up?
not really, it's messages that show selective routes which are aimed at the routing table... not whats currently in the routing table(s)_... which would also show a) what was applied and b) what other routes are present both of which you need... and others will need... to actually be able to help you... other diagnostics like tracerts and related information also assist you and others...
how about actually posting your full routing table when the connection goes up so we have something to work with? a brief tcpdump on tun0 for ipv6 is also a wise move.