Hi Joe, We are waiting for your feedback, but I just want to check we have the same understanding and that we will have a feed back.
We would like to understand if the terminology used in the document is aligned with the one of intarea-tunnels and if we agree that intarea-tunnels and IPsec have different perspectives on handling fragmentation. I do not see what we are proposing very different from what IPsec has been doing for years. I also think that everything is explained in the introduction (2 text pages), so you do not have to read the full document. The document is available here: https://datatracker.ietf.org/doc/draft-liu-ipsecme-ikev2-mtu-dect/ Yours, Daniel On Sat, Nov 26, 2022 at 9:25 AM Daniel Migault <mglt.i...@gmail.com> wrote: > Hi Joe, > > So we just published an update of our draft. We try to catch up the > complete idea in the introduction - to avoid reading the complete draft. I > think we partly aligned with the tunnel document. The current version only > describe the security gateway as a node and does not split it between a > outer and an interface. I think for the remaining of the document we are > taking the exact terminology from the tunnel draft. > > We believe that IKEv2 and the tunnel document have different visions and > tried to highlight this also. > > One big clarification in my point of view is that the previous version > confused MTU with MAP. > > We are happy to get your feedback. > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:32 PM to...@strayalpha.com <to...@strayalpha.com> > wrote: > >> On Oct 31, 2022, at 11:07 AM, Daniel Migault <mglt.i...@gmail.com> wrote: >> >> >> - the tunnel has two DIFFERENT relevant MTUs >>> the egress reassembly MTU (EMTU_R), which is the only thing that should >>> drive the “tunnel MTU” >>> >>> the tunnel MTU, which the ingress needs to know for source >>> fragmentation, but is NOT relevant to the >>> origin MTU upstream of the ingress >>> >>> Will read the draft - but we believe that is better to generate one >> IPsec packet for every inner IP packet as opposed to two. This is why we >> are proposing to adjust the MTU so the outer packet matches the limit of >> the EMTU_R - and fragmentation be avoided. >> >> >> That doc explains why this is effort isn’t useful. As I noted to Tero, >> there’s no ICMP message that says “bigger than I’d like”. PTB means >> “packets larger than this will be dropped”. That’s not what’s going on >> here, so it’s the wrong message to support. >> >> There is no message that supports what you’re trying to do - perhaps >> because there can’t and shouldn’t be. >> >> Joe >> > > > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
