Re: Fun and surprises with IPv6 fragmentation

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Sat, 03 March 2018 06:26 UTC

Return-Path: <mikkelfj@gmail.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 6998512EABD for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 22:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 QFn22SDudik4 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 22:26:57 -0800 (PST)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 81571126C19 for <quic@ietf.org>; Fri, 2 Mar 2018 22:26:57 -0800 (PST)
Received: by mail-io0-x22e.google.com with SMTP id g21so12851724ioj.5 for <quic@ietf.org>; Fri, 02 Mar 2018 22:26:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=aavYC1UDIA8xa/2VhDlG+PKfhA3NX/BLGQ+G3K7bIOU=; b=PM/IMd/A1X15H8mKb3euhjYuSLhC6s7OUH3NHmY3dDVHHqvT1kEWGsNcuqrPT57LkQ 19QoGsifDjXe1eb8pd20giMCl8vpsnjOUoIDzEhATLNTDKy9/ZBNm5n+DmANxgLwyKQL YnH7OuSsWEDnpAjXVqByVI97tRha1SSRI8ODJqGhpRkVOYSicaTFX1cklOumo5BAcgR9 ABOPX0n4CmSz+RJNYzmvYYWYX9YXh5O8POzPz3bmg4bhawZs8KhXhudMWUfF6BWoecMu Lb6j4/j9oinTDOwrRKgE55EUMdowiZNipcK3P3LU4qmS+kRw+bqYvg9cGLadeZlDoyLI 7p7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=aavYC1UDIA8xa/2VhDlG+PKfhA3NX/BLGQ+G3K7bIOU=; b=NDDbx76sV5CxcmBnHnL2hmeQgNQvWW+JPrT3RhdDgUySEUVY+eOlKa4VI70YAouHdE RGR+/Lnvc9mGWqgYR2hPrn5xPGIo/25KqRcTY5I+2j57tYUq3QQIjah1762PnvO/mYG1 8xj7wzUjKk79dpt2nQiWpWClgfZWj3l6MOu+GnxJfMrD1eFLZhjoOyOnRBq7J1o28WzZ dWaKzi3jhJU2IBqH9h3msApp63KFYsV7CpxrkQJpSTcCdWfw/eOEBuy8lzfyCocVq0vf Y+yhi6NPPMMR+pRhRLU9uvqEeCW6Bml8ZaFdYD6nYexWfiXvl2dHoIbMnqxMoOGg3rnk HxZQ==
X-Gm-Message-State: AElRT7GThcW57tiUy12OGSBYQDEE7hTttozmyjyb3KL9HpFZqYfqDtA1 y0p4/tTNhl+iEPJepmtIqywT1t/y8itEHh5TqbQ=
X-Google-Smtp-Source: AG47ELvFh+IrsXnrwTY/owrPH+VKscieCx64M8j2txnj1L6C/xiRcQcobHkLj2c8wBzyuAMNSv3U+QP2J/kvoVFWbM4=
X-Received: by 10.107.33.72 with SMTP id h69mr9347724ioh.209.1520058416758; Fri, 02 Mar 2018 22:26:56 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 3 Mar 2018 01:26:55 -0500
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CAJ_4DfRm1v_+MnTu56G0g_FXuQcYicgs6wq58ZShF8WcK=-JyQ@mail.gmail.com>
References: <681fcc96-4cf9-100d-9ad6-b3c7be9189a5@huitema.net> <CAJ_4DfS=6h9qEQ+uwntLtDZNSODhqc_0pww7c2gK50XKna0BCw@mail.gmail.com> <da0cfd5c-2c25-11f6-ff84-b0d164fc286b@huitema.net> <9e718f13-51db-0af9-637e-3e45379ed48f@huitema.net> <CAJ_4DfRm1v_+MnTu56G0g_FXuQcYicgs6wq58ZShF8WcK=-JyQ@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sat, 3 Mar 2018 01:26:55 -0500
Message-ID: <CAN1APdckzkA4gysV690M64-3_=NGDMBz_2zsfjyK5xa+RPH=mg@mail.gmail.com>
Subject: Re: Fun and surprises with IPv6 fragmentation
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140f5e6f8063005667c2df0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/4k8C8ohlNbsaCAVXKJUC2nFt92U>
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: Sat, 03 Mar 2018 06:26:59 -0000

Excellent writeup - almost like a Mars Rover gone AWOL.

Could it be that IPV6 is tunnelled over IPV4 and reassembled within the
tunnel rather than at the receiving endpoint?



On 3 March 2018 at 06.38.27, Ryan Hamilton (rch=40google.com@dmarc.ietf.org)
wrote:

On Fri, Mar 2, 2018 at 9:29 PM, Christian Huitema <huitema@huitema.net>
wrote:

> On 3/2/2018 9:23 PM, Christian Huitema wrote:
>
> On 3/2/2018 9:09 PM, Ryan Hamilton wrote:
>
> I'm sorry if this is a dumb question, but I understood that in IPv6
> routers could not fragment IPv6 packets, only endpoints.
>
> Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets
> exceeding the size of the maximum transmission unit of the destination link
> are dropped and this condition is signaled by a Packet too Big ICMPv6 type
> 2 message to the originating node, similarly to the IPv4 method when the
> Don't Fragment bit is set.[1]
>
> End nodes in IPv6 are expected to perform path MTU discovery to determine
> the maximum size of packets to send, and the upper-layer protocol is
> expected to limit the payload size. However, if the upper-layer protocol is
> unable to do so, the sending host may use the Fragment extension header in
> order to perform end-to-end fragmentation of IPv6 packets.
>
> https://en.wikipedia.org/wiki/IPv6_packet#Fragmentation
>
>
> How sure are you that it's a router and not the sending host that's doing
> the fragmentation.
>
>
> Yes, you would think that. And you would be right in theory. But then, in
> theory, theory and practice are the same...
>
>
> And to answer the "how do you know" question, here is what the server says
> about itself:
>
> ubuntu@ip-172-31-61-32:~$ ifconfig
> eth0      Link encap:Ethernet  HWaddr 12:40:99:30:a3:86
>           inet addr:172.31.61.32  Bcast:172.31.63.255  Mask:255.255.240.0
>           inet6 addr: 2600:1f18:2310:d230:5103:7d9e:7d75:374f/128
> Scope:Global
>           inet6 addr: fe80::1040:99ff:fe30:a386/64 Scope:Link
>           UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
>           RX packets:32757 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:15697 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:0 txqueuelen:1000
>           RX bytes:8025531 (8.0 MB)  TX bytes:3622487 (3.6 MB)
>
> Note the "MTU:9001". I don't think that a 1518 bytes packet would be
> fragmented by that particular end point. Something else did it.
>
> -- Christian Huitema
>

Middle boxes! *sigh* ​That does seem compelling, I agree. I don't suppose
you have a packet dump from the sending host?