For both IPv4 and IPv6, fragmentation is undesirable. Fortunately,
for IPv6, routers can never fragment packets, so there is no need
for the don't fragment bit that IPv4 has.
This increases the importance of proper path MTU discovery since
packets that are too big to fit through a link will always be
dropped. Assuming unreachables are enabled in the network, an ICMPv6
packet too big unreachable will be sent back to the sender,
encapsulating the offending packet.
IPv6 end hosts are permitted to do fragmentation and reassembly, so if an
application sends a large payload to the IPv6 stack,
the host can send the smaller packets over the network.
That's generally not a good thing, and most applications
are smart enough to simply start sending smaller
application payloads to the IPv6 stack.
Let's dig into this some more so we can avoid IPv6 MTU problems in real life.
Let's generate a packet too big message for future analysis.
We'll use two ping tests.
I've set the IPv6 MTU to 1400 between the Wired Brain
Coffee router, R2, and the target server.
That means R2 should send us the packet too big message. First, I'll send
exactly one packet with size 1400 towards fc00:10:2:5::5,
which is the remote server.
Okay, it's succeeded, as we would expect.
Now let's bump up that MTU to 1401 and try again.
I'll enable ICMPv debugging first.
Well,
there's our packet too big message from R2 revealing the proper MTU, as expected. Now is a good time to explore this message in detail.