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

Tom Herbert <> Sun, 26 August 2018 23:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9108130E2C for <>; Sun, 26 Aug 2018 16:01:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TRDzSjbXIu5A for <>; Sun, 26 Aug 2018 16:01:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E53B2130E03 for <>; Sun, 26 Aug 2018 16:01:29 -0700 (PDT)
Received: by with SMTP id m13-v6so16119869qth.1 for <>; Sun, 26 Aug 2018 16:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=99EvRVI9Qq5bXHoBlRroHLeUNEmfl9mbvNC4PpGxsVM=; b=VXrCzskCW8OX9KjVE/Ea6mBEb4Zjt+oh1GpVglmIEcZ3thsVzMkKSYEuoPh+A/hjc3 JAlyxO+4yxtdnsLucowWC9bjTrnO2UgK2AW/XhUmT8zVtrLPd/8sc6fhSRjeH7jEEnAA Q7TMKNN433PgzhURSEnuzK4rGBS3C+5mr9wpLDWtDCnUFlYQs0l5RKS+puzHY5iL8qVM OcTQKLjiz+sqHhw8t4HYzNT6rYSZKFbRaoHB7JfRR2wY26nCjft5OlJOdZTCspeHfAwM SdqTn+GT2QAIPvCeLnwq0K6BBAXRyeWCynNqbAc6Esbqlwzi1PcbQm4f3FRXKpswVIx4 2t9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=99EvRVI9Qq5bXHoBlRroHLeUNEmfl9mbvNC4PpGxsVM=; b=LwMLEGCtqunIYYzIwQERRA1y768CjG5ejfFJliLUSzdTTph9mLDOuf9cSuL/RKM3KW irlA0zCLaLfAJXaV0mzLT0wyZ4h7jXpPdm4jm8w+KvoLwcZhlr0ZeBm/REYsPkS8kKKD K8/qyiWT9IlvNPotxKOiMhWZbAka3OD8/RueTzRJzSLqe4CxLGXavc7q6GE/b5592M8t CrMGd+wF8gR+FZ8vqrQdJw88r+ZxHBCtMCYCdq2dliZs8wcL70+lVUVc9DQGJFO2gS6s kj+GR5amNLJ6Qiubnifv2142uR3CMyRfksbX27cJ19YA4LgfBlv70Qex52/Vu40gnIta s7LQ==
X-Gm-Message-State: APzg51Ay4gDf1WBtM6I3Ce7w79LoxUma7WcDjpBjebxnKTkt/998H4iN ZTikrFgg0OAm9Mo4w0+JERQMX7X7Hs2L4+3w6iKc7A==
X-Google-Smtp-Source: ANB0VdbXnMvxb9TlQ4mtwBHr/v3YHF85vEYCClDdwonRWuszvNslVVGP1yYE1vX72n8sMd5VWay0ZYtvemX9OfojFQo=
X-Received: by 2002:ac8:2862:: with SMTP id 31-v6mr5263097qtr.18.1535324488767; Sun, 26 Aug 2018 16:01:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3312:0:0:0:0:0 with HTTP; Sun, 26 Aug 2018 16:01:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Sun, 26 Aug 2018 16:01:28 -0700
Message-ID: <>
To: Joe Touch <>
Cc: Christian Huitema <>, Toerless Eckert <>, int-area <>,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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 23:01:33 -0000

On Sun, Aug 26, 2018 at 2:12 PM, Joe Touch <> wrote:
> 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.
Again, there is no such rule in IP. Multiple devices could emulate a
NAT, but the overhead of doing this down to the granularity of
fragmented packets would be extraordinary. The way implementations
have handled dynamic transport state in the network is to assume
consistent per flow routing, or only one egress point.

> 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.
Maybe so, but a NAT is not a host either. NAT is one example of
intermediate nodes attempting participate in transport level protocols
and thereby breaking the end-to-end model. But, unlike a host, there
is no guarantee that it will be given all the necessary information to
produce the same behavior as a host. A set of assumptions external to
the protocols are required to achieve something close to correctness.
Best way to fix that is eliminate the need for dynamic state.
Accordingly, I think a recommendation in this draft should recommend
use IPv6 without NAT in order to address the NAT-fragmentation


> 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.
If it's not a router, then I don't believe it could  could a host or
> Joe
> Tom
> Joe