Paul Wouters writes: > On Mon, 7 Aug 2023, Tero Kivinen wrote: > > > Of course the optimal solution would be the original sender to not > > send 2000 byte packets, but instead fragment the packet already > > himself to 1300 bytes and 700 bytes, but that would require changes to > > the application and might not be that easy to do... > > And you think all these VPN gateways kernel stacks handling and tracking > and communicating upstrean to IKE to relay the message will be easier?
Of course all proper VPN gateway products do that. They already do similar things when making sure ICMP error messages are processed correctly and end in correct tunnel, and that ICMP error messages for tunneled packets are processed so that they will trigger relevant ICMP messages sent to the proper hosts at correct time, and that fragment processing is done correctly etc. All of those are described in the RFC4301, and proper gateways implement them... And then there is linux :-) > I think people will just put mtu=1300 in their VPN config, use this new > notify and now we have yet another uncontrolled, unfixable hardcoded > packet size that will never go away again. And then there is linux :-) > The problem really is "create a 2000 byte packet and expect it to go > over the internet". Don't do that. If I remember right, at least NFS over udp does that (or it might use 8k packets), if I remember correctly... Nobody should be running NFS over udp over internet anyways, but it can happen over VPN links... Of course if you use IPv6 you do not have fragment in the middle issue, but even then you might have IPv6 packets inside the IPv4 ESP tunnel and end up in similar issues. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
