Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)

Fernando Gont <> Thu, 05 September 2019 14:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3C0C1200F7; Thu, 5 Sep 2019 07:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id no-xRA0oMMoC; Thu, 5 Sep 2019 07:37:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDE4B1200EF; Thu, 5 Sep 2019 07:37:25 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 90AB18622D; Thu, 5 Sep 2019 16:37:23 +0200 (CEST)
To: Tom Herbert <>
Cc: "Templin (US), Fred L" <>, Ole Troan <>, Bob Hinden <>, Joel Halpern <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Thu, 5 Sep 2019 17:37:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2019 14:37:28 -0000

On 5/9/19 17:31, Tom Herbert wrote:
> On Wed, Sep 4, 2019 at 5:34 PM Fernando Gont <> wrote:
>> On 4/9/19 18:26, Templin (US), Fred L wrote:
>>> Hi Ole,
>>>> -----Original Message-----
>>>> From: Ole Troan []
>>>> Sent: Wednesday, September 04, 2019 7:37 AM
>>>> To: Templin (US), Fred L <>
>>>> Cc: Bob Hinden <>om>; Tom Herbert <>om>; Joel Halpern <>om>; draft-
>>>> Subject: Re: [Int-area] Alissa Cooper's No Objection on draft-ietf-intarea-frag-fragile-16: (with COMMENT)
>>>> Fred,
>>>> I removed the IESG from this list, as we seem to have drifted into a more general fragmentation discussion as opposed to discussing
>>>> the exact changes to this draft.
>>>>>>>> Why is that more useful than what is in 3.5? If it’s not making a recommendation, why call this out in the introduction.  There are
>>>> lot
>>>>>> of
>>>>>>>> other things it doesn’t make recommendations about that aren’t in the Introduction either.
>>>>>>> Because it sets a more appropriate tone and lets the reader know from the onset that
>>>>>>> fragmentation and encapsulation go hand in hand. And tunnel fragmentation avoids the
>>>>>>> issues raised by others in this thread.
>>>>>> While inner fragmentation ensures the fragment will reach the tunnel tail end, a tunnel endpoint will typically not reassemble that
>>>>>> fragment, so will generate fragments after the tunnel hop.
>>>>>> Inner fragmentation is only available on IPv4.
>>>>> Not true. For IPv6 packets, simply insert a GUE header or an RFC2473 header and
>>>>> fragment on that. The fragments will be reassembled by the tunnel tail end, then
>>>>> passed to the next hop as a whole IPv6 packet. The fragmentation footprint is
>>>>> therefore the same as the tunnel footprint.
>>>> Is that not the exact definition of outer fragmentation?
>>> No. I am talking about outer header (OH) followed by tunnel header (TH) followed
>>> by inner packet (IP). Recipe:
>>>   1) wrap the IP in a TH to create a tunnel packet (TP)
>>>   2) fragment the TP
>>>   3) encapsulate each tunnel fragment in an independent OH
>>>   4) send each outer packet (OP). These will look like ordinary
>>>        unfragmented IP packets, but will contain a tunnel fragment
>> This looks like a recent claim from the IAB that QUIC has shown that it
>> is possible to deploy new transport protocols on the Internet. -- when
>> quick employs UDP, and hence from the pov of the Internet, UDP is the
>> transport protocol.
>> Same with your example: you are tunneling your fragments. The Internet
>> will not see fragments. *That* is why it would work.
>> i.e., if you want fragmentation to not be fragile on the Internet, the
>> trick is that packets shouldn't look like fragmens ;-)
> Fernando,
> Sure, if we dress up protocols in UDP there is a greater probability
> they can traverse the Internet. But this doesn't always work and it's
> fallacious to think that unbiquitously solves the problem of protocol
> ossification.

I fully agree with that. In fact, encapsulating transport protocols in
UDP *circumvents* the problem -- it doesn't actually fix it.

>  I really wish the IAB would look at the issues of wide
> spread middlebox non-conformance-- this is the root problem and a
> fundamental deterrent to evolving the Internet IMO.

FWIW, I did ask about this in the context of EH-insertion on the IAB's
architecture list.

Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492