Re: Fun and surprises with IPv6 fragmentation

Christian Huitema <huitema@huitema.net> Sat, 03 March 2018 07:03 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 5BCB512EABD for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 23:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 qlEX7BpuD4El for <quic@ietfa.amsl.com>; Fri, 2 Mar 2018 23:03:07 -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 29132127863 for <quic@ietf.org>; Fri, 2 Mar 2018 23:03:07 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx61.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1es1CC-0001Ee-Iv for quic@ietf.org; Sat, 03 Mar 2018 08:03:05 +0100
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1es1C6-0003cm-Ra for quic@ietf.org; Sat, 03 Mar 2018 02:03:02 -0500
Received: (qmail 12375 invoked from network); 3 Mar 2018 07:02:57 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.241]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <quic@ietf.org>; 3 Mar 2018 07:02:56 -0000
Content-Type: multipart/alternative; boundary=Apple-Mail-24472AF4-D2B7-4678-ACBD-4802BA766A24
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15D100)
In-Reply-To: <CAN1APdckzkA4gysV690M64-3_=NGDMBz_2zsfjyK5xa+RPH=mg@mail.gmail.com>
Date: Fri, 2 Mar 2018 23:02:53 -0800
Cc: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <A1E61A4E-C73E-462A-8A09-2B41B885993D@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> <CAJ_4DfRm1v_+MnTu56G0g_FXuQcYicgs6wq58ZShF8WcK=-JyQ@mail.gmail.com> <CAN1APdckzkA4gysV690M64-3_=NGDMBz_2zsfjyK5xa+RPH=mg@mail.gmail.com>
To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Subject: Re: Fun and surprises with IPv6 fragmentation
X-Originating-IP: 168.144.250.232
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.00141474247225)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5lxxhsBv4VO1kqq53SQ6Ndp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViYB7WMX02eN7qxputiiHdaM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBo86SAdJ6bLtg5NStMc8F1x/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgizQS7ZJXB6rwDFOa1j0OJR6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cUwr+jP4IC0Xj67AM8vwyjV9IlKha13El6tTzAeqsLP4/06UMvJE30aO2JcVUuLdWiPvH7cxX tl8i6aTMYJPb+6vlm5bIS/7+niZp9XBOa3wCD20eohdCKNiEenBVC0y5aZSc3K2+FO70Srhh/To6 5eidX4Ts4xdG+C13IyWeZaJYU6BarXN3x9zhtKiVG+hhpzpP9IQVNcIGaMccd8cnQsuUtbLhmdim WKABZsHKLeK9MivJ4eMFKT60LLke+Ju5ovvrKfFvr3hhdZ8P166EOw2XLE3dEu55QGy5lTg1mJ0w ZNfSgF6Ga9kAviUImYUjtvbciMrWUb6dBrrd7fe8JsAp0hg2nOYq7GRTx6m52AHgO73HQjX0ziE+ ZYvNWeuZEBxsfJG0rq6yOdYMhgfXRreRC60qLxG7NKuT9w7Gc+iLN0IoWogKMZqfaM4bI8X/9R/2 gMGq0KWAzmMf+ibVDuTrQggsF7Un27hrvG8IQyOh4N1ZtYLgTOdl55etFrfSxgQ5WhUTstUhLxc+ FWbKglss+n2ffnQxt6aJ7klZab/PEOv01feB/X5C0TO9q4ji8LRe0FWEHNT90SqUPFrPXh09jqYN 6sbhopCuLHhVePIxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/i_MeWGYoHUZjkTOLz_gWGTbzV3M>
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 07:03:09 -0000

Mikkel, we have a PCAP capture showing the fragments arriving at the client, out of order of course.

-- Christian Huitema 

> On Mar 2, 2018, at 10:26 PM, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> wrote:
> 
> 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?
>>