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.
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.
Nothing would stop us from formatting IPv6 the IPv4 way except the monstrous length of the resulting address.
Or a strange number with two decimal parts: http://209.216.59087/
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.
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 its IPv4 address by writing http://3520653007/ or http://0xD1D8E6CF/.
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.
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.
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?
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.
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.
Second, IPv6 is not just about addressing, it's a new protocol. Many things are different in IPv6, lots make much more sense. The header structure is different. Etc etc. The address space and notation are just the most visible aspects. But it's like comparing IRC and Signal. It's not just about user names, it's a different protocol.
Third, there are embeddings of the IPv4 address space into the IPv6 address space. For example ::ffff:192.0.2.128. Note the mix in notation. This is a valid IPv6 address! Perhaps a bit more cumbersome to write than your suggestion, but for technical reasons it was preferred to keep things syntactically unambiguous (that it's an IPv6 address).
Source: I work at a large router vendor, in the routing team.
Also, none of this is secret. Just read the Wikipedia page. I'm slightly shocked how a tech forum supposedly full of hackers is posting so much half truths and plain wrong information. It's all easily available and understandable, and it's not like we're discussing neurosurgery or epidemiology where we're all amateurs.
> 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.
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.