10 ms·

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.
- 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.
    - Macha 2y ago
      So you need to send a message from your host 5.6.7.8 to one of these newly enabled hosts 500.600.700.800. You update the software on your host, and your target's ISP is updated, and your target updates, and we'll even hand wave and assume your ISP is updated despite apparently having enough legacy addresses to allocate you one. The message goes out to your ISP router, who then sends it to their upstream ISP, who looks at the IP message, doesn't understand whatever header you've shoved the extended address in, and discards it. Then what's in your standard, backwards compatible 32 bit field? The start of the address? Does your packet go to some other random host on the internet? A placeholder address like all 0s? Does your message get discarded? How do you convince that middleman to update their hardware? They have no benefit from it? This is the situation IPv6 was in for decades until their literally were not enough IPv4 addresses which finally lit a fire under companies to start enabling it.
      - rvnx 2y ago
        (I'm not pushing this idea to the max, I mean, now IPv6 is here so we'll just go with it, but this is for the mental and engineering exercise). To answer your question, in my model, the legacy IPv4 field contains the IP addresses of "IPv4 to IPv4 Extended bridges". Let's imagine you want to connect to [example.com]: Clients who speak IPv4 Extended and their ISP is compatible, get the IPv4 Extended answer: 425.223.231.123 A+ example.com and directly to it Clients who speak IPv4 Extended but don't have an IPv4 Extended compatible ISP, add that extra IPv4 Extended header and speak to the bridges. 425.223.231.123 A+ example.com 34.23.12.2 BR example.com (the bridge) Clients who speak IPv4 only but don't speak IPv4 Extended don't have to think about IPv4 Extended at all, since they will go through the usual layer-7 (typically HTTP) reverse-proxy, or a routing based on rules (ip/port pair). Cloudflare does search large scale reverse proxies, it works fine in practice. If someone has an incentive to run such bridges or reverse proxies solution, first it's yourself, to save your preciouses IPv4. To the end user the promise is "you will connect faster to the internet if you are in native IPv4 Extended (because you skip these intermediate bridges)" We actually have a nice mechanism that we could reuse for knowing which bridges to use, it's reverse DNS lookup. https://www.cloudflare.com/learning/dns/glossary/reverse-dns/ https://www.cloudflare.com/learning/dns/glossary/reverse-dns... In reality this intermediate state with the bridge, is not even necessary, so the migration could be even easier.
- davrosthedalek 2y ago
  Bad idea, then all the fake IP addresses on Law&order and co would suddenly be valid.

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.

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.
  - Macha 2y ago
    So you need to send a message from your host 5.6.7.8 to one of these newly enabled hosts 500.600.700.800. You update the software on your host, and your target's ISP is updated, and your target updates, and we'll even hand wave and assume your ISP is updated despite apparently having enough legacy addresses to allocate you one. The message goes out to your ISP router, who then sends it to their upstream ISP, who looks at the IP message, doesn't understand whatever header you've shoved the extended address in, and discards it. Then what's in your standard, backwards compatible 32 bit field? The start of the address? Does your packet go to some other random host on the internet? A placeholder address like all 0s? Does your message get discarded? How do you convince that middleman to update their hardware? They have no benefit from it? This is the situation IPv6 was in for decades until their literally were not enough IPv4 addresses which finally lit a fire under companies to start enabling it.
    - rvnx 2y ago
      (I'm not pushing this idea to the max, I mean, now IPv6 is here so we'll just go with it, but this is for the mental and engineering exercise). To answer your question, in my model, the legacy IPv4 field contains the IP addresses of "IPv4 to IPv4 Extended bridges". Let's imagine you want to connect to [example.com]: Clients who speak IPv4 Extended and their ISP is compatible, get the IPv4 Extended answer: 425.223.231.123 A+ example.com and directly to it Clients who speak IPv4 Extended but don't have an IPv4 Extended compatible ISP, add that extra IPv4 Extended header and speak to the bridges. 425.223.231.123 A+ example.com 34.23.12.2 BR example.com (the bridge) Clients who speak IPv4 only but don't speak IPv4 Extended don't have to think about IPv4 Extended at all, since they will go through the usual layer-7 (typically HTTP) reverse-proxy, or a routing based on rules (ip/port pair). Cloudflare does search large scale reverse proxies, it works fine in practice. If someone has an incentive to run such bridges or reverse proxies solution, first it's yourself, to save your preciouses IPv4. To the end user the promise is "you will connect faster to the internet if you are in native IPv4 Extended (because you skip these intermediate bridges)" We actually have a nice mechanism that we could reuse for knowing which bridges to use, it's reverse DNS lookup. https://www.cloudflare.com/learning/dns/glossary/reverse-dns/ https://www.cloudflare.com/learning/dns/glossary/reverse-dns... In reality this intermediate state with the bridge, is not even necessary, so the migration could be even easier.
davrosthedalek 2y ago
Bad idea, then all the fake IP addresses on Law&order and co would suddenly be valid.