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.
> But it's pretty unfair how US DoD, Apple, Ford, and others [1] are sitting on enormous IPv4 blocks
Maybe Apple and Ford, but it's more than fair that DoD has large blocks since they created ipv4 to connect themselves to other networks. It was only 10 years ago that the US government decided to give up control of IANA.
I'd love to do that, if my ISP would provide me an IPv6 address. Windstream doesn't provide IPv6s. They did a trial a few years ago rolling it out and then undid it.
It's crazy I can get fiber to my house in the US, but not IPv6.
I was doing this back when I had BT in London, my internet speed back then was pretty abysmal and it would randomly drop routes- ironically this tunnel actually improved my internet (because of the routes not being dropped, not the speed).
Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.
https://tunnelbroker.net/
It's something I've only recently been made aware of as well. Shocked we're not seeing more push for ipv6 everywhere given that it sounds common enough. If I don't have an IP address, I'm not getting the Internet I'm paying for; I'm getting access to a network that happens to itself have a connection to the Internet. Not unlike some of the BBS's in the early 90s which had Internet access -- I might be dialed in, but that didn't mean my computer itself was on the Internet.
I don't think it's sarcasm, I didn't know this was a thing either! At first, I thought OP was writing about their mobile connection.
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.
That explains a lot of the sentiments I've seen on HN then...
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.
My current setup is CGNAT on 5G WAN (T-Mobile US), which obviously doesn't open public ports besides needed NAT.
Worse is I have IPv6 connectivity for devices, yet still no open ports available, so no serving available. And I only receive a /64 so no delegation available through router.
So now it's Hurricane Electric tunnel to their nearest (in my city) hosted node for IPv6 and a prepaid 50 USD/year node (technically x2 since I wanted a backup to play around with) for IPv4 port forwarding.
Both options are acceptable because the needed infra is close by in the largest metroplex in Texas, it just sucks to have to do all this extra work to replicate what I could do with a dial-up ISP.
I'll say this - having LLM assistants handle the nasty routing and firewall rules needed to make this hodge podge work without needing to be a network engineer has been very helpful.
In Sweden CGNAT was not a thing for a long time, the large incumbents still have their huge blocks of IPs so its "just" go to them if you want a pulic IP. Apparently smaller ISPs do use CGNAT, so its fairly common.
Me as somewhat of a nerd, even doubt if I need a public IP, seeing how cyber security is looking today.
Most people don't care about a private IP, which is why they cost about $20-$25 each (which would be about $2 a year to finance). I've used Airtel in the past and they certainly offer a dedicated IP. Currently I'm with TATA and Vodafone in India
Indeed a shared IP is arguably a benefit in that it makes fingerprinting harder.
If your ISP had customers who were interested it could spend $150k on a /19 block giving 8000 IPv4 addresses and charge an extra ₹100 a month for them and after two years it would be in profit.
In fact I think Jio and Airtel offer static IPs for residential use for something like ₹300 a month, which given how cheap IPv4 addresses are is a massive money spinner, but I have't spoken to anyone living in India about ISPs for a couple of years.
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.
I keep IPv4 off on a media computer all the time out of curiosity. IPv6-only is still unusable because only about 5% to 10% of top sites that I find during a Google Search work. It's almost guaranteed that a website will not load on all the top results.
So even if it's true 50% of clients support IPv6, only about 5% to 10% of website hosts do.
Sure a person can do a dual-stack setup or do some IPv4-IPv6 translation, but seriously IPv6-only should be plug-and-play by now.
Cloud providers and hosters seem to have the least interest in implementing IPv6. Sitting on a huge supply of IPv4 addresses gives them a competitive advantage. So they try to disable IPv6 as a default.
one is close to hundreds of millions in cost and with likeminded stakeholders. the other is hundreds of trillions in costs with the entire human population as stakeholders.
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.
This is quite similar situation indeed. It was once easier to adopt the metric system when the infrastructure was not yet as developed around the previous ones.
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...
It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.
I'm Australian and the only things measured in imperial units is babies (stones? But I think younger parents now use metric, but my parents only know baby weights in stones), beer (pints, but not the same as overseas I think, also it can vary by state), certain types of land units ("acerage" is a common land plot size) and height (feet and inches, for some reason people don't understand it in metric)
These are all customary usage so I'd say we are completely switched over, we couldn't tell you generally what these units look like outside of "how big is a baby" or "how tall is that person" or "is my beer large or small" really.
It's the hobbyists who LARP as network engineers, and that end users and hiring managers can't tell the difference, who are holding everyone back.
Anyone who doesn't by default set up IPv6-only networks by default with NAT64 and DNS64, or who present any notion that IPv4 is somehow "okay", shouldn't have a job anywhere, not even an entry-level desktop support job.
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.
This is very valuable, but not sure if you think it contradicts my comment.
I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.
I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.
In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.
> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
I have seen people suggesting this before, but it's problematic for a few reasons:
- If you are managing the 4to6 mappings manually, it's obviously not going to be scalable. Just to give people an idea, websites nowadays can connect to 10+ IPs in a single page due to CDN load balancing and stuff.
- If you are handling the mappings automatically, such as by monitoring DNS queries and creating dynamic mappings based on that, the issues become more insidious: applications with hardcoded IP literals would fail without an obvious reason.
Ran across a comment a while ago on some fun "IPv6 math":
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.
* 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":
But it is really about more than just the available pool of addresses.
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.
Comparing land area to IP address assignments is one of the sillier visualizations I've ever seen. I can't imagine what this is intending to convey. Should Siberia have more IP addresses than all of Europe?
Perhaps I am being uncharitable, but I don't see what's interesting about it at all. Visualizing IPv4 against population (or maybe GDP) would have been far more illuminating.
I’m hoping with RE everything, for at least consumer IOT products we’ll get to a point where we can just get rid of a lot of the need for ipv4 for home.
What’s left are just apps and devices that people don’t wanna change out but are probably pwnd and I don’t think are gonna get updates because the teams that wrote the software moved on and the companies don’t wanna keep spending on sustaining.
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 is the same amount of work as IPv6.
The set of all ip hardware and software is much much larger than just what currently exists, as it includes all hardware and software that is yet to be produced. Said another way, it’s a foolish consistency.
That would still constitute an entirely new system, just one that looks very like the previous one. So much code and other infrastructure (routing tables in hardware etc.) relies on IPv4 addresses being 32-bits not 64 and that would all need to change, complete with extra new stuff being added for that translation layer while both are in operation (which would end up being near permanent, people will find ways to keep the old stuff running as long as they can). I expect that this new scheme would just become a new version of CGNAT, “Global NAT” perhaps, with the same problems that adds.
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.
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.
Honestly IPv4 addresses should always have been formatted in hex, like FF 00 00 69, with whatever delimiter. Would make it trivial to write directly as a 32-bit int, and parsing and formatting a string would also be cheaper. And you could have funny blocks like CAFE.0.0.
You can indeed make good use of those funny names in IPv6. If your /64 or /56 prefix is $prefix you can assign your coffee pot to $prefix::cafe or maybe keep it just fe80::cafe if you only want link local access to your coffee pot.
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 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.
Lots have thoughts on this, few take the time to review the existing implementations/proposals and explain both how it is their approach doesn't run in to the same problems as well as the problems their proposal still doesn't resolve.
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".
You could just use something like fd00:dead:beef::192:168:0:1 for your internal IPv4 host(s). Basically do a human-readable mapping of your IPv4 LAN IPs into a IPv6 private space. Now you only need to remember the ULA prefix and then can continue to use your IPv4 just with colons instead dots. Problem solved. :-)
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 can read one at a glance and the other makes me fill in the blanks myself after having to count how many invisible blanks I need to fill in.
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.
> I can read one at a glance and the other makes me fill in the blanks myself after having to count how many invisible blanks I need to fill in.
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:
You're right, my 100B per square millimeter undershot by six orders of magnitude.
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.
What problem does 128 bits cause? Just that you don't like :: for a run of 0s? Do you need to care about ipv6 addresses in your work? Because I can tell you that when I'm trying to design simple, efficient routing and firewall rules (with e.g. 100s of thousands of endpoints across different datacenters on different continents), it's really nice to be able to subnet things the way I'd like instead of the way I must to squeeze things into the space I have, and not have to worry about backing myself into a corner later because I gave the wrong number of bits to various dimensions. And worst case, if you somehow got it wrong, just give yourself an entire /64 or more to try again, with it being compatible with what you did (no need to do a phased migration that requires reclamation as you go along).
Like I only tangentially interact with this stuff, but I can't imagine how a network operator wouldn't prefer we live in an all ipv6 world.
> 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.
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 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?
I recall something like this, what did you call this? ipv8?
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
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.
There is nothing that makes sense. The world population is about twice the total number of IPv4 addresses total. Many people own more than one device, and there are good networking reasons that you want most of the possible addresses on any network segment unused. There is no way to solve all of those problems at the same time and so nothing make sense when we are talking about IPv4 and it never will.
I initially read the "As" in the "As land" label as "land of plural letter A". Which I understood as the land of DNS A records, which seemed like a whimsical yet fitting name.
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.
A lot of European cloud machines geolocate to the Netherlands. A lot of AWS instances use IPs from the Netherlands, although they are running somewhere else. No idea why, but it's a pattern I've observed many times. Get some cloud instance in Europe and it's often going to be geolocated to Amsterdam.
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.
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
The first thing you need to ask is: Why do you need IPv4?
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?
> 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?
Yes
>why do you need to stick with IPv4?
To support devices and routes that do not have ipv6 support?
>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.
That is correct in principle. Although, in the absence of a contract, if a service has been provided for a long time in one way, I'd say there's an argument for breach of contract when that way changes for the worst.
Another argument for breach of contract, which can work jointly with the previous, are industry standards, as far as they define the terms that are implied by common words like "internet connection".
Finally, there's the specifications themselves, since the service is billed as "internet", one can refer to the Internet Protocol Specification, although if they do offer IPv6, that might be reasonably considered a substitute, it is a material change that was not agreed to originally (this being a pre IPv6 contract). That said, an IPv4 with a local address might technically still be defined as internet, what is broken in this case is TCP, not the IP, although by lacking a public IP address, TCP is broken via an IP protocol failure, so there's an argument that something is being sold as Internet but it isn't really internet, there's no written contract necessary, the term used to describe the product creates the contract in the same way that selling a carton labeled Milk would create a contract based on milk coming from mammaries of a domestic mammal, and not pressed Soy Juice with artificial coloring.
>2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?
I'm open to proposals to moving IPv6, I'm not content with having that be forced and removing it from people and institutions, if there's a shortage, then that means no new IP addresses can be issued, why are we normalizing the removal of IPv4 addresses? Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?
The main issue with IPv6 seems to be IPv6 proponents that try to kill IPv4, no one will migrate if you force them to, if you propose, we will consider.
Have you noted that in the mainline Linux build config file, the option to enable IPv4 functionality is CONFIG_LEGACY_IP= ?
I can tell you that in cicd for production Linux systems today, we have
CONFIG_LEGACY_IP=""
which in a Linux build config file means "do not include this in the build".
_
What might work well for your organization is ZeroTier which will make you immune to what any ISPs do. The downside is your organization would be dependent on ZeroTier, but ZeroTier is much less likely to screw you over than any ISP.
https://www.zerotier.com/
_
I appreciate your speculation on the principles of contract law. Like you, I believe those principles should be upheld and I believe in morality. If you lived under a monarchy and I were of the monarch, I would cross-examine your ISP in public and solve your problem in minutes. I would also on occasion take someone to the side of the road and chop off their head in front of the entire village, and everyone would know on a visceral level they are all much better off with someone taking out the trash now and then.
But, as many technical workers know, the contract stuff takes months or years to resolve, and technical issues involving IP addresses are best worked around with technical approaches.
_
What I would suggest your network team (you and whoever) do in your shoes is:
- set up NAT64 and DNS64 at the edges of subnets that contain devices that don't do IPv6 properly, because if these devices do not have updates to do IPv6 properly then they are broken in a fundamental way, and a workaround is necessary;
- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team. In IPv6, multiple addresses on a network interface issued by the local network (SLAAC or DHCPv6) is the norm rather than the exception (requires userspace tooling in IPv4, DHCP doesn't have this functionality), so leverage this advantage;
- use IPv6 AH (authenticated headers) wherever possible;
- because in an ideal world, ISPs would behave consistently and IPv6 GUA addresses would always be stable, but we aren't living in an ideal world, so be ready to update your internal DNS to drop AAAA records containing IPv6 GUA that an upstream ISP fumbled;
- or, if you have the internal resources, register your own AS and command your own official block of IPv6 addresses;
- use a combination of OpenTOFU (Terraform) and Salt or Ansible, all versioned with Git, be very strict with your team about versioning with Git, to manage everything, and use
terraform plan -detailed-exitcode
and Salt or Ansible equivalents for continuous monitoring;
- move userspace services to Podman where possible.
Personally I like Salt. I know Ansible is more popular out there with more inertia.
_
>> why are we normalizing the removal of IPv4 addresses?
This was normalized a long time ago actually. "The future is already here, it's just not evenly distributed".
You and I are total strangers on different corners of the globe. You may not like what you're about to read, but it's better that you get a hint where the wind is blowing sooner than not.
If my team were consulting with your organization's execs and we caught a hint that the existing internal resources were not already proactively staying current with internet protocol (which is IPv6), we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.
Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.
IPv6 only seems more complicated if you still need to unlearn IPv4. IPv6 does have a steeper learning curve, but once that learning curve is overcome, IPv6 is actually much simpler than IPv4. More people than not don't like reading RFCs, but professionals do slowly read RFCs on their own time.
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.
Most consumer ISPs regularly rotate the prefix. IPv6 has proper support for that and can keep connections on the old and new prefix alive for a while in parallel.
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.
India: 47M
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 it's pretty unfair how US DoD, Apple, Ford, and others [1] are sitting on enormous IPv4 blocks
Maybe Apple and Ford, but it's more than fair that DoD has large blocks since they created ipv4 to connect themselves to other networks. It was only 10 years ago that the US government decided to give up control of IANA.
s/IP/IPv4/g
Configuring my OS to prefer IPv6 addresses of DNS responses significantly reduced the number of web captchas I see (on NAT444 with native IPv6).
IPv4 is old and broken, use IPv6.
I'd love to do that, if my ISP would provide me an IPv6 address. Windstream doesn't provide IPv6s. They did a trial a few years ago rolling it out and then undid it.
It's crazy I can get fiber to my house in the US, but not IPv6.
iirc, hurricane electric was offering IPv6 via tunnelling somehow.
https://tunnelbroker.net
I was doing this back when I had BT in London, my internet speed back then was pretty abysmal and it would randomly drop routes- ironically this tunnel actually improved my internet (because of the routes not being dropped, not the speed).
There is no need for that, every modern OS prefer IPv6 over IPv4
Depends on the application, a web-browser that implements Happy Eyeballs protocol may prefer IPv4 if the IPv6 latency is higher.
> "India: 47M
> "China: 358M
> "Both countries have roughly the same population"
To save anyone else curious from looking it up - their populations are about 1.4 billion (1400 million) each.
Wow I didn’t know CGNAT was a thing for home users.
It's something I've only recently been made aware of as well. Shocked we're not seeing more push for ipv6 everywhere given that it sounds common enough. If I don't have an IP address, I'm not getting the Internet I'm paying for; I'm getting access to a network that happens to itself have a connection to the Internet. Not unlike some of the BBS's in the early 90s which had Internet access -- I might be dialed in, but that didn't mean my computer itself was on the Internet.
I can't tell if this is sarcasm, Poe's law and all.
But if you are living in a Western country, then you are probably blessed with CGNAT-free residential internet.
I don't think it's sarcasm, I didn't know this was a thing either! At first, I thought OP was writing about their mobile connection.
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.
That explains a lot of the sentiments I've seen on HN then...
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.
My current setup is CGNAT on 5G WAN (T-Mobile US), which obviously doesn't open public ports besides needed NAT.
Worse is I have IPv6 connectivity for devices, yet still no open ports available, so no serving available. And I only receive a /64 so no delegation available through router.
So now it's Hurricane Electric tunnel to their nearest (in my city) hosted node for IPv6 and a prepaid 50 USD/year node (technically x2 since I wanted a backup to play around with) for IPv4 port forwarding.
Both options are acceptable because the needed infra is close by in the largest metroplex in Texas, it just sucks to have to do all this extra work to replicate what I could do with a dial-up ISP.
I'll say this - having LLM assistants handle the nasty routing and firewall rules needed to make this hodge podge work without needing to be a network engineer has been very helpful.
In Sweden CGNAT was not a thing for a long time, the large incumbents still have their huge blocks of IPs so its "just" go to them if you want a pulic IP. Apparently smaller ISPs do use CGNAT, so its fairly common.
Me as somewhat of a nerd, even doubt if I need a public IP, seeing how cyber security is looking today.
A lot of the original /8 holders have sold off chunks to AWS and other cloud providers.
Most people don't care about a private IP, which is why they cost about $20-$25 each (which would be about $2 a year to finance). I've used Airtel in the past and they certainly offer a dedicated IP. Currently I'm with TATA and Vodafone in India
Indeed a shared IP is arguably a benefit in that it makes fingerprinting harder.
If your ISP had customers who were interested it could spend $150k on a /19 block giving 8000 IPv4 addresses and charge an extra ₹100 a month for them and after two years it would be in profit.
In fact I think Jio and Airtel offer static IPs for residential use for something like ₹300 a month, which given how cheap IPv4 addresses are is a massive money spinner, but I have't spoken to anyone living in India about ISPs for a couple of years.
End users do notice CGNAT when their internet voice/video calls keep dropping for no apparent reason.
Yep. And, insult to injury, the /4's and /8's of little-unused IPv4 special-use addresses - https://en.wikipedia.org/wiki/Ipv4#Special-use_addresses
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.
I keep IPv4 off on a media computer all the time out of curiosity. IPv6-only is still unusable because only about 5% to 10% of top sites that I find during a Google Search work. It's almost guaranteed that a website will not load on all the top results.
So even if it's true 50% of clients support IPv6, only about 5% to 10% of website hosts do.
Sure a person can do a dual-stack setup or do some IPv4-IPv6 translation, but seriously IPv6-only should be plug-and-play by now.
Cloud providers and hosters seem to have the least interest in implementing IPv6. Sitting on a huge supply of IPv4 addresses gives them a competitive advantage. So they try to disable IPv6 as a default.
> From around 10% adoption up to 50%.
Google sees 70-80% from some countries:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Sure, around 50% is a worldwide estimate.
And Windows 11 now supports CLAT.
But it's not really useful until it has critical mass at say 80 or 90%.
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:
but climate change is not up to the tech industry
one is close to hundreds of millions in cost and with likeminded stakeholders. the other is hundreds of trillions in costs with the entire human population as stakeholders.
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.
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?
Not enough supply/demand. AWS charge like $0.005/hr per IPv4 address
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.
This is quite similar situation indeed. It was once easier to adopt the metric system when the infrastructure was not yet as developed around the previous ones.
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...
Australia managed to do a complete† change over starting in the 1970s:
* https://en.wikipedia.org/wiki/Metrication_in_Australia
It's going to take decades, mostly waiting for the non-metric folks to die off probably and the raised-on-metric folks to grow up, but if you don't start you'll never finish.
† Can Aussie HNer confirm?
I'm Australian and the only things measured in imperial units is babies (stones? But I think younger parents now use metric, but my parents only know baby weights in stones), beer (pints, but not the same as overseas I think, also it can vary by state), certain types of land units ("acerage" is a common land plot size) and height (feet and inches, for some reason people don't understand it in metric)
These are all customary usage so I'd say we are completely switched over, we couldn't tell you generally what these units look like outside of "how big is a baby" or "how tall is that person" or "is my beer large or small" really.
It's the hobbyists who LARP as network engineers, and that end users and hiring managers can't tell the difference, who are holding everyone back.
Anyone who doesn't by default set up IPv6-only networks by default with NAT64 and DNS64, or who present any notion that IPv4 is somehow "okay", shouldn't have a job anywhere, not even an entry-level desktop support job.
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
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:
* https://datatracker.ietf.org/doc/html/rfc1752
This is very valuable, but not sure if you think it contradicts my comment.
I'm not saying that IPv6 is incompetent, or that IPv6 implementations break backward compatibility, or that the problem can be solved without breaking bc.
I'm saying that while IPv6 breaks bc itself, dual stack does not, and even full migrations can maintain bc or gracefully degraded.
In essence, not all implementations IPv6 are good, and not all migrations from IPv4 are responsible, if someone is blindly team IPv6 or blindly team IPv4 in general there's a lack of nuance.
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.
> IPv4 is perfectly and objectively fine on internal networks. IPv6 is overkill and way too complicated for most.
Unless there's a merger/acquisition and the two companies both use 10.0.0.0.
Most home networks use 192.168, and so you can't use that in corporate environments, because the WFH people who VPN in could then have routing snags between local and remote locations.
Also, in your VPN software be sure to perhaps not use 172 addresses (like my previous job did), as some of those ranges are used by Docker by default, and so you can cause issues for developers.
But other than that IPv4 RFC 1918 is not complicated at all…
Alternatively, IPv4 simply does not scale effectively on the LAN, whereas IPv6 allows much simpler addressing and routing topologies. Simple = good.
You can't selectively use IPv6 in the WAN and IPv4 in the LAN.
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.
You can run a 4to6 NAT, where specific v6 addresses (the ones you’re talking to) are aliased to reserved v4 addresses out of the PUA.
I have seen people suggesting this before, but it's problematic for a few reasons:
- If you are managing the 4to6 mappings manually, it's obviously not going to be scalable. Just to give people an idea, websites nowadays can connect to 10+ IPs in a single page due to CDN load balancing and stuff.
- If you are handling the mappings automatically, such as by monitoring DNS queries and creating dynamic mappings based on that, the issues become more insidious: applications with hardcoded IP literals would fail without an obvious reason.
Ran across a comment a while ago on some fun "IPv6 math":
* Via: https://news.ycombinator.com/item?id=28326806#unv_28331245A 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":
* https://www.youtube.com/watch?v=7Tnh4upTOC4
But it is really about more than just the available pool of addresses.
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.
> IMO, IPv6 solved the address pool size part of the issue, but it made managing the v4 to v6 transition very painful.
There is no easy way to transition from IPv4 to any kind of IPng; see my other comment:
* https://news.ycombinator.com/item?id=50288091
Comparing land area to IP address assignments is one of the sillier visualizations I've ever seen. I can't imagine what this is intending to convey. Should Siberia have more IP addresses than all of Europe?
It can be interesting to look at without implying that it ought to be evenly distributed by land space.
Perhaps I am being uncharitable, but I don't see what's interesting about it at all. Visualizing IPv4 against population (or maybe GDP) would have been far more illuminating.
I’m hoping with RE everything, for at least consumer IOT products we’ll get to a point where we can just get rid of a lot of the need for ipv4 for home.
What’s left are just apps and devices that people don’t wanna change out but are probably pwnd and I don’t think are gonna get updates because the teams that wrote the software moved on and the companies don’t wanna keep spending on sustaining.
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 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 is the same amount of work as IPv6.
* https://github.com/becarpenter/misc/blob/main/why6why.md
For every complex and difficult problem, someone has an easy, simple and wrong solution. Usually the presence of "just" is a good clue.
The set of all ip hardware and software is much much larger than just what currently exists, as it includes all hardware and software that is yet to be produced. Said another way, it’s a foolish consistency.
I responded to a claim about existing hardware/software.
That would still constitute an entirely new system, just one that looks very like the previous one. So much code and other infrastructure (routing tables in hardware etc.) relies on IPv4 addresses being 32-bits not 64 and that would all need to change, complete with extra new stuff being added for that translation layer while both are in operation (which would end up being near permanent, people will find ways to keep the old stuff running as long as they can). I expect that this new scheme would just become a new version of CGNAT, “Global NAT” perhaps, with the same problems that adds.
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.
128 innit? Otherwise your /64 would have no subnets.
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?
You're welcome to not use hex. For either addressing scheme.
And vice-versa for decimal on ipv6 if desired, I guess?
> And vice-versa for decimal on ipv6 if desired, I guess?
Or octal:
* https://networkingtoolbox.net/ip-address-convertor/represent...
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.
Honestly IPv4 addresses should always have been formatted in hex, like FF 00 00 69, with whatever delimiter. Would make it trivial to write directly as a 32-bit int, and parsing and formatting a string would also be cheaper. And you could have funny blocks like CAFE.0.0.
You can indeed make good use of those funny names in IPv6. If your /64 or /56 prefix is $prefix you can assign your coffee pot to $prefix::cafe or maybe keep it just fe80::cafe if you only want link local access to your coffee pot.
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 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.
Lots have thoughts on this, few take the time to review the existing implementations/proposals and explain both how it is their approach doesn't run in to the same problems as well as the problems their proposal still doesn't resolve.
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".
You could just use something like fd00:dead:beef::192:168:0:1 for your internal IPv4 host(s). Basically do a human-readable mapping of your IPv4 LAN IPs into a IPv6 private space. Now you only need to remember the ULA prefix and then can continue to use your IPv4 just with colons instead dots. Problem solved. :-)
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
> until software and hardware has been updated
Yeah, about that part. This is a "now draw the rest of the fucking owl" type of idea.
It's always the same with those "I hope IPv6 were just IPv4 with more octets" proposals on Hacker News, aka Godwin's law of the Internet Protocol.
It turns out when you ignore the hardest part of the problem, you can always make a good-looking proposal!
This seems achievable if you can figure out how to fit 64-bits into 32. ;)
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.
just put it in the square hole!
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
>Eg 192.168.0.1 becomes 0.0.0.0.192.168.0.1
How is this different from ::192.168.0.1? :)
I can read one at a glance and the other makes me fill in the blanks myself after having to count how many invisible blanks I need to fill in.
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.
> I can read one at a glance and the other makes me fill in the blanks myself after having to count how many invisible blanks I need to fill in.
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.
You're right, my 100B per square millimeter undershot by six orders of magnitude.
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.
What problem does 128 bits cause? Just that you don't like :: for a run of 0s? Do you need to care about ipv6 addresses in your work? Because I can tell you that when I'm trying to design simple, efficient routing and firewall rules (with e.g. 100s of thousands of endpoints across different datacenters on different continents), it's really nice to be able to subnet things the way I'd like instead of the way I must to squeeze things into the space I have, and not have to worry about backing myself into a corner later because I gave the wrong number of bits to various dimensions. And worst case, if you somehow got it wrong, just give yourself an entire /64 or more to try again, with it being compatible with what you did (no need to do a phased migration that requires reclamation as you go along).
Like I only tangentially interact with this stuff, but I can't imagine how a network operator wouldn't prefer we live in an all ipv6 world.
You are telling me ::192.168.0.1 is not immediately visible as 16-4 bytes?
Fine, let's change the question.
Without counting, how many zeroes are there in 192.168.0.0.0.0.0.1?
5
My blog's hosted on either 3106689564 or 42540619367231808600192856535952785520 depending on your addressing scheme.
See, no colons in sight!
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.
> 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.
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.
I believe that was proposed before IPv6.
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?
That's literally what ipv6 does.
You can do this in IPv6
I recall something like this, what did you call this? ipv8?
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
This reminds me of the following XKCD:
https://xkcd.com/927/
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.
This should be scaled by population. would make the India/china numbers more drastic.
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.
Population would make more sense.
There is nothing that makes sense. The world population is about twice the total number of IPv4 addresses total. Many people own more than one device, and there are good networking reasons that you want most of the possible addresses on any network segment unused. There is no way to solve all of those problems at the same time and so nothing make sense when we are talking about IPv4 and it never will.
I initially read the "As" in the "As land" label as "land of plural letter A". Which I understood as the land of DNS A records, which seemed like a whimsical yet fitting name.
Unsurprisingly, the map is very similar to the World Population Density Map: https://luminocity3d.org/WorldPopDen/#3/20.00/10.00
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.
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.
What an interesting critter the UK is in terms of its shape
Meanwhile I’m here carving out a couple of /64s from the /48 block of IPv6 addresses Comcast gave me.
FWIW I get the most hilarious spam and strangest scanners from Netherlands.
A lot of European cloud machines geolocate to the Netherlands. A lot of AWS instances use IPs from the Netherlands, although they are running somewhere else. No idea why, but it's a pattern I've observed many times. Get some cloud instance in Europe and it's often going to be geolocated to Amsterdam.
As an Italian, I'm astonished by Italy.
I like how Hawaii migrates to California and Egpyt yeets itself into the Indian ocean. Quality animation that instills confidence in accuracy!
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.
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
The first thing you need to ask is: Why do you need IPv4?
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?
> 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?
Yes
>why do you need to stick with IPv4?
To support devices and routes that do not have ipv6 support?
>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.
That is correct in principle. Although, in the absence of a contract, if a service has been provided for a long time in one way, I'd say there's an argument for breach of contract when that way changes for the worst.
Another argument for breach of contract, which can work jointly with the previous, are industry standards, as far as they define the terms that are implied by common words like "internet connection".
Finally, there's the specifications themselves, since the service is billed as "internet", one can refer to the Internet Protocol Specification, although if they do offer IPv6, that might be reasonably considered a substitute, it is a material change that was not agreed to originally (this being a pre IPv6 contract). That said, an IPv4 with a local address might technically still be defined as internet, what is broken in this case is TCP, not the IP, although by lacking a public IP address, TCP is broken via an IP protocol failure, so there's an argument that something is being sold as Internet but it isn't really internet, there's no written contract necessary, the term used to describe the product creates the contract in the same way that selling a carton labeled Milk would create a contract based on milk coming from mammaries of a domestic mammal, and not pressed Soy Juice with artificial coloring.
>2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?
I'm open to proposals to moving IPv6, I'm not content with having that be forced and removing it from people and institutions, if there's a shortage, then that means no new IP addresses can be issued, why are we normalizing the removal of IPv4 addresses? Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?
The main issue with IPv6 seems to be IPv6 proponents that try to kill IPv4, no one will migrate if you force them to, if you propose, we will consider.
Have you noted that in the mainline Linux build config file, the option to enable IPv4 functionality is CONFIG_LEGACY_IP= ?
I can tell you that in cicd for production Linux systems today, we have
which in a Linux build config file means "do not include this in the build"._
What might work well for your organization is ZeroTier which will make you immune to what any ISPs do. The downside is your organization would be dependent on ZeroTier, but ZeroTier is much less likely to screw you over than any ISP.
_I appreciate your speculation on the principles of contract law. Like you, I believe those principles should be upheld and I believe in morality. If you lived under a monarchy and I were of the monarch, I would cross-examine your ISP in public and solve your problem in minutes. I would also on occasion take someone to the side of the road and chop off their head in front of the entire village, and everyone would know on a visceral level they are all much better off with someone taking out the trash now and then.
But, as many technical workers know, the contract stuff takes months or years to resolve, and technical issues involving IP addresses are best worked around with technical approaches.
_
What I would suggest your network team (you and whoever) do in your shoes is:
- set up NAT64 and DNS64 at the edges of subnets that contain devices that don't do IPv6 properly, because if these devices do not have updates to do IPv6 properly then they are broken in a fundamental way, and a workaround is necessary;
- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team. In IPv6, multiple addresses on a network interface issued by the local network (SLAAC or DHCPv6) is the norm rather than the exception (requires userspace tooling in IPv4, DHCP doesn't have this functionality), so leverage this advantage;
- use IPv6 AH (authenticated headers) wherever possible;
- because in an ideal world, ISPs would behave consistently and IPv6 GUA addresses would always be stable, but we aren't living in an ideal world, so be ready to update your internal DNS to drop AAAA records containing IPv6 GUA that an upstream ISP fumbled;
- or, if you have the internal resources, register your own AS and command your own official block of IPv6 addresses;
- use a combination of OpenTOFU (Terraform) and Salt or Ansible, all versioned with Git, be very strict with your team about versioning with Git, to manage everything, and use
and Salt or Ansible equivalents for continuous monitoring;- move userspace services to Podman where possible.
Personally I like Salt. I know Ansible is more popular out there with more inertia.
_
>> why are we normalizing the removal of IPv4 addresses?
This was normalized a long time ago actually. "The future is already here, it's just not evenly distributed".
You and I are total strangers on different corners of the globe. You may not like what you're about to read, but it's better that you get a hint where the wind is blowing sooner than not.
If my team were consulting with your organization's execs and we caught a hint that the existing internal resources were not already proactively staying current with internet protocol (which is IPv6), we would point out there is urgency to start right away with emphasis that the existing internal team is over two decades behind staying current.
Or, if a detected hint the internal team were at all resistant to IPv6, we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.
IPv6 only seems more complicated if you still need to unlearn IPv4. IPv6 does have a steeper learning curve, but once that learning curve is overcome, IPv6 is actually much simpler than IPv4. More people than not don't like reading RFCs, but professionals do slowly read RFCs on their own time.
IP6 babe!
Interesting.
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.
Most consumer ISPs regularly rotate the prefix. IPv6 has proper support for that and can keep connections on the old and new prefix alive for a while in parallel.
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.
Hopefully you mean a static prefix, a static address would be an abomination from an ISP in IPv6!