[ForkMeOnTinder]

IPv6 also required hardware in the wild to be replaced, but that's not a reason to give up and let things ossify. Over the next 30 years most hardware will be landfilled and replaced anyway. Let's get these improvements into the software stack of new devices now, and then let nature take its course.

[ihattendorf]

> IPv6 also required hardware in the wild to be replaced

I understand that, but it was (is) able to do that in a mostly backwards compatible manner.

My question is: how is that possible with different MTU sizes? Have ISPs support 9000 byte frames and fragment to 1500 bytes for compatibility with the wider internet? Then something like PMTUD can be used to bypass this fragmentation when supported?

To be clear, I would love to have larger MTU sizes. I just don't see a straightforward way to transition everything over. I'm not a network engineer though, maybe there just isn't enough a strong enough impetus for anyone to dedicate the resources to this.

[ForkMeOnTinder]

Also not a network engineer. But I'd imagine first the Tier 1 ISPs (Level 3 etc) could enable jumbo frames and make sure they work smoothly amongst each other. After a few years of waiting, new consumer devices/OSs can start trying to send jumbo frames, while setting the Don't Fragment flag. If some router in the path doesn't support 9000, it will signal back ICMP Fragmentation Needed, and the device can transparently resend with 1500. Then add some local caching to avoid the roundtrip for subsequent connections to the same noncompliant network/endpoint.

And since it's a big change anyway, why stop at 9000? Why not 65000? Packets don't have to fill the entire MTU after all. If 65000 is supported, you can choose to send 1500, 9000, or 65000 based on your desired latency/throughput tradeoff.

[quickthrower2]

IPv6 has more pain (lack of IPv4 addresses) motivating it.