|
Establishing cause of non-IPv6 http response on remote server?
![[ca]](/s/countries/ca.gif) Shadow Hawkins on Monday, 28 December 2015 17:40:56
I use Tumblr and when IPv6 is active I find that some of the content does not load. While tumblr.com does not use IPv6 (no AAAA entry), its CDN does, from what I can tell. On an image that was not loading, I decided to use wget to compare response times:
wget -4 https://41.media.tumblr.com/b5cca6b1b2a107ceb8e655e82ad4348e/tumblr_nzop3ixrgE1qigaa4o1_500.jpg
wget -6 https://41.media.tumblr.com/b5cca6b1b2a107ceb8e655e82ad4348e/tumblr_nzop3ixrgE1qigaa4o1_500.jpg
In the above case I observe the IPv4 method succeeds, while the IPv6 method fails, though interestingly a ping6 does succeed. A bit more checking on other images that load seem to indicate that some of the nodes don't have an AAAA entry (36.media.tumblr.com for example), while others do and respond (40.media.tumblr.com for example).
What is the best way to establish whether the issue is down to the source server or a routing problem between?
Establishing cause of non-IPv6 http response on remote server?
Shadow Hawkins on Sunday, 03 January 2016 01:10:58
I have contacted the people over at Tumblr to see what they have to say.
I suspect what we are seeing here is a case where a service doesn't support IPv6, but has providers in their CDN that do to some extent. This means that if a node suffers from an IPv6 issue they don't know, since their health checks aren't looking out for this. Also, at this point only a handful of customers will notice and of those only a few would be technically savvy to understand the issue.
Establishing cause of non-IPv6 http response on remote server?
![[nl]](/s/countries/nl.gif) Shadow Hawkins on Sunday, 03 January 2016 13:11:24
Same problem here. I often encounter links to images hosted on n.media.tumblr.com and those images would never load for me.
n.media.tumblr.com does respond to ping6, but the images never load. It looks like the webserver doesn't listen on IPv6.
Establishing cause of non-IPv6 http response on remote server?
Shadow Hawkins on Monday, 04 January 2016 16:10:11
The response I got back from them was generic. Just thank you for the suggestion and they would pass it on. No acknowledgment of a roadmap or problems in their network. I imagine I shouldn't have expected more.
Establishing cause of non-IPv6 http response on remote server?
![[de]](/s/countries/de.gif) Shadow Hawkins on Wednesday, 13 July 2016 14:58:28
Andre-John Mas wrote:
The response I got back from them was generic. Just thank you for the suggestion and they would pass it on. No acknowledgment of a roadmap or problems in their network. I imagine I shouldn't have expected more.
I have similar problems with tumblr.
Over sixxs I can wget a file with IPv4 without problem, over IPv6 it hangs forever.
On another IPv6-capable host, that has IPv6-connectivity over DFN it works.
Both systems resolve 67.media.tumblr.com to 2001:4de0:ac10::1:1:14, so a DNS problem is unlikely.
Traceroute works in both cases.
This seems to be a problem with sixxs not with tumblr.
__________
http://67.media.tumblr.com/6cb51e6084d6c9fe4f1c8ee3c4ff40f1/tumblr_oa04ycjxT51ufqf11o1_250.jpg
I only waited about a minute or so
Establishing cause of non-IPv6 http response on remote server?
Shadow Hawkins on Wednesday, 13 July 2016 15:00:53
Your forum-software stripped my footnote-numbers without warning.
First one is the file
Second one s the explanation to "forever"
Establishing cause of non-IPv6 http response on remote server?
It is a problem of MTU: Tumblr's servers are dropping ICMPv6, including ICMPv6 Packet Too Big.
Thus when Tumblr's servers send large packets (1500 bytes) back, the PoP notes that the packet is too big to fit the tunnel (typically 1280 to 1480 bytes, depending on setting) and sends back a ICMPv6 Packet Too Big. But, as the Tumblr server/load-balancer/whateversetuptheyhave drops that packet, they will never figure out that the packet is too big and tada, TCP is locked.
Solution:
- Let Tumblr properly fix their servers and let them support ICMPv6.
Note that they are not alone, Google had this problem also (they are magically guessing TCP MSS apparently....), Cloudflare had it too with their load balancers but they fixed it properly.
(or hacky hacky: force TCP MSS on your endpoint to the magically guessed 'correct' size... but that only works for TCP, not UDP).
|
![[ch]](/s/countries/ch.gif)
on Wednesday, 13 July 2016 15:04:03
Posting is only allowed when you are