kern/143666: PMTU black hole detection not implemented

[Arifumi Matsumoto]

>Number:         143666
>Category:       kern
>Synopsis:       PMTU black hole detection not implemented
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Feb 08 11:10:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Arifumi Matsumoto
>Release:        6.4R, 7.2R, and 8.0R
>Organization:
>Environment:
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
>Description:
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.
>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.
>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.

>Release-Note:
>Audit-Trail:
>Unformatted: