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

Tom Herbert <> Fri, 03 August 2018 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13C2B131006 for <>; Fri, 3 Aug 2018 09:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 eyMtD6f_Bjd1 for <>; Fri, 3 Aug 2018 09:00:23 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89E9913105D for <>; Fri, 3 Aug 2018 09:00:23 -0700 (PDT)
Received: by with SMTP id z74-v6so4336448qkb.10 for <>; Fri, 03 Aug 2018 09:00:23 -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=tYHzivm18V/6tHXLoRFNIa690Vojfr0c6gpbXujw434=; b=xFu1ncMwaVBuU93wnJKygm9rbiTW7Qt7SYUX9sHEFoJcFGGomi2/9PdTory7kOEmbG GJ1GFYP+NJiWWcNIESFFjkdmhiH9mUG6kdXXbW67nkDs7tjD5P/kF2CaD5XxBk7K9u1g 5FcjBDHpMSjRyv6DSnlW6D8fCVovLxrVIzhFr1jLq9WMfwyyh7Vk3YTWxYXAbnJ8zEqk MQEo5eoJuf+W5bZibuCsnpGYicxtFu2Meqq22EBDdiZcmC0I+TRoLh3A5ZReQJSYAdjf v+DWEb7tBGkvPwOOUBVg8qkGyaqkQ4qhEXPQYeyfkM47HP+uUhcrIQOQ+F+DVEx8GjPI DUoA==
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=tYHzivm18V/6tHXLoRFNIa690Vojfr0c6gpbXujw434=; b=NDpLMDH0hBJnobU7BCtV3HIgF1llrorvr+sJ2Fv4kFmT7AUBGOrNVJwZ9NJ3M1Vtf/ 2Jqsa+2QlqsiYttQP70vJbfeBH6csyFD5clVpU4TGvXWgRystS5FVL5t9y2GsNmje5HD D/twVebKJbfNTl9GilYY6ki8qBq5E3WsvlTapsypw/LNlhdFzfGnKTQV1/nwoK+0qBx/ nTBP9daIS/VUQew/NPreRlv5zM9v+a6GFTFKhxdbMym2kf1STiHQyllJsTPI3MSdWh/i Q2IKSzPjHA/6oFByTnQYTvZJRBPPbSNHLzZVQalev7zcj3OvmrI5/jd0uGqOyQtipoMj 7vqQ==
X-Gm-Message-State: AOUpUlE58+pe/3LyIZKZchqp5+MbwtniGPU1Vi1Sv/FVqH/lSQavS/3m kbAb8KrS2tDKdw9NVMyGf7ntQ5jEu4Ln5Fnqe9E6/5nu
X-Google-Smtp-Source: AAOMgpcOlfsxO4eYH3vgDlDl6BuOhxIeR3j/dSJTUq4tx/pszg3mU2CTJ0Ko+cQiC7vMJfB9MjeyAUPDoLly/MQ4GHE=
X-Received: by 2002:a37:c946:: with SMTP id q67-v6mr4431962qki.148.1533312021165; Fri, 03 Aug 2018 09:00:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 3 Aug 2018 09:00:19 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 3 Aug 2018 09:00:19 -0700
Message-ID: <>
To: Mikael Abrahamsson <>
Cc: Joe Touch <>, 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: Fri, 03 Aug 2018 16:00:26 -0000

On Fri, Aug 3, 2018 at 12:48 AM, Mikael Abrahamsson <> wrote:
> On Thu, 2 Aug 2018, Tom Herbert wrote:
>> This leads to driving everything down to only support the least common
>> denominator. Problem is that we can never move things forward if everyone is
>> bound to LCD.
> I don't understand why people think this is what I am saying.
> Car engines have "limp mode" when things go wrong. This is a restricted mode
> that gets you home, works much worse, but at least doesn't leave you
> stranded. I am saying applications should have the same.
> I've kept saying "Networks must support ip fragmentation properly.
> Applications should still work somewhat when it doesn't".
> Så relying on fragmentation and falling over when it doesn't work is not a
> good strategy to recommend to application developers.
You could say the same the thing about extension headers, SCTP and
DCCP, and even IPv6 itself since it still doesn't work everywhere. The
only protocols an application can _rely_ on working is TCP over plain
IPv4. That is current LCD. If the advice is that applications only use
protocols they can rely on, then Internet is stuck in time.

IMO, there should be a way for applications to use "alternative"
features and protocols with a fallback mechanism if necessary. For
instance, if the application had a priori knowledge that all nodes in
a path supported fragmentation, then there should be no issue with it
using fragmentation when sending on that path. Applying the car
analogy, if I look at a map and don't see any unpaved roads on the
route to my destination, then I can leave my four wheel drive all
terrain vehicle at home and take my Ferrari instead. I think that a
generalization of "Happy Eyeballs" might be a solution that discovers
and maps what features and protocols work on what paths.

Per the draft at hand, I think the advice to try to avoid
fragmentation is practical under the current circumstances. However, I
think that recommendation needs to be heavily qualified and scoped
appropriately. A general statement that applications shouldn't rely on
fragmentation cannot be interpreted as acceptance of non-conformant
implementation or as a free pass that middleboxes don't need to fix
there stuff.


> --
> Mikael Abrahamsson    email: