Valery Smyslov <smyslov.i...@gmail.com> wrote:
>> > 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?
I think that possibly it can, and this is the kind of discussion that
I think we should have. The advantage of doing that is that it requires
no new code on the responder! That's a big win for deploying.
It means that this can be done unilaterally, no new specification,
just implementation advice.
The slight implementation challenge is making sure that the IKE traffic
is going along the same path as the ESP traffic. I'd like to hear from
Ron about whether this is an issue.
I also thought about using having some plpmtud on each end make a TCP
connection *within* the tunnel and use the already defined plpmtu for
TCP. That might be really easy for systems without user/kernel divisions
(some router kernels). It would require some notifications to indicate that
the responder has a TCP port open. And of course, the traffic would
have to fit into the tunnel as well.
> 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
--
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
