You do have to change everything to actually use v6 rather than having v4 on the side. Re: flag day, I guess you could use the new address space of v4x before everyone is ready, provided the other side supports it.

Having partial deployment of IPv4x 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

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.

Ok, I see what you mean then by 6to4 already supporting what v4x proposed, but that path wasn't taken either. It's a special feature with rare usage rather than the minimum default way of doing v6.

We did take that path. If you zoom in on the start of https://www.google.co.uk/intl/en/ipv6/statistics.html you can see that 6to4+Teredo was more common than native until 2010. (Okay, that's combined with Teredo, but I think probably 6to4 is the majority of it because Windows will use 6to4 without needing a registry change or custom application behavior.)

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.

It's not like the v6 spec said, here are two options on equal footing, go figure out which is better. 6to4 was a temp bolt-on. I had to look up what things were actually like in 2010 because I really don't remember getting a 2002:, which brought me to rfc6343 that explained why exactly 6to4 suffered. A big part of it is that even a v6-enabled ISP didn't give you a 2002:, rather you were relying on anycast to reach a relay server. Why would an ISP or user ever want that mess? Either they do v6, or more likely they don't care and focus on v4.

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.

It doesn't rely on anycast. The ISP gives you a v4 address from which you generate the 2002:: prefix, and when talking to another 6to4 network you send the packets directly from your v4 address to their v4 address. Inside those packets is an extra 80 bits of addressing that the source and destination networks can use.

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.

What you're describing is what rfc6343 called "router 6to4" as opposed to the anycast variant, but anycast was what got used. "In practice, there are few if any deployments of Router 6to4 following these recommendations. Mostly, Anycast 6to4 has been deployed." But even router 6to4 isn't easy like the v4x-like ideas: "not designed to be an unmanaged solution."

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.

I don't think that RFC is quite correct. Both types are set up the same way (the only difference is whether the dest IP of a packet is 6to4 or native) and it was designed to be unmanaged in the scenario we're imagining here. Windows machines configured it automatically if they received a public IP, for example.

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.

tldr IETF's goals with ipv6 were fundamentally different from the goals of proposals like v4x

If your goal is just to roll out support for v6 addresses without actually using them, then you don't need to change anything about your network to do that. (Remember going from XP to Vista? That added support for v6 in Windows, but you didn't need to change your network for it.) This is the same as your described rollout of support for v4x.

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.

Yeah I'm with you on not needing to change much to have v6 without actually using it.

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.

So your suggested ordering is for everybody to add support for your v4x addresses in every OS, device, software, API, protocol etc, and then only allow them to make use of the extra address space after everybody else has also added support everywhere?

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?

To answer your first question, if both hosts understand v4x, you can still use the extra space before everyone else is using it. v6 has the same limitation except all routers in between also need to understand it, unless you've set up 6to4 which is more configuration. But this isn't even the main issue.

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.

Why do you think sysadmins and end users wouldn't need to deal with v4x?

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.