On Tue, Jun 26, 2007 at 01:46:03PM +0200,
 Stephane Bortzmeyer <stephane@sources.org> wrote 
 a message of 76 lines which said:

> 13:33:43.088932 2001:7a8:7509:0:a00:20ff:fe99:faf4.65527 >
>   2001:660:3003:2::4:20.80: S 1901257151:1901257151(0) win 32768 <mss
>   33076,nop,wscale 0,sackOK,nop,nop,nop,nop,timestamp 0[|tcp]>
>   [flowlabel 0x6a261]

Pascal Hambourg (thanks to him) spotted the problem here. The client
machine, the UltraSparc NetBSD, announces a MSS of 33076 bytes, which
has little chance of success.

Why 33076? I do not know, but it triggers the sending of big packets
by the server, packets which are too big and, apparently, the ICMP
"Packet too big" message got lost.

Setting net.inet6.tcp6.mss_ifmtu=1 with sysctl, the problem disappeared.

> 13:35:32.703105 2001:7a8:7509:0:216:3eff:fe78:b525.65513 >
>   2001:660:3003:2::4:20.80: S 4227314701:4227314701(0) win 32768 <mss
>   1400,nop,wscale 0,sackOK,nop,nop,nop,nop,timestamp 0[|tcp]>
>   [flowlabel 0xbbb6b]

There is still a strange discrepancy with the PC, which also had
net.inet6.tcp6.mss_ifmtu=0 and still announced a reasonable MSS. So,
we may still have an UltraSparc idiosyncrasy here.