> It's not very useful to come 20 years later and re-hash the exact same discussion all over again.
I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:
1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.
2. The insanity of SOAP vs. something like REST.
3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.
Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".
Apart from being very far apart time wise, I don't think the examples are relevant. IPv6 was nothing like that. In several ways, IPv6 is more simple than IPv4. It has constant header size (simplifies routing), the layer busting ARP was reworked into special case of ICMP, global routing rules was vastly simplified (routing table takes less space even if addresses are much larger). And it's telling that during the past twenty years, no one has come up with a more practical deployment scheme.
You can criticize IPsec and mobile IP which was tacked on to the spec. But starting from scratch, a core IP v6 stack is easier to implement than a v4. The TCP parts is downright nasty in comparison.
Most importantly, IPv6 was developed in the open. IETF is the counter example to design-by-committee. That's true today, and that was doubly true twenty years ago.
Every discussion since them mostly concerns resurrecting old ideas about either impractical extensions (misusing port numbers and flags to extend addressing, none of these schemes have been proven practical), more efficient address space allocations (which would have bought us a couple of years, at most) or various ways to tunnel traffic in backwards compatible ways (which is what we did back when 6bone was a thing, but which is not useful anymore).
The mailing lists are completely open. You can join any one of them today, and people did. You can still follow how the discussions went in the archives. Hopefully no one has suggested that IPv6 is the best we can do, but that the process still works and that anyone capable and interested is welcome to attend.
As to whether the industry's obsession with complexity has faded, I bring you Kubernetes.
I'm not complaining as if to say "yeah guys, let's stop the ipv6 rollout and do ipv10" or whatever. But I think it is useful to see why the problems of ipv6 came about. A great comment from one of the linked HN threads said "ipv6 was a product of it's time", a time (I put it at mid 90s to mid 00s) when there were a ton of over-complicated, over-engineered specs that were designed by committee. Some examples:
1. XML, and all its complexities and incompatible versions (I still have some PTSD from some Java XML version incompatibilities), vs. what the industry discovered to be the much simpler and now much more widely used JSON.
2. The insanity of SOAP vs. something like REST.
3. The original Enterprise Java Beans spec. Feel like "'nuff said" is good enough here, what a nightmarish shit show that was.
Thankfully I think the industry has largely learned its lesson when it comes to valuing simple even if imperfect specs. But I still totally disagree that "ipv6 is the best we could have done".