My PC is getting along just fine with IPv6 but unfortunately all my Androids have some delay when loading a website. So frustrating to have to disable IPv6 just because Google cannot implement it correctly on Android.

https://code.google.com/p/android/issues/detail?id=79576

There are so many users that got the same problem since lollipop until now. Already set the router. The problem persists.

Except IPv6 performance on Malaysia youtube streaming.

What can I say....right after 11AM.....50kb/s

[attachmentid=7776939]

For the 10 5 or 8 seconds before clock strikes 11:00AM...I got 400KB/S.....then 50KB/s......
EDIT2:
That it ....everyone with 50KB/s IPV6 youtube throttling should send feedback together with CDN info.

First, visit https://redirector.googlevideo.com/report_mapping to find out your assigned CDN.

Then visit youtube website, scroll down to bottom and click 'Send Feedback'
[attachmentid=7776984]

Make a feedback on Malaysia youtube CDN server with explicit mention of IPv6 slowdown to 50KB/s during 11AM to 1AM.

The more people complain about this to youtube.......the better.
Do realize this 'throttling' session has been happening since 2013.

[/spoiler]
Unifi users seem to have 'better' CDN allocated to them.
So, based on https://redirector.googlevideo.com/report_mapping , what are CDNs allocated to both of you?

Bundled free dlinkddns is linked to DLINK MAC addresses now, can't use it on other router.......technically I can.....telnet/ssh into the router and use 'macchanger -m XX:XX:XX:XX:XX:XX interface' , it works.....and editing/adding the profile of available dynamic dns list......
The older version of TM lousy router doesn't clamp TCPMSS to PMTU.

Quoting wikipedia:
IPv6 routers do not support fragmentation or the Don't Fragment option. For IPv6, Path MTU Discovery works by initially assuming the path MTU is the same as the MTU on the link layer interface where the traffic originates. Then, similar to IPv4, any device along the path whose MTU is smaller than the packet will drop the packet and send back an ICMPv6 Packet Too Big (Type 2) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.