Re: Fun and surprises with IPv6 fragmentation

Erik Kline <ek@google.com> Sun, 04 March 2018 12:00 UTC

Return-Path: <ek@google.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6E7124D68 for <quic@ietfa.amsl.com>; Sun, 4 Mar 2018 04:00:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Qicn55XgevmS for <quic@ietfa.amsl.com>; Sun, 4 Mar 2018 04:00:19 -0800 (PST)
Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (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 7A4EA1243F3 for <quic@ietf.org>; Sun, 4 Mar 2018 04:00:19 -0800 (PST)
Received: by mail-yb0-x234.google.com with SMTP id v8-v6so4878879ybk.6 for <quic@ietf.org>; Sun, 04 Mar 2018 04:00:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kjdBOBFjKa49nyPYCcAXLOP+yAWAflpNX8TCIemdrOY=; b=sbiFY6P4adx4rZ5Njo+BTR/xe4ilwK1duJtikCdW8r6zo9xlJn7ZlgKGqGlcaqD9UY KgFjnvR+yfop1ra1qNZGZOa0p9leqef2dHLiqTsOesWkPxvyhUKG2hSgn6iwnrwPhO9+ AW7lLzIwTgmaCAkt4mkiczay+GEgCHEmj+fsM5k5RDuaA9JoPWa71jI/Vn6LHBkUmB3d NAG2eFTze1zOeHZMvNf1jKLi2b8S80ZJuIUA/iT+i3AqY8Bj/ITsFIEZlueeu8dSsQ7I nTU+8CeKLrddgcB1E1t31BjvVGN39wyDRrYQjf4WMytcloODuXqoEUJ6A24IMzu3A7oL lW9w==
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=kjdBOBFjKa49nyPYCcAXLOP+yAWAflpNX8TCIemdrOY=; b=GpUUY+Oz1Bh7o7m+i4bBxjdaWzQulPgLjWWf3Y2L8LK5jvXB3bEwDmh6YKGURdsNTv IkoJPNntsW0Is/SFny1+S+SzW3Lmj/MbGtQcxS2qUZXzQFnxXP4BvWlbqsZY8N8YIizt 1/kgmkUnpFUE51Qa3S4e75kIy9YBpyftFKCmRVf9TxppM1tuHQxYriboVQ+ZSCwqUcYD GMwPSyfY6ulz4Edo310u0K3HADFlCK8XHT9bE3+6aWugd5niVLjBQ8Y/SWTqNNeOfls/ 98xiBm65qBGOTNzzCiczvuTIsmr1ts89Sm9G5RywkDI7mX7wYNJrHDLXRTDFoDiyPM4U sFAA==
X-Gm-Message-State: APf1xPBLNIbUmSYvzHsaUIs5aDT3noRlr/SZyOjdAPimFhH4+3u4TgMG xl5jL+Ova4iI+Agw/Db2gvyH7q3ReRuQUVXLnr6hbw==
X-Google-Smtp-Source: AG47ELvYqfi5v3AJ3zEZtsitiove5k+POaOSxJeJVdM8wVeNEEIUlMbd532x2jgu5lbhqWFqwm5nGdAQLvA/8RftbbU=
X-Received: by 2002:a25:2c87:: with SMTP id s129-v6mr6975982ybs.151.1520164818192; Sun, 04 Mar 2018 04:00:18 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a25:ab51:0:0:0:0:0 with HTTP; Sun, 4 Mar 2018 03:59:57 -0800 (PST)
In-Reply-To: <681fcc96-4cf9-100d-9ad6-b3c7be9189a5@huitema.net>
References: <681fcc96-4cf9-100d-9ad6-b3c7be9189a5@huitema.net>
From: Erik Kline <ek@google.com>
Date: Sun, 4 Mar 2018 20:59:57 +0900
Message-ID: <CAAedzxq5G_gAaBzdizv5x-yobomW5+8sSZ_1rn4ApGYpQZmpvg@mail.gmail.com>
Subject: Re: Fun and surprises with IPv6 fragmentation
To: Christian Huitema <huitema@huitema.net>
Cc: "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000800b1056694f46c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4NAVB23Y7bbwIjo3BbW52fOMUVw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Mar 2018 12:00:21 -0000

> I tried to work around the issue by setting the "don't fragment" bit on the
> socket, but somehow that doesn't work.

I don't see how an app can do any sort of PathMTU on its own without following:

    https://tools.ietf.org/html/rfc3542#section-11.2

Without this, the sender OS can (by default) generate fragments if it
receives an ICMPv6 PTB.  I.e. IPV6_DONTFRAG seems to me like a
requirement for MTU detection.

Put another way, I think you probably /always/ want to perform the
step you describe, whenever probing for MTU.


You said (elsewhere) you had a pcap showing fragments arriving at the
client, but have you checked that the sender isn't receiving PTBs and
reacting accordingly?

If PTBs are being received and the fact fragments are still being
generated with IPV6_DONTFRAG, that could point to a bug in the sender
OS.

If something in the Amazon infrastructure or along the path is doing
IPv6 fragmentation of its own accord it's violating the text at the
top of:

    https://tools.ietf.org/html/rfc8200#section-4.5

even that text isn't particularly strongly worded.  (I looked for a
MUST or MUST NOT elsewhere, but haven't found such text yet.)  Devices
doing this should probably be identified and expurgated from the
network.