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

Tom Herbert <> Fri, 27 July 2018 17:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0C8A131000 for <>; Fri, 27 Jul 2018 10:20:48 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WPRFmzLD0lrR for <>; Fri, 27 Jul 2018 10:20:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 337B0130FF7 for <>; Fri, 27 Jul 2018 10:20:46 -0700 (PDT)
Received: by with SMTP id q12-v6so5793156qtp.6 for <>; Fri, 27 Jul 2018 10:20:46 -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; bh=uHVzORYW4Kr/fBp7ODTyeKJ2ejmye5/LzNe04sfEP/w=; b=OwVRl4eFTyfDcqp8FHvgp/NZXcNW2QYaYF+64qQVdxLTYwOrCe+AcXFQ9teVyRTh0m xlw/uydlRJeIE3OPreOzLzQseE3R+90t1HA0Q+NVVr/yG7768VuWdsGeLOMy+OqQh9Sb ig3cyJ4YTk0tpxpkFEjzdXZ2zzjxA86AM21du52NZbywIAWxZ6HZota4SfeAmI7ajVtS a8H1FyukNMOKZQ1PJ0d+bsk16NuVH+fGDLQRiFZN3er1N0lbr6eibDf/sr/BXB86XsCG t/8SPjAPwXImepv2aCDnf/y7N+VE3byhZ1Ys4wm2IpXWYGiJTwG+oJebo3/6T09OSlfL +qsw==
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; bh=uHVzORYW4Kr/fBp7ODTyeKJ2ejmye5/LzNe04sfEP/w=; b=LOcNPOCLzgf0RLoL48CM6exDB7BqQdly1FqTjfFXcUw9rPdnZnRkx3j6VRhqs1qFlv nDetQIQJlue6pLlcDSAKRAchYJtKEeWBGLourk8LNT2/k8kjqQ++4JD/Ekhn/WtCUGhS fmMl1JSsV2+EDXb9aZjSgBpuebI0SyqkwFR1dzP/MAkYBIqAHwy9trQj3g0SVW3UoPPn dbFMKHczfeb6VPt/Y7v0Fbgw7BQoMT9m+iY/oHRA/N0x33/OjbD7qqlUZNvvwdZ2V/GP DVXpB7rVugE1CavEzUkqSwsDyIJizyL19Eru5iwByoizzRKxhNDUYq+HZbsLS6bAgNsD Q6TA==
X-Gm-Message-State: AOUpUlFFxMGSRHd/TN7eBSvrA0mOBqvhYYjiwJe3eXaauvREcyFyVYQt ClTqvhTMGCra3iML/1ei/XaKpHI45/PP0zeGcDNzQQ==
X-Google-Smtp-Source: AAOMgpeQUy70pud853/VBdmK5B78kXGeV0nAXSR5EzWBW8RDkxotd7miluT4Xuy5t26lX5lx7oMqjMiPhgjsPn5gu6g=
X-Received: by 2002:a0c:a991:: with SMTP id a17-v6mr6414095qvb.83.1532712045114; Fri, 27 Jul 2018 10:20:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 10:20:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Tom Herbert <>
Date: Fri, 27 Jul 2018 10:20:44 -0700
Message-ID: <>
To: Fernando Gont <>
Cc: Joe Touch <>, Wassim Haddad <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
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, 27 Jul 2018 17:20:49 -0000

On Fri, Jul 27, 2018 at 9:25 AM, Fernando Gont <> wrote:
> On 07/27/2018 05:15 PM, Tom Herbert wrote:
>> On Fri, Jul 27, 2018 at 5:38 AM, Fernando Gont <> wrote:
>>> Hi, Joe,
>>> On 07/26/2018 04:14 AM, Joe Touch wrote:
>>>> Hi, all,
> [....]
>>> Side coments:
>>> It would all seem that there are two operating environments:
>>> * Controlled environments, where you can somehow make all this work
>>> * Public internet, which is more of a "fingers crossed" thing (if anything).
>>> I'm not saying that I'm happy with the outcome, but rather that I think
>>> that from an engenering point of view, it all looks like this ship has
>>> sailed, and we should probably figure out how to deal with those cases
>>> where fragmentation is actually needed.
>> Fernado,
>> Couldn't that same line of thinking be applied to several other
>> protocol features?
> Yes, indeed.
>> So has the ship sailed for out ability to ever use
>> extension headers or any protocol other than TCP (and sometimes UDP)?
> It would seem that that's the case, yes.
>> Maybe documents that recommend operational workarounds should
>> distinguish problems that inherent in the protocol from those that
>> have arisen because of non-conformant implementation. It's true that
>> calling implementations that probably won't help to fix what is out
>> there, but maybe this could help prevent new instances of
>> non-conformance.
> I kind of agree with you. That path from spec to implementation is what
> you'd call engineering (or what others might call "taking shortcuts", etc.).
> For example, what happens with EHs has a lot to do with engineering:
> they could be made to work (e.g., remove performance impact), but
> devices would probably be more expensive. Folks buying gear wouldn't pay
> for something that its not used in practice, and vendors wouldn't just
> "improve" the boxes for free. -- yeah, you could argue that "hey, there
> shouldn't be penalties for EHs, since they are part of the core IPv6
> spec" -- but, while probably correct, that will not change reality.

The irony is thatxtension headers (and alternative protocols as well),
including fragmentation, aren't supposed to have to "be made to work"
in intermediate devices. With the exception of Hop-by-Hop options they
are supposed to be ignored by design, and even in the case of
Hop-by-Hop options RFC8200 relaxed the requirements so that they can
be ignored. Extension headers are considered problematic only because
of ad hoc assumptions made for "value add", non-standard features
implemented in intermediate devices.

> Not that I like the situation, but... I think the least we can do is to
> do a reality check wrt how things are supposed to work vs. how they
> actually work.
> For this particular case, this I-D makes that point for fragmentation: I
> I think we all agree that fragmentation is fragile -- making that point
> clear at least raises awareness of the problem, and might trigger some
> action on the topic (whether to correct the issue, or to circumvent it).
Right, but I still think that we should be more clear about the root
origin of problems and blunt in requesting that non-conformant
implementations get fixed. For instance, as I mentioned the ECMP
hasing problem with fragmentation is entriely solvable if only
intermediate devices will use flow label instead of trying to find
ports for a hash. Fixing devices to support this reasonable and should
be low cost.  IMO, use of flow label for ECMP should be a strong
recommendation made in this draft.


> Thanks,
> --
> Fernando Gont
> e-mail: ||
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1