Re: [v6ops] IPv6 fragmentation experience

Jen Linkova <furry13@gmail.com> Thu, 22 March 2018 17:21 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0429126B6D for <v6ops@ietfa.amsl.com>; Thu, 22 Mar 2018 10:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54WcGlTtMJmD for <v6ops@ietfa.amsl.com>; Thu, 22 Mar 2018 10:21:52 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792BC126579 for <v6ops@ietf.org>; Thu, 22 Mar 2018 10:21:52 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id z143-v6so14337958lff.3 for <v6ops@ietf.org>; Thu, 22 Mar 2018 10:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UvDMKNg2k/uWx3JVdRsdlz7yp+g1oMDNPnyh3lH27FM=; b=XMyLDaXDrDCx/WrDwuDKi8ExRV7HLNaWCt8RkHonzj8ViSYsbVQUe0tiX6dP+TutSA cZq3Z15JdXd/EaTN/IQb4VzhLq+0Yo1P9XAU0msC/lJNFqZZsMdJVdUrYBXS78a3lj+k JkpUZHFNZP0zIUbXfK1DYICI3TmDlrPRwl1aGUMhCdVqqkogxo1hi/X637yRgvrtIQkb LY2bcnUsi9avs/LydvS+kgKFlV1A5YzpjPVmbhjJvQvOVdVjU778fJnw3cA7UsTuFENu wNfhySvCBt53dXbDp5DLDGlTXEIgMNTJygHH/eSPdLjvFzyn+fOkTNvlCG5BdbeONJge 9cOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UvDMKNg2k/uWx3JVdRsdlz7yp+g1oMDNPnyh3lH27FM=; b=r1VWt+WMgk2oCFHRoOPBNx4o+5xAN9aiCusi+YyuBoY4V846u1+kuhyF7Gga25poIP oMVMfjMsRn91c6IQVCtOR1mXqqZVROsXpQReH2eK8O5YnnvO+J/mUQgbwBt9imaTsSmR ZRDLzFGHRQEUuT+bRrk+tl0hdgopUHnf2azh19TTjPNpw/nH9+p/KOPjUzV5RjOTbWPU 9txuJkBOFPO22fRa+k+LyInXQ+EHtwD832+h0iAp2+sGYTu++ztz1+5Jrd2N2FRYi0Kj jM7QHsVotY0C1p+Z35O0i7iuiFuqs7vZxv3OhljYw+v+rsoeZJHHydq1rKQfg07GHsUp rtUQ==
X-Gm-Message-State: AElRT7GwKfSE6q/JfdugReVqWpIc9xRVGxIYAS1+H5KUrVHQS0nK6FFX cn9Lmr53TQdWrdUFMB3f0Lt9HPLCN+1CkI8HxwU=
X-Google-Smtp-Source: AG47ELuNp38/Lz/pU1eW+FrlBm3X9WsZasJcCfRMM/84oXsCSmG1LESCaOY9nBWT95MyT+adlIj49yznC+352knz4ZA=
X-Received: by 2002:a19:2145:: with SMTP id h66-v6mr16535447lfh.63.1521739310603; Thu, 22 Mar 2018 10:21:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:d10a:0:0:0:0:0 with HTTP; Thu, 22 Mar 2018 10:21:29 -0700 (PDT)
In-Reply-To: <CALx6S36WA0hV5oa1Ab7D6nH=1B+SGRA=JVJgdYWRH7OH8wB_JQ@mail.gmail.com>
References: <84080e87-9ec6-a676-b535-088470e43923@asgard.org> <alpine.DEB.2.20.1803201208550.20609@uplift.swm.pp.se> <561690FD-9016-4EB0-B03C-CE2BFE4BE7A0@employees.org> <7456C389-0CB0-4E9D-8622-E3461FAA4375@steffann.nl> <5F05318A-0B2D-4B6F-8442-6A0C7E9581EF@gmail.com> <6cc086ed-f6b4-60a9-d181-1e3a6a41c563@strayalpha.com> <alpine.DEB.2.20.1803210918100.20609@uplift.swm.pp.se> <92BFD600-9948-4E2C-80A1-F5F2BD320A31@strayalpha.com> <20180321200444.GX89741@Space.Net> <0c57a669-7cad-e554-b637-a6d86e0e7a67@strayalpha.com> <20180322102010.GE89741@Space.Net> <CAFU7BAQU9NNL=B7YjdNxDH9fjv3cFk=LUsz-eG0Rxe2gA6X+8g@mail.gmail.com> <CALx6S36WA0hV5oa1Ab7D6nH=1B+SGRA=JVJgdYWRH7OH8wB_JQ@mail.gmail.com>
From: Jen Linkova <furry13@gmail.com>
Date: Fri, 23 Mar 2018 04:21:29 +1100
Message-ID: <CAFU7BATfu2remSQTiLGpUDLhp020xFLLQdDBT-3iKsNhBmw+wg@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Gert Doering <gert@space.net>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1CIi942kOGKW3HB-oxdZlcui21k>
Subject: Re: [v6ops] IPv6 fragmentation experience
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 17:21:56 -0000

On Fri, Mar 23, 2018 at 3:58 AM, Tom Herbert <tom@herbertland.com> wrote:
> That's one of the problems with intermediate nodes that attempt to
> infer or participate in transport layer semantics.

I agree it's most unfortunate that almost every intermediate network
device is interested in transport layer semantics
of transit packets. However I'm not sure it can be changed.
Obviously the situations when such behavior is causing the packets
being dropped need to be fixed, and I totally agree
that it's not end points but intermediate devices fault.
On the other hand it's unrealistic to expect that  any modern network
of decent size would be able to operate w/o taking transport layer
into account
(well, there was an awesome idea of deprecating L4 ports and using
IPv6 addresses instead but...;)))

So from operational perspective we might need to think about how to
limit the damage. As an example, network operators might want to look
into
how ECMP and L2 balancing work in their networks and maybe talk to
vendors about adding special treatment for EHs - as well as
reconsidering filtering policies.

The expectations need to be set and documented. I mean, it's
reasonable to expect that an ISP might use L4 for balancing and/or
applying QoS policies (which in MPLS TE networks, for example, might
mean 'your RTT will vary'). Filtering fragments to/from your DNS
servers? Not such a brilliant idea..

>Similar behavior
> can happen if a device is using flow label for load balancing and the
> flow label changes mid flow, or if there is a routing change an
> packets of a flow hit a different load balancer that implements a
> different hash. In these cases it's not IP protocol that is broken,
> but technically it's incorrect and convenient assumptions being made
> within the network that fail under certain circumstances.

Exactly why it's a good idea to document most common scenarios and
discuss who we can ...well, maybe not to solve them completely but
make hurt less.

-- 
SY, Jen Linkova aka Furry