IPv6 TCP transfers are hanging

[Kevin Oberman]

> Date: Wed, 12 Jan 2005 12:31:19 +0900
> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei at isl.rdc.toshiba.co.jp>
> 
> >>>>> On Tue, 11 Jan 2005 14:01:29 -0800, 
> >>>>> "Kevin Oberman" <oberman at es.net> said:
> 
> > I think I have found a problem with TCP when run over IPv6.
> > I set my MSS for TCP to 1460 to allow a full 1500 byte MTU to be
> > utilized on my systems. (Yes, I see that this does break some things
> > like communicating via links where PMTUD is blocked and one or more
> > links restrict MTU to some size less than 1500 bytes.
> 
> > What I am specifically seeing is a packet being sent out with a TCP
> > length of 1460. While this is fine for IPv4, it's too back for IPv6 and,
> > as you might expect, the far end never receives this packet.
> 
> Two questions to clarify things:
> 
> 1. Which version of FreeBSD are you using?
Shows up on 4.11-Release, 4-stable (about a week old), and 5.3-Stable
(about a month old)

> 2. How did you set the MSS?
sysctl.conf

More information. I lowered the value of mssdflt to 1400 on both systems
and I am still seeing attempts to send 1460 byte packets. These, of
course, never make it to the far side of the 1500 byte MTU link.

I am now guessing that PMTUD is finding the MTU to be 1500 and
calculating an MSS of 1460 event hough IPv6 requires 20 added bytes of
header. Also, the problem seems to show up over ssh connections. I have
never seen it over any other link, but I don't use many other things
over IPv6. I have never had a problem with gkrellmd running over
IPv6. (gkrellmd is the network daemon for the gkrellm system monitor.)

Here is the packet that is failing:
08:20:12.680313 aaa.es.net.ssh > bbb.es.net.54854: . 10145:11573(1428) ack 31040 win 58548 <nop,nop,timestamp 9068204 69095244> [flowlabel 0x6ae53] (len 1460, hlim 64)

I am also seeing a number of slightly shorter packets which work fine:
08:19:54.222301 bbb.es.net.54854 > aaa.es.net.ssh: . [tcp sum ok] 23616:25020(1404) ack 5073 win 32844 <nop,nop,timestamp 69094981 9066361> [flowlabel 0x19ed] (len 1436, hlim 64)

I cannot confirm the problem occurring when the source is a V5
system. It is possible that only V4 systems are doing this.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634