Re: Fun and surprises with IPv6 fragmentation

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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?