I can reproduce it too on box with win10 and the same IPv6 broker in Omnia.
No special messages in dmesg + syslog.
Actually there is no need to access the complete page, enough is just to take one element:
https://openstreetmap.cz/theme/img/osmcz.220x220.png
often it will fail too.
Well, it is logical 
But I don’t know, how to trace it.
No pakon, nothing special in firewall. And if it is firewall, it will transfer nothing. But it transfer some data, unfortunately not all.
All the routing stuff is a black box to me 
I have no idea what I should check and how I can “debug” it.
Router itself
root@turris ~ $ ip -6 route
default from 2001:470:6e:7b6::/64 dev 6in4-wan6 proto static metric 1024
default from 2001:470:6f:7b6::/64 dev 6in4-wan6 proto static metric 1024
2001:470:6e:7b6::/64 dev 6in4-wan6 proto kernel metric 256
2001:470:6f:7b6::/64 dev br-lan proto static metric 1024
unreachable 2001:470:6f:7b6::/64 dev lo proto static metric 2147483647 error -113
fd39:c274:6a4a::/64 dev br-lan proto static metric 1024
unreachable fd39:c274:6a4a::/48 dev lo proto static metric 2147483647 error -113
fe80::/64 dev br-lan proto kernel metric 256
fe80::/64 dev eth2 proto kernel metric 256
fe80::/64 dev wlan0 proto kernel metric 256
fe80::/64 dev wlan1 proto kernel metric 256
fe80::/64 dev 6in4-wan6 proto kernel metric 256
fe80::/64 dev veth7LGDU0 proto kernel metric 256
Inside lxc container
root@homeassistant:/# ip -6 route
2001:470:6f:7b6::/64 dev eth0 proto kernel metric 256 mtu 1480 pref medium
fd39:c274:6a4a::/64 dev eth0 proto kernel metric 256 mtu 1480 pref medium
fe80::/64 dev eth0 proto kernel metric 256 mtu 1480 pref medium
default via fe80::da58:d7ff:fe00:15b4 dev eth0 proto ra metric 1024 mtu 1480 hoplimit 64 pref medium
Laptop
[09:46:01 marian@nbmkyral ~]$ ip -6 route
2001:470:6f:7b6::/64 dev wlp3s0 proto kernel metric 256 expires 7002sec pref medium
fd39:c274:6a4a::/64 dev wlp3s0 proto kernel metric 256 expires 7002sec pref medium
fe80::/64 dev wlp3s0 proto kernel metric 256 pref medium
default via fe80::da58:d7ff:fe00:15b4 dev wlp3s0 proto ra metric 1024 expires 1602sec mtu 1480 hoplimit 64 pref mediumThe problem is probably caused by pakon or suricata. Because the problem has been solved by stopping services pakon-handler, pakon-monitor and suricata-pakon.
Nice. I can confirm it. Stopping of Suricata fixes this issue.
root@turris ~ $ ps w |grep pakon
709 root 1396 S grep pakon
8403 root 13352 S python3 /usr/libexec/pakon-light/pakon-handler.py
16298 root 95836 S {Suricata-Main} /usr/bin/suricata -c /etc/suricata-pakon/suricata.yaml -q 10 --pidfile /var/run/suricata/
root@turris ~ $ ps w |grep pakon
2409 root 1396 S grep pakon
8403 root 13352 S python3 /usr/libexec/pakon-light/pakon-handler.py
root@homeassistant:/# time curl -6 >/dev/null https://openstreetmap.cz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 33026 0 33026 0 0 118k 0 --:--:-- --:--:-- --:--:-- 118k
real 0m0.327s
user 0m0.122s
sys 0m0.021s@pepe could someone from team check it? Or I should report this to gitlab?
Could I keep Suricata switched off for now?
As a side note, I deactivated Pakon in Foris as it (or the croned tasks!?!?) was hogging up the CPU. Besides the GUI deactivation, I have to remove /etc/cron.d/pakon every time a OS update is pushed. I guess I should have reported both issues.
This is indeed a severe kernel bug, the same as https://bugs.openwrt.org/index.php?do=details&task_id=1541. It is not just log spam, each message corresponds to one dropped packet. The essence of the bug is that the IPv6 Flow Label field is misinterpreted as IPv4 ToS field, and then rules from RFC6040 are applied that result in packet dropping in 75% of the labelled flows.
With latest update these messages disappear, but my troubles with ipv6 continued. Only Suricata switch off helped.