IPv6 Packet Loss

[mbr]

While testing the free plan of Cloudflare I noticed a strange issue regarding IPv6 connectivity to my site and further testing revealed that all Cloudflare driven websites seem to be affected for me.

The problem occurs when issuing a TCP handshake over IPv6. The first one or two handshakes might work fine without any issues, however, any subsequent handshakes will lead very likely to a TCP retransmission and probably to timeouts depending on the software used. To demonstrate this with an example, here I execute curl -6 -I https://thunderbird.net (they use Cloudflare) 3 times. The following screenshot of all three tries show how the hanshakes turned out:

In the first try (highlighted red) everything works fine, the second time (green) two connection attemts with two retransmissions each are issued without any success (timeout). The third time (blue), the handshake is successful after one connection attempt with two retransmission issues.

Now, there is no way that this is sensible rate limiting because I can reproduce this with any new Cloudflare website on the first try. Moreover, this does not happen whatsoever with IPv4 on Cloudflare websites where I can happily send dozens of requests like the above without a single retransmission happening.

To rule out any problems on my side such as faulty hardware or TCP/IP stack issues I tried this with different devices and operating systems on a dozen of Cloudflare websites and non-Cloudflare IPv6 websites and the result is still the same. Only on Cloudflare IPv6 websites the retransmission occurs. The only thing I could not rule out was an ISP issue because I currently do not have access to any other IPv6 network besides my own. In case this helps, here is a traceroute (my provider is DTAG):

$ tracert -6 thunderbird.net

Tracing route to thunderbird.net [2606:4700:20::6819:af0d]
over a maximum of 30 hops:

  1     1 ms     2 ms     1 ms  <REDACTED>
  2     9 ms     9 ms     8 ms  2003:0:8301:4800::1
  3    12 ms    11 ms    12 ms  2003:0:1304:800d::1
  4    13 ms    11 ms    12 ms  2003:0:1304:800d::2
  5    14 ms    12 ms    13 ms  lo0.franco71.fra.seabone.net [2001:41a8:600::47]
  6    13 ms    12 ms    14 ms  2001:41a8:600:2::19e
  7    12 ms    12 ms    12 ms  2606:4700:20::6819:af0d

Trace complete.

Another probably interesting side note is that this problem is not as apparent when using a web browser. In my experiments I have noticed for example that Chrome will very quickly switch between IP addresses (also from IPv6 to IPv4 for example) and also sends multiple SYN packets which seems to somwhat remedy the situation although retransmissions still occur, but not to an extent which is noticeable during web browsing. However, if I “pin” a domain to a single IPv6 address (by modyfing the hosts file for example), I can also cause timeout issues in in Chrome.

So my question is basically: is this expected behavior? What is going on here?

[clippow]

Hi,
I am experiencing similar problems with TCP retransmissions. I use dnscrypt-proxy as caching DNS server on my local machine and I’ve configured Cloudflare as remote DNS (over HTTPS). For local name resolution (LAN) I use my router’s DNS server.
I noticed that name resolution of external hosts with Brave-Browser (Chromium based) is sometimes slow (several seconds). Wireshark showed up delays due to TCP retransmissions while contacting Cloudflare DNS via IPv6. My provider is also DTAG/T-Online.
Couldn’t figure out the root cause so far. Further investigations ongoing.
Best regards

[mbr]

Thanks for your answer. In the meanwhile I got access to another IPv6 network where I cannot reproduce the problem. Maybe yet another case of crappy DTAG peering .