Note: This post is a joke and not expected to be a normative RFC
Totally. I only suggested as a means to avoid conflating a real RFC with a joke RFC. And I only did that because half of the things I have joked about resulted in having to say "No, wait, I was kidding, what are you doing?!?" and thus I learned to minimize joking about things.
OK, so let's just crank it all the way to 11, since 11 is 1 more than 10.
I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility.
Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.
Making a new system that will automatically go live, work transparently to the current system and is on by default as hardware is updated and replaced is a strong pathway forward to unsnarl the internet when you're stuck in this predicament.
Pedantics won't solve the problem and just ensure that nothing ever gets better.
That would be a strong pathway forward indeed, if it were possible. Is it? Because your suggestion so far was something v6 already did, and it wasn't good enough for you.
Computers are the worst pedants in existence, so if it's not possible, you're not going to be able to do it... which means that not only is it not a useful suggestion, but it drains time and energy away from doing things which will work.
Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local.
So 0000:0000 local network, 0000:0001 legacy internet.
Yeah, that's smart. There's no need for everything to be uniquely identified on the internet anyway, right? Why would someone halfway around the world need to be able to ping my smart fridge after all?
Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities.
Actually, now that I've done the math, why not just extend IPv4 into hexadecimal?
Once again, none of the current addresses would change with this change, but it would turn 60 billion possible addresses (12^10 = 61,917,364,224) into 184 quadrillion addresses (12^16 = 184,884,258,895,036,416).
I feel like that would give us plenty of wiggle room. Sure, it's not on par with ipv6's ability to assign a unique address to every atom on the planet 100 times, but I think it would be enough for the next 40 years or so, right?
And it's inherently backwards compatible, what's not to love about it?
So, in my IPv4.1 suggestion, every address you currently know would work perfectly fine.
But then so would AE1.224.78.BC2
Sure, a little harder to remember maybe, but adding nearly a billion times as many IP addresses would alleviate the strain on the internet, be backwards compatible with IPv4 (but not forwards compatible, so most interior/home networks would use either a NAT or have a software ipv4-4.1 bridge software)
It would also be much more similar to IPv6 which would ease transition to full IPv6 if the human race survives long enough to ever make the jump. IPv6 is just more hexadecimal after all.
Wait, you wanted to extend the text representation of v4 addresses? That's not a thing that exists in the protocol. The addresses are in binary in the packet format and in all data structures, so any extension of the character set in the text representation has to be implemented by increasing the bit length of the addresses.
I don't know why you think this is "inherently backwards compatible" yet think v6 isn't. It's just as backwards-compatible as v6 is.
Decimal addresses are an artifact from the time before CIDR, when subnets were always /8, /16, or /24. IPv4 subnet math now requires obscure binary/decimal conversion. Hexadecimal fixes that problem.
[1] - https://www.noction.com/blog/ipv10
[2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/