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

Brian E Carpenter <> Sat, 28 July 2018 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 039E912F1A5; Fri, 27 Jul 2018 19:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 KwD5dhibJtp6; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::543]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8C8A4130E32; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
Received: by with SMTP id r1-v6so4210435pgp.11; Fri, 27 Jul 2018 19:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=YX/2p2HsEBCf/bNayXW9iwYrHxcDJGuERgvv4YyQjHQ=; b=Y9cr/hkYVXmqOvET5STdfkCTbWprz0PqxuIvQRdCeL/tQaJ1nZKe8x8NYHRjhIwAwf 3wrdH1/ly5I+KKi7NYdMlGqfFgo5g91JoEZMbFDGxqSGrbhkIlHz5MG+WRcntKuSLKk8 aEDLA45eL3jvshUHAEqLqHdzK49AIGvVVxY1Nyz3wnmHG6z/OpTdq8RFeJrro0svS+BH OD5b6Dn9YYT4252dgKUd4b504fBJR2wJjafoychiLZSKQLYxQPpHK7YRWcoFqiRIq6Ru kWimgNxQTSThTQJ/sLGT0IbmxfFhQ8T1wkysVE89WHO37ORd9sEVODN3lJspfSwp/zzT miTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YX/2p2HsEBCf/bNayXW9iwYrHxcDJGuERgvv4YyQjHQ=; b=tl8jyAxQZN9dTSo9YWP1aKfR8b3fEDStP8tA/lOjVyF9+212JcOMQBHT8aEaQOoBgJ pcqYeZO0YQfDMkEoWrb+vs3oBYsFNNlUTsqEYJJ2Bou5tD2y/5rAM3dqtGGvJAcj41Ex EFZj2dGiQ65yGjgf73hmZf5FGo5ajNVEA/vpaocyyZq9CXI/zooLXxZPP8VUzgI/0Fbk VgS0PogJZba+2PTe6MAvIy/KKIFngS2RnyWg9M7OieQd7hNnfNFB5e2pq3+Kt3K99JNF T9J485/+bZTOK8yrTWOoURua7NbaO4KNldn9+iLhq0oTdAQSdGqDS2ih5k23BQX9ngXg gWNw==
X-Gm-Message-State: AOUpUlHAlNG852LrklItCZyANnl0JXsMkp3BtXKc56gs3TrZ6wB9C6iU BAjDZ78Oal3PjkYlUPDRmLBv60f8
X-Google-Smtp-Source: AAOMgpcSo16hA+aq/kUHLbxC2qBxkNEIkYrdE18feP8YisZH3sSEQ8kT1pOQe28aKLCA6sTGhKgPgw==
X-Received: by 2002:a63:4b5a:: with SMTP id k26-v6mr7970736pgl.384.1532745137701; Fri, 27 Jul 2018 19:32:17 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id c85-v6sm10643433pfd.110.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 19:32:16 -0700 (PDT)
To: Tom Herbert <>, Fernando Gont <>
Cc: "" <>, Fernando Gont <>, "" <>
References: <> <> <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sat, 28 Jul 2018 14:32:22 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Sat, 28 Jul 2018 02:32:23 -0000

> The fallback is to only hash over addresses.

Hashing over addresses+flow-label is fine too. If the flow label
is zero, it's the same thing. If the flow label is set properly,
it's a better hash.

I believe this is covered in the various relevant RFCs already
(6437, 6438 and 7098).


On 28/07/2018 10:38, Tom Herbert wrote:
> On Fri, Jul 27, 2018 at 11:54 AM, Fernando Gont <> wrote:
>> Tom,
>> On 07/27/2018 07:20 PM, Tom Herbert wrote:
>> [....]
>>>> 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.
>>> Fernando,
>>> 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.
>> Please see:
>> <>
>> theory != practice. And no matter how right you might be, that doesn't
>> make the theory a reality.
>>>> 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.
>> That is certainly not going to happen. From the pov of the folks
>> operating the networks, there's nothing broken.
>>> 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.
>> Yes and no. There was at least a time in which the flow label wasn't set
>> at all, or even was mistaenly set (e value during 3WHS, a different
>> value afterwards). That means that you cannot really rely on it. If you
>> cannot rely on it, you need a back-up mechanism. And that mechanism is
>> inspecting the trasnport port numbers -- from that point of view,
>> there's not much sense in dong ECMP with the FL if you cannot rely on it
>> and somehow you'd have to be prepared to do it based on addresses and
>> port numbers.
> The fallback is to only hash over addresses. Hashing over ports is not
> reliable and can be problematic in itself. For instance, wrt
> fragmentation, some middleboxes will use ports in the first fragment
> but fall back to hashing over addresses for rest of fragments. This
> mean the first fragment almost always takes a different path which can
> wreak havoc on down stream devices that aren't expecting that. So
> maybe it's another recommendation in this draft that middleboxes don't
> use port information from first fragment to do load balancing. This is
> another relatively easy fix.
> Tom
>>> 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.
>> I wouldn't mind. However, that doesn't change the fact that
>> fragmentation is fragile.
>> That said, if you look at RFC7872, t all looks like anything that is EHs
>> is dropped to some extent (while not included in the RFC, I also mesured
>> IPsec, and you get similar numbers). So besides the issues that are
>> specific to fragmentation, anything that is EHs gets dropped here an
>> there. -- and ding ECMP with the FL will not change that.
>> (Again: not that I'm happy with the situation... but being unhappy will
>> not change reality anyway :-) )
>> Thanks,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail:
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> _______________________________________________
> Int-area mailing list