Google sees 70-80% from some countries:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
:grimace:
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.
You can't.
Anything longer, even if it's just 1 bit, would require a new IP version.
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.
* https://datatracker.ietf.org/doc/html/rfc1671
For anyone curious as to the decision-making process, 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:
Also, that same tech industry has shown remarcable competence in working around IPv4's limitations.
Austria-Hungary adopted the metric system in the 1870s. Back then: no cars, no highways, no speeding laws etc. Oxen-drawn wagons in the countryside were not built to a precise spec.
Only the railway, the architects and the artillery had to really switch. Ordinary people would still ask the grocer for half a pound of ham in the 1930s.
USA in the 1970s would have to remeasure all the land communications etc., or end up with a weird hybrid like the UK.
WHat we have in IPv4 and IPv6 is the weird UK-like hybrid...
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.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
* So (4x10¹¹)x(2x10¹²) = 8x10²³ stars in the universe.
* Size of IPv6 address space: 3.4x10³⁸
* Find the ratio between addresses and stars: 3.4x10³⁸ / 8x10²³
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study":
Much of the IPv6 rollout challenges have been centered around routing and security. It's great that I can personally have (in theory) more IP addresses than I would ever practically need (and I am saying this as someone with 200 IP endpoints just in my house), but if I can't easily manage and control access much of the theoretical benefit goes away.
IMO, IPv6 solved the address pool size part of the issue, but it made managing the v4 to v6 transition very painful.
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.
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.
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 is the same amount of work as IPv6.
IIRC something like that was considered when IPv6 was first being designed, be deemed insufficient for the long-term future. 64-bits is thought to be enough to stave off address starvation though, which is why IPv6 address ranges are usually assigned as /64s (my homer link has a /48 range should I wish to use it all!), so I can see your reasoning on that level.
The entire ipv4 space is already mapped to reserved subsets of ipv6, by the way. e.g. ::ffff:0:0/96 (i.e. 0.0.0.0.0.0.0.0.0.0.255.255.w.x.y.z) 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 or even about v6.
You still need to have routers, clients, and absolutely everything to understand the new scheme to use those new addresses.
Or octal:
* https://networkingtoolbox.net/ip-address-convertor/represent...
Most of the time, this results in people thinking the big problems are one set like "if only there was a way to translate" while the real remaining problems are another set like "and how do you get people to want to transition when it works well enough for those clients in the translated state".
Yeah, about that part. This is a "now draw the rest of the fucking owl" type of idea.
It turns out when you ignore the hardest part of the problem, you can always make a good-looking proposal!
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
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.
That being said, we should take the time to understand why IPv4 is still hanging around when IPv6 has been around since before most people got internet access. What is really holding IPv6 back?
How is this different from ::192.168.0.1? :)
Of all the sins of IPv6, its tied between using ':' as the separator, and the god awful '::' "just skip writing the address because we made them too fucking big lol"
Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
The protocol chosen for IPng, SIPP, did actually have "only" 64 bits, but this was deemed not enough as folks did not want to have to worry about running out again (amongst other reasons), and so tweaked it to have a fixed 128 bits:
* https://datatracker.ietf.org/doc/html/rfc1752
SIPP originally was variable-length capable, but it was decided fixed-length was better (e.g., for hardware like ASICs).
> Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
For the record: IPv6 gives 10¹⁷ addresses per mm²; in terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
I woulda thought 18 quintillion would've been enough addresses for the next century or two but good thing we locked in all this extra data we throw away with a '::'.
I'm sure it was all well considered by intelligent people, but it was still a dumb decision.
Fine, let's change the question.
Without counting, how many zeroes are there in 192.168.0.0.0.0.0.1?
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.
* 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.
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.
the thing is that it does require a switch similar to ipv6. but maybe there’s a subnet that maps 1 to 1 with the legacy block?
something like this could theoretically be pinned onto ipv6 AND anyone could do it, just select a 98 bit prefix you own, and the rest of the 32 bits you can map to ipv4.
phase -1 could be tunneling traffic through a single zone proxy which would be inefficient and is purely conceptual
phase 0 would be the same, but with an anycast ipv6,same ip that resolves differently based on location, like 8.8.8.8
phase 1 would be the mapping prefix to ipv4 (and viceversa?) being distributed to the routing tables like, which could be done via application logic (most efficient), or via some deep arcane isp routing conf files, or just a hell of a lot of routing table entries for each ipv4 but duplicated, possibly programatically controlled by an application that generates router table files as a target, thus avoiding desyncs and effectively becoming the first option of application level implementation
maybe something like this already exists though
of course it’s horrible hacking (as hacking in the non crime sense often is), but it allows for a purely technical solution to issues of political and administrative nature.. which is all the rage nowadays
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.
You haven't lost your marbles, this looks like straight Claude slop, just look at the fonts.
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.
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
I don't know much about your imaging servers: Do they accept incoming https connections, or is it some other kind of TCP or UDP protocol? Assuming it's https, why do you need to stick with IPv4?
> 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)
Two more things:
1: If you require IPv4, that needs to be part of the contract with your ISP. If they just arbitrarily turned you off, it means that you didn't contract for the services you thought you had.
2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?
With IPv4 most ISPs only rotate IPs on new connections (router restart). But my old home internet even stayed on the same ipv4 for years. Only if I shut down the router for a longer time it got a fresh ipv4 assigned.
So it's an implementation detail, not a technical limitation. Not rotating the prefix is a bad implementation.
China: 358M
Both countries have roughly the same population. The IPv4 problem has been swept under the rug with CGNAT and a normal person doesn't even notice it. But it sucks. Forget having a dedicated IP, even on a broadband connection, you don't get a public IP that's truly yours. According to IPInfo[1], there are around 1,000 users sharing my IP. I get flagged for malicious activity, and online gaming is impossible without a Tailscale relay.
Of course, much of this comes down to the bad luck (+ policies) of developing late, when most IPv4 blocks had already been allocated. But it's pretty unfair how US DoD, Apple, Ford, and others [1] are sitting on enormous IPv4 blocks they'll probably never fully use, and may never sell. Meanwhile I am sharing a single public IP with a thousand strangers.
[1]: https://ipinfo.io/223.233.77.184
[2]: https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
But if you are living in a Western country, then you are probably blessed with CGNAT-free residential internet.
Some carriers in my country have recently started to share the same IP between 4 customers, each having a port range (1-16363, ...), but you can always request a full IP for free.
I, unfortunately, have been on CGNATed residential internet since 2016, though I used to still get a public IP on request (they stopped doing that though.) I live in South East Asia, for context.
Without IPv6 my only choice would have been relying on a centralized service like Zerotier and Tailscale.
Me as somewhat of a nerd, even doubt if I need a public IP, seeing how cyber security is looking today.