> Then IPv6 traffic could pass over IPv4 networks without any changes. The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.

So:

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

* https://en.wikipedia.org/wiki/6in4

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

You can sign up for an IPv6 connection, without any IPv6 support from your ISP, via Hurricane Electric's tunnel service:

* https://wiki.archlinux.org/title/IPv6_tunnel_broker_setup

* https://docs.netgate.com/pfsense/en/latest/recipes/ipv6-tunn...

It's been around for at least a decade:

* https://www.internetsociety.org/blog/2014/01/weekend-project...

Any 'expanded IPv4 address' solution will (have) face the same problems that IPv6 has faced, and the solutions will end up being the same: having to slowly upgrade the network stack (hosts, routers, firewalls, ASICs), changes in networking system calls and associated structs (because the number of bits), gateways and transitions mechanisms, expansion of related protocols (DNS A records are only 32-bits, so a new record type needs to be supports (e.g., AAAA for IPv6, AAAAAA for your new proposal)).

If you want to argue that we should have (say) kept ARP instead of moving NDP, sure.

But anything to do with expanded addressing would be the exact situation: code upgrades and transition mechanisms.

> It's been around for at least a decade

I just logged into tunnelbroker.net to check: my HE account has been registered November 22, 2010 11:30:00 UTC. Today it's unused because IPv6 is basically always available in France.

That's not even the first time I tried IPv6 things, part of it being I had some access to RENATER via my engineering school, right when they kicked off IPv6 around 2002.

The past 10 years of IPv6 have been largely uneventful for me: it just works.

> The past 10 years of IPv6 have been largely uneventful for me: it just works.

Yeah, ditto. Except that it has been more like twenty than ten for me.

From my he.net tunnel, to (several years later) my Comcast-provided native IPv6 service, to IPv6 on my phone, to IPv6 with my local ISP (once I switched off of Comcast/NBCUniversal) it has been so very, very boring and reliable for so many years.

I didn't have IPv6 available from the sole (land-based) ISP who offered service at my last house, Altice USA (Suddenlink/Optimum).

I moved away about 13 months ago.

(Worse yet their modem/router did RAs or whatever but there was no connectivity out)

The past 10 years of IPv6 have been largely uneventful for me: it just doesn't work.

> The past 10 years of IPv6 have been largely uneventful for me: it just doesn't work.*

IPv6 worked "too well" for me: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.

Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.

And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.

Someone please prove me wrong, but afaik HE's tunnelbroker requires a sane IPv4 environment, i.e. doesn't work with CGNAT. I'd love to keep using it but since we switched ISPs to one using CGNAT I don't think I can use tunnelbroker.

We switched ISPs so we could get better than 6/.768Mbps DSL w/60ms ping. Now we are on 15/2 fixed wireless w/20ms ping and CGNAT.

> The only constraint would be that each IPv6 network would have to have an IPv4 "gateway" address.

In your scheme, any IPv4 address is automatically expanded into an IPv6 gateway address, since there is no other way to map that partial addresses together. So, for every /32 of space you want to add, you have to get another IPv4 and use it as a gateway.

It's also going to be a massive amount of fun doing "second level CIDR" on those gateways.

You've just turned CGNAT inside out to no real benefit.

One problem with this approach is it doesn't really expand the address space for new address assignments. We're still stuck within the 32-bit IPv4 space for the "outer" routing. This seems worse than simply tunneling IPv6 for users with ISPs that don't support it yet.

> So your IPv6 address would be 1.2.3.4.5.6.7.8. The header would have 5.6.7.8 as the IPv4 destination. When it got there, that router would unpack the rest of it and send it off to 1.2.3.4.5.6.7.8. If that host had to talk to an IPv4 host, it would just use the IPv4 headers.

How does the IPv4 person craft the reply back to the not-IPv4 source?

They don't. They still have to upgrade. But at least the service owner has options to run the services on their gateway and then pass the traffic back to the hosts behind on their internal IPv6 network.

And more importantly it means that if a client wants to interact with IPv6, they only have to upgrade their client, and not wait for everyone in between to upgrade too.

In other words, your proposal establishes only not-IPv4<->not-IPv4 communication over an IPv4 tunnel, which is something actual IPv6 has had for decades?

(There's also the interesting question of how not-IPv4 addresses are supposed to get their not-IPv4 addresses if the entity they get their IP addresses from doesn't support not-IPv4.)

No, it establishes a path for piecemeal upgrades to the infrastructure that is cross compatible with IPv4.

I'm not seeing it... can you clearly explain specifically what scenarios your not-IPv4 deployment strategy enables that doesn't exist with IPv6 today?

(If you're going to say "not-IPv4 local network with IPv4 ISP", then clearly explain how the not-IPv4 local network is supposed to get its not-IPv4 address, and why that is materially different from existing IPv6 tunnel options.)

This has been proposed many times already, and it actually wouldn't work.

Why not?

Because the IPv4 host can't talk to new protocol hosts. IPv4 hosts can only do 32-bit addresses and don't know about the wrapping. If they did, they would be new protocol hosts.

I had idea of putting the internal address for NAT in options so could be addresses directly. But too many boxes would need to be changed, and lots of unchanged boxes remove options. Plus, all the IPv4 applications wouldn't know what to do with stack of addresses. It would devolve to NAT.

Of course they can't. But the point is that if a client wants to interact with IPv6, they only have to upgrade themselves, and not wait for everything in between to get upgraded. And the service can serve on their IPv4 gateway and then pass the traffic back to other hosts to server IPv4 clients.

Pretty simple indeed Will it rewrite all my hardware, without it nothing will work ?

No You'd need a full rewrite at the parser level

As everybody said : ipv4 cannot be made compatible with larger addr space

Where you gonna put the bits for the extended address?