I think Michael is correct. The problem comes from the fragmentation of the outer IPv4 packet. The inner packet might be IPv4 or IPv6 and the security gateway may use any possible means to ask the nodes to adjust their MTU. Currently we suggest using ICMP PTB, but if RFC9268 also provides some means to do it, we do not want to prevent using it. We currently believe that this may be up to the gateway to decide what to do, so we do not necessarily require any use mechanism to be normative - but that point may evolve depending on what the WG decides.
Yours, Daniel On Mon, Oct 31, 2022 at 11:37 AM Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Tero Kivinen <kivi...@iki.fi> wrote: > > My understanding is that this draft (which I have not yet properly > > read) is solving the situation where the tunnel does not get ICMP PTB > > messages as they are forwarding packets with DF bit set to 0, and > then > > the receiving end will see extra fragmentation happening for the > > packets. Then the receiving end will simulate the ICMP PTB by sending > > authenticated IKEv2 notification that tells the sending end that his > > packets got fragmented. > > While I think that the authors think they are solving this problem, I think > that what they have created is a protocol for dealing with fragmentation > beyond the far gateway. > > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
