kern/143666: PMTU black hole detection not implemented
a at arifumi.net
Mon Feb 8 11:10:02 UTC 2010
>Synopsis: PMTU black hole detection not implemented
>Arrival-Date: Mon Feb 08 11:10:01 UTC 2010
>Originator: Arifumi Matsumoto
>Release: 6.4R, 7.2R, and 8.0R
FreeBSD mail.nttv6.net 6.4-RELEASE-p7 FreeBSD 6.4-RELEASE-p7 #0: Fri Oct 2 02:29:33 UTC 2009 root at i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386
When both a local host and a remote host supports IPv6, and path mtu is decreased to 1480 or something below interface's mtu value somewhere between these hosts, and ICMPv6 packet too big message is lost somewhere in the network, a TCP connection stalls and if one side tries to send 1500-byte packet, resulted in disconnection.
RFC 2923 "TCP Problems with Path MTU Discovery" Section 2.1 recommends to fix this problem by making TCP to try sending smaller packets when a connection stalls.
The corresponding description cited below:
How to fix
TCP should notice that the connection is timing out. After
several timeouts, TCP should attempt to send smaller packets,
perhaps turning off the DF flag for each packet. If this
succeeds, it should continue to turn off PMTUD for the connection
for some reasonable period of time, after which it should probe
again to try to determine if the path has changed.
Note that, under IPv6, there is no DF bit -- it is implicitly on
at all times. Fragmentation is not allowed in routers, only at
the originating host. Fortunately, the minimum supported MTU for
IPv6 is 1280 octets, which is significantly larger than the 68
octet minimum in IPv4. This should make it more reasonable for
IPv6 TCP implementations to fall back to 1280 octet packets, when
IPv4 implementations will probably have to turn off DF to respond
to black hole detection.
Ideally, the ICMP black holes should be fixed when they are found.
If hosts start to implement black hole detection, it may be that
these problems will go unnoticed and unfixed. This is especially
unfortunate, since detection can take several seconds each time,
and these delays could result in a significant, hidden degradation
of performance. Hosts that implement black hole detection should
probably log detected black holes, so that they can be fixed.
I also noticed modern other OSes have already implemented this fix.
Prepare the MTU black holed environment, and filter out ICMPv6 error messages between them, and start a TCP session and send 1500-byte packets by retrieving a file or something.
As stated in RFC 2923, tweak TCP implementation to detect path MTU black hole, and to react to it by sending smaller packets like 1280-byte long.
More information about the freebsd-bugs