FWIW, in general: With all the concern not detecting when frag fails, I’d like to point out that it’s equally impossible to detect when it works, e.g., when it happens on tunnels that start more than one hop away or more than one layer of intermediate headers.
E.g, PLPMTUD turns of frag *on the connected interface*. There’s no way to disable source fragmentation that happens later in the network (as it would at tunnel ingresses) or deeper in the stack (when what you think is your interface is locally tunneled over a layer you don’t even know about). So *all* systems that try to backoff and use smaller MTUs are actually *already* testing whether fragmentation already works in those cases. Even if your app sends a 1-byte packet you have no idea that some set of layers inflates the headers (e.g., with signatures or key exchanges) beyond the MTU somewhere. Thus claiming that “fragmentation must be avoided at all costs” is simply not even possible anyway. That’s why it’s reasonable to bring encapsulation up. It works - even when you don’t know. Joe > On Sep 7, 2019, at 10:25 AM, Bob Hinden <[email protected]> wrote: > > Ole, > >> On Sep 6, 2019, at 9:03 AM, Ole Troan <[email protected]> wrote: >> >> >> This document should not recommend IP in UDP in IP encapsulation to achieve >> end to end IP fragmentation for new applications. > > The document doesn’t say that, nor is the document recommending this. The > current text Joe and I proposed to the list was: > > The risks of IP fragmentation can also be mitigated > through the use of encapsulation, e.g., by transmitting IP fragments > as payloads. > > If this was recommended it would have included the word “recommended” or > SHOULD/MUST terminology. > > It’s only mentioning this, along with other approaches, as a possible > approach for mitigating the problems. > > Bob > > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
