IPv6 connections to GitHub (2606:50c0::/32) reset during TLS handshake – IPv4 fine – moderator help

[nickfinch]

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?

[Crimliar]

Excuse me for being stupid here but I though the handshake was end to end - ie between the server and client, which would be your end-point device and not the router?  *Unless your device is masquerading (has it's uses)!

Using IPfoo as an extension in my browser, I see the main guthub accessed by IPv4, but various assets are accessed by IPv6 - I would have assumed this is normal!

Sorry if I'm off at a tangent, but I trying to understand the problem when all I really see is the internet being the internet!

[nickfinch]

Yes, TLS is end to end between my PC and GitHub, and the hub just passes it through. I don't think the hub is at fault. The problem is a TCP reset that kills the connection before the TLS handshake completes. A reset can be sent by the server or by any device along the route, and from my end I can't tell which. 

And yes, mixed IPv4/IPv6 is normal. I'm not complaining that the assets use IPv6, but that IPv6 connections to them fail most of the time:

 - IPv6 to github.githubassets.com: 17/20 failed
 - IPv4 to the same host: 0/20 failed
 - IPv6 to Google, Cloudflare and Facebook: 100% OK

An 85% failure rate on one destination, with everything else fine, is more than the internet being the internet. In the browser it shows as GitHub pages loading without styling until you refresh a few times. Something between BT and GitHub's IPv6 servers looks broken, and I'd like BT to check their side of that link.

Hope that makes a little more sense?

[licquorice]

Is the problem solely with a BT connection or does the same problem occur with a different network?

[nickfinch]

Solely with a BT connection. Same machine (it's a laptop) on a different network and it's fine.