There's a surprising number of people who think you could magically expand the IPv4 address space in a backwards compatible manner.
There is a (somewhat) backward-compatible way to do this at least for TCP and UDP:
Instead of assigning an IPv4 network prefix (or one single IP address as a special case), assign a tuple (IPv4 network prefix, port prefix), i.e. by firewall rules not every source port can be used from every IP address for TCP and UDP connections.
Is this a better solution than IPv6? I clearly don't think so. But it is an ugly, hacky solution that is theoretically possible if one really insists that one wants to keep using IPv4 (only), and needs to magically expand the address space.
It might have been possible to extend IPv4 by having each NAT hop add the internal IPv4 address as option header. Then it would be possible to refer to inside host directly with a list of addresses.
That isn't worth doing now because it would require rewriting everything to deal with the new protocol. For one thing, lots of NAT boxes remove all the option headers. The new protocol wouldn't be reliable.
TLDR: Cloudflare is using five bits from the port number as a subnetting & routing scheme, with optional content policy semantics, for hosts behind anycast addressing and inside their network boundary.
Filed in my bookmarks under "abominations".
Already 1 sentence in and we've already got Eldritchian horrors with customers described as just their watery orbs in their skull.
If both endpoints do this you can directly establish connections. If only one does it, fall back to NAT like before. Core internet routers don't have to be updated. Addresses at endpoints are effectively variable-length.
The thing with phone infrastructure though is that it is centralized. So may happen in a reasonably coordinated rollout. Global internet is a lot more distributed so it would take a very long time.
The open question is, would it take longer than IP6 has? Maybe not. Part of the reason I didn't care to use it early was because of the long addresses. If we could get a five byte address written in hex it would be somewhat user friendly.
So?
Make it bigger, call it IPv7, then enjoy.
IPv6 has 128 bits for addresses, why can't IPv7 have 128 bits as well, but still use more familiar patterns/techniques borrowed from IPv4?
IPv6 threw just about everything out the window... for what reason? Two decades of confusion and resistance...
I think at this point in time, people are afraid to say "ya, we overthought the hell out of IPv6".
What more familiar techniques? How are they going to be worth the millions of man-hours to implement? How are they going to be so much better that people will abandon IPv6 and switch from IPv4? Could this be accomplished by changing part of IPv6?
It is quite possible that you are using IPv6 to access Hacker News without knowing it.
Uh, you mean like IPv6?
IPv6 once was new, and it was radical at the time (still mostly is). IPv4 should have just been extended to a 128 bit address space, breaking changes implemented around that, and then everything else would have been easier to adopt. No relearning everything - just rationalizing about larger address space.
> It is quite possible that you are using IPv6 to access Hacker News without knowing it.
No I am not, because our IT Dept. disables IPv6 on all workstations and doesn't support them at our gateways. IPv6 was the culprit in a lot of networking issues that just magically "go away" when disabled... so, they disable.
The decades and decades of knowledge built around IPv4 is immense. IPv6 asked everyone to forget almost all of it and start over. It's really not surprising IPv6 is still not well adopted...
Why do you think your IPv7 will magically just work? There will be problems with it and IT departements will still disable it.
This is how you configure telephone dial plans. Earlier dialed numbers influence the interpretation of later numbers. You dial a 1, an area code is expected next. You dial 9, you get an outline line. Dial plans are a pretty decent setup and allow scoped dialing, but are limited in their extensibility (you can't have a local number start with 1). In IP, the IP protocol version field influences the interpretation of later fields, logically similar to dial plans.
> If we could get a five byte address written in hex it would be somewhat user friendly.
For local addresses, you can use fec0::zzzz.
Do you need to memorize or hand-type global addresses very often?
How well did IPv6 turn out by that criteria?
> memorize or hand-type
We read things many more times than we type them. Yes, gibberish at 4x the length is substantially harder to deal with. I do write addresses occasionally and with IP4 it is at least possible, if not desirable.
About the same. So it's good we made it big for the future.
> Yes, gibberish at 4x the length is substantially harder to deal with.
I find copying and pasting to be pretty easy, and if you're looking at your own machines you can organize them all with the last 4 characters.
I don't have to compare random internet servers very often.
How do you do that? I have read the IPv4 protocol spec, there isn't any space to put that byte can still be IPv4. That is what I mean when nobody has proposed anything that I can implement: I have read the spec and it doesn't allow room for what you want to do. Sure conceptually you can describe any number of ideas - but they are not IPv4 and no existing computer or router will work with it - so we may as well go with IPv6 which many smart people spent who understand the real problems of the internet have a lot of effort creating to solve existing problems to the best of their ability.
Brazil didn't just add that leading 0. They planed this well in advance and forced everyone who connects to the phone system to update their systems to support it: you must apply a software update or buy new hardware; otherwise your phones stop working. Of course most of the software and hardware was controlled by the Brazil phone company (s?) and so they could ensure this was all done.
I first found out about Brazil doing this from your comment - yet I can say the above with all confidence because those are things that have to happen behind the scenes to make it work. (I have no doubt people who actually know something about what Brazil did can tell you things I didn't think about)
The argument upthread was that v6 was too big a change, resulting in a slower than anticipated rollout. And perhaps merely shoehorning another byte or two into v4, say v4.1 would be easier and more quickly accepted by the world.
Possibly—I'm not strongly arguing for either, besides the fact that v6 didn't solve any problems I was having besides the world running out of addresses. It's a lot harder to grok at a glance though.
Also, a smaller change wouldn't break existing networks, just like the existence of v6 didn't break v4.
(This is basically the Python 2 to 3 transition argument in global form.)
Phone number lengths are defined by ITU E.164:
* https://en.wikipedia.org/wiki/E.164
They can be up to 15 digits long: so as long as the format change that goes from length x to length x+1 doesn't break that limit, then no changes to code or equipment needs to be done. The routing just needs to be tweaked so that when a number is read the signal is sent to the correct destination.
This is different from IPv4 where the digit length needed to be changed. It would be like if telephones went from 15 digits to 20+ digits: all the telephone gear would have to be changed to deal with the larger numbers.
Which starts to sound an awful lot like an IPV6 migration.
IPv6 breaks all backwards compatibility. So, it's not unreasonable for people to ask why we can't just break it in a more familiar way?
Extending IPv4 into say, IPv7 and using familiar addressing schemes, well understood routing/NAT/DHCP techniques, etc, while providing the same usable address range as IPv6 is possible.
E.g. you can still NAT the massive IPv6 private address space with static and/or DHCP assignments without having to change your understanding (addresses would even be darn short too!) but... it's just silly to do.