There is no "just" in this.

Copy-pasting from my other comment:

--

IPv4 data structures have four bytes/octets (4B) for addresses. So how do you fit 8B of addresses in 4B structures? You don't. So you have to update every network element—host (desktop, laptop, mobile, embedded), router, switch, firewall—to have a new data structure (and maybe new function/system calls, as the old ones assume the old structures). So all devices have to have updated network stacks, including long-lived ones that sometimes are not touched for a decade+.

And not just pure networking code: anything that touches (e.g.) DNS as well, as A records are 4B-only as well, so you need a new record type and deploy new DNS server and resolver code everywhere.

But of course if you have a 4B-only network elements/devices, they cannot talk to 8B-only devices/services, so you have to create translation mechanisms because some devices may not yet have the update 8B-capable network stack. And sometimes an 8B network is an island in a sea of 4B, so you have to have tunneling. Of course some may have both 4B and 8B, and want to talk to something has also has 4B and 8B, so now you have to have code for source/destination selection.

--

So "just" expanding IPv4 to IPv4+ ends up being the exact same amount of work as ended up with IPv6.

Only only thing you could say with "just" more addresses is keeping ARP and the like (instead of DAD, etc).

> Complete backwards compatibility

> If it's 8 bytes then it's a full address

Existing IPv4 devices wouldn't be able tell that it's 8 bytes, and wouldn't be able to make heads or tails of such a packet. At best, they discard the packet, at worse, they misinterpret it. It's not backwards compatible.

You can attempt to construe the bits however you like, but you're going to butt up against the pigeon-hole principle here. Any solution that works is going to be materially the same as IPv6.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|  IHL  |Type of Service|          Total Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Identification        |Flags|      Fragment Offset    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Time to Live |    Protocol   |         Header Checksum       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source Address                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

You've just made a new protocol that isn't IPv4, and is even /worse/ than IPv6. Now, not only does one have still have to upgrade every device that deals with these packets, since every device that is routing these packets hop by hop needs to know where to find the new address, every packet now has 64 bits of unusable data in the header.

And the Internet still has to do all of the ancillary work to upgrade things like DNS!

1. The address space is ludicrously unwieldy. Humans are good at remembering long numbers. We're quite bad at remembering random strings outside of pure muscle memory. For the cases where you're manually fiddling with IPv6 space in situations where a domain name isn't mapped to an IP (ie. home networks), the reality is that IPv6 is only a negative. Telling people to go to "192.168.2.1" to log in on their router is easy. Telling them to punch in a long IPv6 address that includes the A-F range isn't. (And that's without getting into colon collapsing 0000 ranges which just reeks of "did anyone run this past a human being", because this makes even less sense to people who barely get "I need to type the address on the ISP router sticker in my browser").

2. The complete lack of even a one-way compatibility layer with IPv4 (so communicating from an IPv6 to an IPv4, which should be possible in a tech stack) means that even if you take the slow movement of hardware to IPv6 space into account, the offering simply isn't worth it until everyone switches over. Right now the standard offer for home ISPs is CGNAT + IPv6 if they offer the latter, is not solving anything - the reality is that if you give an IPv6-only offer, your customers just straight up can't access ~40% of the internet (and by law of institutions, that will include parts of the internet they really need because the people running it are restricted by yellow tape and budgets to also move to IPv6), so all we get is the worst of both worlds where IPv4 is still running out of space and IPv6 isn't ready to replace it.

Would it really have been too much work to slightly compromise on address space for IPv6 to just allocate a region to old IPv4 addresses, where the relevant low-level bits of the stack just switches over to the IPv4 protocol if it detects that region? If that were the case, the transition process would go much smoother and we probably wouldn't be haranguing about getting public entities to sell off their address space, just to delay the inevitable.

Those are the reasons why IPv6 isn't replacing anything beyond a slow crawl of "maybe I should set an AAAA record" (and considering like 80% of the DNS+VPS providers I've used in the past decade just dump the /16 when you pick a VPS from a dropdown in the address, which obviously fails to work, it's also clear that hosting companies don't consider it a real priority either). When it comes to core infrastructure like this, backwards compatibility isn't a "nice to have" or to be "thrown out because it was based on bad ideas". It's a requirement, no matter how insane the original product might have looked.

192.168.8.9.0.1.2.3

old devices get accessed the old way. new devices "know" about the add ons. The new part of the address travels inside "as data" so it gets delivered.

as company firewalls and routers switch to new, the whole company needs only one "old" ip. To get the ball rolling, spend some time deploying before it's switched on.

All those early adopters who have class A networks? They can go first this time too, freeing up their class A's quickly to facilitate the transition for everybody else.

source: this was my idea for phone numbers back when they kept rejiggering area codes.

However, we're pretty stupid how we use ipv4. A connection identifier is actually 48 bits, which is a massive pool. Currently nearly everything on the internet runs 32 bit ipv4 address with a 16bit port number. The vast majority of internet traffic waste the last 16 bits because of convention (Hey only accept HTTP/SSL connections on port 443! lol)

We could extend ipv4 a couple hundred years by adopting SRV records, which would be a painless change compared to swapping ipv4 to ipv6. That puts the last 16 bits of the total 48 bits to work.

The other part of the ipv4 packet is a bunch of flags that are pretty dangerous and nobody uses. Those might be able to be used as identifiers, but it'd be pretty not-backwards compatible.

I'm a critic of the ipv6 transition because of the players promoting it in a certain way that is detrimental to the consumers. However, one thing ipv6 gets correct is the concept of network flows and the removal of a ton of cruft from the ipv4 packets. In that regard ipv6 is very well designed.

Anyway, I will continue to turn off ipv6 and block it on all the devices and networks I operate, as it offers no benefit to me personally, only downsides, and it's just one more thing to monitor for privacy.