Re: kern/57163: IPv6 route MTU handled any more

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Jan 05, 2023 at 07:25:00PM +0000, bouyer%antioche.eu.org@localhost wrote:
> >Description:
> 	I have a pppoe over ADSL connection at home, with an MTU of 1492.
> 	The router advertises IPv6 with an MTU of 1492, per rtadvd.conf:
> default:\
> 	:chlim#64:raflags#0:rltime#1800:rtime#30000:retrans#1000:\
> 	:pinfoflags#192:vltime#3600000:pltime#3600000:mtu#1492:
> 
> 	The client properly get its default route with the right MTU:
> rochebonne# netstat -rn -f inet6 |grep default
> default                                 fe80::4a:6ff:fe41:9271         UG          -        -   1492  alc0
> 
> 	This works fine with 9.x clients.
> 	But since I upgraded one client to 10.0_BETA TCP connections from this
> 	client stall when receiving large amount of data. tcpdump shows:
> 20:19:19.339688 IP6 (flowlabel 0xdfd4b, hlim 50, next-header TCP (6) payload length: 28) 2001:41d0:fe9d:1100:96de:80ff:fe21:bec0.65449 > 2001:660:3302:282a:204:75ff:fe9f:9e11.80: Flags [S], cksum 0x4100 (correct), seq 1784052849, win 32768, options [mss 1440,sackOK,eol], length 0
> 
> 	that is, the client adverstises a MSS of 1440 instead of 1432.
> >How-To-Repeat:
> 	setup a IPv6 default route with MTU lower than the interface's MTU.
> 	Notice that the TCP mss sent on connection is too large.

I was wrong on this one. After reading the code, and testing, it appears that
a 9.3 client also sends a mss of 1440.

Further testing shows that the initial packet has different options
between -9 and -10:
NetBSD-9 sends
13:10:51.347038 IP6 2001:41d0:fe9d:1100:92d1:bf4e:6d13:758f.65533 > 2001:660:3302:282a:204:75ff:fe9f:9e11.80: Flags [S], seq 2687969843, win 32768, options [mss 1440,nop,wscale 3,sackOK,TS val 1 ecr 0], length 0

NetBSD-10 sends
13:11:52.466509 IP6 2001:41d0:fe9d:1100:96de:80ff:fe21:bec0.65401 > 2001:660:3302:282a:204:75ff:fe9f:9e11.80: Flags [S], seq 3955253542, win 32768, options [mss 1440,sackOK,eol], length 0

That is, -10 adds "eol" and miss "wscale 3" and "TS val 1 ecr 0"

It happens that I had net.inet.tcp.rfc1323=0 in my sysctl.conf, I don't
remember why. In netbsd-9, this turned rfc1323 for ipv4 only; but in
-10 this turns it off for ipv6 too. With rfc1323 back to 1 I get ipv6 working
again.

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--