Hello Swinog members,
There is apparently an MTU issue with SwissPost website when MTU of the link is <1500 bytes. It is like if webserver answers everytime with 1500 bytes packets and doesn't make PMTUD.
The client connexion is over 6in4 with 1480 bytes MTU. No issues with other IPv6 enabled sites.
Can another person with <1500MTU connexion confirm the same behaviour, and maybe anyone from Swiss Post IT take a look at this probable ICMP filtering issue.
Below are the tests done:
jacota@cactus:~$ curl -6 http://www.post.ch/ <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="https://www.post.ch/">here</a>.</p> </body></html>
==> small packet <1480bytes ==> OK
jacota@cactus:~$ curl -6 https://www.post.ch/ no answer
==> SSL negociation with full packets ==> FAIL
jacota@cactus:~$ telnet -6 www.post.ch 443 Trying 2a00:17c8:0:103::20a... Connected to www.post.ch. Escape character is '^]'.
==> TCP connectivity with port 443 ==>OK
Best regards, Antoine Jacot-Descombes
On 2015-12-15 17:10, JACOT-DESCOMBES Antoine wrote:
Hello Swinog members,
There is apparently an MTU issue with SwissPost website when MTU of the link is <1500 bytes. It is like if webserver answers everytime with 1500 bytes packets and doesn't make PMTUD.
Your browser/OS should properly do Happy Eyeballs and make this invisible btw.
"Server:Microsoft-IIS/8.5" wow, that is fun to see, IIS doing IPv6.
Request URL:https://www.post.ch/assets/portal/vendor/jquery-1.11.0.min.js Request Method:GET Status Code:200 OK Remote Address:[2a00:17c8:0:103::20a]:443 Content-Length:42757
Seems to work quite fine from a non-1500 MTU link.
The client connexion is over 6in4 with 1480 bytes MTU. No issues with other IPv6 enabled sites.
Can another person with <1500MTU connexion confirm the same behaviour, and maybe anyone from Swiss Post IT take a look at this probable ICMP filtering issue.
You don't need to check from a non-1500 link to see that something is really b0rked in their network. A mere tracepath6 will show you this:
[...] 10: gw-sunrise.init7.net 9.188ms asymm 9 11: no reply 12: no reply 13: no reply 14: no reply 15: 2001:1700:3300::1 64.543ms asymm 11 16: 2001:1700:3300:2::2 23.897ms asymm 10 17: no reply 18: no reply 19: no reply [..]
Not going anywhere. As traceroutes don't work, it is extremely likely that somebody is silly enough to filter ICMPv6 and cause issues that way, but it could be anything else too.
One would think that after 20 years of IPv6's existence people would learn.
Note though there are various load balancers who do not properly handle ICMPv6.
Cloudflare solved it in a very reasonable way: https://blog.cloudflare.com/path-mtu-discovery-in-practice/
Google's load balancers apparently just forces the MSS to something magic that 'might just work'. Hence, never do a test for this against their network, they are breaking all kinds of things to just handle a few more bits (which in itself is good engineering work actually, just ignoring ICMPv6 on the other hand... is not).
Greets, Jeroen
-
JACOT-DESCOMBES Antoine -
Jeroen Massar