> 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.
But this was what literally happened. All routers today support NAT and most of them actively use it. Isn't it a magical form of extended IPv4 address space? Could have been easily done in less band-aid fashion instead of chasing IPv6.
It is impossible to address hosts behind NAT. Only the public IPv4 address is visible.
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.
From the link: "A lot of Cloudflare's technology is well documented. For example, how we handle traffic between the eyeballs (clients) and our servers has been discussed"
Already 1 sentence in and we've already got Eldritchian horrors with customers described as just their watery orbs in their skull.
There are semi-compatible ways. My favourite proposal (if we couldn't have IPv6) was recursive IP: you transmit a packet to 12.34.56.78 and inside that packet is a packet addressed to 192.168.1.5. If you have more layers of NAT, inside that can be a packet addressed to 10.1.2.3.
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.
Unfortunately none of those people have explained how it could be done in enough detail that I could try it. Most walk away when pressed but a few press on telling me it is easy so shut up and do it .
Similar to how it has been done with phone numbers. I saw this done in Brazil for example. You add a digit to the front and put all existing address on 0.*. Short number dials are assumed to be 0.*. Update OS and hardware. Then you allocate across the new digit much later as time goes on.
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.
The IPv4 address field is fixed size. You can't simply add a digit and deal with it at the telephony company premises like you can with a phone number. You have to rev every piece of equipment and software that can ever touch a packet. At that point, why are you not also fixing other architectural flaws and ensuring that the address space is large enough to accommodate any future needs?
One interesting thing about this idea is that, from a higher level, that's exactly how IPv6 works; the "leading zero" is the IP protocol version field. If that leading zero, er IPv4, is there, the fields of the IP packet are interpreted using IPv4 semantics. If the version field is IPv6, then the IP packet is interpreted using IPv6 semantics.
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.
Nothing in the world can work with IPv7. That means need to update all the software and replace all the hardware. This takes years of effort, and years of time.
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.
> Nothing in the world can work with IPv7. That means need to update all the software and replace all the hardware. This takes years of effort, and years of time.
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...
> You add a digit to the front and put all existing address on 0.*
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)
Well, you asked for a design and I gave one. Any change is ultimately going to require a software rollout. (I suppose you could squeeze a byte into an underused header in the short term.)
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.)
I have actually seen the protocol specs for both IPv4 and IPv6. IPv6 is simpler than IPv4 - but you probably never looked into how to do source address routing which you are required to support when you implement IPv4 even though nobody uses it (If you try I'm sure that the large backbone providers will block it)
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.
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.
I believe it's more along the lines of the concepts in IPv4 are easier to grasp than IPv6, starting with the actual addresses themselves.
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.
IPv6 breaks less backwards compatibility than many people think. Many get caught up in all of the other changes you can (and often do) do because it makes life better and conflate that with IPv6 not letting them do things the same way. About the only generally true "it breaks backwards compatibility" is the format of the address being longer for the longer address. Netmask, gateways, DHCP, static assignment, and neighbor discovery are all about as 1:1 as one could ask if that's all you care about but it's just a dumb way to do things if you're upgrading everything so then you have SLAAC, a more present link local, DHCP-PD, and so on to hear/think about as well.
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.
What are you exactly asking for? Sure it's not recommended but you can have NAT66 for IPv6, and DHCPv6 for IPv6. You can choose to configure your own IPv6 network in a way that's familiar to IPv4. Not exactly best practice but doable.
There are a bit more than a hundred unused protocol numbers, and the options field has more than enough room to stuff some more address space into it. You'd need enough buy-in to get the protocol number accepted as valid, and could introduce better routing gradually: as long as the OG destination address knows how to send the packet on to the extended-address computer, it'll get where it's going.
The problems, and they are real, show-stopping problems, are more social than technical.
I know nothing of networking, could you explain why you can't use 4 bytes of option to extend the address space by 8 bits without invalidating existing addresses or require routes to them to understand the new option? Do routers not reject unknown options?
