4 ms·

Doing this brings you close to OSI, which famously failed by being overcomplicated. The current design was implementable by zillions of cheap humans running ch

Doing this brings you close to OSI, which famously failed by being overcomplicated. The current design was implementable by zillions of cheap humans running cheap hardware. I always wonder if the internet is thesurvivor of the networking cambrian explosion, with a slight roll of the dice making another candidate the winner.

cobbzilla 3mo ago
You’re definitely right — the tech stack travels through time along what’s called a “path dependent” trajectory. https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence
Sesse__ 3mo ago
> The current design was implementable by zillions of cheap humans running cheap hardware. Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.
- pix128 3mo ago
  A bad application can still open unencrypted connections. Imagine a shoddily written game with a chat function.
dboreham 3mo ago
As someone who was there at the time, OSI certainly didn't fail by being "overcomplicated". It failed because a) they charged money to read the standards documents and b) TCP/IP already had so much deployment momentum that nothing was going to supplant it (we see proof of this in the fact that IPv6 also didn't achieve that). Edit: also c) there was no requirement (unlike RFCs) to have an interoperable reference implementation available. So the implementations that were created mostly didn't interoperate.
- ayewo 3mo ago
  In your opinion, do you think Internet Protocol Version 8 (IPv8) [1] stands a chance to fix the mistakes of IPv6 after more than 20 years now? Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4? Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8. 1: https://www.ietf.org/archive/id/draft-thain-ipv8-00.html https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
  - throw0101a 3mo ago
    > In your opinion, do you think Internet Protocol Version 8 (IPv8) [1] stands a chance to fix the mistakes of IPv6 after more than 20 years now? IPv8 solves precisely zero of the problems that is causing a 'slow' roll out of IPv6 / replacement of IPv4: """ So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: You have to change the version number. You have to add new code to handle the new version. Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. […] Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introduction%20and%20Foreword/Why%20IPv6%20is%20so%20complicated.md https://github.com/becarpenter/book6/blob/main/01.%20Introdu... * Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s https://www.youtube.com/watch?v=W3jkZ1Ulz-s
Parodper 3mo ago
> Doing this brings you close to OSI, which famously failed by being overcomplicated. We're slowly reinventing OSI, one step at a time: OSI had multiple sessions per transport connection (QUIC), 20 byte addresses (IPv6) and a directory system with public-key infrastructure (DANE, vCard, SSHFP, etc). It's a shame TUBA (CLNP + TCP) failed.
- throw0101d 3mo ago
  > It's a shame TUBA (CLNP + TCP) failed. See "The Recommendation for the IP Next Generation Protocol", §8.3 TUBA Reviews: * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752 The document explains why SIPP was chosen (with the tweak of 128-bit addresses instead of 64).
  - Parodper 2mo ago
    Very interesting, thanks. I like they even admit their own bias, that the main reason was that they didn't want another's protocol; except for the word alignment, all the other issues are solvable.

cobbzilla 3mo ago

You’re definitely right — the tech stack travels through time along what’s called a “path dependent” trajectory. https://en.wikipedia.org/wiki/Path_dependence https://en.wikipedia.org/wiki/Path_dependence

Sesse__ 3mo ago

> The current design was implementable by zillions of cheap humans running cheap hardware. Yes and no. The current internet arguably does not work without a browser and a TLS stack anyway, neither of which is easily implementable (e.g. number of practically usable rendering engines is in the single digits). I mean, I can piece together an IP packet, too, but there's not that many usable services reachable that way.

pix128 3mo ago
A bad application can still open unencrypted connections. Imagine a shoddily written game with a chat function.

dboreham 3mo ago

As someone who was there at the time, OSI certainly didn't fail by being "overcomplicated". It failed because a) they charged money to read the standards documents and b) TCP/IP already had so much deployment momentum that nothing was going to supplant it (we see proof of this in the fact that IPv6 also didn't achieve that). Edit: also c) there was no requirement (unlike RFCs) to have an interoperable reference implementation available. So the implementations that were created mostly didn't interoperate.

ayewo 3mo ago
In your opinion, do you think Internet Protocol Version 8 (IPv8) [1] stands a chance to fix the mistakes of IPv6 after more than 20 years now? Or there is too much inertia for IPv8 to overcome to become a truly backwards compatible extension / superset of IPv4? Part of the reasons for the slow adoption of IPv6 was that it was never designed to be backwards compatible unlike IPv8. 1: https://www.ietf.org/archive/id/draft-thain-ipv8-00.html https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
- throw0101a 3mo ago
  > In your opinion, do you think Internet Protocol Version 8 (IPv8) [1] stands a chance to fix the mistakes of IPv6 after more than 20 years now? IPv8 solves precisely zero of the problems that is causing a 'slow' roll out of IPv6 / replacement of IPv4: """ So it's a matter of mathematical and physical fact that to expand the address size, you must change the protocol, and that means two things immediately: You have to change the version number. You have to add new code to handle the new version. Furthermore, you don't want to split the Internet in two, so you must design a method of interworking between the old version and the new version. Annoyingly, you need to do that in a way that can be done completely in machines that know about the new version, because other machines don't know anything at all about the new version, by definition. So, You need a coexistence technique so that updated systems, with the new protocol, can connect to old systems that know nothing of the new protocol. Two minutes of thought show that this third requirement has only two solutions: (3A) Dual stack, in which the new machines speak both the old (IPv4) and new (IPng) protocol. (3B) Translation, in which something translates addresses between the old and new protocols. […] Incidentally, "IPv8" proponents often ask why IPv6 didn't simply stick some extra bits on the front of IPv4 addresses, instead of inventing a whole new format. Actually, we tried that: the "IPv4-Compatible IPv6 address" format was defined in [RFC3513] but deprecated by [RFC4291] because it turned out to be of no practical use for coexistence or transition. The related "IPv4-Mapped IPv6 address" format is still valid and has a role in the POSIX socket API. Mappings of this kind also figured in the moderately successful coexistence technologies known as 6to4 [RFC3056, RFC3068] and Teredo [RFC4380], which have now been overtaken by events. """ * https://github.com/becarpenter/book6/blob/main/01.%20Introduction%20and%20Foreword/Why%20IPv6%20is%20so%20complicated.md https://github.com/becarpenter/book6/blob/main/01.%20Introdu... * Interview with author of article: https://www.youtube.com/watch?v=W3jkZ1Ulz-s https://www.youtube.com/watch?v=W3jkZ1Ulz-s

Parodper 3mo ago

> Doing this brings you close to OSI, which famously failed by being overcomplicated. We're slowly reinventing OSI, one step at a time: OSI had multiple sessions per transport connection (QUIC), 20 byte addresses (IPv6) and a directory system with public-key infrastructure (DANE, vCard, SSHFP, etc). It's a shame TUBA (CLNP + TCP) failed.

throw0101d 3mo ago
> It's a shame TUBA (CLNP + TCP) failed. See "The Recommendation for the IP Next Generation Protocol", §8.3 TUBA Reviews: * https://datatracker.ietf.org/doc/html/rfc1752 https://datatracker.ietf.org/doc/html/rfc1752 The document explains why SIPP was chosen (with the tweak of 128-bit addresses instead of 64).
- Parodper 2mo ago
  Very interesting, thanks. I like they even admit their own bias, that the main reason was that they didn't want another's protocol; except for the word alignment, all the other issues are solvable.