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

Joe Touch <> Fri, 31 August 2018 00:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CF0B130F67; Thu, 30 Aug 2018 17:26:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kJzwgG3PKvXB; Thu, 30 Aug 2018 17:26:34 -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 0A09D130DCB; Thu, 30 Aug 2018 17:26:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=0hANZ6mpIAougB10J772OsRDSnMNjI057y2tdZyxFew=; b=w9pxF7hOSJQOTUtDWiqYJmD7H wMOgUwcQjbo6UYczbPDpJ6PkfFF/uvJquqps/MXzPoSN5x6GxbFbiFsFu8tBw0Zqzb/tr58xfJrz6 Z0c98wREhl23IfhIJw1s5FJiNodM9VMCbb5aMivbGeIMQzLjkmJLqcVbGJuc4HUd6Oz7cykPgmccn QiNVykxIKgJHLtKD5aUQTbcPSNtnExgd2kwyiU5D76h+Dm7mWAuVr3iF/q8Bdgd5TKbXfDxz8/I2Z 46SUW/OHiJZferEMPVygTxoXgaGWEG9dTvP+Rf8A+wNKGVM4a7uRW8Ihy8lwS4GMXZra6Ggsdw1Ds K84MYzfkA==;
Received: from ([]:61105 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1fvXGg-001I8y-Dt; Thu, 30 Aug 2018 20:26:31 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_70C7005E-D938-457B-B2CD-BB21E79C531F"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Thu, 30 Aug 2018 17:26:32 -0700
Cc: Tom Herbert <>, Toerless Eckert <>, int-area <>,
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Christian Huitema <>
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: Fri, 31 Aug 2018 00:26:37 -0000

> On Aug 29, 2018, at 11:19 PM, Christian Huitema <> wrote:
>> Regardless, middleboxes shouldn't be avoiding their own effort by creating work for others. A corollary to the Postal Principle should be "you make the mess, you clean it up". 
> Joe's stubborn adherence to the letter of the RFC would be very nice if the protocol police could somehow punish the merchants of NATs…

My concerns are pragmatic - merely not supporting something does not make it unnecessary.

There was a time when Internet service in hotels would regularly block all except basically DNS and HTTP/HTTPS; that’s becoming much less the case. There was a time when devices didn’t support IPv6 at all because it was considered merely an unnecessary expense; that’s becoming much less the case too.

In this case, we have two problems 
	1) NATs/firewalls as currently implemented do not support fragments
	2) our current protocols, in many cases, require fragments (IPsec tunnel mode) and in other cases (tunnels in general) would benefit from IP fragmentation support
	3) we DO NOT HAVE an alternative (there are some piece-wise proposals for various aspects, but none support IPsec tunnel mode and none are otherwise universal

Yes, something needs to be done, but I argue that *until we have a worked alternative*, we need to keep restating the fact - NATs/firewalls MUST reassemble to work properly; where they don’t, the error is on them - not the rest of the Internet for using fragments.

> The whole discussion reminds me of Martin Thomson's draft, "use it or lose it" (draft-thomson-use-it-or-lose-it-02). Martin is describing how extension mechanisms that are not actually used get ossified away by the deployment of middle-boxes. The same happened long ago with IP segmentation. With NATs, applications cannot assume that reassembly will work. With Firewalls, transports cannot assume that ICMP will work. 

Yes, that’s the tension:
	a) identify bugs and fix them
	b) accept bugs as de-facto protocol evolution

The problem with (b) is that it is not guided by what Internet users need; it’s guided by what is profitable for individual vendors. That path is hazardous - there’s no reason to believe that the result will be a useful Internet. So until we know it’s safe to do (b), we need to stick with (a).