I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.

Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1

And then we dish out all the new address space. You would get the network providers to handle address conversion until software and hardware has been updated. Because all the existing addresses are reserved in the new set, it doesn’t affect them.

Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.

> backwards compatible with existing hardware/software

Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long. They expect packets to have a 4 byte source address at offset 12 in the header, then a 4 byte destination address at offset 16. Everything breaks if you try to give them a header with an 8 byte source address at offset 12 and an 8 byte destination address at offset 20.

That would still constitute an entirely new system, just one that looks very like the previous one. So much code and other infrastructure (routing tables in hardware etc.) relies on IPv4 addresses being 32-bits not 64 and that would all need to change, complete with extra new stuff being added for that translation layer while both are in operation (which would end up being near permanent, people will find ways to keep the old stuff running as long as they can). I expect that this new scheme would just become a new version of CGNAT, “Global NAT” perhaps, with the same problems that adds.

IIRC something like that was considered when IPv6 was first being designed, be deemed insufficient for the long-term future. 64-bits is thought to be enough to stave off address starvation though, which is why IPv6 address ranges are usually assigned as /64s (my homer link has a /48 range should I wish to use it all!), so I can see your reasoning on that level.

This is all the bad parts of ipv6 with none of the good parts...

You still need to have routers, clients, and absolutely everything to understand the new scheme to use those new addresses.

How does 192.168.0.1 talk to 192.0.0.0.0.168.0.1? Like, literally, how does it make a packet with that destination address?

The entire ipv4 space is already mapped to reserved subsets of ipv6, by the way. e.g. ::ffff:0:0/96 (i.e. 0.0.0.0.0.0.0.0.0.0.255.255.w.x.y.z) or 64:ff9b::/96. v6 devices can already "talk to" v4. The problem is the ipv6 space is obviously not a subset of ipv4, so v4 doesn't have a clean way to talk to or even about v6.

Lots have thoughts on this, few take the time to review the existing implementations/proposals and explain both how it is their approach doesn't run in to the same problems as well as the problems their proposal still doesn't resolve.

Most of the time, this results in people thinking the big problems are one set like "if only there was a way to translate" while the real remaining problems are another set like "and how do you get people to want to transition when it works well enough for those clients in the translated state".

> until software and hardware has been updated

Yeah, about that part. This is a "now draw the rest of the fucking owl" type of idea.

Hey, if you want to add OAuth and JWT to that idea for some reason, boy do I have an RFC for you https://www.ietf.org/archive/id/draft-thain-ipv8-00.html

You could just use something like fd00:dead:beef::192:168:0:1 for your internal IPv4 host(s). Basically do a human-readable mapping of your IPv4 LAN IPs into a IPv6 private space. Now you only need to remember the ULA prefix and then can continue to use your IPv4 just with colons instead dots. Problem solved. :-)

>Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1

How is this different from ::192.168.0.1? :)

This seems achievable if you can figure out how to fit 64-bits into 32. ;)

There is barely any legacy hardware/software that doesn't work with IPv6. It's just not an issue.

Dual-stack is also the default, and CG-NAT exists as a fallback. For IPv6 only websites there is still the option to use a HTTP proxy.

> I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.

There is no "just" extending the address length:

      So it's a matter of mathematical and physical fact that to expand
      the address size, you must change the protocol, and that means 
      [three] things immediately:

            You have to change the version number.

            You have to add new code to handle the new version.

      […]

            You need a coexistence technique so that updated systems, 
            with the new protocol, can connect to old systems that know 
            nothing of the new protocol.

      Two minutes of thought show that this third requirement has only 
      two solutions:

            (3A) Dual stack, in which the new machines speak both 
                 the old (IPv4) and new (IPng) protocol.

            (3B) Translation, in which something translates addresses
                 between the old and new protocols.

* https://datatracker.ietf.org/doc/html/rfc1671

> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.

You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.

You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)

You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the 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 that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)

You're updating the exact same code paths in both the "IPv4+" 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.

"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.

I believe that was proposed before IPv6.

That being said, we should take the time to understand why IPv4 is still hanging around when IPv6 has been around since before most people got internet access. What is really holding IPv6 back?

That's literally what ipv6 does.

You can do this in IPv6

I recall something like this, what did you call this? ipv8?

the thing is that it does require a switch similar to ipv6. but maybe there’s a subnet that maps 1 to 1 with the legacy block?

something like this could theoretically be pinned onto ipv6 AND anyone could do it, just select a 98 bit prefix you own, and the rest of the 32 bits you can map to ipv4.

phase -1 could be tunneling traffic through a single zone proxy which would be inefficient and is purely conceptual

phase 0 would be the same, but with an anycast ipv6,same ip that resolves differently based on location, like 8.8.8.8

phase 1 would be the mapping prefix to ipv4 (and viceversa?) being distributed to the routing tables like, which could be done via application logic (most efficient), or via some deep arcane isp routing conf files, or just a hell of a lot of routing table entries for each ipv4 but duplicated, possibly programatically controlled by an application that generates router table files as a target, thus avoiding desyncs and effectively becoming the first option of application level implementation

maybe something like this already exists though

of course it’s horrible hacking (as hacking in the non crime sense often is), but it allows for a purely technical solution to issues of political and administrative nature.. which is all the rage nowadays

This reminds me of the following XKCD:

https://xkcd.com/927/

That was kinda the way IPv5 proposed to handle it.

But the big big problem isn't windows/Linux/mac. Writing drivers for those are "easy".

The problem lies in all the networking gear speaks only IPv4 and/or 6. LLM assisted hacks can get into maintenance areas, but these devices are also built to support the least amount of things. Like, there may not be enough ram or storage to even run it.

And 20 years in, you see how well IPv6 has taken off :eyeroll:

And even on my network, I disabled IPv6. My upstream ISP is doing something that makes '6 unstable, but '4 is fine. And I find most network engineers don't have to maintain '6, so they never really learn it.