I find it fascinating how these key technologies handle upgrades and breaking changes. For example, Python eschewed breaking changes through 2.7.x but the dam has burst since 3.0 and every point release (it seems?) makes breaking changes, sometimes reversing itself (eg the whole s/u string prefix thing).
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
> 3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
What makes you suggest that it's backbone hardware that is the problem? It's largely enterprise customers and tier 3 providers that don't really do IPv6 afaics.
>3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
Would say the opposite is true. Core routers were the first to enable V6 support in any network as they would need support it for anything else to even use it. They got regularly replaced as bandwidth needs keeps rising as well.
Plenty of isps advertise ipv6 but haven't managed to give it to customers yet.
Interrupts are hardly a problem with any nics of the last decade really.
Many here will be familiar with the second system effect [1]. Usually people want to avoid making breaking changes but once they do, they can go a little nuts. My personal opinion is only major versions should make breaking changes and a lot of thought should go into making them as painless as possible.
IPv6 is fascinating for these reasons but also that it's a product of its time in two main ways:
1. It doesn't do anything about roaming because that wasn't an issue in the 1990s but it certainly is now;
2. A 64 bit address space would've basically been infinite addresses but instead they went with 128 bit addresses (rolling in ports) but then giving individual users a /64 address range. For some reason people deny it now or simply weren't aware but that too is a historical artifact because it was intended to put a 48 bit MAC address into that space but later we realized that's a huge PII and tracking issue; and
3. History has shown that upgrading network backbone hardware (in particular) is incredibly difficult through a process that's been described as "ossification", which is a nice description. Basically, network relays and routers wanted to avoid security issues and decided to discard things they didn't understand.
That's interesting because it violates Postel's Law [2], which basically says be liberal in what you accept and conservative in what you send.
But this shows up in all sorts of interesting ways, like it's practically impossible to reliably use MTUs larger than about 1536. When IPv4 was designed, that wasn't an issue. With 1-100G+ networks it is. There are RFCs about using large MTUs but you're dependent on backbone hardware you have no control over.
Even Linux struggles with this, to the point where you need to do some configuration for high-bandwidth networks (eg RPS [3]). Just handling all those interrupts presents a bunch of problems beyond the original scope. And again, it's hard to fix through no fault of Linux's.
I'm old enough to remember the talk about us running out of IPv4 addresses back in the 1990s. It's been interesting to watch how this has consistently been kicked down the street (eg cgNAT).
What is funny though is large companies (eg Facebook) actualy ran out of internal addresses on a 10/8 network and there's no good solution for that (with IPv4 at least).
[1]: https://en.wikipedia.org/wiki/Second-system_effect
[2]: https://en.wikipedia.org/wiki/Robustness_principle
[3]: https://lwn.net/Articles/362339/