There are endless protocols and methods which embed ipv4 addresses to ipv6 ones. RFC 4291 specifies exactly what you want, all-zero prefix+ipv4 address: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.5.5

See also the text representation section: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.2

   3. An alternative form that is sometimes more convenient when dealing
      with a mixed environment of IPv4 and IPv6 nodes is
      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
      the six high-order 16-bit pieces of the address, and the 'd's are

      the decimal values of the four low-order 8-bit pieces of the
      address (standard IPv4 representation).  Examples:

         0:0:0:0:0:0:13.1.68.3

         0:0:0:0:0:FFFF:129.144.52.38

      or in compressed form:

         ::13.1.68.3

         ::FFFF:129.144.52.38

So in addition to having the addresses embedded on binary level, you even have that text notation that uses traditional ipv4 dot-notation!

You might ask why they are not more prevalent, but then you will find the practical issues that various transition mechanisms are attempting to solve.

It comes down to user experience.

How many people managing networks who knew their ip addresses by heart and typed it regularly for all kind of tasks were put off by the new format and decided, consciously or not, to wait until "I really have to deal with it"?

Some people get really angry when you point that out ;)

Good thing for IPv6 it didn't really have any competitor (except IPv4).

Another person who does not understand IPv4.

IPv4 isn't a text based protocol where IP addresses are parsed like DNS. It's a binary protocol where addresses are recorded in binary and adding more address space WOULD BE A BREAKING CHANGE.

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.

2a09:: 2a11:: and 2409:: are even shorter than 8.8.8.8, though not quite as memorable.

I'm not recommending those DNS servers, just highlighting that "vanity" IPv6 addresses exist now. It's possible that 2222:: or 3333:: could be allocated someday.

Related: <https://www.sprint.net/>'s IP address was 2600:: for many years, but they sadly started using a DDoS mitigation service with different IPs.

and people are wondering why v6 never took off...

Huh? IPv6 does have backwards-compatible-ish notation for writing IPv4 addresses. To take your example: 1.2.3.4 would be ::ffff:1.2.3.4, the 96-bit prefix indicated by ::ffff: is where all of the IPv4 addresses live in the larger IPv6 space.

If your issue is with the use of colons at all, they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.

> they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.

Wait until you try to write an IPv6 address with a port number in standard notation.

Usually IPv6 addresses are enclosed in square brackets when a port number is involved. But it's true that in many configuration files IPv6s are a nightmare to put in, especially because you never remember what syntax you have to use: sometimes you even have to duplicate semicolons (that's what Exim does...). But I think this is rather a convention problem for the config files, rather a problem of IPv6 addresses themselves.

The IPv6 people must have known that : was a common way to separate IPv4 and port numbers. IPv6 was standardized 4 years after the URL format which used a colon to denote a port number.

Makes sense, the choice of the colon is a bit unfortunate.

Technically it's just 128 bits, it doesn't matter how you represent it. I've written this IPv4ES solution, which allows you to use 128 bit addresses using IPv4 format.

https://www.sami-lehtinen.net/blog/ipv4es-the-perfect-soluti...

Exactly this misconception comes up (often multiple times) every time there’s a discussion about IPv6 on HN.

No, it’s not possible without running into the exact same problems that we had with IPv6 (which actually has various compatibility mechanisms, to the point where now some mobile networks are IPv6 only but still work to let people access IPv4).

The problem with your proposal is the same issue we have now - something that only talks the old protocol can’t possibly talk to something in the new protocol (without the same kind of hacks we use with IPv6 like NAT64/464XLAT), since IP addresses in headers are fixed sized. Which also means that any router in the middle can’t possibly route packets to networks with the expanded addresses. So we have the exact same issue - everything needs to be upgraded to deal with your new scheme, but unless that all happens on the one same day, you need to be able to deal with the old addresses. So you need dual stack, just like with IPv6 until everything is transitioned.

So basically all you’d have with this kind of proposal is exactly the same problems, but it would be more confusing why older devices can’t talk to the newer devices since the addresses would look very similar!