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

Joe Touch <> Sun, 26 August 2018 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DBA9130E1C; Sun, 26 Aug 2018 14:12:31 -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 5FyzvcmKCj8g; Sun, 26 Aug 2018 14:12:29 -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 87DFE130DDA; Sun, 26 Aug 2018 14:12:28 -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=mNGjBaeApTz7f/NN8MFt9wNbZtaWlWTXfZbwffFMjIs=; b=tFJ2dQ4AlNbGMhGftWjmooxVO CBInD3KK0lCQQqZCFANHHVQiqXj8JUBQvYxQ4q1rmNZEmT6QoWJZeCnQbMHVvm54KtosLa+ZzZira miPUDqI8Ihvc+NhC9gmls/7YgQrcCSri/cvT4cKYoPko4RLdFcSOTrGVapQDy3lWPp36trdyWLdLX xIb9S9xfoPPSPy1zlnnUaMeY6z/h8V6gHe4twpiv3FOteQs+MSW9r0S/pkskcAUqk9coZ7qWdAoN1 8QLkuic9ueR405gprFi1MFibVWI/ULjrgDB2E9Exg2quUYtJDt1nMAbNw+2qKbD5r1jxKjuq9PcQ8 Umut3XfPw==;
Received: from ([]:60803 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <>) id 1fu2Kb-001cGw-8l; Sun, 26 Aug 2018 17:12:26 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6F1AB002-C18A-4F35-BF64-5536AB042C21"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Sun, 26 Aug 2018 14:12:20 -0700
Cc: Christian Huitema <>, Toerless Eckert <>, int-area <>,
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Tom Herbert <>
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: Sun, 26 Aug 2018 21:12:31 -0000

> On Aug 26, 2018, at 12:58 PM, Tom Herbert <> wrote:
> On Sun, Aug 26, 2018 at 11:38 AM, Joe Touch <> wrote:
>>> On Aug 26, 2018, at 10:31 AM, Christian Huitema <> wrote:
>>> It seems that the biggest obstacle to fragmentation are NAT and Firewall. They need the port numbers in order to find and enforce context. NAT might be going away with IPv6, maybe, but firewalls are not.
>>> Have considered strategies that move the port number inside the IP header? For example, have an UDP replacement for IPv6 that does not have any port number in the new UDP header, and relies instead on unique IPv6 addresses per context?
>> NATs already have what they need to do the proper job - they need to reassemble and defragment using unique IDs (or cache the first fragment when it arrives and use it as context for later - or earlier cached - fragments). There’s no rule that IP packets that are fragmented MUST have a transport header both visible (not encrypted) and immediately following the IP header.
>> Firewalls are just delusions; the context they think they’re enforcing has no meaning except at the endpoints; it never did.
>> Using part of the IPv6 space for this solution would then break per-address network management (different UDP ports would use different IPv6 addresses, presumably).
>> The “disease" is that NATs don’t reassemble (or emulate it). It’s not useful to try to address the symptoms of that disease individually.
> Joe,
> That is only a better solution, not a complete or robust one.

It is complete and robust...

> For
> reassembly to work all fragments of a packet must traverse the same
> NAT device. There is no rule that IP packets going to the same
> destination (fragments or not) ever MUST follow the same path.

Correct, but there has to be a rule that all packets in a NAT’d flow go through the same NAT or multiple devices that emulate a single NAT.

> So in a
> multi-homed environment this will eventually break someone. For IPv6,
> this is also a clear violation of RFC8200 since intermediate nodes are
> processing a non-HBH extension header in a packet not addressed to the
> them.

A NAT is not a router. A router is not allowed to modify the IP addresses or port numbers.

When a NAT does these changes, it is acting as a proxy endpoint in the public Internet; as such, it is *required* to do whatever is necessary to ensure that its behavior follows that of a host.

> The only robust solution to NAT and its fragmentation problems,
> as well as a bunch of other problems NAT brings, is to not use NAT!
> (i.e. switch to IPv6)

As I’ve mentioned, there are rules under which a NAT is a valid Internet device, but it is simply not just a router.


> Tom
>> Joe