I think if they just double the address length the people would still cry about how 111.211.234.231.189.243.253.100 too hard to write and remember... There is no helping with people.

On extra byte shoved in a reserved field would have created 256 internets. That's two more for big countries and another for each small country and other planets. Then write in hex so addresses are shorter, require dhcp/sec etc, solved. My proposal for IPv7. ;-)

> On extra byte shoved in a reserved field would have created 256 internets.

Ah yes, the old IPv4 with 'just' adding more address byte(s) idea (you "IPv7"):

So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A7" address (for "IPv7" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:

* update the IP stack (like with IPv6)

* tell applications about new DNS records (like IPv6)

* set up translation layers for legacy-only code to reach extended-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

You're updating the exact same code paths in both the "IPv7" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.

Deploying the new "IPv7" code will take time, there will partial deployment of IPv7 is no different than having partial deployment of IPv6: you have islands of it and have to fall back to the 'legacy' IPv4-plain protocol when the new protocol fails to connect:

* https://en.wikipedia.org/wiki/Happy_Eyeballs

(This idea of "just add more addresses" comes up in every discussion of IPv6, and people do not bother thinking about what needs to change to "just" do it.)

Don’t need dual stack, just one updated. Further addresses would have stayed readable and there wouldn’t be two bindings per adapter etc.

When typing addresses first byte is optional and defaults to zero. Problem solved. I saw this strategy work well with Brazilian phone numbers.

Partial rollout is not a problem to me at home but multiple address gibberish is.

A node having 198.51.100.42 and 7.198.51.100.42 (or 198.51.100.42.7) is dual-stack: one address is for the IPv4 protocol and other is for the IPv7 the protocol.

You need different DNS records for IPv7 and new API calls. You need Happy Eyeballs so that if 7.198.51.100.42 fails your application falls back to 198.51.100.42. It's the exact same situation.

There’s not two there’s one, the longer. There will be old equipment that can’t handle the new but would have been mostly replaced over time, perhaps a deadline. Like phone numbers or hdtv.

Now think a better name is IPv4+.

Sounds identical to IPv6, but with only one new byte instead of 12 new bytes.

As mentioned three times now, the addresses would be readable, and there would not be two stacks. Much less complexity. So no, not identical.

yeah and the global migration to add bits is already so expensive, if you're adding bits you shouls add a lot of bits so it only has to be done once. Wish they'd made it 256 bits actually, it could fit cryptographic hashes for secure routing protocols of the future.