Over 30 years after its introduction, IPv6 has still not replaced IPv4. I've seen those "just add more bits to ipv4, call it ipv5" proposals before. They tend to skip the important details and talk past others, but they have a point. After filling in the details over time, I think this actually works, it'd make a serious difference, and it's doable with the current IPv6 header.

Background...

Let's assume the IPv6 packet format is already sufficiently supported on routers, hosts, etc. That's not the blocker anymore, rather plenty of ISPs, web services like Github, and corporate networks have chosen not to adopt IPv6. Home routers just enable it, but it's nontrivial for services because it's a separate network from v4 in every way, requiring extensive config changes. End result, almost everyone needs a v4, while many use v6 but don't depend on it.

IPv6 absolutely needed a new packet format to support >32-bit addrs. But it made more choices beyond that, largest of which was starting with a fresh topology instead of expanding the space under the existing IPv4 address blocks. I understand this was to ditch v4's fragmented routes and create fairer ownership.

The other choices were more about defaults, like SLAAC over DHCP, or lack of NAT. IPv6 proponents often present the options as the best of both worlds, but in reality the default is more important, for example Android doesn't even support DHCP6. And most routers deny inbound v6 TCP/UDP connections by default, but not all, maybe because of RFC 6092, REC-49.

IPv6 had extensions to ease the transition from v4 using v4-on-v6 addresses (NAT64, 6to4). The common theme was you're still really using IPv4 on those. These things helped, but there's always a leap from v4 to dual stack and an even bigger leap from dual to v6-only.

Proposal, phase 1...

IPv5 is a toggle on an IPv4 interface. It shares everything with v4 except the packet format, which is actually a v6 packet with a 5000: prefix. So if you owned 1.2.3.4, now you have 5000:1.2.3.4. IPv5 therefore has 120 bits of address space. But in this initial phase, you're still limited to 32-bit in order to maintain compatibility with v4. The point is to just get everyone onto IPv5 without making them reconfigure anything.

This also requires upgrades to DHCP, NAT, and DNS to support 120-bit addresses, but unlike v6, the new versions of those still talk to v4 clients. A v5 host can still read A records off 1.1.1.1 DNS. If a v4-only host gets 192.168.1.2 assigned, a v5 host on the same network sees that as 5000:192.168.1.2 due to the common state.

As consequences of the above, v5 and v4 packets follow the same routes, and websites assign the same reputations to both, avoiding the most common end user problems with IPv6.

The only snag here is, what happens if a v5 host talks to a v4-only one? Routers could translate v5 to v4 when they know the next hop router/host is v4-only. Or the ends could do something like Happy Eyeballs. In fact v5 is parallel to how v6 uses DNS to ease the cutover, except it's at layer 3 instead.

Proposal, phase 2...

You only reach this phase when a host is ready to disable IPv4, either because the world has sufficiently adopted v5 or because it only needs to talk to known v5 hosts. You put the iface into v5-only mode. Now your 5000:1.2.3.4 can be split into 5000:1.2.3.4.1 and so on. Anyone on v5+v4 who doesn't get the memo is still compatible too.

DHCP and NAT are still default, but each customer of an ISP easily has enough addresses to disable NAT and/or use SLAAC if desired.

Back to IPv6...

IPv5 is meant to complement IPv6, not replace it. V5 hosts can talk with v6 hosts. And if a v5 iface receives an RA packet, it can just switch to v6. Shifting to v6 is probably the easiest way to clean up the routes left over from v4.

A fleshed-out IPv5 proposal