Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

Joe Touch <> Sat, 28 July 2018 15:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9929E130F16; Sat, 28 Jul 2018 08:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4uWFuGelVdtF; Sat, 28 Jul 2018 08:49:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5749130DED; Sat, 28 Jul 2018 08:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZivhbzYWlhjTAcoWyIk+KQwYvxFzJdaT/pnoFWZpUr4=; b=omv/sxnzAjQwd8apqsZIdqMWN kMCyeRUMhV1x9Zb5Z4xs59mB01g4RKGvp80BBmubw4bX9lvwJoo/Uo9I+o+dLQtpeeodI8avaY9BN lcNAtIWoKa67037cTIyWihOc5ri4Em06gxoB/KbXsR2ze86ikFmpwpXfFLh94e+vXUrYeszhbrGcO YSJ5hiznelcIMH+MLLOBuZClJX1SIn+FUbZPHWxu+8/aSF8Tldb6ukkcQFY/cgI2D10MveJRk5fbL cUqXH0qKiOotcTxY/frBRuDhURznzKNrfAx3AO87bEhpBMC/xeyzGmVb3g6awmtGvhaDMvnB0yKKs he9wcEsiw==;
Received: from ([]:53587 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1fjRTP-0015dl-DJ; Sat, 28 Jul 2018 11:49:43 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sat, 28 Jul 2018 08:48:45 -0700
Cc: Tom Herbert <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Mikael Abrahamsson <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Jul 2018 15:49:48 -0000

Hi, all,

Here’s the thing about fragmentation:

	1. all links have a maximum packet size
	2. all tunneling/encapsulation/layering increases payload size

1+2 implies there is always the need for fragmentation at some layer:

	3. fragmentation always splits info across packets

And there’s something important about layering:

	4. layering intends to isolate the behavior of one layer from another, such that
	it will always be impossible for an upper layer to know exactly what is going on below,
	i.e., to determine that limiting size across an entire path of possibly virtual tunnels

The next two are where we get into trouble:

	5. network devices increasingly WANT to inspect contents beyond the layer at which they are intended to operate
	6. inspecting contents ultimately means reassembly, at some level

Which brings us to the punchline:

	7. but network device vendors want to save money, so they don’t want to reassemble at any layer

So I agree, IP fragmentation has its flaws - but those flaws are created not only because it leaves out the transport port numbers, but also because DPI and NAT devices don’t reassemble. And they don’t because it’s cheaper to sell devices that say they run at 1 Gbps (e.g.) that don’t bother to reassemble.

I.e., it will never matter what layering we add to fix this - GRE, GUE, Aero, etc. - ultimately, we’re doomed to need fragmentation support down to IP exactly because:

	a. #1-4 mean we need frag/reassembly at any tunnel ingress
	b. vendors want to sell #5 at a price that is too low for them to support #6 (i.e., point #7)

So pushing this to another layer will never solve it. What will solve it will only be a compliance requirement for #6 - which could be done right now, and has to be done for ANY solution to work.

NOTE: even rewriting EVERY application won’t fix this, nor will deploying a new layer at any level. 

And yes, I do intend to add this to draft-ietf-tunnels, so it can be referred to elsewhere.