[Int-area] Re: WGLC for "IP Tunnels in the Internet Architecture" draft-ietf-intarea-tunnels

[Ole Trøan <[e-mail]>]

Thanks Joe!
Ah, I misread «Outer fragmentation» to imply «Outer IP fragmentation».

Thanks for the clarification. 

Ole


> On 8 Aug 2025, at 16:07, [e-mail] wrote:
> 
> Hi, Ole,
> 
>>> On Aug 8, 2025, at 12:26 AM, Ole Troan <[e-mail]> wrote:
>>> 
>>> Additionally:
>>> 
>>>> On Aug 7, 2025, at 1:15 PM, Templin (US), Fred L <Fred.L.Templin=[e-mail]> 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
> 
>