The biggest single cause of network engineer hair loss must be MTU and fragmentation. We had some customers over a tunnel (IIRC, it was MPLS) that reduced the MTU from 1500 (default Ethernet) to 1496. This happened while our vendor changed some equipment and forgot to update either MTU to accommodate the extra MPLS header. Of course, there was a misconfigured firewall that wouldn't fragment and wouldn't send "ICMP won't fragment".<p>The result? Most DNS queries went through. All chat applications worked. SSH generally worked, except when you started a full-screen terminal application. Smaller web pages load. Larger web pages loaded only partially.<p>Imagine non-technical users explaining their issue. "The Internet is half-broken. Please help."<p>God only knows how much hair I would have today if the world had figured MTU and fragmentation properly.
Couple of years ago I wrote a tool to check if end-hosts are complying:<p><a href="http://icmpcheckv6.popcount.org/" rel="nofollow">http://icmpcheckv6.popcount.org/</a><p>(v4 version <a href="http://icmpcheck.popcount.org/" rel="nofollow">http://icmpcheck.popcount.org/</a> )<p>it answers:<p>- can fragments reach you<p>- can PTB ICMP reach you<p>hope it's useful. Prose: <a href="https://blog.cloudflare.com/ip-fragmentation-is-broken/" rel="nofollow">https://blog.cloudflare.com/ip-fragmentation-is-broken/</a><p>Notice: it's easy to run the tests headless with curl if you need to see if your server is configured fine.<p>Fun fact is that it's very much not easy to accept/send fragmented packets from linux. I learned the hard way what `IP_NODEFRAG` is about.
The article conclusion is basically that IPv6 extension headers (fragmentation is one of them) are useless on the Internet, which seems pretty reasonable to me. They're basically a research tool.<p>The lack of on-path fragmentation in IPv6 is definitely on purpose. It was a mistake in IPv4 and would be silly to replicate in IPv6. The fragmentation header in IPv6 is effectively useless. It can only be done at the endpoints, and if that's the case the application should be doing it, not the stack. Instead IPv6 mandates path MTU discovery, which is the correct solution.
Based on how fragmentation is handled (generally poorly, often because there's little choice), I would have preferred truncation with an in-band signal. For TCP, truncation is a clear win; you get some of the packet, and can signal back to the other end that things are missing, and hopefully the other end adapts to stop sending packets that get truncated. (Of course, when a middle box uses large receive offload to combine the packets and then complains that they're too big to forward, it's hard to fix as an endpoint).<p>For UDP, it's not so simple; IP fragmentation does allow for large data, all or nothing processing, without needing application level handling, but the cost of fragmentation is high.<p>The out of band signalling when sending packets that are too large is too easy to break, and too many systems are still not setup to probe for path mtu blackholes (the biggest one for me is Android), and the workarounds are meh, too.<p>Another option would be for IP fragments to have the protocol level header, so fragments could be grouped by the full 5-tuple (protocol, source ip, dest ip, source port, dest port) and kept if useful or dropped if not, without having to wait for all the fragments to appear.
Part of the problem with IPv6 extension headers is that there can be an unbounded number of them. No hardware designer wants to deal with that, so just dropping all of them is far easier.
Regarding the half working internet it comes to my mind: We have remote Linux boxes accessible via ssh tunnels. Very rarely, but repeatedly the sudo password is not accepted. You type it extra carefully one by one, you copy-paste it, it just doesn't work. You angrily complain to the team has anybody changed the password in that box. Nobody has. Typically others say it works for them, in rare cases they can even confirm it at the same time. After a while, 10 or 20 minutes it just works again. It does not happen often, but in the meantime everyone in the team who initially claimed this cannot possibly happen has experienced it.
It seems will all "standards" there is the published standard as written, and the standard "as implemented" - and many of the unused corners quickly become "here be dragons".
"IPv6 was intended to be "just like IPv4, but with 128-bit source and address fields". Just make IP addresses 96 bits longer and add no more magic. But it didn't turn out that way. "<p>Where does that quoted portion come from. The mind of the OP author or someone else.<p>If IPv6 was just a 128-bit version of IPv4, I would be an IPv6 user.<p>As long as it continues to work, on the networks I control, I will prefer the relative simplicity of IPv6.<p>Relative to IPv4, IPv6 is more complex.
Meanwhile IPv6 adoption rate[1] slowed down, and apart from a few countries pushing the migration most simply don't care it seems. You would expect that global pandemic and going remote to speed up the change but for some reason it didn't.<p>[1] <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="nofollow">https://www.google.com/intl/en/ipv6/statistics.html</a>