In a nutshell, Ubuntu and generally any host not having the role of router in the network will listen to Router Advertisements in order to form the SLAAC address or use DHCPv6 to acquire address and other settings.
Every node that has ipv6 activated will create a link local address, both hosts and routers.
The protocol dhcpv6 option in WAN6 interface basically instructs the router to acquire settings for ipv6 over DHCPv6. If your provider doesn't offer that, then it is useless.
If the router doesn't get a global prefix from your provider, then the hosts will not install a global address, but they will install a ULA address (something in the range fc00-fdff) which is configured by default on the OpenWrt.
Turns out things are a bit more interesting. DHCPv6 is disabled for the network, but there is another tool running:
To ease the routing the Z/IP Gateway will send out RFC 4191 router announcements. Clients who support RFC4191 will be able to communicate with the PAN nodes via IPv6 without special routes.
Turns out the other hosts (Ubuntu, Mac) are auto-assigning IPv6 addresses based on those announcements.
Z/IP Gateway sends out RFC 4191 announcements. They seem to be ignored by (some component of) OpenWRT. The behavior is different than i.e. Mac or Ubuntu. That's the problem.
In this case, the router advertisements are probably getting ignored because they have a local source address (Z/IP Gateway is a daemon running on the OpenWRT device).
Anyway, I fixed the problem by adding the route manually with ip -6 route add.
You probably should have noted that the OpenWrt was running this non-official package...that would have been a good clue. You never noted that the OpenWrt software isn't handling normal stuff. And that was quite confusing when you then state that OpenWrt doesn't do what other Linux distros do. Nonetheless, glad you figured it out.
(The announcements are probably not ignored; it's more so because it never gets an announcement - as it's the sender of them.)
odhcp6c is the dhcp client for ipv6. You don't have any dhcp6 server. Moreover the default setup for routers (that is with routing enabled) is to disregard the RAs. The valid setups for the upstream interface are static or dhcp6. You are not using any of them, so no wonder it doesn't work out of the box.
Many distributions and users prefer to handle router advertisements in
userspace; one example is OpenWrt, which includes a combined RA and DHCPv6
client. For such configurations, accept_ra should not be enabled by
default.
This would indicate the RAs should be handled by odhcp6c without tinkering with accept_ra.
I'll try adding some debug prints to the odhcp6c script to see what's really going on.
OpenWrt is a router distribution, normally you don't want a router autoconfiguring itself. remember anything can send a router advertisement... it's just a packet on the wire. if you have your router listening to them then any malicious or misconfigured device can DOS your entire network by advertising itself as an invalid route
Ok, but the default dhcpv6.script shipped with OpenWRT DOES perform at least SOME autoconfiguration based on RAs, as can be seen here (case ra-updated on line 230):
DHCPv6 doesn't provide route information so you have to either have static routes, or listen for RA on the upstream interface, so yes you want RA on WAN