Hi Michael, > > 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.
Why IKE messages cannot be used for this purpose? Regards, Valery. > 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 <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
