> Dynamic IPsec PMTU PLPMTUD - Shibu Piriyath, Ron Bonica
>
https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01
> Problem: IPsec Tunnel has an PMTU as any other tunnel.
> Solution in Transport Area: Inband Path discovery
I spoke to Ron afterwards, and I'm very enthusiatic about getting PLPMTUD
widely deployed. We didn't get to this slides, so we didn't figure
out what he needs. Slides talk about an IP-level probe that IPsec
encapsulators can use to get estimate for tunnel inner MTU.
But, if we can get PLMTUD deployed for all traffic, then the end-nodes can
do appropriate PMTU probing and can figure out what the inner MTU is.
i.e. just get everyone to enable plpmtu (4821). It's a knob on most
systems, which has been left in the off state because of lack of evidence
that it isn't harmful.
There seems to be some sticking points among the high-speed about CDNs:
they hate all PMTUD as it screws with tx scheduling into hardware.
(TCP segment offload issues)
So they just use 1280 is what I was told. That's good for the network, but
it removes them as strong allies for getting PLPMTUD enabled by default
everywhere. It would be nice if we could get a BCP out of them. Such
BCP could also bless PLPMTUD for everyone else. I was pushing for this
with RFC8200/STD86 but there was insufficient evidence of deployment.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
