Not at all. We could have taken one of the unassigned /8's at the time and allocated it to v6 transitional addressing (the failure to address 4->6 reachability is IMO why v6 failed). For the sake of this example lets use 53.0.0.0/8. All new addresses start with 00110101 followed by the first three bytes of the new v6 prefix. The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.

Now your border router can announce your assigned transitional prefix, i.e. 53.32.122.91/32, and is responsible for routing packets to a NAT gateway that knows both v4 and v6 and rewrites packets seamlessly each way.

What we are left with is a scheme that allows v6 to exist on top of v4 and continue working across the existing internet, and the only people who need to worry about it or upgrade anything are the ones who need more address space.

But instead they followed the model of baking in every stakeholders random pet project into v6 to get consensus in the hopes of forcing adoption. They put letters in the middle of numbers, and expected us to not hate it like algebra.

> They put letters in the middle of numbers

If you prefer, you could write an IPv6 address in dotted-decimal notation just like an IPv4 address, or an IPv4 in hexadecimal notation like an IPv6 address. It's just 128 (IPv6) or 32 (IPv4) bits of data after all, the representation is completely independent of the protocol.

For example, you can also reach HN through it's IPv4 address by writing http://3520653007/ or http://0xD1D8E6CF/.

> The prefix acts as a flag that indicates it is a new address and routers read an additional 5 bytes from the beginning of what would be the data section of a traditional v4 packet to get the complete address.

Your proposal, as usual for these kinds of proposals, fails to consider how would an "old world" endpoint talk to a "new world" endpoint. An "old world" endpoint wouldn't know about these "additional 5 bytes", and would both send packets without them to "new world" endpoints (confusing them) and treat them as data bytes when receiving from "new world" endpoints. The only solution would be to upgrade all the computers on the "old world" first, but once you have to do that you could move them all to the "new world" instead.

If what you want is just the addressing (for instance, you already have 192.0.2.1, and want to use it for IPv6 without needing to obtain an IPv6 address first), there's already 6to4, which has most of the properties you want: it exists on top of IPv4, your router announces the IPv4 prefix, and IPv6 packets sent to it are transparently routed to a relay router which encapsulates them inside IPv4 packets destined to that IPv4 address (in the other direction, your encapsulated packets are sent to a relay router which extracts the IPv6 packet and forwards it). I've used this in the past to give full IPv6 connectivity to a site which had only a single IPv4 address, and it worked well.

I address that. Old hosts and networks only know about the first part of the address and the rest of the address resides in the data section so a new application can run on an old host even. When you cross from an old to a new network, the router can hand packets to a side box that runs CGNAT. This allows for new hosts and networks to talk to old without having to include their full address in the data payload.

Think of it like the mail service. For the majority of the journey your letter is only routed based on the first 3 digits of the zip code. When it reaches the last mile sorting facilities is when the full address becomes relevant.

Your scheme already exists, although instead of using the first octet of the IP address it uses a 41 in the protocol field, so it doesn't need to eat an entire /8. Routers can see the 41 as a flag and then read the v6 address from the beginning of the packet payload.

You haven't managed to suggest anything that v6 doesn't already do, or anything that would solve any of the problems v6 has when doing it. I'm not sure you even noticed the problems, yet you think you can throw stones at the v6 people, who not only noticed the problems but had to solve them too?

Throw that packet at a non-v6 router and let me know what happens. v6 could have been an overlay extension to solve the address space issue without the migration complexities.

We are now 26 years in and v6 has only gotten serious adoption because mobile carriers came along too late in the game to get enough number resources.

For a practical demonstration: That's the reason decimal IPs work, too - i.e. http://3520653007/ is the same as http://209.216.230.207/ (and both will go to HN) - it's all just nice formating for our human brains.

Nothing would stop us from formatting IPv6 the IPv4 way except the monstrous length of the resulting address.

You can even make it funnier by having it look like a floating point number: http://209.14214863/

Or a strange number with two decimal parts: http://209.216.59087/

Wow learned something new today. What's interesting is that the decimal representation looks more like a phone number which people would be used to. Interesting that IP addresses as they are written today was the format that won, as a kid before learning how computers worked I always found it weird how 255 was the highest number in each group.

Its often challenging enough for people to do CIDR subnet calculations in their head when its broken out into octets. I'd have just given up on networking entirely if the standard was to use decimal notation.

My whole life I went without knowing decimal IPs were a thing..

There's more than just decimal .... https://daniel.haxx.se/blog/2021/04/19/curl-those-funny-ipv4...

A 32-bit number is a 32-bit number. Whether you represent it in dot notation, hex or decimal.

That's not what GP said.

Of course IPv4 devices wouldn't be able to use IPv6 addresses, that would be impossible. But it is possible to "keep" IPv4 addresses, just make a.b.c.d to correspond 0.0.a.b.c.d.

You and Plasmoid completely misunderstood dheera and me. I failed to clarify this misunderstanding explicitly (I still don't see where does it come from), so I do it now.

> I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.

As you can see, dheera did not state that IPv4 or IPv6 work with strings. They just said that they wished/expected the trivial extension of the IPv4 protocol, with the same notation, and preserving the existing IPv4 addresses. (These are 2 distinct wishes.) Acknowledging that this did not happen.

Nor dheera nor me posted any half truth or plain wrong information.

> the trivial extension of the IPv4 protocol

It wouldn't be trivial in practice. You'd still end up needing to replace everything in between. And if you're going to replace everything in between, you might as well upgrade it to something much larger instead of taking little half steps that will need to be repeated again and again.

> preserving the existing IPv4 addresses

But it wouldn't really in the end. 0.0.1.2.3.4 is still a different address than 1.2.3.4. You'd still end up needing to translate 0.0.1.2.3.4 to 1.2.3.4, aka a 6to4 tunnel. So, you're in the same place in the end as where we are with the current IPv6, just with only a baby step in changes that will probably need to be upgraded again in the future.

64:ff9b::/96 is allocated for NAT64 - and most US mobile carriers use this as most Android and iOS phones use IPv6 only APNs with DNS64 and 464XLAT.