Re: Fun and surprises with IPv6 fragmentation

[Christian Huitema <[e-mail]>]

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 <[e-mail]> 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=[e-mail]) wrote:
>> 
>> On Fri, Mar 2, 2018 at 9:29 PM, Christian Huitema <[e-mail]> 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?
>>