3 ms·

Which explains why professionals have so eagerly adopted it over the last two decades

by CookieCrisp 2y ago

dbdoskey 2y ago
Reminds me of the line that network engineers love implementing IPv6 so much they have been doing it for years
- rvnx 2y ago
  We could also have bumped 255.255.255.255 to 999.999.999.999 = 1 trillion IP addresses, easy-to-remember and backward compatibility with legacy devices. Modern clients and servers get IP addresses in these new whole IP ranges and can communicate together. Relatively easy to adapt the code of modern software also since it's about removing a restriction from a client-perspective. Load-balancers and legacy clients use IP addresses from the old pool. If you have Windows XP you can communicate only to legacy IPv4 (in practice only loadbalancers from Cloudflare, GCP, AWS and co) and your other legacy stuff. Others happily communicate together. But no, we got this wonderful IPv6. Sad because it was really doable, theoretical maximum below 512 GB of memory for routers to store the whole routing table, it's manageable, versus the 2.176×10^22 exabytes (!) of IPv6.
  - davrosthedalek 2y ago
    Bad idea, then all the fake IP addresses on Law&order and co would suddenly be valid.
  - SonOfLilit 2y ago
    I'm guessing everyone downvotes you for the very strange implication that most software stores IP addresses in ASCII. All networking APIs I'm aware of expect IPv4 addresses as a DWORD.
    - rvnx 2y ago
      This is the point, instead of rewriting a full stack, I would rather change the prototype of these APIs. To store 999.999.999.999, then you are totally fine with a 64-bits INT (QWORD), and there is no struggle to backward-compatibility store a 32-bits INT (DWORD) into it. It's more of a matter of doing #ifdef IPV4_EXTENDED #define DWORD QWORD #endif and add an extra IP field inside the IP header packet itself that says, "this is the IPV4_EXTENDED DESTINATION 5-bytes IP", and the previous field is marked a legacy/deprecated. In fact, it's quite convenient, since we are all INT64, sockaddr_in would largely fit in an INT64 for both IP itself and the other elements that are in the struct. https://man7.org/linux/man-pages/man3/sockaddr.3type.html https://man7.org/linux/man-pages/man3/sockaddr.3type.html 5 bytes for the sin_addr field is enough to store until 999.999.999.999. Gives you 3 bytes to store the port etc. The networking APIs guys could be drinking cocktails at the bar by now, if they would change these types. There is backward compatibility and smaller effort for a great impact, and this is beautiful. It's actually beneficial for the majority of developers. From the developer of Windows, to the developer of Age of Empires, to the developer of a CRUD app on the web (who stores IP addresses as a string or as an int), they wouldn't see too much struggle to port to int64. Less than having to build a full new IPv6 experience. In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted. time() had a similar situation. We migrated by adding new bytes, we didn't redefine the concept of time. From a developer-experience, "link to the latest version of the network library, oh btw, connect() accepts an int64" and remove the UI restriction of 255. It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
      - immibis 2y ago
        and what about the protocol bytes that go over the wire - you know, the most important and hardest to change part? There've been several proposals to make "IPv4 but bigger addresses". All of them are just as hard to deploy as IPv6. You still need to upgrade all your routers and you still need to run two parallel networks.
      - 2y ago
chippiewill 2y ago
IPv6 hasn't failed to be adopted due to being over engineered. Its failed to be adopted because breaking changes are hard.

Which explains why professionals have so eagerly adopted it over the last two decades

dbdoskey 2y ago

Reminds me of the line that network engineers love implementing IPv6 so much they have been doing it for years

rvnx 2y ago
We could also have bumped 255.255.255.255 to 999.999.999.999 = 1 trillion IP addresses, easy-to-remember and backward compatibility with legacy devices. Modern clients and servers get IP addresses in these new whole IP ranges and can communicate together. Relatively easy to adapt the code of modern software also since it's about removing a restriction from a client-perspective. Load-balancers and legacy clients use IP addresses from the old pool. If you have Windows XP you can communicate only to legacy IPv4 (in practice only loadbalancers from Cloudflare, GCP, AWS and co) and your other legacy stuff. Others happily communicate together. But no, we got this wonderful IPv6. Sad because it was really doable, theoretical maximum below 512 GB of memory for routers to store the whole routing table, it's manageable, versus the 2.176×10^22 exabytes (!) of IPv6.
- davrosthedalek 2y ago
  Bad idea, then all the fake IP addresses on Law&order and co would suddenly be valid.
- SonOfLilit 2y ago
  I'm guessing everyone downvotes you for the very strange implication that most software stores IP addresses in ASCII. All networking APIs I'm aware of expect IPv4 addresses as a DWORD.
  - rvnx 2y ago
    This is the point, instead of rewriting a full stack, I would rather change the prototype of these APIs. To store 999.999.999.999, then you are totally fine with a 64-bits INT (QWORD), and there is no struggle to backward-compatibility store a 32-bits INT (DWORD) into it. It's more of a matter of doing #ifdef IPV4_EXTENDED #define DWORD QWORD #endif and add an extra IP field inside the IP header packet itself that says, "this is the IPV4_EXTENDED DESTINATION 5-bytes IP", and the previous field is marked a legacy/deprecated. In fact, it's quite convenient, since we are all INT64, sockaddr_in would largely fit in an INT64 for both IP itself and the other elements that are in the struct. https://man7.org/linux/man-pages/man3/sockaddr.3type.html https://man7.org/linux/man-pages/man3/sockaddr.3type.html 5 bytes for the sin_addr field is enough to store until 999.999.999.999. Gives you 3 bytes to store the port etc. The networking APIs guys could be drinking cocktails at the bar by now, if they would change these types. There is backward compatibility and smaller effort for a great impact, and this is beautiful. It's actually beneficial for the majority of developers. From the developer of Windows, to the developer of Age of Empires, to the developer of a CRUD app on the web (who stores IP addresses as a string or as an int), they wouldn't see too much struggle to port to int64. Less than having to build a full new IPv6 experience. In practice, client apps, at the time you open a new socket, if your lib says it wants an INT32 or an INT64 it doesn't matter for the developer of that app, since type is automatically casted. time() had a similar situation. We migrated by adding new bytes, we didn't redefine the concept of time. From a developer-experience, "link to the latest version of the network library, oh btw, connect() accepts an int64" and remove the UI restriction of 255. It could even be possible to give compatibility to very old software that we lost source-code from by overriding the network layer with LD_LIBRARY_PRELOAD or equivalent, and patch these softwares by manually NOP the right JGE instruction (the asm code for " >= " ) that checks if we are over 255.
    - immibis 2y ago
      and what about the protocol bytes that go over the wire - you know, the most important and hardest to change part? There've been several proposals to make "IPv4 but bigger addresses". All of them are just as hard to deploy as IPv6. You still need to upgrade all your routers and you still need to run two parallel networks.
    - 2y ago

chippiewill 2y ago

IPv6 hasn't failed to be adopted due to being over engineered. Its failed to be adopted because breaking changes are hard.