Re: Fun and surprises with IPv6 fragmentation

Ryan Hamilton <rch@google.com> Sat, 03 March 2018 05:38 UTC

Return-Path: <rch@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 126D11241F5 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level:
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] 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 XfgehqFdOui3 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:38:18 -0800 (PST)
Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 D7BF9120724 for <quic@ietf.org>; Fri, 2 Mar 2018 21:38:17 -0800 (PST)
Received: by mail-yb0-x230.google.com with SMTP id v8-v6so4106188ybk.6 for <quic@ietf.org>; Fri, 02 Mar 2018 21:38:17 -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=b+7lnH4aprLaVrW2aHJ4KEQEd97vjpvF8X2Hef3H4qs=; b=ZqaCnaXQ4hoGhHqD0S4qeGGXkDxAF6I9BHltyyAB0V3SiDwCz8q0ZYkfAiRWp9Topw OyJXA2tJr39tH5I5G/MPXLviUezV8t1IHY071c1XmlZ32GMqij25HznsY4mH4P7kdcEK cQwyw4fuGDEMyHdnlGp0osQqOC2xYIepkDAj60pJ1L+MXIzYGVGfAc/FDEEBMgsSXsCN iAGupSyYYisI2jPe23Gbl8v5zFFNgkrRk5/uPVguFLEyqoPy37R3SFQepThn+TkgESV3 W4t0LjDtuYvYLX3CFEILYkK3iUJR0jotqiY0HPTAJ029K8dTmkQwXmu+RbBSwSEeTZ5K pZEQ==
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=b+7lnH4aprLaVrW2aHJ4KEQEd97vjpvF8X2Hef3H4qs=; b=MrT46HJUwoVie0OwNKZRoaPcKsfrvKB8GI6bU9/SEwjgyZR/894olIvNQVZYAZkCBu vDnRkUQtwFo/u6gQKrhjB5fIW6b5PF8HqDeJ1YZxlgH3mZsKp/mD/k7sM+60KsKy4HTs Fjpd6kDBA9eBEgSGkwBessXnnkQ8dsdOk0oXuJhJA8/yso4et82P6Zr+KB8Fa6WtBIzM i3Gukyjj1Z/mHefRywJRhqyLNrpEPNeC33Fh0sDzLRiFDdlbOg8Ng7VbFAbMDv/iOQbP sJUiUXyKiVhsPD3I21H4ezfFAu5V1S9MLhg/tJu+ncm4d9ISLG8Ow9aB6rypElGVvM53 4Vzg==
X-Gm-Message-State: AElRT7EMQiNE5yJIPSVtTYt/ghvj/+CaqE5Z7lT6hhh5ZEMKFkCcktMR pqHpiNyCuYoryN1fblu69D2OERd/cTU0u1bhDn3pq+Lz
X-Google-Smtp-Source: AG47ELvdNVt9lUNC4ptDelU1WGPjxKSPhebCQW2i+neD9ky/65TV/9YgZJU3GJo8vcrBu+ZogCq7ZTxugBJmQLdHyJQ=
X-Received: by 2002:a25:3c03:: with SMTP id j3-v6mr5095529yba.357.1520055496591; Fri, 02 Mar 2018 21:38:16 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a25:918a:0:0:0:0:0 with HTTP; Fri, 2 Mar 2018 21:38:15 -0800 (PST)
In-Reply-To: <9e718f13-51db-0af9-637e-3e45379ed48f@huitema.net>
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>
From: Ryan Hamilton <rch@google.com>
Date: Fri, 2 Mar 2018 21:38:15 -0800
Message-ID: <CAJ_4DfRm1v_+MnTu56G0g_FXuQcYicgs6wq58ZShF8WcK=-JyQ@mail.gmail.com>
Subject: Re: Fun and surprises with IPv6 fragmentation
To: Christian Huitema <huitema@huitema.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eaad2305667b7fb0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1sZDb-qkgFr7_o_6nxX6SL1UxkI>
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 05:38:20 -0000

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?