Paul Wouters <[email protected]> wrote: >> Christian Hopps <[email protected]> wrote: >> The ingress node >> encrypts this packet and adds the IPsec >> encapsulation, and this >> IPsec-processed packet is also larger than the >> Link MTU. The >> ingress node fragments this IPsec-processed packet and >> sends all >> the fragments to the egress node. >> >> > This should not happen. The ingress node should first fragment the > >> inner IP packet so that it fits in the tunnel (i.e., so that the ESP > >> packets it creates do not violate it's own MTU). >> >> You can't do that if DF=1, or IPv6. You can form big ESP packets and >> then fragment them, even with IPv6. DF=0 for IPv4 on ESP packets is >> good, until there is a firewall that cant cope with fragments.
> Why does any of this even matter? The applications should use PLPMTUD /
> DPLPMTUD ?
1) For TCP things. We also have RFC9268 now.
2) how can we get it turned on by default? I tried to make this case to
Linux distros and kernel people, but there is a lack of evidence that
it is safe, and the people who might have the evidence (at scale)
don't want to do it.
3) the gateways really have no idea if PLPMTUD is being done, and sometimes
it's better to just make things work.
> Sprinkling bits to try to communicate with hops in between hasn't
> worked for decades.
Agreed. PMTUD is a fail.
> Or use IPTFS and set your own max packet size sufficiently low?
I think that this is the killer app for IPTFS.
> I'm not convinced doing this between IPsec peers will solve any real
> use cases.
I am also skeptical, but I don't object to the work getting standardized.
In particular, for networks where there are MTU constraints on the far side
of the far gateway, telling the sending gateway about the MTU has a far higher
chance of working than anything else. The sending gateway probably can send
PTB ICMPs with better results.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
