IPv6 packet drop caused by large MTUThis results in a rather miserable TLS (HTTPS) handshake failure in my case..
tcpdump shows a suspicious SACK packet when capturing packets through ppp0:
123 00:00:02.112304 IP6 (hlim 63, next-header TCP (6) payload length: 32) 2001:db8::1.12323> 2001:db8::2.443: Flags [.], cksum 0xabcd (correct), seq 23, ack 1, win 507, options [nop,nop,sack 1 {5761:5772}], length 0
And packets for {1:5760} had never appeared.
5760/4 gives 1440, which is MSS for IPv6 if MTU is 1500 (the maximum one).
MSS = MTU (1500 bytes for Ethernet) – IP header (40 bytes for IPv6) – TCP header (20 bytes)
As IPv6 no longer permits fragmentation (which IMO is quite reasonble), it occurs to me that the packet loss could be caused by some middle box who can’t handle such large MTU.
I tried specifying AdvLinkMTU 1480 in radvd.conf, and it turns out it solved the problem.
But actually this shouldn’t be necessary, as Path MTU Discovery (PMTUD) should have handled the issue transparently, perhaps with some minor performance penalty. PMTUD works by sending an ICMPv6 Packet Too Big packet back and let the sender resend a smaller packet.
I’m not sure why PMTUD does not in effect, presumbly some lazy operation man simply drops all the ICMP packets, including ICMPv6 ones. (which is really really bad practice in IPv6 world).
This results in a rather miserable TLS (HTTPS) handshake failure in my case..
tcpdump shows a suspicious SACK packet when capturing packets through ppp0:
1 2 3 | 00:00:02.112304 IP6 (hlim 63, next-header TCP (6) payload length: 32) 2001:db8::1.12323 > 2001:db8::2.443: Flags [.], cksum 0xabcd (correct), seq 23, ack 1, win 507, options [ nop,nop,sack 1 {5761:5772}], length 0 |
And packets for {1:5760} had never appeared.
5760/4 gives 1440, which is MSS for IPv6 if MTU is 1500 (the maximum one).
MSS = MTU (1500 bytes for Ethernet) – IP header (40 bytes for IPv6) – TCP header (20 bytes)
As IPv6 no longer permits fragmentation (which IMO is quite reasonble), it occurs to me that the packet loss could be caused by some middle box who can’t handle such large MTU.
I tried specifying AdvLinkMTU 1480 in radvd.conf, and it turns out it solved the problem.
But actually this shouldn’t be necessary, as Path MTU Discovery (PMTUD) should have handled the issue transparently, perhaps with some minor performance penalty. PMTUD works by sending an ICMPv6 Packet Too Big packet back and let the sender resend a smaller packet.
I’m not sure why PMTUD does not in effect, presumbly some lazy operation man simply drops all the ICMP packets, including ICMPv6 ones. (which is really really bad practice in IPv6 world).