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