Re: Fun and surprises with IPv6 fragmentation

Christian Huitema <> Sat, 03 March 2018 05:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A82EC1241F5 for <>; Fri, 2 Mar 2018 21:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Lu22h8DCiv1L for <>; Fri, 2 Mar 2018 21:29:16 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFBEF120724 for <>; Fri, 2 Mar 2018 21:29:15 -0800 (PST)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1erzjN-0000fR-AT for; Sat, 03 Mar 2018 06:29:14 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1erzjH-0000VE-BJ for; Sat, 03 Mar 2018 00:29:11 -0500
Received: (qmail 13186 invoked from network); 3 Mar 2018 05:29:05 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 3 Mar 2018 05:29:05 -0000
References: <> <> <>
From: Christian Huitema <>
Message-ID: <>
Date: Fri, 02 Mar 2018 21:29:03 -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: <>
Content-Type: multipart/alternative; boundary="------------C5ED0A628B834132DFA37FB6"
Content-Language: en-US
Subject: Re: Fun and surprises with IPv6 fragmentation
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: ham
X-AntiSpamCloud-Outgoing-Evidence: SB/global_tokens (0.0038241385634)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5lBbWk6p/jAaew7IizFZQ/J602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViKG7Ar2LIc3sH7qxH14S0W87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBVJlvs1RB82smE8/eMfkvDvvRa7MR4hgRIg8N 1QlY4G4/E7SMkAew92PUfpE24E7riSGt4Ko2sv7hY6P0Yu3OA+AIcPc2JG++Fh0y/kogNkMJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isEl8GMeldW04GUXlO89sftb6zqsOfS1M5VyYnCojwm7ad5vz90OufDbaLXzlZcD/WPXYn71+xsW DN+KNU6aZ6jEL0QqMGQOSwmEPwP4wBzM77OgZjZYo0UlkM2wWceUouIaEv86PIRN08X0tAylge+B SECbSNTtgnWem52FbrSHJo5eJze/hsKQqfFwmUA5avNupzpP9IQVNcIGaMccd8cnQja7qhQxh3nA WL1MmDK00la9MivJ4eMFKT60LLke+Ju5ovvrKfFvr3hhdZ8P166EOw2XLE3dEu55QGy5lTg1mJ0w ZNfSgF6Ga9kAviUImYUj8uMA2s7vloV95q0EsNB/b8Ap0hg2nOYq7GRTx6m52AF5UBV0yBXnDaS8 2A9m7GDIrO3NBXzjB8acdlweYzD8JreRC60qLxG7NKuT9w7Gc+g48v6kfkGDknp2YkTIwY179R/2 gMGq0KWAzmMf+ibVDpGalYFer/fVtRNcqrC8aKKh4N1ZtYLgTOdl55etFrfSxgQ5WhUTstUhLxc+ FWbKglss+n2ffnQxt6aJ7klZab/PEOv01feB/X5C0TO9q4ji8LRe0FWEHNT90SqUPFrPXh09jqYN 6sbhopCuLHhVePIxL7hrJSk60SF3F6RYOYr2
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Mar 2018 05:29:18 -0000

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.  
>> 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:  Bcast:  Mask:
          inet6 addr: 2600:1f18:2310:d230:5103:7d9e:7d75:374f/128
          inet6 addr: fe80::1040:99ff:fe30:a386/64 Scope:Link
          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