Hi, I'd like a moderator to raise this with BT's network team please, as it's a routing issue rather than a line fault.
Problem: On BT Fibre (Smart Hub), HTTPS connections over IPv6 to GitHub's servers are reset by the remote end during the TLS handshake around 50–85% of the time. The same requests over IPv4 succeed 100% of the time. As a result, github.com pages load without their CSS/JavaScript and need several refreshes.
Affected: GitHub's IPv6 range 2606:50c0:8000::/48 to 2606:50c0:8003::/48 (hosts github.githubassets.com and avatars.githubusercontent.com). All four prefixes are affected.
Test results (13 Oct 2026, 15:50 UTC, wired Ethernet, no VPN/proxy/AV):
- IPv6 to github.githubassets.com: 17/20 failed ("Recv failure: Connection was reset" / "schannel: failed to receive handshake")
- IPv4 to the same host: 0/20 failed
- The TCP connection completes; the reset arrives during the TLS handshake
- It doesn't depend on the website name requested (same result with a different hostname to the same IP), so it isn't content filtering
- Not MTU: 1500-byte IPv6 pings (1452-byte payload) to the same address succeed with 0% loss
- Other IPv6 sites (Google, Cloudflare, Facebook) work 100% over IPv6
IPv6 traceroute:
1 <1 ms [my hub]
2 2 ms 2a00:2302::1103:203:66d
3 *
4 *
5 13 ms 2a00:2380:107::f9
6 *
7 13 ms 2606:50c0:8001::215
The route is short (BT → GitHub at about 13 ms), so this looks like a problem at or near the BT–GitHub connection point, possibly a faulty link or load-balancer member that only some connections hash onto.
Workaround in place: I've set Windows to prefer IPv4, but other devices in the house are still affected, and I understand IPv6 can no longer be turned off on the Smart Hub.
Happy to run further tests. Could this be passed to the team that handles BT's IPv6 connections to other networks?
