On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km². Not counting the oceans, that would be 28 IPv4 addresses per km² land.
IPv6 gives 10¹⁷ addresses per mm² (yes, square millimetre).
In terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.
Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1
And then we dish out all the new address space. You would get the network providers to handle address conversion until software and hardware has been updated. Because all the existing addresses are reserved in the new set, it doesn’t affect them.
Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
> backwards compatible with existing hardware/software
Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long. They expect packets to have a 4 byte source address at offset 12 in the header, then a 4 byte destination address at offset 16. Everything breaks if you try to give them a header with an 8 byte source address at offset 12 and an 8 byte destination address at offset 20.
> Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long.
As does DNS.
"A" records are fixed at 32 bits, so you have to add a new record type and update all DNS software, plus user-space API/library code and data structures to ask for and store the new record type.
Just like IPv6.
There is no "just" adding more addresses: whatever scheme anyone comes up with it's the same amount of work as IPv6.
Computers use binary. Hex is a human convenience. For anyone in computers hex is much better than decimal for obvious reasons. For anybody not in computers hex makes no sense and I'd need weeks of math lectures (which they wouldn't do the homework for and thus fail) to explain it.
How does 192.168.0.1 talk to 192.0.0.0.0.168.0.1? Like, literally, how does it make a packet with that destination address?
The entire ipv4 space is already a subset of ipv6, by the way. e.g. ::ffff:0:0/96 or 64:ff9b::/96. v6 devices can already talk to v4. The problem is the ipv6 space is obviously not a subset of ipv4, so v4 doesn't have a clean way to talk to v6.
You just drop the top half. Or xor it? That'd make for some nice traffic-pattern art ;)
Now the reason this doesn't work is that the address length is not encoded, so if you make the address longer, no one knows about it and they [routers and destinations] just assume the wrong address and send it on or discard the frame
> I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.
There is no "just" extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
That was kinda the way IPv5 proposed to handle it.
But the big big problem isn't windows/Linux/mac. Writing drivers for those are "easy".
The problem lies in all the networking gear speaks only IPv4 and/or 6. LLM assisted hacks can get into maintenance areas, but these devices are also built to support the least amount of things. Like, there may not be enough ram or storage to even run it.
And 20 years in, you see how well IPv6 has taken off :eyeroll:
And even on my network, I disabled IPv6. My upstream ISP is doing something that makes '6 unstable, but '4 is fine. And I find most network engineers don't have to maintain '6, so they never really learn it.
If you have a dedicated IPv4 address, those behind NAT and CGNAT face significant throttling and false positive blocking. It's been made worse by scraper botnets.
Creating an IPng was always going to be complicated:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
IPv6 got some real traction in the last decade. From around 10% adoption up to 50%. It's not dead, like many are claiming. It works fine, just keep implementing it.
Reddit shadowbanned me multiple times for either absurd or political reasons, but my ISP used to assign dynamic IPv4 addresses, so I could easily create a new account. Then it switched to IPv6 with a static address, and now I can't create new Reddit accounts anymore.
First impression: Poland stronk. Even Czechia strong. Charles IV.'s realm restored. Russia in shambles, not a very efficient conqueror of the address space. And the glory of Rome restored, with pitiful Constantinople looking at their backs from afar.
Second impression: Morocco, Kenya, Egypt and South Africa as the African heavy-weights. Corresponds to what I know.
Third impression: the real bosses are Taiwan and South Korea - just wow.
Either I've lost it, or there are other countries there that are bigger losers than the DRC. North Korea says it is 1069.6 times smaller, Greenland says it is 1507.8 times smaller, etc.
Hi, I’m helping a hospital in Buenos Aires that has lost their IPv4 due to their ISP moving to CGNAT, putting their on prem imaging servers offline for 7 days. (it’s ok for us though, we have a backup failover isp)
Might have to do something horrible like:
- setup an ipv4 tunnel, which will require hacking a VPN to allow TCP listening, and routing connections to some external proxy with a dedicated static ipv4 address
- or do some modem router level nat port forwarding, and use a ddns to avoid ip changes breaking stuff. but that won’t work probably since public ip is shared
will investigate the isp to see if they are truly short in ipv4 or if they are just moving clients off them in order to sell them to higher bidders and plans, which is likely since I’ve been upsold into optic fiber, static ip surcharge, sd-wan, dedicated connection so far
if you have any advice or RIR contacts (or an ipv4 block to donate, invest or sell), I’d be thankful, my email is in my profile
Ran across a comment a while on "IPv6 math":
* Via: https://news.ycombinator.com/item?id=28326806#unv_28331245I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.
Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1
And then we dish out all the new address space. You would get the network providers to handle address conversion until software and hardware has been updated. Because all the existing addresses are reserved in the new set, it doesn’t affect them.
Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
> backwards compatible with existing hardware/software
Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long. They expect packets to have a 4 byte source address at offset 12 in the header, then a 4 byte destination address at offset 16. Everything breaks if you try to give them a header with an 8 byte source address at offset 12 and an 8 byte destination address at offset 20.
> Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long.
As does DNS.
"A" records are fixed at 32 bits, so you have to add a new record type and update all DNS software, plus user-space API/library code and data structures to ask for and store the new record type.
Just like IPv6.
There is no "just" adding more addresses: whatever scheme anyone comes up with it's the same amount of work as IPv6.
* https://github.com/becarpenter/misc/blob/main/why6why.md
There is barely any legacy hardware/software that doesn't work with IPv6. It's just not an issue.
Dual-stack is also the default, and CG-NAT exists as a fallback. For IPv6 only websites there is still the option to use a HTTP proxy.
This is all the bad parts of ipv6 with none of the good parts...
You still need to have routers, clients, and absolutely everything to understand the new scheme to use those new addresses.
Not using hex is a plus I guess?
Computers use binary. Hex is a human convenience. For anyone in computers hex is much better than decimal for obvious reasons. For anybody not in computers hex makes no sense and I'd need weeks of math lectures (which they wouldn't do the homework for and thus fail) to explain it.
You're welcome to not use hex. For either addressing scheme.
And vice-versa for decimal on ipv6 if desired, I guess?
How does 192.168.0.1 talk to 192.0.0.0.0.168.0.1? Like, literally, how does it make a packet with that destination address?
The entire ipv4 space is already a subset of ipv6, by the way. e.g. ::ffff:0:0/96 or 64:ff9b::/96. v6 devices can already talk to v4. The problem is the ipv6 space is obviously not a subset of ipv4, so v4 doesn't have a clean way to talk to v6.
Hey, if you want to add OAuth and JWT to that idea for some reason, boy do I have an RFC for you https://www.ietf.org/archive/id/draft-thain-ipv8-00.html
This reminds me of the following XKCD:
https://xkcd.com/927/
This seems achievable if you can figure out how to fit 64-bits into 32. ;)
You just drop the top half. Or xor it? That'd make for some nice traffic-pattern art ;)
Now the reason this doesn't work is that the address length is not encoded, so if you make the address longer, no one knows about it and they [routers and destinations] just assume the wrong address and send it on or discard the frame
Kids these days can fit 64-bits into a 3-bit hole, and if you squint hard enough it still sounds like a robot. Amazing times, I tell you.
>Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1
How is this different from ::192.168.0.1? :)
That's literally what ipv6 does.
> I still think we should just extend the length of IPv4. In my proposed system, existing addresses would become a subnet of the new set.
There is no "just" extending the address length:
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
So you also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
You can do this in IPv6
That was kinda the way IPv5 proposed to handle it.
But the big big problem isn't windows/Linux/mac. Writing drivers for those are "easy".
The problem lies in all the networking gear speaks only IPv4 and/or 6. LLM assisted hacks can get into maintenance areas, but these devices are also built to support the least amount of things. Like, there may not be enough ram or storage to even run it.
And 20 years in, you see how well IPv6 has taken off :eyeroll:
And even on my network, I disabled IPv6. My upstream ISP is doing something that makes '6 unstable, but '4 is fine. And I find most network engineers don't have to maintain '6, so they never really learn it.
The fact that we have yet to fully deprecate IPv4 should be considered a great failure in the tech industry's competence.
Well the migration from IPv4 to IPv6 is probably less important and less impactful than climate change, and let's check the score on that...
:grimace:
Then again, given some even failed to adopt the metric system ...
Also, that same tech industry has shown remarcable competence in working around IPv4's limitations.
Why? It was designed and implemented by competent people and continues to work today.
If you have a dedicated IPv4 address, those behind NAT and CGNAT face significant throttling and false positive blocking. It's been made worse by scraper botnets.
Not enough supply/demand. AWS charge like $0.005/hr per IPv4 address
IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
It's actually a blessing for some, what would drive a company holding such a large capital of IPs to make it lose value by supporting IPv6?
No, backwards compatibility is competence.
> No, backwards compatibility is competence.
Creating an IPng was always going to be complicated:
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
Here are the criteria for what the IETF was looking for in an IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
Here are the candidates that were floating around at the time, and the reason why the winner was chosen:
* https://datatracker.ietf.org/doc/html/rfc1752
IPv6 got some real traction in the last decade. From around 10% adoption up to 50%. It's not dead, like many are claiming. It works fine, just keep implementing it.
Reddit shadowbanned me multiple times for either absurd or political reasons, but my ISP used to assign dynamic IPv4 addresses, so I could easily create a new account. Then it switched to IPv6 with a static address, and now I can't create new Reddit accounts anymore.
Hopefully you mean a static prefix, a static address would be an abomination from an ISP in IPv6!
FWIW I get the most hilarious spam and strangest scanners from Netherlands.
The elephant in the room: I didn't check the other mammoths, but e.g. Amazon has 4.4% of all ipv4 addresses.
They have more than 4.4% of all servers so none of this is unexpected.
Population would make more sense.
I'd be interested to see how this compares to the same scaling procedure, but by population. Essentially seeing what the IPv4-per-capita is.
I like how Hawaii migrates to California and Egpyt yeets itself into the Indian ocean. Quality animation that instills confidence in accuracy!
Good to see the Dutch were able to seize a lot of blocks from the sea!
It's what we do ;). I'll never forget my visit to the Delta Werken, 35 years ago? Remove our dikes, boom, half the country gone.
Anyway, the Netherlands also seems to be an attractive place to build datacenters.
What an interesting critter the UK is in terms of its shape
Now this is an interesting map.
First impression: Poland stronk. Even Czechia strong. Charles IV.'s realm restored. Russia in shambles, not a very efficient conqueror of the address space. And the glory of Rome restored, with pitiful Constantinople looking at their backs from afar.
Second impression: Morocco, Kenya, Egypt and South Africa as the African heavy-weights. Corresponds to what I know.
Third impression: the real bosses are Taiwan and South Korea - just wow.
As an Italian, I'm astonished by Italy.
Either I've lost it, or there are other countries there that are bigger losers than the DRC. North Korea says it is 1069.6 times smaller, Greenland says it is 1507.8 times smaller, etc.
> Tables include countries with at least 100,000 IPv4 addresses and 20,000 km² of land.
> Either I've lost it
You haven't lost your marbles, this looks like straight Claude slop, just look at the fonts.
Hi, I’m helping a hospital in Buenos Aires that has lost their IPv4 due to their ISP moving to CGNAT, putting their on prem imaging servers offline for 7 days. (it’s ok for us though, we have a backup failover isp)
Might have to do something horrible like:
- setup an ipv4 tunnel, which will require hacking a VPN to allow TCP listening, and routing connections to some external proxy with a dedicated static ipv4 address
- or do some modem router level nat port forwarding, and use a ddns to avoid ip changes breaking stuff. but that won’t work probably since public ip is shared
will investigate the isp to see if they are truly short in ipv4 or if they are just moving clients off them in order to sell them to higher bidders and plans, which is likely since I’ve been upsold into optic fiber, static ip surcharge, sd-wan, dedicated connection so far
if you have any advice or RIR contacts (or an ipv4 block to donate, invest or sell), I’d be thankful, my email is in my profile
Interesting.