Thanks Joe! Ah, I misread «Outer fragmentation» to imply «Outer IP fragmentation».
Thanks for the clarification. Ole > On 8 Aug 2025, at 16:07, [email protected] wrote: > > Hi, Ole, > >>> On Aug 8, 2025, at 12:26 AM, Ole Troan <[email protected]> wrote: >>> >>> Additionally: >>> >>>> On Aug 7, 2025, at 1:15 PM, Templin (US), Fred L >>>> <[email protected]> wrote: >>>> >>>> Many tunneling protocols live by “grace” and assume 1500 everywhere. But, >>>> robust >>>> tunneling protocols need to live by the “law”, and the law says 1280. >>> >>> And its subtle - for IPv4, they assume 1500 everywhere but it’s really 576 >>> after reassembly at the receiver. >>> >>> For IPv6, it’s 1280 over each hop BUT up to 1500 after reassembly at each >>> receiver. >>> >>> These and other aspects are why this isn’t just an op-ed. >> >> I think the current text is fine from a historical perspective. >> For future recommendations I would prefer a recommendation that tunnels must >> support link-layer segmentation and reassembly. >> That could be UDP options FRAG or something else. >> >> Outer IP fragmentation is undesirable for multiple reasons. >> E.g. a tunnel tail-end has to reassemble _before_ it can check if the >> fragment chain belongs to a tunnel. Last I looked, a lot of IP fragments are >> part of attacks, and they are costly to process. >> >> Ole > > Tunnel fragments must be reassembled by the receiver - that’s a fundamental > point of the document. The mechanism used for fragmentation and reassembly > happens on the packet being tunneled, not within that packet. That is what > outer fragmentation refers to - not necessarily fragmentation at the > outermost IP layer. > > I.e., yes, we can avoid use of IP fragmentation IF there are other protocol > layers available as part of tunnel encapsulation. But regardless of method > used, the tunnel endpoint MUST do the reassembly. > > That clarification can be added. > > Joe > > _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
