kern/56348: MTU discovery fails with IPv6 sockets bound to IPv4 mapped address

[kardel%netbsd.org@localhost]

>Number:         56348
>Category:       kern
>Synopsis:       MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 04 17:45:00 +0000 2021
>Originator:     Frank Kardel
>Release:        NetBSD 9.99.86
>Organization:
	
>Environment:
	
	
System: NetBSD kebne-new 9.99.86 NetBSD 9.99.86 (GENERIC) #3: Wed Aug 4 15:43:10 CEST 2021 kardel@pip:/src/NetBSD/cur/src/obj.amd64/sys/arch/amd64/compile/GENERIC amd64
Architecture: x86_64
Machine: amd64
>Description:
	Setup:
		Server socket bound to ::ffff:A.B.C.D
		Client reaches server via IPSEC VPN -> MTU 1280
	Effects:
		On first access the server delivers all data to client - ok.
		On subsequent accesses only partial data is delivered and
		the writev(2) in the server experiences error 40 (EMSGSIZE).
		Bindung a true IPv4 socket works and does not show
		MTU discovery problems.
	State observations:
		At the first access no host route for the client
		is known at the server node. After the first
		access the ICMP/NOTREACH/NEEDFRAG-1280 packets install
		a dynamic host route with the correct MTU of 1280.
		Deleting the IPv4 host route result in a successful
		transfer again for IPv6 sockets bound to mapped IPv4
		addresses.
	Analysis:
		Dtracing shows that on the error case ip_output()
		returns EMSGSIZE for the first ip_output() call.
		This is caused by mtudisc being active (IPv6 standard) and
		thus IP_DF is in effect and ip_output cannot fragment.
		Further dtracing shows that the TCP connection has
		a cached route in the failure case:
Internet6:
Destination                             Gateway                        Flags    Refs      Use    Mtu Interface
::ffff:0.0.0.0/96                       ::1                            UGRS        -        -  33624  lo0
		Thus TCP assumes an MTU of 33624 and due to IPv6 MTU
		discovery ip_output returns EMSGSIZE.

		The route entry is picked up during connection completion
		in ip_input from the syn-cache via
		in6_pcbconnect>in6_selectsrc>in6_selectif>in6_selectroute.

		in6_selectroute looks up the route for the IPv4 mapped
		destination address via the IPv6 routing table and gets
		there a match of the statically configured route from
		above. with that MTU(33624) TCP is suffciently confused
		and produces above effects.

>How-To-Repeat:
	see above.
	Server test program:
