Router info:
Model: Xiaomi Mi Router 4C
Firmware: OpenWrt 21.02.3
My ISP delegates me a /60 global prefix. Also the lan interface gets an IPv6 assigned within the prefix. Connected clients (PC, mobile etc.) also get IPv6 addresses (both GUA and ULA).
But wan6 interface does not show any IPv6 address. Also IPv6 upstream seems broken (showing fe80::1 as DNS and Gateway). Everything is OK in IPv4 side.
I cannot access global Internet using IPv6. No response to ping6, traceroute6 etc.
This sounds all good to me. You're not allowed to use the any address from the delegated prefix on the wan interface (if that's where the delegating DHCPv6 server is). From https://datatracker.ietf.org/doc/html/rfc3633#section-12.1
Upon the receipt of a valid Reply message, for each IA_PD the
requesting router assigns a subnet from each of the delegated
prefixes to each of the links to which the associated interfaces are
attached, with the following exception: the requesting router MUST
NOT assign any delegated prefixes or subnets from the delegated
prefix(es) to the link through which it received the DHCP message
from the delegating router.
And fe80::1 is perfectly fine both as gateway and DNS server, as long as that's actually an address on the wan link. And I assume it is. Doesn't it work?
Wireshark shows that IA_PD and DNS options are coming from two different Link-Local addresses. IA_PD from fe80:xx...xx:7fb6 but DNS from fe80::1 having lower preference value. fe80::1 gives "Status: NoAddrAvail" in response to IA_NA. May be this is why wan6 does not get an IP.
But traceroute6 gets no response from any upstream hops.
There is nothing indicating any error or problem in the info we have. That doesn't mean that there can't be a problem. Just that the provided info is too limited to tell if there is one. You seem to be testing all the stuff that doesn't matter. Your goal with the internet connection isn't just to run a traceroute, is it? I assume you want https access to some IPv6 site? So test that, then.
I agree that the failing traceroute is a bad sign, but it needs to be followed up with other tests to confirm a real problem. It's perfectly possible (and some will claim reasonable) to filter traceroute handling on routers, without breaking anything except traceroute. Another possiblity is that infrastructure addresses, including the link addresses used by the routers as sources for the icmp6 errors, are filtered before they reach you.
Why not just test real connectivity over IPv6 to some site you know will be answering? For example
bjorn@miraculix:~$ curl -I 'http://[2600::]'
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.16.1
Date: Sun, 19 Jun 2022 08:37:22 GMT
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://[2600::]/
Set-Cookie: NSS=AAAAAGKu4EJ32wAKe919Ag==; expires=Thu, 31-Dec-37 23:55:55 GMT; path=/
If you get an answer like that, then you know that you can reach the world and the world can reach you. Whether you can see traceroute hops on the way or not doesn't matter. Then you can go on with the DNS settings and see if it works using http://sprint.net or whatever from an IPv6 only client.
One final note about the fe80::1 (or any link local) address for DNS: Although this is fine, it will cause problems if you simply forward that address to clients behind your OpenWrt router. Link local addresses can obviously not be routed. So you either need some global resolver address for your clients (e.g Google or Cloudflare), or you can let e.g dnsmasq handle DNS for the LAN clients. dnsmasq or other resolvers running on the OpenWrt router can use the fe80::1 as a forwarder if you like, but the configuration must include the interface qualifier (like "fe80::1%wan" or similar). I haven't tried, but I would hope that any automatic config generation script does that by default.
???
Incorrect, the OP can merely assign a /64 (or greater) from the PD to wan6.
It merely seems the OP failed to do so.
I do agree it seems the RFC warns against it, though. Subsequent RFCs that obsolete the one posted, do not mention it.