3 ms·

It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals

It's not like people didn't think of that when IPv6 was discussed. It was something like a decade from when the first IPng proposals came to when the proposals which looked like today's IPv6 came. Bernstein was certainly part of that discussion, at the later stages, and the document you link to reflected that. It was just one of many counter proposals that influenced what became IPv6. Some people seem to suggest that Internet standards are written in some ivory tower and dropped down on the network engineers to implement. In that light, such criticism of IPv6 would be valid and important. But the IETF does not work like that. You can take part, and I can take part, and any reasonable criticism is discussed in the open. In general, practical proposals and code is taken more seriously than loose ideas. There is no central command which decides what you or any other network operator should implement. People all over the world implements what they think is good for their network, in order to interoperate with other networks. If anything, Internet standard can be criticized for being slow to fruition because of this open process. That's the price we pay. It's not very useful to come 20 years later and re-hash the exact same discussion all over again. All counter proposals turned out to be impossible to deploy, and the consensus and running code we ended up with is what we call IPv6. A dual stack approach was the only solution practical enough to get general deployment. There are certainly problems with any protocol, and let's suggest improvements and new protocols. Just make them relevant today if they should have any chance of deployment.

butlerm 3y ago
It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process. I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes. That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago. All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net. Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything. There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly. And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.
- welterde 3y ago
  I don't think that plan is feasible at all. The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware. Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth. And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay. The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.
hn_throwaway_99 3y ago
> 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".
- xorcist 3y ago
  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.

butlerm 3y ago

It is not true that all counterproposals are impossible to deploy, they just have a number of downsides that were either politically or technically impalatable in 1996. For example, the network could have been made administratively compatible (same config files, DNS entries, routing prefixes) for a decade while a variety of internal changes and updates took place as part of the normal upgrade process. I do not mean no changes at a binary level, but at an administrative level. An upgraded "A" record for example so that DNS admins could go about their day somewhere between completely and largely unaware that the protocol was undergoing transparent upgrades behind the scenes while preserving administrative compatibility with all existing configuration files, source data, and user interfaces. In such a scheme it would be quite important that there only be one "A" record from an administrative point of view, not different ones like A and AAAA. Admins need to be insulated from the binary protocol changes going on behind the scenes. That means that the new address format would need to be compatible with the old one, and of course a routable embedding of the current address space be provided in the new address space. That means existing routing prefixes would have to be preserved indefinitely, complete with the routing table explosion that was a major challenge a couple of decades ago. All routers would need to be upgraded over the transition period to handle a new frame type that supported current addresses, extended addresses, and a single routing table with larger extended address sizes. It is quite important that there be a single routing table, not two of them. Same configuration file, same everything from an administrative point of view for a decade, while older hardware was gradually replaced with new hardware that had extended capabilities that would be dormant on the public net. Comparable and in some cases less transparent updates would need to be made to programming APIs, and to the Berkeley socket API in particular. Not to require programmers to do everything for two different layer 3 protocols, but rather to allow them to do it once and have it work with current and extended addresses, transparently from an administrative point of view, not doubled configuration for anything. There are many other things that would need comparable binary behind the scenes upgrades that would be administratively compatible and not affect current network configuration files, and in particular not require anything to be duplicated from an administrative point of view. No one does that and no one wants to for protocol extensions that are not actually usable yet. It doubles their workload with no short term benefit, and does so indefensibly. And then after all these extensions and capabilities have been designed, implemented, and transparently deployed across essentially the entire Internet without requiring large scale administrative intervention - a process that could easily take a decade - would the first extended addresses with non-zero bits in the extension fields actually be usable and globally routable in both directions. The entire network would be ready for it, it would be a dormant capability unused until that day arrived and requiring no large scale intervention when that day arrived either, because the silently upgraded network would remain administratively compatible with the old one.

welterde 3y ago
I don't think that plan is feasible at all. The incentives for vendors to implement it are just not there, since the customer is not actually going to use the expanded address-space feature at all for at least a decade, so why bother implementing it and break the existing stuff in the process? While with IPv6 you could at least somewhat use it right away or at least implement it on the side, where it won't break the existing stuff. And even if you get the vendor to implement it, chances are they are gonna do it the same way IPv6 got implemented initially: By routing it software, so performance is going to absolutely suck. So the first decade after the proposed flag day performance is going to suck until everyone has upgraded their hardware that can do both in hardware. Next are the random boxes (firewalls or NAT boxes) that will happily mangle all your option bits in the IPv4 header for no reason. Of course while you haven't used any expanded address space everything will seem fine and might even work fine in the lab, but once your flag day arrives and people are supposed to start using it, you will realize it doesn't actually work, because of all those broken boxes in the wild and fun routing bugs and so forth. And then you get all the regular bugs that come with making any change that were hidden by no one actually using it. You get all the phases IPv6 went through, but much worse and with a couple decades of delay. The only way to make things work is by using it. The earlier one gets started the better. Wishing really hard does nothing.

hn_throwaway_99 3y ago

> 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".

xorcist 3y ago
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.