begin 644 tcpresponder.c.gz
M'XL("$D9"F$``W1C<')E<W!O;F1E<BYC`*U8>T_;2!#_._D4TUPI#@0"I5AW
M0$"(`S4J+1&OZZE%D6.OPZJ)'7G7X7%WW_UF9G<=.PDJ.EVKUKNSNS._>0^T
MU^JP!F\_BB`2V5M<\_8D$X$6T1Y<YP*.\R'`#FS]MK?C[^WZ\'[K_3:XJR?I
MY"F3PWL-WDG3'`V>X"P+DA_P*<@B,<);[?HO,@E'>23@0#VI=B[3S?O#.:+2
M@5Y"3<,?8HZ>""WQ7ULF57J038(VG<RQT9E,AE6:3+1^F@@U?S-:0*:CD1Q4
M:7DBD5REQ6&B1U62R#(BU$DQ&<(TE5$]5\%0>+1LUO^JU^()0M.QA^SP=@L:
M?+X'*PH.NKWI!PBB*!-*_8T;WVT.X6"29AH_2@S'(M&@Y+/`;2Q'XO![TFC!
M4.A)E@Z38"R\9G._7A./4GNG7[O7_;/C[OG-Y2D2_ZG747A]',C$PP4$V3!L
M07@?9+"&Z^FW.\:(1^/@L:]![O,&,E(H5W8W]>TBCEJ@(MP8#B*))O:$T-HE
M(B:P+5X@C3;(6CT7[T@)PHV$/%%RF(C(8AKD<2S02&N3_1J^U%D>XDO$PO\-
M]@N:3*<BA#7\S&@41V2_ODS8CDM/C(G])6=*IQEZ!A2#1BJ")-SX<<@1WK=?
MM^YP2W]E#!X9%`Y@MPEHQIIQ/3D##0_V3[TV%F,EM/>.Q+1@J\7.3&./]NRZ
M\@5__H9/5XPT"OS^1*>)=WS6[WXYO6X!>W'[K@7\>%/)I,]LH=.!;8,*PZH#
M6RBF5EQ!G9!6AE$YCH.Q'#WA#2N&%`(Q4@*6HO#G8?C$Q5\.9-M)LI<6H/C-
MN1OS:/P9'.**6?58B7O,L5AB!!.HG)-GG.-N(""`:3"2$6#6I=EL5Z1=P[JN
M)@F2SG0J/=;L/6E&X<[.V6Z!O[N[LXLTFRCTCDSCMB\"HSPIX&"<ZGL!6$@Q
M[-(8MC<WF:^%4>/+'4K*140[_Q>B<H%Y-3*;XP8<IH++:"0PN@\F1^((">E$
M))Z[T(*+_N7O%U_._W0`Z4X'-K8+A`N^#/!M!#IE3O"]L:*^-[``.I:%SX@9
M:>M1F7K'!:/Y:MY83IDC!!I[R2#78A8-MH(W6&6TAH$`*Z,(&R%>Y'H\TY`E
M;RK=I_N<NV0NM(17.8%U5RIA@S*D[;9L.B?S%Z;"2L1":-W<=\6'3P[AIGO1
M_WS\M7MQ^[*7L6-AO\>,F8G4:0KC('ER`L##'H#?II73*C.VEC#U&549!Z-1
M&GKSJC(L=ZD#7V[.SU_&E"?!``V.QF=F.(T8#YCW+M209SHM232%HMP&FCBC
M.,-P?:+[_T&XZ2E!E@5/C7)0>91[:+V(`\NUJ*KJ37C3F2.Q:,93#L)E43C#
M0E*61WBYXBU5B)\6(8D9K#11,%R)B.X6V5@F.*8D0V0M%\.T1M8FG<WL$HY2
M)5!C#N`)6L`H3KWQ&>9T16*,!94-M;5/K=YJGTZ_R;M-_/0'%'P=H'FA3+;5
M_QD..T5H'A6K/3,UH/CU#E1?$1F?;2RCR_5UZSY%!<C,EQZ6^2/HV1:"K'NN
MA5Y=G'SJ7UU?GAY_;D&WU[N\N+[H7Y_TBK:K?E:B9@X,>:H&?-WN]JSD4B0C
MLS=3W_`INJTM\_?8495'&W8&Z4%6ETF$`%K@S<TKL-:T`\7\-%&*%)K'TCAV
M_;_:5Y?)M2&+TPC)22>:93NC='NW/NUN_?ZM3T4<ZRRR=Q!(5*7BUAZ"+/%*
MYM%YEI3?TXN&B[U7J^POSD>5.CW"V5TD&.B0)C1GLZ*F@M9K=BKC(2;1Z<3$
MQ?$L+MQH1?B!#SDA"N&SV08O5XZ*Z<N\Q80I+(/K)E$+,R\4AB5A=59T)S()
M?:TFF,`N3ER1,CJSV79_UO7,73#-;Q:=JCR*F3'XX9X*LL=-&H(P%#8@EGE&
M*>JZR,,40R<_Q.C2=KP'JB,SRRNUJ90=[]ADQCEE,FE2^.9H=J>PNS</A6=\
MAM/<."RYZI5ORT]GOC0/YQVZ;[-E4FTW-NH+/:VAH9AC5^C'*&-L]F7%#GS"
MK+GJ-HX:I?1P$7Z2)HD(M<3XCK-TC"DU70DQU/=<E+LP?\&6&-2K'U8Q?E?]
MU=+M27GM"A$+5O>YCM*'A%O@U<>;:YSB"OVY[C]D4HLIGV,IMJ/*2VUQ25]<
MJ!6&H1NV/!Q0F&5UU+)MO]H>F=6CUWC(4JS%+_7$E[H@V[K,SAG]BL;D&3>$
MN&)&OPH/3,UR05LTW!^7?%[JK[5EJ<<I&6="T#Q#EWAMFC!M,\'%=(M_R&^;
3W^F<I\.W_+N8?P'"JV_R\Q$`````
`
end
	Use netcat as client. Send file with 16k size. via
	an IPSEC VPN. After the first successful transfer
	you should see an error on the sender side and
	only about 2k on the receiver side.
		
>Fix:
	Workaround 1: don't use an IPv6 socket bound with an IPv4 mapped address.
	Workaround 2: delete the ::ffff:0.0.0.0/96 ::1 route - what is the
                      rationale for that route anyway?
	Proposed fix: make in6_selectroute fetch an IPv4 route
                      entry for IPv4 mapped addresses.
begin 644 ipv6mtu.patch.gz
M'XL("-RU"F$``VEP=C9M='4N<&%T8V@`I5++;MLP$#Q;7S&GP`_)>E25'1LI
M'#0]&$@#(T&"W@1"HF+""FF0E)V@R+]W23EI@.96`N**N\/9X>ZN9<V?%Q"R
M*(VNIE5P\?\KN/U^AT:T?(&X.ABME(V)/#8O)I;<"OJ*^#UC>`@TMUKP@Y"/
MT&2,4!+I=#X+:M$TB#I$VAT_J(RBZ.]ID,UQV3TB2[($2;'XDBVR'%%":^!I
M)I/)!W3^!DZ1?EWD^2+)>G"P6B$JTBPL,'%FAM4JP,!8W546VG)I]0O&VN("
M-_?7UTL*=M*)_4U_;SBCJAVK:ST8U,8N@\D_@5)(%\J7GURB6.&"A0N^HB/3
MJYJ=A^>D:IZ$Z4D6QK@W'`P5J[:\AE:=Y1`-A`5_%L8:,%E#&!Q8*^H0O"6X
M>X%58&VK*F9YS\,@^1%*\BEPHXC%;IG%D<-L5=?6(/YJ1T[*1AJY,6C8DVA?
MH!KG[4E.,FINJ,/,4EE"*CJY*2OAS)9IUV#'XJ$X"KO%>G/(IU0DC/V&1FD\
MY'AB^SV1G=)QX\0<F;1.^UZ0F&[OF0YY_^[^LN$<F]MXQ[7$+[^\M#B(!MW4
M594:-R;KJKU\=TZ-GXU*[7DI:H(DKFM4R.'ZIBC7=^7EU=5M^9#_O-QL?EP-
MSTX$T3=_STD<C6@"J-&>QVV9,\,SSY^'.-T8.=[7O@\>_XFH=^_GJEZ#"3W)
G3Z"VOHQEJ]2NVZ?#L58A^I0ATI&;'/A7.'0_L*/@#Z_0YU?O`P``
`
end

>Unformatted: