Re: Fun and surprises with IPv6 fragmentation

Christian Huitema <huitema@huitema.net> Sat, 03 March 2018 05:29 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 A82EC1241F5 for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:29:17 -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 Lu22h8DCiv1L for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 21:29:16 -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 CFBEF120724 for <quic@ietf.org>; Fri, 2 Mar 2018 21:29:15 -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 1erzjN-0000fR-AT for quic@ietf.org; Sat, 03 Mar 2018 06:29:14 +0100
Received: from [10.5.2.49] (helo=xmail11.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 1erzjH-0000VE-BJ for quic@ietf.org; 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 [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.241]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 3 Mar 2018 05:29:05 -0000
To: quic@ietf.org
References: <681fcc96-4cf9-100d-9ad6-b3c7be9189a5@huitema.net> <CAJ_4DfS=6h9qEQ+uwntLtDZNSODhqc_0pww7c2gK50XKna0BCw@mail.gmail.com> <da0cfd5c-2c25-11f6-ff84-b0d164fc286b@huitema.net>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <9e718f13-51db-0af9-637e-3e45379ed48f@huitema.net>
Date: Fri, 2 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: <da0cfd5c-2c25-11f6-ff84-b0d164fc286b@huitema.net>
Content-Type: multipart/alternative; boundary="------------C5ED0A628B834132DFA37FB6"
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: 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
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i8teoDRb9KJ9O2xZXvUBE6F3o6I>
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: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.  
>>
>>     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