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

Joe Touch <> Mon, 30 July 2018 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7B10130E92; Mon, 30 Jul 2018 10:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.778
X-Spam-Status: No, score=-1.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-sUI8w7i_cj; Mon, 30 Jul 2018 10:34:36 -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 8670E130E90; Mon, 30 Jul 2018 10:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version: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=bnWtBVdJCY0Mwxjg2i+QbQnsFM9a9x5wb8Tz4rSEY64=; b=pvT1RQC2UOW6rxMVbTaLQDpF8 yykvmMBr0PEXOrNSg2e+tS5M2L2CgM68c2VnUsF+UqQ4q8YKhWyFd12T3tjxqjGt4G0vQOFAAHH8r bbNmNEiDGGhjniSl24SELqM9xYOi7fszwESkhirpCN/HF/zhBiENfADMK8wcJ8Iey+0VnU1dlx7Fe KIzqLYRZgKdF85HuGOYKKKwsutNufvyBs9II7mWGW/3KYwyYDKdZ5QBlGbJW2E5iCvCvTco3UQpAs ClqTA+gaCKsoXRdJJ4LvGGKm27F+YLYiu3wL1m8n7Xj9ofQDNjytC8av3zntOgySWyzSeKHwHwi4F 40rQzAhkw==;
Received: from [::1] (port=41968 by with esmtpa (Exim 4.91) (envelope-from <>) id 1fkC42-001XTj-UX; Mon, 30 Jul 2018 13:34:35 -0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_c5784cf0db3e99f0f2b62b899cd9884a"
Date: Mon, 30 Jul 2018 10:34:34 -0700
From: Joe Touch <>
To: Tom Herbert <>
Cc: Ole Troan <>, "" <>,
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.3.3
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: Mon, 30 Jul 2018 17:34:38 -0000

On 2018-07-30 08:11, Tom Herbert wrote:

> On Sun, Jul 29, 2018 at 9:22 AM, Joe Touch <> wrote: 
>> On Jul 29, 2018, at 9:11 AM, Tom Herbert <> wrote:
>> ...
>> That said, there's no real problem with a NAT *IF* it acts as a host on the
>> Internet
>> (see ouch, J: Middlebox Models Compatible with the Internet. USC/ISI
>> (ISI-TR-711), 2016.)
>> Joe,
>> It's still a problem though. A NAT (or any stateful device in the
>> network) forces the requirement in network architecture that all
>> packets of a flow are routed through the same device.
>> I didn't make that requirement. The Internet does - it's what it *means* to
>> have an IP address.
> It's not a requirement of the Internet and certainly not a core IETF
> requirement that packets always follow the same path. It's an ad hoc
> requirement imposed by _some_ solutions that have been deployed.

1122 requires that devices shouldn't be sourcing IP addresses they don't

And any device behind a NAT would have a similar requirement - that the
private side is setup such that any translation appears as a single
device -- which means either that each host on the private side forwards
all its traffic to one egress (as a stub net) or that the multiple
egresses coordinate state to look like one egress on the private side
and one host on the public side. 

I.e., the Internet architecture imposes exactly the restrictions you
note - these aren't ad-hoc, they're derived from the Internet

>> A NAT *has* the address of the packets it sources; if it isn't the sink of
>> that address, then it's being used incorrectly. If it doesn't reassemble
>> those packets before translating them (i.e., by translating only
>> unfragmented packets and dropping fragmented ones), then it is broken and
>> ought to be returned for a refund.
> You are only considering the return path.

Only for that rule; for the private side, the rule is that the network
is a stub behind the translator (or emulates that). 


> This has killed
> our ability to use multi-homing and multi-path.

It didn't kill it. It never existed *for this sort of mechanism* -
exactly because of requirements of the Internet architecture. 

If there is only one device that represents a private node on the public
net, it can work (using the model I describe). If there isn't, then it's
the Internet architecture that makes the device inherently broken - we
shouldn't go around believing we can patch the protocols to "make it
work again".