> 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.
A lot of networking gear is far closer to an ASIC than a general-purpose CPU, so you can't "just change it to int64". They were built to process 32-bit addresses, and are unlikely to be able to swap to 64-bit without enormous performance penalties.
E.g. routing tables would balloon in size, which in practice means that you can store far fewer routes. Ignoring changes in the size of the netmask, it's 4x the size to store 64-bit address pairs, so your route tables are a quarter the size they used to be.
The hardware refresh requirements are a big part of the reason why IPv6 rollout is so slow, and your proposal doesn't avoid that. Getting the software side of things to play nice has always been the easy part of this, even in IPv6.
> 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.
In IPv6 land, you just encapsulate IPv4 in IPv6 [1]. It's a lot cleaner than jankily trying to override instructions, especially when the relevant code may run on your NIC rather than your CPU and require kernel firmware patches (or, god forbid, custom NIC firmware) to implement.
A lot of networking gear is far closer to an ASIC than a general-purpose CPU, so you can't "just change it to int64". They were built to process 32-bit addresses, and are unlikely to be able to swap to 64-bit without enormous performance penalties.
E.g. routing tables would balloon in size, which in practice means that you can store far fewer routes. Ignoring changes in the size of the netmask, it's 4x the size to store 64-bit address pairs, so your route tables are a quarter the size they used to be.
The hardware refresh requirements are a big part of the reason why IPv6 rollout is so slow, and your proposal doesn't avoid that. Getting the software side of things to play nice has always been the easy part of this, even in IPv6.
> 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.
In IPv6 land, you just encapsulate IPv4 in IPv6 [1]. It's a lot cleaner than jankily trying to override instructions, especially when the relevant code may run on your NIC rather than your CPU and require kernel firmware patches (or, god forbid, custom NIC firmware) to implement.
1: https://en.wikipedia.org/wiki/6to4