Re: Fun and surprises with IPv6 fragmentation

Christian Huitema <huitema@huitema.net> Sat, 03 March 2018 05:23 UTC

Return-Path: <huitema@huitema.net>
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 333021241F5 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:23:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 65oD2IUlUZYw for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:23:57 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0234C120724 for <quic@ietf.org>; Fri, 2 Mar 2018 21:23:57 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1erzeD-0007kT-U7 for quic@ietf.org; Sat, 03 Mar 2018 06:23:55 +0100
Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1erze7-00005Y-7e for quic@ietf.org; Sat, 03 Mar 2018 00:23:51 -0500
Received: (qmail 31917 invoked from network); 3 Mar 2018 05:23:44 -0000
Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.241]) (envelope-sender <huitema@huitema.net>) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 3 Mar 2018 05:23:44 -0000
To: Ryan Hamilton <rch@google.com>
Cc: "quic@ietf.org" <quic@ietf.org>
References: <681fcc96-4cf9-100d-9ad6-b3c7be9189a5@huitema.net> <CAJ_4DfS=6h9qEQ+uwntLtDZNSODhqc_0pww7c2gK50XKna0BCw@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <da0cfd5c-2c25-11f6-ff84-b0d164fc286b@huitema.net>
Date: Fri, 2 Mar 2018 21:23:41 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <CAJ_4DfS=6h9qEQ+uwntLtDZNSODhqc_0pww7c2gK50XKna0BCw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------75DC1E9E970AA3EF02710CBB"
Content-Language: en-US
Subject: Re: Fun and surprises with IPv6 fragmentation
X-Originating-IP: 168.144.250.215
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sqlLt9pxuw9ZonJmb9C/Hp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViPisjbA4BlspmA+sRO05tyM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBVJlvs1RB82smE8/eMfkvDvvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X4YOVFgAoWZARPb9ZllYFzqxIv43wzXWtTdd9BKP57VV6WPJeWEI/BElo8uQ1OVEcwfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4CT J7q4QftjYVRI4vivMj6DSGG/BQd7r2NVEaNhWos5pqubrLNF051VEs6eQuOmmnkccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtt1Lx8F1uBisuhh9Eb2drX2Bi6owqeb+h1kbxIVWYdC7mWfB wRrxmI1OlqTCPsUGPVeqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g==
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ESSHWAiZH5qWdWVHVZazR4VGsaA>
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:23:59 -0000


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...

-- Christian Huitema