The new players would each get a /24 and everyone would say that's "enough".
From where?
All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them.
But at some point IPv4 addresses would all be allocated… along with all the extended addresses 'behind' them.
Then what?
The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from?
You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bits… just like with IPv6. Great you managed to purchase/rent a legacy address range… but you still need a translation box for non-updated code… like with CG-NAT and IPv6.
This IPv4x thing is bullshit but we should be accurate about how it would play out.
But right now you can get an IPv4 /24 (as you say), but you can get an IPv6 allocation 'for free' as we speak.
In both cases 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 IPv4x 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.
Note that going from v4 to v6 also doesn't mean changing all your routes and addresses; you just enable it and everything still works. Network components can get updated behind the scenes without user impact. There's no flag day though; ISPs can start using the new address space as soon as they want, rather than being forced to wait until everybody else is ready.
* https://en.wikipedia.org/wiki/Happy_Eyeballs
Getting "free" new-protocol addresses is also nothing new:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
Translation boxes and tunnels are still needed for both IPv4x and IPv6.
You see it as a special feature with rare usage because it competed with native and lost. People overwhelmingly preferred deploying v6 natively instead of deploying 6to4. Obviously more people would be using it if it was the only option, but if you're trying to come up with an alternative to the way v6 went then "an approach that v6 took but which nobody wanted to use when native v6 was the alternative" might not be a very promising place to start.
So actually I take it back, 6to4 was pretty different from this ipv4x idea. I misunderstood and thought a v6-enabled ISP would give you a 2002: under 6to4, which you could later subdivide.
Ignoring that, say 6to4 were like v4x... The idea that those 2 years showed that native was preferable, that was among a small minority who even cared about v6 to begin with (0.25% at the time). This was a primary, not a final.
Or, ISPs that want to do so can use one of their own v4 addresses to get the corresponding /48 6to4 prefix, split it up and hand that out to customers while handling the v4 packets themselves.
Looking at the 15 or so years afterwards shows native v6 deployment at 50% of the Internet, and approximately nobody interested in deploying 6to4 outside of these posts where people keep reinventing it but with different names and an assertion that if only the IETF had thought of this, everybody would have loved it. I think that's decent evidence that they wouldn't.
To whoever wishes the IETF had thought of ipv4x, I'll bet the IETF thought of it and decided they wanted to start with a clean slate in v6. I can understand why, big part because of v4's fragmented routes, and also /8 haves&have-nots. But v4x at least had a way to gradually defrag things once it was fully adopted. If you're suggesting staying on 6to4 forever, that would've meant continuing to use vanilla ipv4 between subnets.
Also, all those compromise ideas had NAT staying at least on day 1. Many v6 proponents seem to think your device on any random guest network should be able to receive inbound connections, enabling true P2P everywhere, which implies having no router firewall. Others recommend a router firewall. Not sure what IETF's initial position was on this, but they later recommended that residential routers give the user a clear choice between closed vs open. v4x with its NAT would just default to closed. In reality, I've never seen a consumer router clearly say what it does with inbound v6 traffic.
But if it is, it's basically saying that people really didn't want to take this approach.
> To whoever wishes the IETF had thought of ipv4x, I'll bet the IETF thought of it and decided they wanted to start with a clean slate in v6.
They obviously did think of it, since v4x and 6to4 take pretty much the same approach. Both of them put extra address bits into the start of the payload. Both of them indicate they've done this with some flag in the header. Both of them send packets through unmodified v4 routers. About the only difference is that v4x consumes the entire 128-bit address space while 6to4 sits in a /16.
Everything that you've said can be done in v4x can also be done with v6 and 6to4 (possibly combined with some of the other transition options), and it doesn't make it any easier either unless you handwave away a bunch of the work that needs to happen.
> But v4x at least had a way to gradually defrag things once it was fully adopted. If you're suggesting staying on 6to4 forever, that would've meant continuing to use vanilla ipv4 between subnets.
6to4 prefixes can be routed natively without needing to be tunnelled inside v4 packets, so you don't need to do that. That's how ISP-side 6to4 would work, but you could also do the same thing in the DFZ. If you're announcing v4 addresses you could also make a BGP announcement for the 6to4 prefixes that correspond to those v4 addresses, allowing packets sent to those prefixes to reach you natively instead of getting tunnelled. Presumably this is about the same as what you were imagining v4x would have done to get rid of vanilla v4.
I don't see how you could gradually defrag things in v4x, unless you include ways that would also work with 6to4.
> Many v6 proponents seem to think your device on any random guest network should be able to receive inbound connections, enabling true P2P everywhere, which implies having no router firewall
A few do, but it's rare. The main point is that the IP of a machine should be the same no matter where you are in the network, and nobody should be using clashing address spaces. None of that implies no firewall.
NAT features heavily in the v6 transition. It's how you handle connectivity to and from v4 hosts that can't do v6. There's just no need for it between two v6 hosts.
Once the world is ready and your ISP actually issues you with v6, then you need to change some things (I would argue not everything). Again, this is the same as for v4x. The only difference is that in the v4x case, you put this after the end and ignored it.
Ignoring the bit you don't like for one of them but not for the other isn't a fair comparison.
But when the world is actually ready for v6, you do need to change everything. And it's worse than that, the world only becomes ready by people changing everything before the world is ready. You said I put this part at the end of v4x, and yes that's the point, the ordering of changes matters.
To be clear, you don't need to change much in order to have v4x without using the extra address space... but starting to use that extra space means changing everything in the same sense that starting to use the extra address space from v6 means changing everything.
At least with v6 you don't have to wait for the rest of the world to be ready. You can start using it straight away. What you're asking for would give people _less_ motivation to do the work, so the "the world only becomes ready" problem gets worse. How is this better?
How is v4x easier, because from many parties' perspectives (end users, ISPs, hosts), there is little to no change. Yes, whoever makes the router or OS has to deal with the new protocol. Now if you buy a new router or update your OS, it supports and truly uses v4x without you needing to configure anything. Unlike v6 where even if you don't make a router or OS, you very much have to deal with it as a sysadmin or maybe even an end user.
How is v4x more motivating, well to most people it's not. It's just easier. Those who already own large v4 blocks might be more motivated to support v4x than v6, but it's a double-edged sword.
I'm not saying it's simply better though. There are downsides. It's better if your only goal is to extend the address space.
I understand it in the situation where you aren't using the expanded address space, because then you can just present v4 addresses to the sysadmin/user and they don't need to do anything differently. But... then you don't get any expanded address space.
If you want to actually use the expanded address space, then they need to deal with it in the same ways and for the same reasons they need to deal with v6. There doesn't appear to be any aspect of v4x that would alter or avoid that need.