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

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

The following reply was made to PR kern/57163; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/57163: IPv6 route MTU handled any more
Date: Tue, 31 Jan 2023 13:49:53 +0100

 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
 --