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. Fix: 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. How-To-Repeat: 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.
State Changed From-To: open->suspended Awaiting someone to take an interest in this.
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s).
Hi, I made a patch for 8.0 release to fix this issue of path-mtu blackhole detection. This was mostly derived from macosx, which is APSL and BSD dual-licensed code base, and slightly modified so that it should not affect ipv4 path mtu detection. I tested it on 8.0 release only. I'm guessing this can be applied for CURRENT also, as the related code does not seem to be changed that much. Best regards,
State Changed From-To: suspended->open Take it.
Responsible Changed From-To: freebsd-net->ae Take it.
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
I think this can be closed, since PMTU balckhole detection is now implemented. From tcp.4: pmtud_blackhole_detection Enable automatic path MTU blackhole detection. In case of retransmits of MSS sized segments, the OS will lower the MSS to check if it's an MTU problem. If the current MSS is greater than the configured value to try (net.inet.tcp.pmtud_blackhole_mss and net.inet.tcp.v6pmtud_blackhole_mss), it will be set to this value, otherwise, the MSS will be set to the default values (net.inet.tcp.mssdflt and net.inet.tcp.v6mssdflt). Settings: 0 Disable path MTU blackhole detection. 1 Enable path MTU blackhole detection for IPv4 and IPv6. 2 Enable path MTU blackhole detection only for IPv4. 3 Enable path MTU blackhole detection only for IPv6.