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.
PSA that if you have a ham radio licence, anywhere in the world, there are IPv4 addresses available for you for the taking at ARDC (AMPR)[1].
You can either get a block of /24 to announce yourself (you've got to cover all the technical setup and costs of this) or use their free 44net.connect service and just organise a wireguard tunnel.
Ok so I was looking at the market rates for ipv4, and it appears that $20 per IP is a common figure, which means that a /24 block is worth about $5000.. so, what's the catch? And how many /24 blocks does ARDC have available, really?
I'm most curious to understand why didn't bad actors gobble up all those /24 blocks already.
You're absolutely correct - it's an incredibly valuable asset.
It's a really interesting piece of internet history. The whole 44.0.0.0/8 was assigned for loose 'amateur radio use' back in the 80s. For the most part it was used for building mesh networks over RF in different locations.
Then IP addresses became quite valuable. Now, I feel that what was really going to happen is that, with no real organisation around it, and not that much use of a very valuable asset, it would have been not unthinkable for the whole lot to have been taken away [by ARIN/ICANN/whoever] and assigned for general use. Certainly easier than taking it away from the US military. So, about a third of this space was sold to AWS and the money used to fund an actual organisation with staff - but mainly to issue grants to amateur radio projects around the world.
They therefore really do have [tens of thousands - sorry I don't remember how to calculate it right now] of /24s available.
Internally - they allocate it how they want, some are only used on mesh networks, some are used for infra, some only private networks, but plenty for people to announce.
When they assign it to you, they're only giving you a Letter of Authorisation, and creating a route in a routing DB saying that your ASN is allowed to announce that allocation. They can withdraw that at any time which means the routes will be ignored by others.
Having the ham radio licence requirement is a reasonably accessible, yet robust entry barrier. The catch is you can't use the addresses for commercial purposes. They have staff and volunteers pretty much full time so if they find that they just cut you off.
An interesting parallel is the ham radio frequencies themselves. I love messing around with building equipment and transmitting, but actually getting an exclusive licence for a chunk of spectrum would cost me an impractical amount.
But in many countries (including Germany), you are not allowed to encrypt your transmissions via ham radio, e.g. using TLS with such IPv4 addresses is against the law.
No that would only be if you were to use actual packet radio across the amateur bands with these. Some of them are used for that purpose indeed.
But the ones I’m referring too are just internet addresses you use on the public internet. Eg, ssh-ing to a raspberry pi, setting up an SDR, or just leaning BGP and suchlike.
> 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.
Sure there's historic reason that the DoD has such a large block, but it is definitely unfair in the modern world. There is no way they need or will ever use their massive block of addresses. They have 13 different /8 blocks, ~218 million unique addresses, that's over 5% of the entire IPv4 address space.
The modern paradigm you're using as a comparison only exists because this network designed for the US military industrial complex was so freely open and fair that it is now used by everyone.
There were and still are are other global networks -- none of them come close to being anywhere near as open or interoperable. What's the next closest, PSTN maybe?
My take is that the solution here isn't "give India more IPv4 addresses", it's "force more Americans onto CGNAT", so that it becomes untenable for service providers to treat IPv4 addresses as if they're tied to a single user, and to encourage people to use IPv6.
The US is already 55% IPv6, and this figure is only going to go up in future as ISPs decide to migrate their network cores to IPv6 for financial reasons, making IPv4 a lower-performance edge protocol riding on CGNAT on top of IPv6. Similar selfishness elsewhere will start to drive other parts of the ecosystem to IPv6, and the problem will solve itself.
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).
They do this for free because they're a tier 1, meaning everyone pays to connect to them and they benefit from having more things hosted on their network. It's free because your ISP pays for it.
And they can always tell your ISP if they don't like paying to connect to the tunnelling server they should just implement v6.
Unfortunately, he.net tunnels have terrible reputation, so if you use this for your regular browsing, you're likely to get hit with more captchas than if you're on a cgnat with well behaved neighbors. Some sites will just not work, with no errors, because why waste errors on networks with bad reputation.
It wasn't always like this, but it was for me the last time I tried.
Your greedy ISP won't provide you with IPv6 for financial reasons - it's cheaper not to change or upgrade systems. This won't change until they start to provide you with IPv6 for financial reasons, as they reach the point where going to IPv6 starts to be a cost saving for them rather than having to run two different networks at once, with a whole bunch of CGNAT to keep the IPv4 part of it going.
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/
Try getting a /24 these days without paying a fortune. We NAT everything and still wait for IPv6 because the ISP CPE barely supports it. Land analogy is apt, landlords everywhere.
My ISP is only a few years old, but they don't support IPv6 at all. And when I complain about it to support, their response is basically "we don't see the point".
Sure, but if they're a new ISP, chances are they have a hard time getting IPv4 and they likely run CGNAT. If they run CGNAT, the benefit of IPv6 is there's a lot of high volume traffic that will move to v6 and the CGNAT use will be smaller. Routing v6 packets is much easier than tracking connection states and munging packets...
If they have enough v4 for all their customers, sure fine.
This is an interesting take, however from what I seen its other way around. Most security conscious operators would only allow IPv4 instead of IPv6. Your ACL rules and tools are still better at handling/managing IPv4 compared to IPv6
> Most security conscious operators would only allow IPv4 instead of IPv6.
I strongly disagree. That's obsolete knowledge, thrown around by people who want to be considered security conscious but haven't actually updated their knowledge in many years. A statement with similar implications might be "security conscious operators require their users to rotate their passwords monthly", which is what a lot of people use to think a decade ago, and now what it really communicates is that you're talking to a dinosaur.
No, it's not. If you really want a NAT there is no reason you can't use a NAT with ipv6. In fact, it can work even better because instead of using a random port for the translation, you can use a random ip address for each connection.
Why would it be reachable? It might be name-able but that doesn't imply reachable.
You're conflating the two parts of NAT: address translation and inbound filtering. A router can block any inbound traffic coming from WAN, even if the IPv6s on the LAN side are public.
In fact, hole punching for IPv4 shows this distinction. By default inbound traffic is blocked, but as soon as private host has opened up a connection, it is (indirectly) reachable and nameable (via the routers public IP + port).
BTW, static IPv4 NAT with public addresses on both sides exists as well.
Addressable means routable. Otherwise the distinction between a Public and Private address becomes one of firewall rules rather than a meaningful property of the IP Address.
And as you say, hole punching is still “PUBLIC IP” + port. Not an IP and any port you fancy unless the firewall was configured correctly.
Maybe I am wrong, maybe you’re confused, maybe IPv6 is just rubbish. Maybe all 3.
You were asking about reachable, not routable. Of course, an address behind a firewall might be adressable and theoretically routable, but it certainly isn't reachable.
The default config of a SoHo router has both: (a) NAT44 separating public vs. private IPv4, (b) and also a firewall that blocks any unknown ingress traffic on IPv4 and IPv6.
From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts: If the firewall is in-place both IPv4 and IPv6 traffic will be blocked. If you open up the firewall (via hole punching or port forwarding on IPv4, or via IP allows for IPv6), I can send packets to your public IPv4 + port and they will arrive at you private server, or I send them to your servers GUA IPv6 and it arrives. There is no security difference.
The fact that the private IPv4 block is not globally reachable counts for something. If I accidentally give you my private IP (192.168.17.102, by the way!) you can't do anything, absent other details, no matter how much misconfiguration occurs. If I give you my IPv6 GUA, there's a lot more variability.
I “inherently” reachable. You can play semantics but the point stands.
> From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts
This is complete nonsense. Security is about layers and risk mitigation. You know what is better than firewall rules that can be misconfigured or overridden due to conflict or interface name changes and so on? An IP that can be addressed from global space. Wild!
What do you mean globally accessible? All the devices on my network have global IPv6 addresses for the last 5 years - since my ISP enabled IPv6 but none of them are accessible unless I configure it.
Do you ever wonder if most people don’t “see the facts” and after almost 3 decades and so much the adoption at 50% might mean to consider if the technology is just rubbish?
I do! But then I ask those people to explain how to go about doing v6 in a way that isn't rubbish, and the only answers I get to that are a) impossible, b) no answer/refuse to answer, or c) they start reinventing v6 but with weird names for everything. Or some combination of the above ("just add two octets and have a flag day" is a common one, combining (c) with (a)).
I've more or less come to the conclusion that the people who think v6 is bad don't know what they're talking about. If none of these people can come up with a better approach than v6, that suggests that v6 really is more or less the best approach available.
> after almost 3 decades and so much the adoption at 50%
I think we all wish it had been faster, but the v4->v6 transition is the first time humanity has ever done a transition like this, on this scale, involving so many disparate networks controlled by so many people in so many countries. How do you know that 50% at 3 decades is slow? Maybe this is just the par time for this kind of thing.
They key things is that pretending interoperability with IPv4 can be an after thought or dual stack is a good idea was just stupid and proven to be so. Flag day or IPv4 fading into oblivion never going to happen.
I know 50% is slow because that is LESS than new deployments over the past 3 days, so if someone thing “better” can be deployed to new projects until all old projects migrate is broken.
I've seen that draft. It's not backwards compatible in any ways that v6 isn't.
The people designing v6 knew from the start that interoperability with v4 was a requirement. It's written right into the list of requirements for v6[1], right in the same place that they say that a flag day is never going to happen.
Why do you believe otherwise? The RFC is right there for anybody, including you, to read.
You don’t understand it then. In V8 every IPv4 address is a valid address, that means you can have IPv4 and IPv8 on same IPv8-lan and first class support for translation into the protocol instead of an array of hacks is a miles better solution than the pile of rubbish that v6 is. In fact, IPv6 isn’t even a new version of IPv4, it is a different protocol entirely and a rubbish one.
Most IPv4 "security" is a side-effect of NAT. NAT was not intended as a security feature, but it does provide a level of security in the common consumer implementation (PAT, single external IP, unroutable internal network.)
There's more that's been written about configuring/protecting IPv4 networks and if you learn about network security from a mentor or from coworkers at a job, rather than reading books/the internet/LLMs, you're more likely to learn about IPv4 security.
But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.
In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.
Blocking /128 is unlikely to block anyone for very long around here. Both the major ISPs give out /56 blocks with prefix delegation. In almost 4 years, mine hasn't changed.
IPv4 is old, very old. But how is it broken? It's literally been working just fine since it came out.
That there are limited addresses is something else: it doesn't mean it's broken.
I don't care that spying/surveillance devices have more trouble spying on me with IPv4 than with IPv6 and I don't care that some apps have a harder time establishing connection.
IPv4 works. SSH over IPv4 works. Browsing the Web over IPv4 works.
IPv4 stopped working fine some 30 years ago. The invention of NAT was caused by IPv4 not working fine (RFC 1631 was written under assumption it's a temporary solution). Hole punching is a thing solely because IPv4 stopped working fine. Much like Y2K, the reason IPv4 appears to work fine is because absolutely massive engineering effort was put to work around the parts that don't work fine.
NAT and CGNAT break the basic idea of how the Internet was designed, forcing everyone into servers and consumers. We've just become used to it, and most people have never experienced it any other way.
The Internet was supposed to be a purely peer-to-peer network, where the addresses on each side of a connection pointed to an end node. That's why protocols like FTP or SIP break when NAT is used, and why you have to play games with port forwarding if you want to run services from your house (assuming you have a public IP address at all).
It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer.
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
We couldn't do it with FTP. That's kinda the point. We didn't have static IP addresses for every machine or the entries in DNS to go with them.
The whole idea of "consumer" and "server" nodes is so baked into how people think about networking they don't even realize it. But that's not how the Internet was intended to be in the first place.
You absolutely can do it within the existing paradigm, in a number of ways, actually. Search for iroh, or DynDNS for example.
And if you seriously believe that Dropbox appeared because of NAT, and not because people prefer out-of-the-box solutions, I can only suggest you to go out of your bubble, and discuss technical issues with random people.
"Intended" btw is not even an argument. Internet wasn't intended for many things which we happily do here.
I'm well familiar with DynDNS. I used to run it before I got a real domain. It can't tell the difference between my laptop and my workstation, since they're both behind the same IP. I wasn't aware of iroh, but having looked it up, it's just a hack to get around problems that NAT has caused.
And yes, Dropbox does exist because of NAT, or more generally the fact that "consumers" are second-class citizens on the Internet. If everyone had a publicly routed address and an entry in DNS - which is how the Internet was originally envisioned - we'd have solutions that don't require a third party server.
Both of your examples just show how deep the Stockholm syndrome is. IPv4's limitations have shifted the way people think about networking so much that they rarely even realize they're doing it. But this isn't the way it was supposed to be. "Intended" is completely valid when we're talking about how something has strayed from its original design and the ramifications of it.
I'm not naive enough to think that we can ever get rid of the "consumer" and "producer" ideas that have crept into everyone's head. But it's important to remember that these ideas came about only because of limitations in the protocol, not because they're some kind of natural law of how global networks function.
Yes, and DynDNS too. Which is fine, cause it works, and that is what I said. The claim to which it replies is that people have to pay to Dropbox cause poor souls were stopped from sharing files using existing technologies like FTP by the damned IPv4, and not because they simply prefer an out-of-the-box GUI thing.
There were out-of-the-box GUI experiences, like Apple's "Back to my Mac", that never worked right because of all the issues with poking through NAT caused by IPv4.
Relying on peer-to-peer relays also doesn't scale, which is why Skype dropped its supernode architecture.
> That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity *BECAUSE IT MADE IT EASY TO DO THIS WHEN YOU'RE STUCK BEHIND NAT TRASH*. By the time it was even a thought in anyone's brain the internet had already been ruined by that garbage.
It would never have existed in a world without NAT because it wouldn't have been needed, syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
Every ISP that has CGNAT v4 without providing full v6 needs to be shut down. They are either incompetent or actively choosing to make their users' service less useful to restrict them and/or encourage "upgrades". Internet service has a public routable IP address, period.
>it would never have existed in a world without NAT because it wouldn't have been needed,
I'm sorry, but this claim is one of the brightest examples of false consenses effect I've seen in ages. People generally just prefer an icon on desktop to click/tap. And that's the reason Dropbox found its audience.
Now imagine if you didn't need that icon and Windows Explorer (or whatever file manager you use) could just connect to wherever your file is. Maybe through a "Favorite."
Then imagine the security implications of trusting windows to serve just some selected files over FTP and never have any security hole that exposed other files or allowed RCE
> syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
In no way am I denying that people would like to solve the same problems easily. What I'm saying is that it would have been a much simpler problem requiring much less infrastructure. An application like SyncThing that works without any central infrastructure would have been an order of magnitude easier to implement in a world where every internet connected device had a unique routable address.
> Only today we would have put everything behind something like NAT anyway because your devices would be getting hacked constantly.
So the security "provided by" common 1:many NAT comes from the fact that 1:many NAT inherently requires stateful connection tracking and by its nature traffic coming in from the "1" side without an associated connection or rule has nowhere to go, effectively denying any other traffic by default from the "1" side which is almost universally the untrusted side.
Do you know what else has stateful connection tracking and deny-by-default rules on untrusted interfaces? Every single firewall that's worth using or even was at one point worth using in a year starting with a "2".
So yes, in a world without NAT we'd still have stateful firewalls blocking unsolicited incoming traffic that had not been specifically allowed. Those who wish to host public services will still need to configure rules to allow that traffic in unsolicited but those rules will be simpler than NAT port forwards because there's no address translation involved. Anything else wanting to generate on demand temporary connections between systems will be able to do so simply by having each system perform a basic hole punch, sending traffic at the other at the same time with the same pair of ports, and expect it to work again in ways much simpler than what's necessary for reliably doing the same in a 1:many NAT environment.
1:many NAT makes nothing better, it only makes things worse. It's a bad thing and needs to go away as quickly as possible.
---
1:1 NAT is an entirely different beast, it can be entirely stateless and thus has no has no negative impact on most protocols that don't try to communicate address info in-band but also that statelessness means it doesn't inherently provide a firewall effect.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity because none of us can or want to bother to do it with FTP, with the exception of a very small and determined minority.
Why do you think that even FANG engineers use cloud storage systems such as Dropbox/iCloud/OneDrive/Google Drive/etc. Can't an elite software engineer put together a FTP server?
Why do you think Dropbox et al are still a thing in spite of projects such as Syncthing?
This is not the only instance where user experience and convenience show their value. Look at Docker, for example. The "aktually" crowd will be fast to say that anyone can do the same with chroot et al, but they will again be missing the whole point. It's the same thing why Microsoft tried to invest in Aspire even though Docker is here.
It's like complaining that people can buy bread when all they need to make their own is flour, water, salt, and yeast. That's completely besides the point, ain't it?
I think you're taking the "FTP" part a bit too literally here. No one's suggesting we'd jump in a terminal and type in FTP commands manually or even use the FTP protocol itself - we've got better options today, and we'd have even better options if the Internet had had global node-to-node connectivity all along.
It'd likely just be built into your operating system's tooling. Your file manager would be able to access other machines it can authenticate to, or you'd automount remote directories on login, etc.
The reason people use cloud storage systems for moving files around is because they have to. A 3rd party server is required because we don't have node-to-node connectivity.
Hell, we'd likely have had cloud storage options sooner because people wanting extra remote storage would totally have been a thing.
> You mean it's fixed by NAT and CGNAT. Because it's works just fine for me.
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
I don't play this kind of games at all, but I still can sympathize with you if it's your preferred pastime, and it doesn't work as good as you'd like. I just don't think it warrants a conclusion that those nets in which we are arguing are broken. They are tangibly, observably doing pretty well. And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
> And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.
There are working procedures to follow in such situations, and minimally competent ISPs deal with them well enough so that most users don't even know the problem exists.
Back when I managed teams that dealt with API traffic at a unicorn, this wasn't the case. We'd ban a /32 and several times customers would start reaching out to our support portal (which ran behind different ingress rules) asking why they couldn't use the site a couple weeks later.
I've never worked on the ISP side so there's no doubt that there is a process at the competent ones, but my guess is most users do not have a competent one.
(I work on performance tuning a browsers happy eyeballs implementation)
Especially for DNS, browsers don’t wait “very long” for the AAAA (v6) record to be resolved when they already have the A record (v4) and will start the v4 connection after at max 50ms (iirc thats the spec value, but imo it is too long and most browsers wait less I think).
The good news is that if the AAAA still arrives later it will be cached, thus this only affects the first connection to a site.
As for the actual v6 connection being slower (lets say both A and AAAA come from cache) the browser will start a v6 connection and only fall back to v4 if the connection isn’t established within some time (I think the spec says 250ms).
And to make this all more complicated HTTP1/2/3 enter the decision matrix. I.e. should the browser rather try v4/http3 than v6/http2? Opinions probably differ.
All of this is also on the critical path to a website loading for the user, thats why all of those waits cannot be too long. At some point the benefit of the better protocol will be outweighed by waiting. Even worse if the website doesn’t support v6 and the wait was for nothing.
Is this fundamentally from poor routing from infrequent use? For example, if usage was 50%, would the routing/hops between the two somewhat converge? Or is this actually a "v6 is hosted on a separate server somewhere else" type problem?
Google publish a per-country latency comparison[1]. Typically v6 is slightly faster. (Also, usage is in fact 50% on average.)
But in general, it's mostly because v4 and v6 can end up taking different routes. If an ISP has any BGP peers that are v4-only or v6-only then they can end up sending packets for the same host to different peers. In the worst cases, one of them can go to another country and back again. It's usually harder to get ISPs to fix this on v6 than it is on v4, because the problem is visible to fewer people (in part due to happy eyeballs itself).
For smaller websites, DNS caching can play a role. If there are fewer clients requesting AAAA records than there are clients requesting A records, there's a chance that a client requesting both will get a cached A record back quickly but have to wait for full resolution of the AAAA record. This is unlikely to happen for the most popular sites (because another client will probably have triggered the caching) or for the least popular sites (because the A record will also fall out of cache for those), but there'll be a band somewhere in the middle that's affected by this. There's enough v6-capable clients around these days that I doubt this has a major impact now, but it's interesting that caches can cause unfairness like this.
The Chinese are having a big push for IPv6 adoption, and, being China, this is likely to actually happen as ISPs follow government orders. But also being China, they are also pushing for 'enhancements' for IPv6 for the usual reasons, which the rest of the world is unlikely to be willing to adopt.[1]
Interesting, never heard of IPv6+. Can't find much in the net about it either. This looks like the offical page, but do you know of any articles where experts anayze it?
https://www.ipv6plus.net/IPv6Plus/ipv6plus
A large chunk of IT people don't understand it. So they don't demand it from their vendors. The vendors see the lack of demand so they spend fewer resources on it. When someone wants to implement IPv6, they see the limited vendor support and decide against it.
The last three companies I've worked at have all been IPv4 only. I set up IPv6 in our lab, but neither the SCADA software nor the PLCs we use support it at all, and none of my coworkers can troubleshoot it if problems pop up.
I've got a buddy that's a technical manager at an ISP and he'll straight up tell you they don't do IPv6 because he and his people don't know it.
Yep. I run into "enterprise" cloud environments where IPv6 is disabled, all the time. The sad thing is IPv6 is easier to understand than v4, just based on subnetting practices alone. The real problem is the average "IT" person doesn't understand hexadecimal.
Thing is, you can run ipv4 only, dual stack or ipv6 only. Ipv6 only won't work. Dual stack has a larger attack surface and is complex. Ipv4 works but costs a relatively tiny bit of money so far.
It's definitely a slight learning curve (a few days at most for basic understanding and troubleshooting). I can't speak to complexities like routing protocol configurations.
But goodness, the infinite-subnets-of-same-size glitch is so amazing. I see companies all the time that struggle to subnet their sprawling enterprise. Different subnet sizes everywhere, fragmented networks, subnet migrations to try to defragment, so on.
Many orgs are so short-staffed and staffed with mediocre talent that they spend their days fighting fires and keeping their flawed current practices operating just well enough to keep the lights on and not cause outages or security breaches. Things like "optimizations" and "redesigns" of the IP stack, even in 2026, would be a 5-10 year journey without a dollar sign benefit attached to it. So they limp along until the transition is seamless and necessary or monetarily desireable.
Early bad experiences made a lot of people reluctant to try again.
There's a lot of edge cases to bite people still.
That said, something like 50% of users have working v6 now, which helps to file down the edges. Growth of v6 in the last 10 years has been much more significant than the previous 10 years. I suspect the next 10 years will be pretty significant, too.
I don't think many organizations are in a position to force adoption though.
You have mandates from say US government for government services and vendors and similar in some other countries. Some countries can force it through strong regulations on equipment sales. And then there's Jio (and maybe other ISPs) that have significant market power in some locales and a significant lack of v4 resources and can strongly encourage vendors and partners to support v6 for better service to users on their network.
IPv6 brings more address space but also a whole bunch of other stuff, it is much more complex and changes basically everything to how you manage a network. The fact that it's not been widely adopted after 30 years indicates that people generally think the tradeoff is not worth it.
We're 10 years out from the Epochalypse as well. Past a certain point you need a governing body to intervene to force the issue in advance of problems with systems, and we've got a dearth of functioning governments these days.
Replicating even a simple ipv4 lan with mostly stable local addresses and some isp uplink is pretty complex, even assuming all the devices involved support ipv6, which they wont
It's much easier to run a dual stack with v4 for ease of use on the lan and v6 as an additional address that can change whenever and is only used to reach the wan
But the main reason you'd care would be if you can't get a public ipv4 address to NAT to. And if you can't get that, some of the internet breaks anyway.
What I really don't understand is why IPv6 was made so human unfriendly, why not just use 6 three digit blocks? Surely we are not better of now with two parallel IP versions.
There's no way to expand the address space without breaking compatibility. A router is expecting IPv4 addresses, not 10.15.100.252.xxx.yyy addresses. All routers, firewalls, operating systems, programs, smartphones, etc would have to be replaced to support "IPv4 with 56-bit addresses."
Hexadecimal is shorter than the equivalent decimal representation. An 128-bit address would be 10.15.100.252.111.222.333.444.555.666.777.888.999.000.111.222. Use DNS!
From my readings and limited experience, it's two things.
First, IPv6 in the 90s and 00s is different from IPv6 today. Various extensions and standards have been added that make IPv6 administration easier than it was in the early days. I want to say RDNSS is one of them. Background: one of v6's early selling points was SLAAC, where DHCP could be disposed of and endpoints would auto-configure their own IPs in accordance with the network announced by a router. Problem is, without DHCP, there was no way to get DNS, and DHCPv6 wasn't widely deployed/it was discouraged... so how does one get a DNS server automatically? RDNSS came around to announce DNS servers from the router directly.
TLDR: Early IPv6 sucked more than today.
Second, it's simply a chicken-and-egg problem, particularly at the consumer network level. User-friendly IPv6 router configurations are still rare for home routers, and ISPs have simply dragged their feet. At this point, if we're going to have government mandating all manner of things for consumer products, we should be mandating IPv6 support on home routers and that ISPs delegate at least a /60 to each customer.
You mustn't be on HN very often. People constantly complain about IPv6 being less secure because it doesn't have NAT. And that's part of the reason. Fear and misinformation keeps demand low. The same people don't drive IPv6 implementation where they work, so their fear impacts more than 1 person.
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.
If you're willing to jump through hoops, you might want to check if it's still possible to setup an EIN and a new SMB T-Mobile 5G internet and get a static ipv4 for a small charge per month.
Personally, I had major issues with the 5g wan equipment and my network as well as a snafu with ordering... Sales rep put in the order for a static ip with a ssn based SMB account, but that got removed during provisioning and couldn't be added back. (And then billing issues because the account didn't get cancelled properly, either)
I converted from residential-class to business-class cable a few years ago. In both cases, I had routable IPv4 addresses.
I was just looking at flipping back, but now it seems the default for new resi accounts is CGNAT. They say they'll give me a real IP upon request at no additional charge, but it's anyone's guess how long that holds out.
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.
I now live in a "western" country and I have CGNAT. It is extremely common here. On the other hand, my ISP (largest provider in the country), in a "developing" country, gave me a public IP so I think there are more moving parts.
I think CGNAT is the default for new connections in .au, since about 5+ years, at least among "younger" ISPs that popped up around the national broadband network crawlout.
You can generally request to get off it though, at ~1-5$/m extra cost.
In my experience they charge for a static IP but not to turn off CGNAT. Obviously depends on the isp but I’ve tried a few.
One of them I had to call phone support and they asked me why I wanted to turn it off. I said I wanted to run a server and they turned CGNAT off on my account.
Bell in Canada continues to offer only IPv4 on their fibre network. I fully expect for them to somehow crap up the transition to IPv6 by putting up CGNAT because fuck you, customer.
Fascinating. The resellers, particularly TechSavvy have ipv6. For TechSavvy I believe it was dynamic /64 by default but static /56 for free on request.
> For TechSavvy I believe it was dynamic /64 by default but static /56 for free on request.
"On request" meaning you told your CPE equipment to send a DHCP-PD packet, i.e., you didn't have to call them and ask for something special with your account.
I did phone them to request the static /56, and to assign PTRs. I didn't try requesting the /56 before I called them so I can't say whether that would have worked or not. If you're saying it would have I'll believe you.
On HN, 'In Europe' means in one person's particular locale based on their experience and generalised across a continent of about 30 countries. But it's always better than in the US of course.
I wrote this as a European (British) who is living in another European country (Finland). People happily write ‘in Europe’ whilst being quite selective in their definition of Europe - usually their very close neighbourhood, and it usually means North and Central Europe. If that.
I’ve seen some truly unhinged takes here, my favourite ever being something along the lines of European cars not having cup holders because we don’t have drive-throughs in Europe…
I have driven my Volkswagen across this continent and enjoyed many a hot beverage on the move.
I’ve come to learn that discussions on a lot of things, in English, usually end up as a comparison to the States, especially if it involves the healthcare sacred cow.
I wish, just 37.73% of IPv6-capable users in Europe according to APNIC despite much higher availability in transit AS. Highest subgroup is Western Europe at around 72.09%, which is still far from near universal. Similar per-country numbers from Cisco.
Unless I've missed something, the US only mandates it for government networks. I don't think there is any mandate for private entities to implement it.
A residential network that can't connect you to government websites is called a fraudulent business model. No different from selling a car that only transports up to 20kg.
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.
CGNAT is awesome, you cant IP ban me anymore and I dont need a VPN turned on for silly things, and I can control fingerprinting (mostly), CGNAT is great for anonymity. If I want a static it cost me ~10.00 a month, im fine with that.
Lab-grown diamonds found a strong role as industrial components, which expanded overall demand for diamond materials and widened their use cases. IPv6 may follow a similar path, with adoption concentrated in newer and novel applications where IPv4 addresses were scarce.
IPv4 seems likely to remain in place for many existing applications, much like natural diamonds in jewelry, regardless of policy/advocacy views.
From a Georgist perspective, IPv4 is actually a form of land (it's a finite "natural resource", although that's not quite proper), and you could make a case for "land rent" being taxed on the addresses. This is the same as radio broadcast frequencies, web addresses, actual land, un-mined gold/oil/coal/whatever, and other finite natural resources that create monopolistic tendencies.
Wait do georgists describe any "finite natural resource" as "land"? Is clean drinking water "land"? Are radio frequencies "land"? Are domains "land"? (I mean domain names aren't "natural" but neither are IPv4 addresses????)
Georgists don't literally think that other scarce natural resources are actually land, but instead think that all scarce natural resources, if untaxed, lead to economic rents being extracted. Land/location ownership is probably the most damaging form of this, so it's the one that Henry George focused on, but the same basic principle applies to other natural resources.
This is why people refer to Norway's taxation of natural resource mining as "Georgist in principle" even though no land value tax is involved.
I (and I'm not original here) extrapolated that to other not-natural resources like IPv4 addresses, domain names, and so on that function much like a limited natural resource.
You even have cases of "land-banking" like nissan.com, although I don't believe Mr. Nissan ever intended to profit from owning the domain name; probably more akin to the main character of the movie Up.
Money is a scarce resource and should therefore be taxed.
You could say that it's intentionally kept scarce, and that is somewhat true, but currency is kept scarce because it only functions if it's scarce. Currency without scarcity ceases to be currency.
But yes. When they say land they actually mean "natural resource".
The idea is that human-made resources should have their profits go to humans, but natural resources (most notably location value) do not belong to humans because humans did not make them, and also, the economic incentives normally associated with markets such as supply/demand management and price discovery don't apply because supply can't change.
Its extremely economically efficient and is endorsed by many economic thinkers on both the right and the left, as well as many social justice activists.
Nah the ideology is just rich people or wannabe rich people wanting less taxes. Having a land value tax makes sense, removing all other taxes does not.
Many georgists propose LVT + citizens dividend which is in effect a better version of a wealth tax with UBI - meaning it would be highly re-distributive from the asset-rich class to the asset-poor, and therefore very positive for inequality.
Nobody who claims to be Georgist or support Georgism seem to agree what it actually means. I'm following the traditional definition of having only a land value tax. If you want to propose something completely different you can do that, but I don't even know what "Georgism plus a bunch of extra taxes" is supposed to be mean.
Nowhere in what you linked describes this as a wealth tax. That link just describes paying people a UBI from the income generated by the land value tax. There's no mention of additional taxes.
Seems my understanding of Georgeism was correct after all. Maybe you're the one who should stop spreading misinfo?
Or did I miss the part where it proposes non-land-value types of tax?
Whereas IPv6 is effectively unlimited, so by Georgist principles should be free. I wonder if charging 'rent' on IPv4 addresses would be enough to get people to switch over?
My hosting providers gives you IPv6 for free, whereas IPv4 costs ~3€/month. It seems like a no brainer, until you realise that many clients wouldn’t be able to find you with IPv6 alone.
So I don’t see how to fix this except at the ISP level (forcing them). No one is preventing this but the providers.
Yes, but 'use' rather than 'get'. If you tax land or other natural resources, people use less so there is more for everyone else. It doesn't pay to hoard or speculate.
Incidentally, auctions of time bounded licenses, which are what we use to allocate frequency spectrum, have the same theoretical pareto efficiency as a value tax.
Surely that would assume low/predictable volatility thought right?
If the probability changes over time that the price might go up and back down for a 6 month period which is bounded inside of a single auction-able period, then the auction would not have ever captured it correctly... Low frequency auctions assumes perfect risk prediction which isn't realistic and comes with large insurance and analysis overheads.
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.
ah yeah, golden times of crawling google when they actually didn't monitor ipv6 traffic properly against scraping (seo monitoring tools were first to drive 'adoption', lol)
I don't know what you count as “golden times”, but at least when we started the measurements, there was no indication bot traffic would drive up these stats at all. (You wouldn't trigger it just by fetching a search result page.)
Thank you. It's been a while since that paper was published )
I was interested in the number for Russia; 2 out of 4 mobile networks do not provide ipv6, and wired network ipv6 availability depends on provider; provider-supplied routers generally disable ipv6 anyway. So the 78% seems high.
Could be that this is measured from youtube; people use vpns to go there, and those typically have ipv6. That would mean that country is tracked by account, not source ip.
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.
I guess a lot of sites just turn it off. Even if Cloudflare proxies it over IPv4 the IPv6 source address still shows up in server logs. Features like geolocating users or fraud prevention might need additional work for IPv6.
The obsession about "IPv6 only" has never made sense to me. Any decent firewall software will let you write rules that apply regardless of IP version. The "software complexity" argument is bunk... you already have v4 and v6 IP implementations in your OS, and every major OS has provided IP-version-agnostic socket interface code for much more than ten years. If you are using software that is IPv6-capable, it's very likely that it's using IP version agnostic library functions.
Unless stewardship of the Internet is wrested from the hands of the responsible, level-headed type of folks that run it now and transferred to the hands of folks who think nothing of making backwards-incompatible changes every six months, IPv4 won't stop running across the Internet within the lifetime of anyone who's currently reading HN. This delay is fine. The only thing about IPv4 that's a problem is that its address space is 32 bits wide. Had it been defined with a 128+ bit address space, we wouldn't have seen another version of IP on the Internet. Now that IPv6 is around to reduce address pressure, there's no big need to do anything about IPv4.
I believe the folks worrying about IPv6 only are just looking ahead to a possible future. Especially when they are looking at the question of do all the pieces work locally, vs do popular domains support it.
There are domains like T-mobile US that are IPv6 only already. T-mobile runs NAT in the network so that all of IPv4 is NAT'd to IPv6.
I do think it is reasonable to expect there will become a time when IPv6 is pervasive enough, that new deployments will target users with IPv6 rather than IPv4.
Once IPv6 becomes the choice to support to get new customers, it is reasonable to expect that IPv4 support will start deteriorating and will eventually fade away.
I will be very surprised if we don't hit that tipping point in my lifetime. Say the next 30 years.
> I believe the folks worrying about IPv6 only are just looking ahead to a possible future.
I'm certain that that is not what the folks who scream very loudly about how IPv6 has been and continues to be a colossal failure because it's not the only version of IP on the Internet are doing.
> I do think it is reasonable to expect there will become a time when IPv6 is pervasive enough, that new deployments will target users with IPv6 rather than IPv4.
Sure. That's the future I find most plausible: For "residential" connections, provide IPv6 GUAs and IPv4 via CGN... [0] for "commercial" connections, provide IPV6 GUAs and give the customer the option of one or more IPv4 GUAs.
> I will be very surprised if we don't hit that tipping point in my lifetime. Say the next 30 years.
I do hope we get to that point within the next five years, if not ten! But notice that my claim is that IPv4 will still be crossing the Internet after everyone reading HN today is dead. [1]
[0] I'm calling the various mechanisms that only provide an IPv6 address to an end user and do fancy gyrations to provide IPv4 access "CGN", even if might not strictly be CGN.
[1] ...as long as the the responsible, level-headed type of folks that run it now aren't replaced with the "making backwards-incompatible changes to everything every six months is A-OK!" type of folks.
I can totally understand why. IP addresses are hard to get for a large chunk of the global population. There's twice as many people as there are IP addresses.
Plus dual-stack means more work, and more possibilities for misconfigurations or vulnerabilities in your network. It'd be way easier if you only had to worry about one or the other.
I live in the US and my ISP gives me one address I have to share across all the machines in my house. That's a tragedy - by all rights I should have a subnet or two. You can't directly address any of my servers from the outside on IPv4 which means I have to do hacky crap like port forwarding and can't use a lot of the older protocols that aren't NAT friendly. And I've got it good compared to most of the world!
IPv6 gives us back a large chunk of the original premise of the Internet - that all nodes are peers. IPv4 hasn't been able to do that for decades, and it's warped the way we think about networking by separating everyone into consumers and providers.
> Plus dual-stack means more work, and more possibilities for misconfigurations or vulnerabilities in your network.
Nope. Your OS vendor already did the work to make both versions of IP work. And as I mentioned, if you're using a decent firewall you can write IP-version-agnostic rules just as easily as you can ones that depend on the version.
Plus, most SOHO firewalls default to dropping unsolicited non-ICMP traffic. That's the exact same security stance that IPv4 + NAT gives you. You have to go out of your way (or be using fancy gear that is aimed at people who know what they're doing) to expose your LAN hosts.
My OS vendor didn't set up my firewall rules, lay out my subnets, or configure my routing. I did that. Twice. Because I've got a slightly more advanced network layout than your typical home user. And that's all much less complicated that what your typical corporate network would be, which is much less complicated than what an ISP or COLO provider has to deal with. And then there's the cloud...
Yeah, sure, if your requirements can be met by a cable modem, then you're basically good to go. Until DNS breaks for some machines and not others, and it's because your ISP screwed something in their IPv6 routing but it still works on IPv4. Or Microsoft's authentication servers decide they don't like your IPv6 subnet anymore and Minecraft refuses to start unless you turn IPv6 off. Or... You get the idea.
> My OS vendor didn't set up my firewall rules, lay out my subnets, or configure my routing. I did that.
Wow! Me too!
> Because I've got a slightly more advanced network layout than your typical home user.
Mine's quite a bit more advanced, if we're being frank. Though, the way I have things set up should be the default for SOHO stuff. This sort of configuration really is something whose setup can be automated, but never will be for as long as dumbswitches are the go to for SOHO equipment.
Anyway. I guess you and I just have dramatically different opinions on what's difficult. ;)
Possibly. Or maybe you and I did a dramatically different amount of work on our networks. My setup is very much not what should be default for SOHO, for instance.
You should try staying at small boutique hotels. They tend to just sign up for a regular business internet and you’ll get IPv6 that way. Large chain hotels want central management and their management isn’t modern enough to support v6.
Okay, if you say so. Hotel Wifis are known for being on the bleeding edge of technology, and as the main innovator pushing new internet technology. Everything starts with hotel Wifis. /s
Exactly my point. IPv6 failed to reach the "boring, just works" level after 30 years of deployment. So much so that we are now deploying solutions with 10+ years of expected service lifetime that do not support IPv6.
Meanwhile, CGNAT really solved most issues with IPv4. Yes, even the voice/video chat issues.
Want another fun example? Try to find a SIP telephony provider in the US that supports IPv6. Go on. I do this exercise about once a year.
> IPv6 failed to reach the "boring, just works" level after 30 years of deployment.
/me glances over at my phone, which only has an IPv6 address when connected via cellular modem.
/me thinks back to the decade+ of incredibly boring IPv6 service from the residential ISPs I've used.
Sure.
If an ISP wants to provide only IPv6 addresses to CPE, they can set things up so that happens. But if you won't be satisfied until IPv4 no longer passes over the Internet, then you're going to die unhappy about that. The goal for our lifetime is one where every residential site has a global /56 and is behind IPv4 CGN, and servers hosted by commercial entities get to choose whether they assign IPv4 addresses, IPv6 addresses, or both to their servers.
/me searching through all the mobile network providers in Switzerland (a technologically advanced country) and not finding any.
Seriously, this drives me mad. There is NO WAY to get IPv6 on mobile networks in Switzerland. Neither Swisscom, nor Sunrise, nor Salt, and of course no reseller.
And Android handles this particularly poorly. I have some servers set up in my tailscale network on private IPv6 addresses, but android doesn't query AAAA addresses if it has no ::/0 route, so I HAVE to route all my traffic through my VPN which often creates other complications (with corporate wifi etc.)
I am in the same situation. However, I have found that there's a workaround/hack to make Android 'think' it has IPv6 connectivity. Instead of routing ::/0 through your VPN, simply add these two routes to your devices:
- 2001:4860:4860::/112 (for chrome)
- 2000::/128 (for the system)
They don't need to be actually accepted by your VPN. They only need to exist in Android's routing table for it to start using AAAA lookups.
The drawback is that this breaks happy eyeballs, and you may notice slower response times on requests (since now your phone will start by quering AAAA results first which always fail for sites not on your VPN, and then fall back to the A result). In practice however I haven't really noticed any difference.
I get your frustration. But not having access to IPv6 personally does not mean IPv6 is dead. It's very much alive and handles considerable amounts of traffic.
Well ok, not dead. Dead sounds final and I still think that we will get more IPv6 deployed in the future. And I set up all my servers as IPv6-first. So no, I don't think IPv6 is dead.
But I'd claim it failed completely. Many very public services (eg. github.com, sentry.io, office365.com, archive.org) outright don't support it. And the fact that infrastructure providers (like mobile network carriers) don't support it either, proves that it is far from "alive". In fact, I'd say it is deader than MMS, Fax and landline. For these I can still get service. For IPv6 (on the phone) I can't.
It only failed to fully replace IPv4. But it runs perfectly fine along IPv4 and is very much alive. It replaced IPv4 where it was needed and didn't where it doesn't matter yet.
Email didn't replace letters on paper. But I wouldn't say email failed completely.
Given the number of scaredy-ass ISPs out there who refuse to offer IPv6 service, I disagree with this. But I do strongly agree with the rest of your comment.
I also very strongly assert that claims of the form "IPv6 is not the only version of IP used on the Internet, therefor it is a complete failure." maybe with a side of "And this 'failure' means that IPv6 is a dead protocol." are just plain stupid. v4 and v6 were very deliberately designed to coexist, and if v4 continues to run on the Internet until the day the Internet is shut down, that's totally fine.
In my opinion, the most plausible future is one I mention in my second paragraph here. [0]
To be clear, 'TobTobXX' isn't 'cyberax'. 'cyberax' is claiming that IPv6 is dead, whereas 'TobTobXX' is -quite justifiably- complaining that both his local cellular ISPs and Android suck.
You're welcome to try to solve the challenges from my sibling post. Both of them are solved in IPv4 by a $100 router from a nearby store and with zero configuration.
I don't get your point. IPv6 is at "boring, just works". The majority of the worlds devices run on it dual-stack and it handles a considerable amount of traffic. A lot of 5G networks run on IPv6 single stack with IPv4 compatibility on top.
IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
> I don't get your point. IPv6 is at "boring, just works". The majority of the worlds devices run on it dual-stack and it handles a considerable amount of traffic.
Most of the world runs on IPv4. If we shut down IPv6 on the core routers tomorrow, pretty much nobody is going to blink an eye. And now I believe that we should do it and start again.
The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6. Mostly because there's not enough private or even squattable IPv4 space available for many large mobile phone operators.
> IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
Sigh. No, it's not. In a thread a couple of weeks ago, I gave several examples:
1. You're a SOHO-type business. How can you do multiple WAN uplinks with IPv6 without NAT?
2. How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
For context: I deployed IPv6 in my networks in 2006. I have war stories.
> How can you do multiple WAN uplinks with IPv6 without NAT?
Advertise the addresses offered by the primary uplink, then retire those addresses [0] and advertise the secondary when the primary fails. Or are you talking about load balancing, which is its own thing? Either way, this situation is inherently not boring, so the way you solve it is going to be quite a bit more complex -regardless of IP protocol version- than the very boring single-upstream situation.
> How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
I'll flip this around on you:
How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Obviously, you use the ISP-assigned globally-routable IPv4 address and also assign an RFC 1918 address to the printer.
How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world. Just like in IPv4, IPv6 globally-routable addresses are for global communication and can be used for LAN-local communication. And -just like 1918 addresses- ULAs are for LAN-local communication. Just like with IPv4, if you can't control the addresses that you get from your upstream provider, and/or if your router is set up to retire your upstream provider's delegated address space when your upstream link goes down, then you use ULAs. [1]
I know that OpenWRT has a setting in LuCi to enable advertisement of a ULA prefix, and fifteen seconds of searching revealed that at least some Linksys combination router/APs seem to just generate and advertise a ULA prefix by default. [2]
So, if you're not configuring your LAN this way and upstream provider renumbering is getting in your way, then you really should bother to.
[0] ...by advertising their valid lifetime as zero seconds...
[1] ...or if you happen to like to be able to assign fixed IP addresses to certain pieces of hardware...
Isn't that the default for modern routers? They just generate a random ULA during setup and assign it.
Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps. Everyone setting up their LAN on 192.168.0.x makes it quite a mess on IPv4.
I assumed so because it's the obviously correct thing to do, but I haven't used a SoHo router in so many years, so I don't know.
> Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps.
Yep! Extremely low chance of prefix collision is their most important purpose. I've been part of several corporate acquisitions, and it inevitably took 6->18+ months to do enough of the IPv4 renumbering and server-discommissioning [0] process to begin to merge the LANs of the merging companies. Had they used ULA addressing, the odds of having to do that massive amount of work would be effectively zero.
And if collisions aren't something you give any shits about, nothing stops you [1] from setting your ULA to fd00::/48 and advertising fd00::/64 on your LAN for static IP addresses that are notably shorter than you can get with IPv4!
[0] ...because there's so little space in the 1918 range...
[1] ...well, unless your router's configuration system doesn't let you specify your ULA prefix...
> In IP discovery GUA is prioritized over ULA. And if the GUA goes away or changes regularly it leads to connectivity issues.
Sure, but you're generally not going to get both addresses associated with a single host unless you either hard-code them or use DNS. For any non-stupid network, source address selection for reaching LAN hosts doesn't really matter. And for many-to-most SOHO networks, you're going to be running dnsmasq, which will quickly set you right after any GUA change.
And like, the thing to be noticing here is that source address selection priorities for both IPv4 and IPv6 seem to give us the same actual behavior. Consider a pair of hostnames served up by BIND 9 and some applications running on bog-standard Gentoo Linux whose '/etc/gai.conf' contains only comments and blank lines:
# getent ahosts dumbhost.invalid
1.1.1.1 STREAM dumbhost.invalid
1.1.1.1 DGRAM
1.1.1.1 RAW
192.168.30.30 STREAM
192.168.30.30 DGRAM
192.168.30.30 RAW
# ping -n -c1 dumbhost.invalid
PING dumbhost.invalid (192.168.30.30) 56(84) bytes of data.
From <redacted> icmp_seq=1 Destination Host Unreachable
--- dumbhost.invalid ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
# curl -v dumbhost.invalid
* Host dumbhost.invalid:80 was resolved.
* IPv6: (none)
* IPv4: 192.168.30.30, 1.1.1.1
* Trying 192.168.30.30:80...
* connect to 192.168.30.30 port 80 from <redacted> port 47140 failed: No route to host
* Trying 1.1.1.1:80...
* Established connection to dumbhost.invalid (1.1.1.1 port 80) from <redacted> port <redacted>
<snip>
# getent ahosts dumbhost6.invalid
fd00::1 STREAM dumbhost6.invalid
fd00::1 DGRAM
fd00::1 RAW
2002:db8::1 STREAM
2002:db8::1 DGRAM
2002:db8::1 RAW
# ping -n -c1 dumbhost6.invalid
PING dumbhost6.invalid (fd00::1) 56 data bytes
From <redacted> icmp_seq=1 Destination unreachable: No route
--- dumbhost6.invalid ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
# curl -v dumbhost6.invalid
* Trying [fd00::1]:80...
* connect to fd00::1 port 80 from <redacted> port <redacted> failed: Network is unreachable
* Trying [2002:db8::1]:80...
* Host dumbhost6.invalid:80 was resolved.
* IPv6: fd00::1, 2002:db8::1
* IPv4: (none)
^C
# ip addrlabel list | sort -hk 4
prefix ::1/128 label 0
prefix ::/0 label 1
prefix 2002::/16 label 2
prefix ::/96 label 3
prefix ::ffff:0.0.0.0/96 label 4
prefix fc00::/7 label 5
prefix 2001::/32 label 6
prefix 2001:10::/28 label 7
prefix fec0::/10 label 11
prefix 3ffe::/16 label 12
Notice how actual application behavior doesn't match what folks in this thread are saying that source address selection dictates. Android behaves the same way, and -weirdly- my OpenWRT hosts have the exact opposite behavior and prefer using global addresses to ULA or 1918 ones, regardless of IP protocol version.
Anyway. If he put both IPv4 GUAs and 1918 addresses in DNS or his '/etc/hosts', he'd be having the same problem he's complaining about here... depending on -I guess- the OS he's using and how his resolver treats the ordering of entires in '/etc/hosts'.
This isn't an IPv6 problem, this is a "Things break for a little while when I use addresses to communicate with a host that can change out from under me instead of addresses that I control and those addresses happen to change." problem.
> ULA work well in combination with DNS though.
Yep! Most everything works great with DNS. Remembering IP addresses is for the birds.
Ah, so this is in the range assigned to 6to4 (2002::/16). Both Windows 10 and Android seem to treat it specially, [0] but Linux does not. So, I changed the AAAA record to 2400:db8::1 and re-ran my tests. I found out:
The 'getent ahosts' output remains unchanged.
When dealing with IPv4, all Linuxes, Android, and Windows 10 intermittently switch between preferring the GUA or the 1918 address. I seem to have gotten unbelievably (un?)lucky when testing v4 on Android, Gentoo Linux, and OpenWRT the first go around.
When dealing with IPv6, Android and Windows 10 always preferred the v6 GUA to the ULA. Every Linux I tried -and I tried several, each from different distros, some with and some without systemd, spread across years of releases- always preferred the ULA to it... except for OpenWRT, which always preferred the GUA. The only way I could get OpenWRT to prefer the ULA was to remove its GUA address but keep its v6 default route in place. Odd behavior. I wish I had a Steam Deck to see if "prefer the GUA" is something that appliance vendors tend to do, or if it's just a dubious OpenWRT customization.
The IPv6 behavior of all the OSs I tested is far better than the v4 behavior... predictability is always good. But it is remarkable that even many years ago, Linux was doing the sane thing for v6 address selection, while its commercial cousins and competitors -apparently- hadn't [1] bothered to think through how best to arrange things for "residential" users.
[0] ...even when no 6to4 addresses are configured on the host!
> Advertise the addresses offered by the primary uplink, then retire those addresses
Prefix withdrawal doesn't work reliably on Android. And neither is it required to work, btw. Neither does this solution allow for load balancing, as all traffic will just go through one connection.
Bonus points: triangular routing to your local NAS through the router.
> How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Printers get an RFC1918 address and don't care about global connectivity.
> How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world.
They're not. IPv6 is nothing like IPv4 operationally. Back to my challenge, ULA will NOT work.
The scenario is very simple: the printer gets a ULA prefix and a GUA prefix. Your computer also gets a GUA and a ULA from the same router.
So far so good.
Now the uplink goes down, and the router withdraws the prefix. The printer sees the withdrawal and removes its GUA address. Your computer misses it, and still has the GUA and the ULA addresses.
> Prefix withdrawal doesn't work reliably on Android.
Works fine on the Android hardware I have. Are you attempting to retire prefixes that have an infinite lifetime? That doesn't work, and I don't think it's supposed to work.
> Neither does this solution allow for load balancing...
As I said
Or are you talking about load balancing, which is its own thing? Either way, this situation is inherently *not* boring, so the way you solve it is going to be quite a bit more complex -regardless of IP protocol version- than the very boring single-upstream situation.
> Printers get an RFC1918 address and don't care about global connectivity.
Okay, so why are you complaining about your printer being broken by GUAs that you're not permitting it to have? ;)
> IPv6 is nothing like IPv4 operationally.
For anyone who's not an IP stack developer, network hardware developer, or Enterprise sysadmin it absolutely is. And other than the fact that every endpoint is able to get a global address in v6, the sysadmin-visible differences between v4 and v6 are minor. RAs instead of... well, nothing, and DHCP for both.
> Whoops. The printing is now broken somehow. Why?
Exactly.
Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server? This Just Works™ on dnsmasq, which is one of the most widely-deployed DNS+DHCP servers on SoHo gear. [0] dnsmasq's default TTL for hosts added to the DHCP lease file appears to be 0, so -worst case- your sleepy computer tries to continue its conversation with the printer a couple of times, does ND and discovers that the IP it was using is gone, then looks up the hostname again and gets the new address of the printer. I think the trendy term for this back in the 2000s was "self-healing".
If you're going to retort "But we don't use dnsmasq in the companies I'm sometimes talking about!"... well, if you can't figure out how to not register upstream-controlled GUA addresses for your LAN hosts in your DNS, then do what dnsmasq does and serve them up with a TTL of 0.
[0] To head off the "Android doesn't really do DHCPv6" retort: Even though Android refuses to use anything other than DHCPv6-PD for managed address assignment, -AFAIK- Android still sends DHCPv6 ADDR_REG_INFORM messages for addresses it autogenerates on networks with either the "OtherConfig" or "Managed" flags set. I haven't bothered to set up my Linux systems to do this, but I'd be surprised if Windows and Darwin systems didn't do this.
> Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server?
I don't have a LAN's DNS server or a DHCPv6. BTW, I have had an IPv6-only home network for 10 years, with NAT64 and 464XLAT.
You still haven't solved my puzzle or even understood what's happening. The current source address selection rules result in hosts prefering a GUA address pair over ULA. This _will_ result in broken connectivity when GUA addresses change.
There is currently no standards-compliant way to solve my challenge, except getting an ASN, an IPv6 assignment, and announcing it through your uplinks. Which I've also done in my home network, btw.
And no, this is not a theoretic problem. It affects protocols like SIP or even mDNS that exchange the IP addresses. They will consistently prefer unstable GUAs over ULAs.
Yeah, that's why you think that this is a "puzzle".
Though, it does invalidate every complaint you've made about IP source address priority. The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS [0]. Given that you're not using DNS, then you either have automation to update all those hard-coded configs, or you do it all by hand. Either way, you're deliberately recording addresses that you don't control for your LAN hosts, and considering it a "puzzle" when you have trouble reaching those LAN hosts when your upstream provider changes their address.
[0] Given that every resolver I've ever used pulls data from '/etc/hosts', I'm considering that to be part of DNS for the purposes of this conversation. I'm also considering Avahi and friends to be DNS. [1]
[1] And if you've talked to any long-term Avahi user, you've certainly heard about its habit of -on daemon or host restart- erroneously considering host name of the machine it's running on to be "in use" and appending a "-N" to the end of it. The remarkable eagerness of Avahi to engage this collision-avoidance mechanism makes it entirely unsuitable for discovery of LAN hosts whose hostname is actually important. This fact breaks my heart, but Avahi has been doing this shit for a very, very long time, so it's probably never going to get fixed.
> The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS
mDNS exists. As does SIP and SMB.
I first discovered the ULA/GUA issue when my TimeMachine backup dropped mid-session when I was testing Internet connection failover. Apple later fixed it by allowing multiple SMB sessions in parallel and preferring IPv4 connections. I have a pure IPv6-only network, as I said.
The same issue happens with SIP, as phones send their own addresses during the media connection negotiation.
(I have another funny story about SIP: Asterisk used to send a Cartesian product of available codecs and IP addresses, so if you had IPv6 privacy addresses on, it eventually accumulated enough of them to overflow the MTU, causing connections to silently drop)
> The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6.
The largest ISPs in the US are Comcast, AT&T, Charter, Verizon, T-Mobile, Starlink, and Google Fiber. They all support IPv6. The only top-10 US provide that didn't support it is Frontier Communications, who is rolling it out.
In other words, the biggest companies who actually do this for a living all demonstrate that you're wrong.
As to your questions, read up on IPv6 ULA which solves all of them. None of the hosts on my LAN depend on having an outbound connection.
Having to waste 64 bits for the local part of the address is another one. There's an RFC in progress to allow neighbor discovery with shorter prefixes, so we might be able to use it by 2045.
The only thing that surprised me was that Canada was so small compared to other Western countries. But I suppose that might be an artifact. The map shows IPv4 proportional to land area, but a "fair" allocation would have IPv4 proportionate to population, not land area, and I'd assume Canada is (overall) less densely populated than most other developed countries.
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.
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.
AFAIK you all use imperial pints, which are a little bigger than the ones used in countries that still use the customary system (US and I assume Liberia). I'm pretty sure your pints are the same as those used in the rest of the commonwealth, but corrections are welcome.
That goes back to the fact that the imperial system replaced the older customary system after the American revolution. The US legislated a somewhat simplified version of the Customary System the English were using at the time, which was a piecemeal system based on several different acts of parliament over hundreds of years. We (much) later made slight changes so that our measurements are based on metric.
The Imperial System was instituted in the UK in 1826 and most of the measurements stayed the same, which is why our foot and pound are the same as your foot and pound. The biggest change was that imperial simplified the various liquid measurements to make them uniform. Before then, different liquids used different measurements. The gallon used in the US was originally based on the wine gallon whose value had been last set by parliament in 1709.
Canada also changed over in the 1970s. I was told as a kid that the US had planned to switch with us but backed out at the last minute. I'm not sure if that's true or not. Today, the imperial system holds on in a few places, like heights and weights of people (although not at the hospital) and cooking temperatures.
IPv4 is better than IPv6, and imperial is better than metric. I would like something to replace IPv4, but that thing shouldn't be IPv6 and probably won't be at this rate.
IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
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.
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.)
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 extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.
Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.
No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.
Some of those locations probably did feel more exotic back in the early 90s than they do today... but they're also sensible places to hold international conferences. Where are you supposed to do them, if not there?
IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.
Nobody's stopping you from using DHCP and NAT on IPv6, it's just not the norm.
The protocol itself is literally very similar to IPv4. They got rid of the IP header's checksum, but I don't think that's something you're complaining about, right? They renamed Time-To-Live to Hop Limit because that's what it actually does - is that a complaint you have?
What do you mean it doesn't share any state with v4?
By not sharing state, I mean v6 doesn't honor v4 routes/addresses, DHCP state, and DNS entries. They made all-new address blocks. This seemingly never gets talked about for how big of a deal it is. That makes it so enabling v6 instantly means reworking your entire network, not just speaking a different protocol.
Say I have 1.2.3.4/32 in v4. Let me keep that in v6. Just getting everyone onto v6 is a big enough change without also changing the routes. If I talk to 9.8.7.6 and it's v4-only, fine, the last v6 hop translates to v4. Even DNS doesn't strictly need to change yet. Then let's say enough people get on v6, so I hand out 1.2.3.4.5 to some host. If 9.8.7.6.5 wants to send to that, but there are some v4-only routers in the middle, no problem. The last v6 router translates to v4 dst=1.2.3.4 and puts the extra address bits in the payload, then when it reaches my router, it knows to rewrite as 1.2.3.4.5. Even in this later state, you really only need v6 support on the ends and any routers going deeper than /32.
DHCP and NAT on LAN could share state too. A host at 192.168.1.2 should be able to just turn on v6, it's still 192.168.1.2, some other host gets leased .3 instead, and the router knows to translate if .2 and .3 want to talk. I don't want it to suddenly be FC00::whatever.
I have no complaint about the v6 header, and a subset of the v6 protocol is fine because it's indeed just v4 w/ extra bits like you said. That ipv5/whatever proposal people keep making is doable with most routers/hosts just seeing it as ipv6 w/ DHCP+NAT.
And yeah, today I could use DHCP6 if I really wanted, but it'd mean lots of incompatible devices get either booted off my network or put on a separate SLAAC one, so it's not a serious choice. NAT66 is way more doable but also rare on consumer routers. So my only complaint about the protocol is that the defaults are backwards.
Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
This was not a "mistake":
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.
> Yes it's 3A. They didn't need to make the new protocol have separate state from the old one.
Except there will be a period of time when many 'network elements' (routers, firewalls, servers (web, SMTP, DNS, etc), clients) will not be updated for the new protocol so you may also need 3B.
And this will be true for any IPng, and not just the one that just happened to be chosen to be for "IPv6" (which was SIPP, over CATNIP and TUBA; see RFC 1752).
> Let me keep my old address on the new protocol.
You can/could. You can encourage people who have addresses in the older protocol to use the new one with "free" "automatic" address assignments in the new one to encourage translation and tunnelling:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
And the 'old' IPv4 addresses are available in the new IPv6 world:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
> I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
… except for the fact that you have to have completely new data structures and packet format to fit more address bits, and once you change the structures you need a new version field so any gear that sees a packet knows where to use the old code paths or new ones.
Then you're at the point where you have to push new code everywhere to handle these changes, and some nodes will have only the old code and some the new code, so now you're into translation and/or tunnelling to make sure the old addresses can talk to new addresses. Depending on their risk tolerance, some operators will enable the new code and some will not.
You also have to update DNS with new records, as A records are hard-coded to 32 bits. So now you're updating DNS libraries and user land.
There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through.
I know. All these things were possible and completed for IPv6, but that's only part of the battle. The rest is making it easy for users at various levels to migrate. IPv6 didn't do that, that's why we're stuck in today's situation.
IPv6 added an unnecessary requirement to change all existing routes, which is huge. If still using old v4 addrs in v6, there should be no need to change DNS yet. You shouldn't need a different DNS or DHCP server, only one that supports both protocols (also shouldn't be forced to use SLAAC). V6 translation to/from v4 should be doable at any hop instead of relying on a flaky anycast relay. The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then. Even still there should be no requirement for every hop along the route to be v6, only the ones that go deeper than /32 near the ends. But we got all these extra constraints because of ipv6 design decisions.
Why spend all this energy complaining about v6 not doing something that it did do?
> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then
It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.
IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).
The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.
Wasn't "dual-stack hosts talking over a v4 network" what you wanted?
v4 routers don't understand and can't route v6 packets, so you can't use the same route for both of them. v6 packets have to go to a router that understands v6, and v4 packets have to go to a router that understands v4.
I have no idea what "or a superset in the later stages (shared down to /32, v6-only in deeper subnets)." is trying to say.
It's perfectly possible to turn v6 on without changing anything at all about your networking. When e.g. Windows Vista came out, hundreds of millions of people did exactly that.
Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
I wanted switching to v6 to involve the minimum necessary changes. You keep your old /32. If you're sending from a /32 to a /32, it follows the same path of routers that an ipv4 packet would follow, that's what I meant by same route. There could be a v4-only router in the middle requiring translation, but I'm not even assuming that's a common issue at this point.
"or a superset in the later stages (shared down to /32, v6-only in deeper subnets)": The ipv6 state would be a superset of the ipv4 state. So if a router owns 1.2.3.4 in v4, it also owns that in v6. The ownership of 1.2.3.4.5 below that would only be part of v6 state.
What we got instead was two separate states, or parallel networks. Switching to v6 means changing everything all at once.
> Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
It's not that simple, otherwise they would've done it. They have stuff like multiple addresses, geo DNS, and rate-limiting. Separate issue, AWS was v4-only for a long time and still treats it as more first-class because of how many internal things need to change for v6, well beyond just having hardware + OSes support it.
IPv4 is inherently more user-friendly. IPv6 was designed for a world, in the 1990s, where it was expected that every host wanted to be routable. SLAAC etc were all natural consequences of that. For today's use cases, the v4 NAT public/private thing actually turned out to be nicer than v6 global routing. There's still confusion today about whether devices are exposed on a v6 network because the spec itself says default-deny firewall is optional. They had to recently add privacy addresses. The other kinds of v6 addrs like link-local and ULA add more complexity. V4 addresses are easy to remember, which v6 advocates keep saying doesn't matter but it does. There are all these little network management details that are messier in v6, as you will find on online help forums for v6 advocates who you cannot write off as just being too used to v4.
The v6 spec also has all these alternative ways to use it more like v4, commonly brought up as a cop-out against the above criticisms, but that's actually part of the problem. The spec is too big, and things only implement a subset of it, see Android not supporting DHCP6. Realistically you'll have 99% of people using anything like this the default way, and the spec does define SLAAC, no-NAT, etc as default.
But you could say v6 is better just cause it has more addresses, and that's fair.
...Imperial is better than metric because it lines up with everyday usage better unless you're specifically concerned about the physical properties of water. Especially ˚F vs ˚C. Not a big deal though.
0-100˚F lines up well with weather ranges, and 1˚F is about the smallest diff someone can feel. Many digital thermostats use integer ˚F and introduce 0.5 steps if you switch to ˚C, even in countries where ˚C is default, so they kinda admit it.
Pounds vs kg, similar story as F vs C. Pound is pretty much the human-discernible granularity. Otherwise doesn't matter.
0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
As a Canadian I have no idea what 72˚F means or feels like: is it warm or cold? I do know what 22˚C feels like and how to dress for it. How "intuitive" a temperature number is completely learned behaviour and cultural acclimation.
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
So 'more granularity' is good for temperature but not for speed. Got it.
> The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
By "foot" do you mean 'regular' foot or survey foot:
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.
Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.
I'm not the person you were replying to, but I can answer this one. And yeah, I can see all the metric fanboys (a very small subset of metric users, mind you) hovering over that downvote button, but I don't get paid in Internet points so here goes:
The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
It's difficult to explain to metric folks because it's really something you have to experience. But here's an example:
Reservoir volume in the US is measured in acre-inches. An acre is a unit of area used for measuring property, usually farmland. It's a bit less than half of a hectare. And of course an inch is 2.4cm. Acre-inches sounds totally bizarre when you first hear about it. But for the people that need to work with this value, it's an extremely useful way to measure reservoirs and gives you an intuition that you just don't get from cubic meters.
It's true that you can't just convert that to other units of volume without doing some math or looking up the conversion rate, but that rarely matters. If you're trying to figure out how fast the lake will rise or fall with a given inflow and outflow, you're going to have to have some way to account for the fact that the lake is a) an irregular shape and b) takes up more area the higher the water gets. You already need to know the area of the lake at any particular height to work out the evaporation rate anyway, so that's a number you're going to have. The units are designed to make that calculation easier, which was really important back in the days when slide rules were the state of the art.
All the customary units are like this in one way or another. They're units designed for a particular domain, and when used in their domain they work very well and calculations can be done in your head. They use fractions because that's what people have historically used (seriously - my grandfather could work fractions in his head faster than I could type them into a calculator, and he made asphalt for a living. Imagine what a carpenter could do.).
Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Bonus challenge to the fine folks clicking that downvote button: give me a real practical reason to prefer Celsius to Fahrenheit, besides the fact that Celsius is part of the metric system. No, the freezing and boiling points of water don't cut it - I work with hydrocarbon fuels, I salt my driveway and patio, I don't live at sea level, and quite honestly every American 8-year-old can spout off 32° and 212°. There's a Fahrenheit equivalent to Kelvin (Rankine) so the Kelvin to Celsius equivalence doesn't count either. My claim is that both scales are completely arbitrary, and only advantage one has over the other is that you're used to one of them. Go ahead, prove me wrong!
> Reservoir volume in the US is measured in acre-inches.
Never heard of an acre-inch before, and I'd have to get out a calculator to work out how much water that actually is in pints or gallons, or how much it weighs.
The metric equivalent would be a hectare-meter or a hectare-mm. I know a hectare is 100 m x 100 m, so 10,000 m². So I instantly know that a hectare-meter is 10,000 m³ (10 ML, or 10,000 tonnes of fresh water). A hectare-mm is 10 m³ (10 kL). If my 1 ha block gets 1 mm of rain, then that's 10 kL or 10 tonnes of water. So easy i can do it in my head.
I only know of it because it's a unit used by the US Army Corps of Engineers, who maintain the local reservoir. A buddy of mine's dad worked for them when I was a kid so that lake was my stomping ground.
A couple more to add to your list: an inch is about as long as your thumb joint (with some variation between individuals obviously). It's an easy way to gauge the size of everyday objects without needing to carry around a tape measure.
The recommendation for emergency supplies is about a gallon of water per person per day - or 3.7 liters if you're using metric.
I've also heard it claimed that the 0-100 Fahrenheit scale is more functionally useful because the endpoints of 0 and 100 represent the tipping point of serious danger for humans from hot or cold weather. The closer you get to 100 degrees the more care you need to take about heat stroke and keeping hydrated, and similarly the closer you get to 0 degrees the more care you need to take about retaining heat and staying out of the elements - the freezing and boiling point of water isn't a necessary marker for survival. And people like nice round numbers to serve as markers for such things, divisibility be damned.
Metric is sterile and functional for calculation and consistency, which is fine and necessary for many things, but that's not a reason to completely ditch Imperial.
> The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
US customary is not "thousands" of years; temperature (Fahrenheit) only came out in 1724 for example, and many other units were only standardize much more recently:
Second, even with-in the system itself there was also sorts of inconsistencies. Until just a few years ago there were two "foot" units; one was recently retired:
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces". And let's not forget about the third system [3], which got replaced by… the metric system in 1971.[4]
> Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Millimeters. That single unit gets you down to very small scales (finer than 1/16") and to large lengths: four significant digits (9999mm) gets you to the equivalent of >32' (~11yd).
You misunderstood me. It's based on measurements that people have been using for thousands of years. The Romans had feet and miles, for example - not exactly the same lengths, but for the same purposes. The Japanese shaku is almost exactly the same as a US foot. A Japanese Shō is about half a gallon. A Chinese jīn is just slightly larger than a pound. There's a reason for this.
> there was also sorts of inconsistencies
I never claimed otherwise. But do notice that the survey foot and standard foot weren't used for the same purposes, and the difference between them wasn't likely to confuse anyone except maybe people new to the field.
> Here's another one: which weighs more, a pound of feathers or a pound of gold?
Yep, Troy weights. And no one's sure where the Troy system came from. The main reason for its use is because of international trade. Also not something regular people (i.e. people that didn't work directly with precious metals) would have had contact with.
> Millimeters
Hah! Yeah right. Look at all the various non-metric systems that have existed throughout history. Did any of them use something like millimeters to measure wooden planks? Why not?
> As evidence for this Australia/NZ/EU do everything in millimetres in construction.
They do it because the metric system is mandated there and it doesn't give you reasonably sized unit for that scale of work.
Try this: go to a home center (or whatever it's called there - the place you buy building supplies) and measure some drywall. Do the measurements you made agree to the advertised ones within half a millimeter? Compare the dimensions of drywall sheets from different pallets and manufacturers. Do their dimensions agree to within half a millimeter? If not, that's a sure sign you're using units poorly adapted for purpose.
They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.
1 trillion addresses isn't anywhere near enough[1]. Remember that we're not talking about L2 here. (...I don't think 1 trillion MACs would even be enough if we want to ensure they're unique, and it seems the IEEE agree with me since they expanded MACs to 64 bits, but that's a different conversation.)
And you already don't have to use all 128 bits in v6. You're forced to use about 48 of them, but the rest is your choice. You can just... not use some of them. It's fine.
The world is already managing with 32 bits of addresses plus NAT, and NAT most likely gives you less than 256 concurrent users per address. But sure, if some cheap ISP only owns a few /32s and needs to use more octets, let them do that, doesn't mean my 4-octet address needs to be super long too.
You're kinda forced to use 128 bits in v6 if you're an end user, cause that's the lowest common denominator. SLAAC is default, DHCP6 is widely unsupported. Most ISPs also only give out a /64 per spec minimum.
Will you repeat the whole dance when you need a second extra octet? There are good reasons IPv6 is designed the way it is.
They considered 64 bit addresses at first but they didn't want to ever risk running out again so they doubled it again.
Try to remember it's not just about the sheer number of addresses - you also want to allocate them in big blocks so that few people ever need to expand their blocks, and they can split their big block into more blocks that are still big.
No, the field should be 128-bit to have headroom, but you don't need to hand out /128s to everyone. Everyone with a /32 now would be fine with /32 or /40.
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.
> 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…
IPv6 discussions keep having this scenario - which is barely relevant to how nearly all IPv4 LANs operate.
It's assuming a huge zero-trust point-to-point network where it's a rare scenario for IPv4 LANs. IPv4 LANs tend to assume the internal network is semi-trusted and route through hubs, so merging networks is a bad idea even when the mapping does not conflict (which often doesn't if the companies are tiny like most are). Even in a zero-trust point-to-point environment you'd want to review the other side, convert it to your software, etc. And the people on the being acquired side have little reason to care too.
It's a scenario that's only relevant for a huge company constantly acquiring other companies that operates via zero-trust point-to-point networking and strongly tries to minimize human review - basically Google/Alphabet.
In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.
Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
> In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
IPv6 solves this by making it easy for everyone to get their own 200::/3 address so that when two companies get together they have completely different /48s (or whatever).
> […] but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
There has never been a recommendation to add entropy to 10/8 addresses. At least I have never heard of such a thing. Can you provide a citation for this (alleged) recommendation? Is there an RFC of some kind?
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.
I have encountered multiple IPv6-only domains - certain random domains were accessible through Chrome, but unreachable from any command line tools. Turns out they were IPv6-only, and Chrome was doing its own DNS resolution, while anything that was using the platform DNS stack was hitting a black hole between OPNsense and my ONT.
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.
It's impossible for a long address system to be compatible with a short address system. No one has ever found a way to make it work. Plenty of people think they have, but upon closer inspection, they haven't.
NAT is the only one that actually does work, and it's terrible.
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.
You can still control access. Most home routers have firewalls that work a lot like V4 port forwarding except they don't have to maintain NAT tables or use as much CPU
.
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.
Fun fact: At the Assembly demoparty, every system wired to the party network receives a dedicated, publicly routable IPv4 address. It's a lot of fun, but can lead to some interesting moments. One year as I was getting my setup ready, I had a bit of a heart dropping moment when I realized that the raspberry pi I use to bridge ethernet to my Mac Plus over SCSI, the very same one that usually lives on my home network with all kinds of exciting old daemons running, was in fact reachable on the public internet!
The only real use-case for IPv6 is self-hosting, and that's just very niche. Other than that the arguments in favor of IPv6 turn to stuff like latency and network complexity. That's not nothing, but it won't make anyone change ISP, and so ISPs don't have to care about it.
From the ISP's POV a complex IPv4 network plus a simple IPv6 network is more work than just having a complex IPv4 network. IPv6 is optional, and IPv4 isn't.
The only way I can imagine IPv6 succeeding is if somehow big websites decide to slow things down for IPv4 users enough that they complain to their ISPs.
One thing that was always a curious anomaly for me is Brazil having the second largest number of autonomous systems (ASNs) in the world. [1]
I've been told that this is actually because Brazil has a very competitive local ecosystem of small ISPs competing with eachother on the regional scale.
There is federal funding available to finance the connection of underserved areas, specially rural, so the nature of the problem makes it natural to be fragmented. Also considering how bureaucratic Brazil is, most of the red tape was greatly streamlined for small providers.
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.
Sure, but it's evidently not that bad. And actually safer than firewalls because the default is so strongly deny-inbound. Most people absolutely don't want random devices on LAN to be exposed to WAN, and those with servers can get a public IP.
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.
Hence my having a /64 (/48 in fact, should I ever enable more than the current /64) shows that 64-bits is enough for global addressing. If it wasn't then giving me a /64 would be part of a path to creating an address exhaustion problem just like the one with IPv4 (which was exacerbated somewhat by handing out /8 ranges unnecessarily in the early days).
No worries, I'm happy to have very slightly reduced the amount of confusion in the world (especially if it might have been caused by my previous message not being as clear as I thought it was at the time of writing!).
However many bytes are used in the scheme, you could in theory use decimal or hexadecimal to represent an address in string form for either scheme. Once the string is unpacked and interpreted, the address is just a number.
Though I've never seen a v6 address represented that way, it would make then noticeably longer, so I don't know if anything will accept such a string as a valid address. Though IPv4-mapped addresses are sometimes show as a mix (::ffff:10.5.2.1 for 10.5.2.1) so maybe I'm wrong there.
Likewise I've never seen IPv4 addresses written in hex in the wild, but the relevant specs say it is valid. `ping 0xc0a82bc2` works just as well as `ping 192.168.43.194` but I doubt many forms accepting IPv4 addresses will validate that and allow it.
I have a script that does takes an IPv6 address and displays it as dotted decimal that I like to bring out any time this discussion pops up. As an example, Facebook's IP address:
$ ./ipv6todecimal.py 2a03:2880:f366:1:face:b00c:0:25de
Your IPv6 Address is: 42.3.40.128.243.102.0.1.250.206.176.12.0.0.37.222
Or good old 2600::
$ ./ipv6todecimal.py 2600::
Your IPv6 Address is: 38.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0
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".
Iot isn't what's holding ipv6 back. There are tons of websites and even cloud platforms with totally ipv6-capable hardware and OSes, but the services are v4-only or strongly v4-preferred.
IPv6-lacking hardware and software definitely do exist in the wild, have you seen how some programs from incompetent developers accept only IPv4 addresses in the config files? I think all of us have seen at least one such program.
Often times it's just a matter of using another function to parse the address string. But you are shit outta luck if the program is closed source.
Yeah it's in the wild, but random crappy software isn't the reason all these big services are v4-only. Transitioning from v4 to v6 requires redoing your entire network, except you still have to maintain the v4 side until everyone else has done this. So it's not worthwhile unless you have an easy way to go v6-native and only use v4 at the ends, eg cellular networks.
There's still quite a few pockets of the industry where IPv6 just isn't available. Industrial control systems, for instance - there's lots of PLCs and SCADA software that are still IPv4-only. It's changing slowly, but industrial computing runs on thirty year time scales and there's still a lot of stuff out there that won't even run on modern operating systems. We use 32-bit Windows XP VMs or sometimes even FreeDOS for some of the software we use.
Those devices run in a private network and usually don't have any internet connectivity at all. If they do access the internet, it's usually limited to a few hosts that can easily be routed over some compatibility layer or a proxy.
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.
You don't need 192.168.0.0.0.0.0.1. 40 bits covers the world easily, like 1.2.3.4.5. This doesn't mean the field has to be only 40 bits, could be 128 and you don't write the trailing 0s. Of course this means no SLAAC.
But I don't get why the other commenter was proposing putting the 0s at the beginning instead of the end. Shouldn't the new address space be under the existing subnets?
> 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.
Don't forget you want extra bits for hierarchical routing. Companies like Amazon and cloudflare have many separate address blocks instead of one big one because that's what was available, but it means every router in the internet has to remember all their blocks instead of just one.
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?
Everything in v6 was for a good reason, but it was targeting now-outdated use cases. Separately, there's no good migration path from v4. They should've kept the v4 address blocks in v6, and following the natural consequences of that, it'd be way easier to migrate. But they didn't do this with v6 because they were trying to solve the address fragmentation issue upfront, which again had valid reasoning but in hindsight wasn't the right move.
> 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.
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. :-)
Not really, it assumes people will make IPv5 devices without a reason to. If you can get them to make IPv5 you can use the same mechanism to get them to make IPv4/6 dual-stack.
People already make ipv6 devices, that's not the problem though. It's also maybe possible to do ipv5 with ipv6 hardware at least on the hosts, since the v6 header is totally fine for this.
V4 address blocks, DHCP, and NAT, not SLAAC. So if I have 1.2.3.4 in ipv4, my ipv5 address is also 1.2.3.4. Ipv5 isn't a separate network from v4, it shares all the v4 state, and I can enable without giving it much thought. And once there's enough adoption, I can start handing out addresses like 1.2.3.4.5 that are incompatible with v4-only hosts.
Except you can't enable it because your software doesn't support it.
What you're describing sounds very similar to a NAT64 network. You can address an IPv4 host by 64:ff9b::8.8.8.8
It's not NAT64 or 6to4. An ipv6 host doesn't own such an address; it goes to a relay, and the v6 host is using a random unrelated v6 address. The ipv5 thing is ipv6 natively using ipv4 /32s.
You have 2002:47b1:11ab::/48. If your ISP supports it, packets sent to that /48 will be delivered to you as native v6 packets, otherwise they'll be stuffed into a v4 packet which will be sent to 71.177.17.171. Or there's ::ffff:71.177.17.171 which will reach you using unmodified v4 packets.
That's two different ways your v4 address is present in v6.
I would like 71.177.17.171, encoded as 2002:47b1:11ab:: or whatever static prefix, to go directly to my router as v6 packets without ever being translated to v4. 2002:47b1:11ab:: doesn't do that, it goes to a 6to4 relay and is translated to v4. I'm pretty sure every ISP will at best give you a v4 /32 and an unrelated v6 /64. I don't want that separate v6 address, I want the same logical address for both.
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
There already is a subnet. Actually a few. ::ffff:192.168.0.1 is reserved for when you need to pass an ipv4 address through an ipv6 API (e.g. v6 client application on a dual-stack OS on a dual-stack network) and 64:ff9b::192.168.0.1 is reserved as an actual address for NAT64 gateways to use (v6-only client, network has a NAT64 gateway somewhere on it)
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.
As a small WISP operating within the RIPE region, Are there ways to obtain usable IPv6 address space for customer connectivity (to provide e.g. /56 to customer CPEs) without becoming a LIR and paying the associated fees (Which frankly are unfair considering that companies that hold millions of ipv4 addresses pay the same amount... but that's another topic)?
I currently own a single IPv4 PI /24 prefix, but I am not a LIR.
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.
The scrolling scaling-controller on the map is genius. I wish more maps would add this dynamic ability to scale the logical size when there is a considerable ratio delta to the land size.
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.
Can I have an AI look at my ff::ee::::fa345::32sdfklasd ipv6 address and translate it to something like 192.168.1.4, and have another AI make sure my frikin Amazon Stick isn't exposed to WAN
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.
Amsterdam, specifically Science Park, is basically the biggest internet hub in Europe. Frankfurt is second. A lot of stuff is there. It also helps they don't have overly strict policing like in Germany.
Sure, but even if a provider peers through Amsterdam it doesn't mean their IPs must be geolocated and registered there. It's probably because of favorable legislation.
Also some car entertainment systems with integrated 4G/5G use Dutch IPs. Which leads to the weird situation that I sometimes get dutch radio ads on TuneIn or some websites redirect to the Dutch version.
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.
> 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.
My experience is more the opposite. I keep seeing people say things like "I don't do v6 at home because I don't need it". These people are outright telling us that they're not going to start using v6 unless we make them need it.
Note that I didn't say "migrate to" v6. They're not even willing to do the first step of that ("start using v6"), even with no pressure to do the last step ("stop using v4").
I read an anecdote from Facebook that they had huge trouble getting their developers to stop writing v4-only code. Eventually they ended up removing v4 from their developer machines, who all of a sudden were able to write v6-capable code -- and it didn't take long for them to start asking when they could drop support for v4.
People will moan and moan and moan about v6 until you make them use it, at which point they discover that it was never as bad as they imagined it being.
So you admit that IPv6 people routinely create the problem if it doesn't exist. Maybe there's some nuance where you need to go backwards in order to go forwards?
In any case it's not relevant to the case from the root comment, since the ISP doesn't offer IPv6. IPv6 folk are siding with the ISP here or getting distracted with IPv6.
Essentially IPv6 people are delusional about the state of support of the tech and the extent of issues it brings, there's regions where there's no IPv6 support, so when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.
One of the thing the ISP did was try to upgrade the connection from copper to fiber optics, like instead of understanding the issue, "let's just try upgrading from your OLD technology which is OUTDATED, no wonder you were having issues? Also have you tried turning it off an on again that helps? Talk to you tomorrow.". IPv6 guys so far have been a distraction, get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.
No? It wouldn't be taking this long if they could do that.
The problem in this thread stems entirely from v4: they're being moved onto CGNAT (which is NATed v4), because the v4 address space is exhausted, and this is only a problem because the hospital relies completely on v4. None of these problems were created by "IPv6 people". The IPv6 people created the thing that solves these problems.
This hospital has had twenty years to gradually move things over to v6 which would have rendered the CGNAT a non-issue, but instead they've done zero work towards that and are completely unprepared to deal with the realities of v4 running out. Had they been forced to use v6, they would've be fine.
> when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.
Another opposite. What usually happens is that IPv6 gets blamed for any network problems, even on networks that don't use it.
I've seen people run software that failed to connect to a server's v4 address over a v4-only network due to broken v4, that have then blamed v6 for the problem. The error message from the software was somewhat misleading (it only prints the last connection failure instead of all of them), but even so.
It's usually the people not doing v6 that are delusional about it. Even on HN there's a steady stream of people complaining that v6 didn't do <thing that v6 did do> or that it's impossible to do <thing that's possible to do in v6>.
I do realize that you're likely to hit bugs or lacking support or something somewhere or another, but that's what the past twenty years of gradual transition were for. We've all put a ton of effort into buying you more time to figure this stuff out in. If you squandered all that time and then need to deal with everything after it becomes a big emergency, that's not v6's fault.
> get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.
If you wanted a nice orderly transition, you needed to start doing it earlier. Instead everybody is fighting to be the last person to transition, and you probably won't be able to beat Walmart on that fight.
The professional services that I work with give plenty of notice (years) before turning off services. Were you using an internet connection that's intended for hosting servers? (As in you were paying for a dedicated static IP.) If so, then you have a case.
Otherwise, your arguments about what "internet" is are flawed. IPv6 has been a thing for about 30 years, with a well-publicized problem with IPv4 address space and migration plan. I suspect that it's (IPv6) older than your hospital's contract. Even in the IPv4 world, your IP can change at any time and you can be put behind a NAT. That's why ISPs will sell you a static IP if you need one.
>> why do you need to stick with IPv4?
> To support devices and routes that do not have ipv6 support?
> Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?
After reading your response, I suspect the real problem is attitude and experience. The hospital should have IT staff that know to purchase a static IPv4 IP. This should be part of the contract with the ISP. If it wasn't, ultimately it's up to the IT staff to approach the ISP and arrange to purchase one.
> The hospital should have IT staff that know to purchase a static IPv4 IP
I purchased a static IPv4 IP, and they made the CGNAT IP static.
I thought about making a blog post about it, but I realize there's so much nuance and details. I can't tell if it's just venting about work, or a genuinely interesting clusterfuck in some forlorn corner of the new world.
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;
- dictate that starting on December 1st, all new devices and VMs have IPv6 addresses with all userspace services listening on IPv6 addresses or some nftables rule to kludge IPv6:$port -> 127.0.0.1:$port if necessary, with firewall configured to block that IPv6 traffic, then at a later date firewalls not blocking those IPv6 addresses, then at a later date prohibit any new IPv4 addresses being assigned anywhere with special exception to devices tagged "legacy" or "end of life" requiring documentation of such;
- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team -- in IPv6, multiple local gateways and multiple addresses on a network interface issued by those local gateways via RA is relatively a norm rather than an 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.
Many network engineers at many ISPs would gladly drop all IPv4 traffic if they thought they could get away with it.
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.
Thanks, I'll take a look into the recommended protocols.
One clarification I'd like to make is that IPv6 is not offered, I can only get IPv4 addresses through the ISP DHCP, there is no ipv6 being offered with command 'dhclient -6' for example on linux, neither does window pick any ipv6 up so it doesn't seem to be an us problem.
It's often that Argentinians miss nuances when copying ethical gray areas from the Americans, and without those slight nuances the debate often gets mixed up with a much more subtle debate.
To make a parallel, Trump issued a memecoin days before entering office, it wasn't technically while being president, it was a memecoin so there was no underlying asset, a gray area, see? America.
Now Milei saw and culted the cargo, he made a coin during his office mandate, and he mentioned it would be used to fund Argentina tech projects, so it's an unregulated security. The nuances are lost, and it's just plain bad.
EDIT1:
>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.
>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.
I appreciate the candor
>You and I are total strangers on different corners of the globe.
This is true and it might impact the nuances and extra-technical semantics of the protocol. For example, in here dropping IPv4 support might mean dropping support for older devices, which might be less common in America, ISPs might not support it, so it's not just about the device but the network, to give you an idea I just got off the phone with the ISP which is THE biggest ISP in Argentina, they don't offer IPv6, period.
>If my team were consulting with your organization's execs
Here might be a big disconnect, my organization execs would probably be way out of budget for whatever your org may charge, that would never happen.
If you want to point the salesmen of your org to try and stir some shit up like that with the ISP, then that may make a bit more sense, the budgets may align for importing American consulting, and berating a big org chart that includes engineers might make more sense than trying to replace a 'team' of 1 or 2 fractionalist generalist IT guys on <500$ month contracts.
The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company. IPv6 is not offered to consumers right now.
>we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.
Everything I am suggesting here is what an internal team with full ownership of the network should do. An external team could chisel little by little, and progress the network in phases.
What is shared here is a general direction. I am sure some people I know where all they do is networking could tell me harshly some of these ways could be done better, and often these people are right ; but sometimes these same people are actually wrong and don't fully consider the positions of people in IT roles at companies that aren't ISPs.
All suggested below is not necessarily the ultimate way but a general direction.
_
>> can only get IPv4 addresses through the ISP DHCP
ISP-owned IP addresses, either of legacy IP or IPv6, are capricious and can suddenly change, as you experienced recently.
I suggest to adopt a mindset of "our network" and "their network", rather than functionally have your network be a passive extension of their network by using their IP addresses.
The router announcements (IPv6 RA) or DHCP (IPv4) for any IP addresses within your network should always be issued by devices controlled solely by our organization.
NAT64 and tunnels exist, any upstream ISP is not a blocker.
Modern Linux has eBPF and eXpress Data Path. Both Linux and FreeBSD (use HardenedBSD if you can) have DPDK. They can make for surprisingly high performance edge routers on x86_64 server boxes over a decade old, exceeding what most campuses or even datacenter footprints actually need and at low cost. Even without eBPF & XDP or DPDK, these on x86_64 are often "good enough" for router and firewall.
DNS running on these or adjacent boxes internal to the organization is essential.
The addresses at the gateways, either of IPv4 or IPv6, can be made highly available with VRRPv3.
IPv6 has an elegant way to handle multiple upstream ISPs without VRRP or CARP at the gateways, but even Linux is just recently implementing what may only be a piece of them (the BSDs will later), some mention of them here https://news.ycombinator.com/item?id=50143420
_
What I would do, which is opinionated so I'm not necessarily suggesting others do it, assuming tunneling will be involved: if the organizational wherewithal is there to register an AS and do BGP, is pay the AUD 500 fee to register an AS and have a chunk of IPv6 space for to use IPv6 GUA addresses that officially belong to the organization.
If not, which is often enough the case because we know how some organizations can be slow (not making any assumptions about your's), the remaining avenue is to use IPv6 ULA addresses which are the spiritual counterpart to IPv4 RFC1918 addresses.
You can embed MAC addresses in IPv6 ULA addresses, like the MAC 82c6.7943.acb2 put in an IPv6 like
fc00:5007:6525:2001:3003:82c6:7943:acb2
and use DHCPv6 to always assign a specific IPv6 ULA address to a specific MAC address, where you have thought through the potential information-disclosure implications and you are certain you want to do that.
Then I would use IPv4-only ISP paths for what they're good for: dumb paths to tunnel IPv6 packets to where there is proper internet.
For the option with an AS, BGP announcements on the other side of the tunnel. Personally I would do SCION on the gateways and out the other side of the tunnel, but you don't want to do SCION unless you are also crazy (like a fox).
For the IPv6 ULA option, PAT which is the spiritual counterpart to IPv4's NAT but is also technologically simpler.
With IPv6 ULA and no tunneling, NAT64 and DNS64 can work for outbound.
Site to site tunnels will be tricky no matter what. Tailscale, ZeroTier, Netbird, and similar may be able to do much of the work for you ; these should run in a DMZ on another side of a router/firewall that filters the appropriate IPv6 ULA prefixes.
I would try to see if I could make vanilla Wireguard work with NAT traversal techniques using some cloud-hosted VMs that help with the "hole punching", but not everyone would do that.
There aren't many options that will all work well but almost always more than one option that can work well, all subject to the specific site and inter-organizational resources.
_
>> dropping IPv4 support might mean dropping support for older devices
For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.
With Salt or Ansible, such a scheme with NAT, DNS, DHCP configuration may all be templatized and in perfect alignment, and is scalable.
Authoritative inventory of canonical identifiers/names versioned with Git, what Ansible calls "inventory", is imperative.
Sometimes this looks like a couple of old x86_64 boxes doing CARP (similar to VRRP) on the IPv4 side for a few dozen or couple hundred devices downstream.
Sometimes this looks like, in a handful of distant corners of the larger network, a cheap single-board computer between a single device and the rest of the network ; without a wifi chip or the wifi chip removed by heating (board-repair style), unless downstream of a wifi AP.
_
>> the ISP which is THE biggest ISP in Argentina, they don't offer IPv6
>> The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company.
I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.
Something like this will probably start happening sooner than people think.
>I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.
Yes, there's no shortage of employees that would vote to reduce their workload by removing their service offering, if you ask a physician here if the hospital should stop taking patients of X type, they'd be onboard, less work for them.
It's a dream though, try to make an AAAA request for any website, it's not there, even government websites.
>Something like this will probably start happening sooner than people think.
I'm even trying american companies, like citi.com, walmart.com, there's no AAAA records there.
>For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.
This is an external facing service, so we don't control the devices or routes that patients and external physicians will be accessing the website.
>Tunneling
Yeah, I'm going to go this route, IPv4 tunnel, it's a horrible hack, but this is hacker news after all.
If the www. is prefixed or not, results for domains of Argentina differ. The results aren't almost-perfect like US, but IPv6 is apparently already somewhat prevalent in Argentina.
The list from ChatGPT:
"This 2026 list ranks organizations by LinkedIn employee count, not revenue, and includes public bodies and universities as well as companies. I’ve kept the listed order; entries without a domain in the source are omitted."
Almost all large companies in the US are on IPv6 and more of the smaller companies are on IPv6 than not.
If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1
and run this bash command:
for USCompany in apple akamai att berkshire bestbuy boeing bofa burgerking cnn chase chevron citi comcast costco cvs dell disney fedex fidelity gatorade google goldmansachs gopro hellofresh hilton homedepot infowars in-n-out jcpenny johnsonandjohnson kaiser kroger lulumon macys mcdonalds microsoft nike pepsi petco radioshack safeway shell southwest sprouts statefarm tacobell target tesla traderjoes ups usbank uschamber walgreens walmart wellsfargo wholefoods yahoo aquantuo atlanticseafarms beehivemeals beetlesplumbing dynamicautomotive jamies-farm joeandbella jovyco privacy4cars prosperityehr redroostercoffee resortlifecarts sproutlabs tradedesignbuild
do
echo ${USCompany}
dig +short aaaa www.${USCompany}.com
echo ; done
and this one too
for USent in cia congress dhs epa ice fbi fcc nasa nsa whitehouse
do
echo ${USent}
dig +short aaaa www.${USent}.gov
echo ; done
Then maybe call up your ISP and rant about them allowing your country to devolve into some 3rd world shit hole stuck on legacy IP and over two decades behind the Western countries.
Yeah I had later noticed that too. Much of the US companies do end up resolving to IPv6.
100% of the aforementioned US gov domains resolve to IPv6.
More 5G networks than not are using IPv6 and 464xlat. Many ISPs are IPv6 only too so closer to half the time than not there are IPv6 packets to reach to those IPv4 addresses.
I work for the hospital, occasionally, they are my client.
> You have an actual contract with the ISP, right?
They do not, it's an implied consumer contract, like when someone buys a hot dog from a stand.
I'd like a written contract too, but when trying to negotiate one, they want a lot more money for them, it depends of the nuances of the terms, but I've talked to sales reps, and it comes down to having a 1Gbps line that works right now vs a 100Mbps line that's more expensive, with the only difference being that the contract is now written and there's a symbolic SLA with some 10% penalty, and a single professional beration receiver instead of multiple anonymous on call rotation.
It's not a clear choice, especially considering that the dedicated route with SLA means introducing change risk to the operational and SLA benefit of the ISP, fiber, new holes, new lines, etc..
>You could also update to IPv6.
I would, they don't offer IPv6
>You don't need an address block from an RIR. You just need your ISP to give you an address.
Yeah, maybe. If I get an IPv4 block though what I'd do is a regional entity whether for profit or NFP to offer emergency regional tunneling, potentially while finding alternative revenue streams like collecting lists of wronged ISP customers and notifying them of class action lawsuits they may participate in. A 25K check, or a 5K check with an ipv4 block and I'm golden.
Well if your hospital is running on the cheapest possible internet made for houses, then you have no rights. You should GET a contract that includes what you actually need.
Service was marketed to corporations, (FiberCorp, business branch of FiberTel)
Also, in technical terms the tech is the same, the internet connects corporations with consumers so it's not surprising that the connective tissue is homogeneous, and there is no strict protocol asymmetry (unless you posit that there's an upload/download semantic association with upload producers and download consumers) so if there's any difference between an consumer and a corporate connection, it comes down to raw traffic volume, which in this case is 1Gbps, which both theoretically and empirically has been fine for years.
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...
PSA that if you have a ham radio licence, anywhere in the world, there are IPv4 addresses available for you for the taking at ARDC (AMPR)[1].
You can either get a block of /24 to announce yourself (you've got to cover all the technical setup and costs of this) or use their free 44net.connect service and just organise a wireguard tunnel.
You cannot use it for anything commercial.
[1] https://wiki.ampr.org/wiki/Main_Page
Ok so I was looking at the market rates for ipv4, and it appears that $20 per IP is a common figure, which means that a /24 block is worth about $5000.. so, what's the catch? And how many /24 blocks does ARDC have available, really?
I'm most curious to understand why didn't bad actors gobble up all those /24 blocks already.
You're absolutely correct - it's an incredibly valuable asset.
It's a really interesting piece of internet history. The whole 44.0.0.0/8 was assigned for loose 'amateur radio use' back in the 80s. For the most part it was used for building mesh networks over RF in different locations.
Then IP addresses became quite valuable. Now, I feel that what was really going to happen is that, with no real organisation around it, and not that much use of a very valuable asset, it would have been not unthinkable for the whole lot to have been taken away [by ARIN/ICANN/whoever] and assigned for general use. Certainly easier than taking it away from the US military. So, about a third of this space was sold to AWS and the money used to fund an actual organisation with staff - but mainly to issue grants to amateur radio projects around the world.
They therefore really do have [tens of thousands - sorry I don't remember how to calculate it right now] of /24s available. Internally - they allocate it how they want, some are only used on mesh networks, some are used for infra, some only private networks, but plenty for people to announce.
When they assign it to you, they're only giving you a Letter of Authorisation, and creating a route in a routing DB saying that your ASN is allowed to announce that allocation. They can withdraw that at any time which means the routes will be ignored by others.
Having the ham radio licence requirement is a reasonably accessible, yet robust entry barrier. The catch is you can't use the addresses for commercial purposes. They have staff and volunteers pretty much full time so if they find that they just cut you off.
An interesting parallel is the ham radio frequencies themselves. I love messing around with building equipment and transmitting, but actually getting an exclusive licence for a chunk of spectrum would cost me an impractical amount.
But in many countries (including Germany), you are not allowed to encrypt your transmissions via ham radio, e.g. using TLS with such IPv4 addresses is against the law.
No that would only be if you were to use actual packet radio across the amateur bands with these. Some of them are used for that purpose indeed.
But the ones I’m referring too are just internet addresses you use on the public internet. Eg, ssh-ing to a raspberry pi, setting up an SDR, or just leaning BGP and suchlike.
I have looked into acquiring an ipv4 block many times but never came across this. Thanks for the lead!
> 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.
Sure there's historic reason that the DoD has such a large block, but it is definitely unfair in the modern world. There is no way they need or will ever use their massive block of addresses. They have 13 different /8 blocks, ~218 million unique addresses, that's over 5% of the entire IPv4 address space.
The modern paradigm you're using as a comparison only exists because this network designed for the US military industrial complex was so freely open and fair that it is now used by everyone.
There were and still are are other global networks -- none of them come close to being anywhere near as open or interoperable. What's the next closest, PSTN maybe?
Seen differently, it’s fair for a founder who has relinquished most of their control over the system to retain 5% equity ¯\_(ツ)_/¯
You can always just use IPv6 where there is plenty of address space available. You can even get a /44 as a hobbyist easily
For what cost? Last I saw you had to pay at least a few hundred dollars a year and run enough network infrastructure to justify it.
It's a lot cheaper than ipv4, for the most part.
I have no deep ip knowlede, but if the companys do not use those addresses , cant we just use them an snatch away those unused addresses?
Nobody will peer with you if you start announcing addresses you don’t own, so there’s no way to make those addresses reachable on the public internet.
My take is that the solution here isn't "give India more IPv4 addresses", it's "force more Americans onto CGNAT", so that it becomes untenable for service providers to treat IPv4 addresses as if they're tied to a single user, and to encourage people to use IPv6.
The US is already 55% IPv6, and this figure is only going to go up in future as ISPs decide to migrate their network cores to IPv6 for financial reasons, making IPv4 a lower-performance edge protocol riding on CGNAT on top of IPv6. Similar selfishness elsewhere will start to drive other parts of the ecosystem to IPv6, and the problem will solve itself.
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).
They do this for free because they're a tier 1, meaning everyone pays to connect to them and they benefit from having more things hosted on their network. It's free because your ISP pays for it.
And they can always tell your ISP if they don't like paying to connect to the tunnelling server they should just implement v6.
Unfortunately, he.net tunnels have terrible reputation, so if you use this for your regular browsing, you're likely to get hit with more captchas than if you're on a cgnat with well behaved neighbors. Some sites will just not work, with no errors, because why waste errors on networks with bad reputation.
It wasn't always like this, but it was for me the last time I tried.
I think I had HE and Surfnet tunnels in the very late '90s already. IPv6 sure is taking some time...
Annoyingly, this will not work over CGNAT as far as I know - the tunnel needs 'both ends' to be accessible directly from each other I think.
There are cgnat provides who don’t also give you a real ipv6? Evil.
Your greedy ISP won't provide you with IPv6 for financial reasons - it's cheaper not to change or upgrade systems. This won't change until they start to provide you with IPv6 for financial reasons, as they reach the point where going to IPv6 starts to be a cost saving for them rather than having to run two different networks at once, with a whole bunch of CGNAT to keep the IPv4 part of it going.
Try getting a /24 these days without paying a fortune. We NAT everything and still wait for IPv6 because the ISP CPE barely supports it. Land analogy is apt, landlords everywhere.
My ISP is only a few years old, but they don't support IPv6 at all. And when I complain about it to support, their response is basically "we don't see the point".
Practically everything on IPv6 also has a IPv4 address you can use instead. Adding IPv6 just adds more that can go wrong.
Sure, but if they're a new ISP, chances are they have a hard time getting IPv4 and they likely run CGNAT. If they run CGNAT, the benefit of IPv6 is there's a lot of high volume traffic that will move to v6 and the CGNAT use will be smaller. Routing v6 packets is much easier than tracking connection states and munging packets...
If they have enough v4 for all their customers, sure fine.
It's not just that the ISP will lower their costs for CGNAT, the users will also get a much better experience.
On IPv4 with CGNAT you get blocked and sent millions of captchas because you are sharing an IP with 5 IoT devices actively running a botnet.
On v6 you don’t have that problem.
Well, one benefit is that your users will not get blocked on websites because someone else with the same IPv4 did something suspicious.
This is an interesting take, however from what I seen its other way around. Most security conscious operators would only allow IPv4 instead of IPv6. Your ACL rules and tools are still better at handling/managing IPv4 compared to IPv6
> Most security conscious operators would only allow IPv4 instead of IPv6.
I strongly disagree. That's obsolete knowledge, thrown around by people who want to be considered security conscious but haven't actually updated their knowledge in many years. A statement with similar implications might be "security conscious operators require their users to rotate their passwords monthly", which is what a lot of people use to think a decade ago, and now what it really communicates is that you're talking to a dinosaur.
But IPv6 is complex and inherently globally accessible. Yes, NAT IS not supposed to be a firewall but it works like one nonetheless in many cases.
IPv6 will never replace IPv4 because it is a different protocol rather than merely a new version. The name is a lie.
> IPv6 is... inherently globally accessible.
No, it's not. If you really want a NAT there is no reason you can't use a NAT with ipv6. In fact, it can work even better because instead of using a random port for the translation, you can use a random ip address for each connection.
A random ip address that is globally reachable?
Why would it be reachable? It might be name-able but that doesn't imply reachable.
You're conflating the two parts of NAT: address translation and inbound filtering. A router can block any inbound traffic coming from WAN, even if the IPv6s on the LAN side are public.
In fact, hole punching for IPv4 shows this distinction. By default inbound traffic is blocked, but as soon as private host has opened up a connection, it is (indirectly) reachable and nameable (via the routers public IP + port).
BTW, static IPv4 NAT with public addresses on both sides exists as well.
Addressable means routable. Otherwise the distinction between a Public and Private address becomes one of firewall rules rather than a meaningful property of the IP Address.
And as you say, hole punching is still “PUBLIC IP” + port. Not an IP and any port you fancy unless the firewall was configured correctly.
Maybe I am wrong, maybe you’re confused, maybe IPv6 is just rubbish. Maybe all 3.
You were asking about reachable, not routable. Of course, an address behind a firewall might be adressable and theoretically routable, but it certainly isn't reachable.
The default config of a SoHo router has both: (a) NAT44 separating public vs. private IPv4, (b) and also a firewall that blocks any unknown ingress traffic on IPv4 and IPv6.
From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts: If the firewall is in-place both IPv4 and IPv6 traffic will be blocked. If you open up the firewall (via hole punching or port forwarding on IPv4, or via IP allows for IPv6), I can send packets to your public IPv4 + port and they will arrive at you private server, or I send them to your servers GUA IPv6 and it arrives. There is no security difference.
The fact that the private IPv4 block is not globally reachable counts for something. If I accidentally give you my private IP (192.168.17.102, by the way!) you can't do anything, absent other details, no matter how much misconfiguration occurs. If I give you my IPv6 GUA, there's a lot more variability.
IPv6 has private blocks too. See https://en.wikipedia.org/wiki/Unique_local_address
I “inherently” reachable. You can play semantics but the point stands.
> From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts
This is complete nonsense. Security is about layers and risk mitigation. You know what is better than firewall rules that can be misconfigured or overridden due to conflict or interface name changes and so on? An IP that can be addressed from global space. Wild!
What do you mean globally accessible? All the devices on my network have global IPv6 addresses for the last 5 years - since my ISP enabled IPv6 but none of them are accessible unless I configure it.
“inherently globally accessible” means basically addressable.
Very weird take, and not supported by facts or evidence, but OK.
Do you ever wonder if most people don’t “see the facts” and after almost 3 decades and so much the adoption at 50% might mean to consider if the technology is just rubbish?
I do! But then I ask those people to explain how to go about doing v6 in a way that isn't rubbish, and the only answers I get to that are a) impossible, b) no answer/refuse to answer, or c) they start reinventing v6 but with weird names for everything. Or some combination of the above ("just add two octets and have a flag day" is a common one, combining (c) with (a)).
I've more or less come to the conclusion that the people who think v6 is bad don't know what they're talking about. If none of these people can come up with a better approach than v6, that suggests that v6 really is more or less the best approach available.
> after almost 3 decades and so much the adoption at 50%
I think we all wish it had been faster, but the v4->v6 transition is the first time humanity has ever done a transition like this, on this scale, involving so many disparate networks controlled by so many people in so many countries. How do you know that 50% at 3 decades is slow? Maybe this is just the par time for this kind of thing.
The answer is something like:
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html#sec...
They key things is that pretending interoperability with IPv4 can be an after thought or dual stack is a good idea was just stupid and proven to be so. Flag day or IPv4 fading into oblivion never going to happen.
I know 50% is slow because that is LESS than new deployments over the past 3 days, so if someone thing “better” can be deployed to new projects until all old projects migrate is broken.
I've seen that draft. It's not backwards compatible in any ways that v6 isn't.
The people designing v6 knew from the start that interoperability with v4 was a requirement. It's written right into the list of requirements for v6[1], right in the same place that they say that a flag day is never going to happen.
Why do you believe otherwise? The RFC is right there for anybody, including you, to read.
[1] https://datatracker.ietf.org/doc/html/rfc1726#section-5.5
You don’t understand it then. In V8 every IPv4 address is a valid address, that means you can have IPv4 and IPv8 on same IPv8-lan and first class support for translation into the protocol instead of an array of hacks is a miles better solution than the pile of rubbish that v6 is. In fact, IPv6 isn’t even a new version of IPv4, it is a different protocol entirely and a rubbish one.
Every v4 address is a valid address in v6 too, so it seems it may be you that's lacking an understanding of v6.
Most IPv4 "security" is a side-effect of NAT. NAT was not intended as a security feature, but it does provide a level of security in the common consumer implementation (PAT, single external IP, unroutable internal network.)
Otherwise, what are the practical differences?
There's more that's been written about configuring/protecting IPv4 networks and if you learn about network security from a mentor or from coworkers at a job, rather than reading books/the internet/LLMs, you're more likely to learn about IPv4 security.
But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.
In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.
Blocking /128 is unlikely to block anyone for very long around here. Both the major ISPs give out /56 blocks with prefix delegation. In almost 4 years, mine hasn't changed.
> IPv4 is old and broken
IPv4 is old, very old. But how is it broken? It's literally been working just fine since it came out.
That there are limited addresses is something else: it doesn't mean it's broken.
I don't care that spying/surveillance devices have more trouble spying on me with IPv4 than with IPv6 and I don't care that some apps have a harder time establishing connection.
IPv4 works. SSH over IPv4 works. Browsing the Web over IPv4 works.
IPv4 stopped working fine some 30 years ago. The invention of NAT was caused by IPv4 not working fine (RFC 1631 was written under assumption it's a temporary solution). Hole punching is a thing solely because IPv4 stopped working fine. Much like Y2K, the reason IPv4 appears to work fine is because absolutely massive engineering effort was put to work around the parts that don't work fine.
> IPv4 is old, very old. But how is it broken?
It is broken for you by upstream NAT and CGNAT.
You mean it's fixed by NAT and CGNAT. Because it's works just fine for me.
NAT and CGNAT break the basic idea of how the Internet was designed, forcing everyone into servers and consumers. We've just become used to it, and most people have never experienced it any other way.
The Internet was supposed to be a purely peer-to-peer network, where the addresses on each side of a connection pointed to an end node. That's why protocols like FTP or SIP break when NAT is used, and why you have to play games with port forwarding if you want to run services from your house (assuming you have a public IP address at all).
It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer.
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
We couldn't do it with FTP. That's kinda the point. We didn't have static IP addresses for every machine or the entries in DNS to go with them.
The whole idea of "consumer" and "server" nodes is so baked into how people think about networking they don't even realize it. But that's not how the Internet was intended to be in the first place.
You absolutely can do it within the existing paradigm, in a number of ways, actually. Search for iroh, or DynDNS for example.
And if you seriously believe that Dropbox appeared because of NAT, and not because people prefer out-of-the-box solutions, I can only suggest you to go out of your bubble, and discuss technical issues with random people.
"Intended" btw is not even an argument. Internet wasn't intended for many things which we happily do here.
I'm well familiar with DynDNS. I used to run it before I got a real domain. It can't tell the difference between my laptop and my workstation, since they're both behind the same IP. I wasn't aware of iroh, but having looked it up, it's just a hack to get around problems that NAT has caused.
And yes, Dropbox does exist because of NAT, or more generally the fact that "consumers" are second-class citizens on the Internet. If everyone had a publicly routed address and an entry in DNS - which is how the Internet was originally envisioned - we'd have solutions that don't require a third party server.
Both of your examples just show how deep the Stockholm syndrome is. IPv4's limitations have shifted the way people think about networking so much that they rarely even realize they're doing it. But this isn't the way it was supposed to be. "Intended" is completely valid when we're talking about how something has strayed from its original design and the ramifications of it.
I'm not naive enough to think that we can ever get rid of the "consumer" and "producer" ideas that have crept into everyone's head. But it's important to remember that these ideas came about only because of limitations in the protocol, not because they're some kind of natural law of how global networks function.
> Search for iroh, or DynDNS for example
CG-NAT breaks all this. iroh relies on relays from people with non-broken internet (no CG-NAT).
>iroh relies on relays
Yes, and DynDNS too. Which is fine, cause it works, and that is what I said. The claim to which it replies is that people have to pay to Dropbox cause poor souls were stopped from sharing files using existing technologies like FTP by the damned IPv4, and not because they simply prefer an out-of-the-box GUI thing.
There were out-of-the-box GUI experiences, like Apple's "Back to my Mac", that never worked right because of all the issues with poking through NAT caused by IPv4.
Relying on peer-to-peer relays also doesn't scale, which is why Skype dropped its supernode architecture.
> That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity *BECAUSE IT MADE IT EASY TO DO THIS WHEN YOU'RE STUCK BEHIND NAT TRASH*. By the time it was even a thought in anyone's brain the internet had already been ruined by that garbage.
It would never have existed in a world without NAT because it wouldn't have been needed, syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
Every ISP that has CGNAT v4 without providing full v6 needs to be shut down. They are either incompetent or actively choosing to make their users' service less useful to restrict them and/or encourage "upgrades". Internet service has a public routable IP address, period.
>it would never have existed in a world without NAT because it wouldn't have been needed,
I'm sorry, but this claim is one of the brightest examples of false consenses effect I've seen in ages. People generally just prefer an icon on desktop to click/tap. And that's the reason Dropbox found its audience.
Now imagine if you didn't need that icon and Windows Explorer (or whatever file manager you use) could just connect to wherever your file is. Maybe through a "Favorite."
Then imagine the security implications of trusting windows to serve just some selected files over FTP and never have any security hole that exposed other files or allowed RCE
Yep. That's something we would have had to deal with. I would love to see what solution we would have come up with.
Sadly, we'll never know.
You ignored the second half of that sentence:
> syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
In no way am I denying that people would like to solve the same problems easily. What I'm saying is that it would have been a much simpler problem requiring much less infrastructure. An application like SyncThing that works without any central infrastructure would have been an order of magnitude easier to implement in a world where every internet connected device had a unique routable address.
Only today we would have put everything behind something like NAT anyway because your devices would be getting hacked constantly.
> Only today we would have put everything behind something like NAT anyway because your devices would be getting hacked constantly.
So the security "provided by" common 1:many NAT comes from the fact that 1:many NAT inherently requires stateful connection tracking and by its nature traffic coming in from the "1" side without an associated connection or rule has nowhere to go, effectively denying any other traffic by default from the "1" side which is almost universally the untrusted side.
Do you know what else has stateful connection tracking and deny-by-default rules on untrusted interfaces? Every single firewall that's worth using or even was at one point worth using in a year starting with a "2".
So yes, in a world without NAT we'd still have stateful firewalls blocking unsolicited incoming traffic that had not been specifically allowed. Those who wish to host public services will still need to configure rules to allow that traffic in unsolicited but those rules will be simpler than NAT port forwards because there's no address translation involved. Anything else wanting to generate on demand temporary connections between systems will be able to do so simply by having each system perform a basic hole punch, sending traffic at the other at the same time with the same pair of ports, and expect it to work again in ways much simpler than what's necessary for reliably doing the same in a 1:many NAT environment.
1:many NAT makes nothing better, it only makes things worse. It's a bad thing and needs to go away as quickly as possible.
---
1:1 NAT is an entirely different beast, it can be entirely stateless and thus has no has no negative impact on most protocols that don't try to communicate address info in-band but also that statelessness means it doesn't inherently provide a firewall effect.
> It's slightly unrealic idea though, as most of internet users are consumers, and that's the role they really prefer. That's why Dropbox gained popularity in spite of, you know, the fact that we all can do it with FTP.
Dropbox gained popularity because none of us can or want to bother to do it with FTP, with the exception of a very small and determined minority.
Why do you think that even FANG engineers use cloud storage systems such as Dropbox/iCloud/OneDrive/Google Drive/etc. Can't an elite software engineer put together a FTP server?
Why do you think Dropbox et al are still a thing in spite of projects such as Syncthing?
This is not the only instance where user experience and convenience show their value. Look at Docker, for example. The "aktually" crowd will be fast to say that anyone can do the same with chroot et al, but they will again be missing the whole point. It's the same thing why Microsoft tried to invest in Aspire even though Docker is here.
It's like complaining that people can buy bread when all they need to make their own is flour, water, salt, and yeast. That's completely besides the point, ain't it?
I think you're taking the "FTP" part a bit too literally here. No one's suggesting we'd jump in a terminal and type in FTP commands manually or even use the FTP protocol itself - we've got better options today, and we'd have even better options if the Internet had had global node-to-node connectivity all along.
It'd likely just be built into your operating system's tooling. Your file manager would be able to access other machines it can authenticate to, or you'd automount remote directories on login, etc.
The reason people use cloud storage systems for moving files around is because they have to. A 3rd party server is required because we don't have node-to-node connectivity.
Hell, we'd likely have had cloud storage options sooner because people wanting extra remote storage would totally have been a thing.
> You mean it's fixed by NAT and CGNAT. Because it's works just fine for me.
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
I don't play this kind of games at all, but I still can sympathize with you if it's your preferred pastime, and it doesn't work as good as you'd like. I just don't think it warrants a conclusion that those nets in which we are arguing are broken. They are tangibly, observably doing pretty well. And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
> And I find that the idea that in a shiny world of pure IPv6 central servers/nodes would decentralize themselves comes from deep misunderstanding about what "normal" humans want.
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.
Until a service's WAF catches your /32 because your ISP had previously handed it out to a spammer.
There are working procedures to follow in such situations, and minimally competent ISPs deal with them well enough so that most users don't even know the problem exists.
Back when I managed teams that dealt with API traffic at a unicorn, this wasn't the case. We'd ban a /32 and several times customers would start reaching out to our support portal (which ran behind different ingress rules) asking why they couldn't use the site a couple weeks later.
I've never worked on the ISP side so there's no doubt that there is a process at the competent ones, but my guess is most users do not have a competent one.
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.
I know little of this. How/why could one be higher latency over the other?
Different paths. If you’ve got a “dual stack” on your computer, give it a try.
tracert -4 google.com
tracert -6 google.com
I do get very different hops and latency.
However for “happy eyeballs” algo to fallback to IPv4, latency needs to be very bad on IPv6.
(I work on performance tuning a browsers happy eyeballs implementation)
Especially for DNS, browsers don’t wait “very long” for the AAAA (v6) record to be resolved when they already have the A record (v4) and will start the v4 connection after at max 50ms (iirc thats the spec value, but imo it is too long and most browsers wait less I think).
The good news is that if the AAAA still arrives later it will be cached, thus this only affects the first connection to a site.
As for the actual v6 connection being slower (lets say both A and AAAA come from cache) the browser will start a v6 connection and only fall back to v4 if the connection isn’t established within some time (I think the spec says 250ms).
And to make this all more complicated HTTP1/2/3 enter the decision matrix. I.e. should the browser rather try v4/http3 than v6/http2? Opinions probably differ.
All of this is also on the critical path to a website loading for the user, thats why all of those waits cannot be too long. At some point the benefit of the better protocol will be outweighed by waiting. Even worse if the website doesn’t support v6 and the wait was for nothing.
Is this fundamentally from poor routing from infrequent use? For example, if usage was 50%, would the routing/hops between the two somewhat converge? Or is this actually a "v6 is hosted on a separate server somewhere else" type problem?
Google publish a per-country latency comparison[1]. Typically v6 is slightly faster. (Also, usage is in fact 50% on average.)
But in general, it's mostly because v4 and v6 can end up taking different routes. If an ISP has any BGP peers that are v4-only or v6-only then they can end up sending packets for the same host to different peers. In the worst cases, one of them can go to another country and back again. It's usually harder to get ISPs to fix this on v6 than it is on v4, because the problem is visible to fewer people (in part due to happy eyeballs itself).
For smaller websites, DNS caching can play a role. If there are fewer clients requesting AAAA records than there are clients requesting A records, there's a chance that a client requesting both will get a cached A record back quickly but have to wait for full resolution of the AAAA record. This is unlikely to happen for the most popular sites (because another client will probably have triggered the caching) or for the least popular sites (because the A record will also fall out of cache for those), but there'll be a band somewhere in the middle that's affected by this. There's enough v6-capable clients around these days that I doubt this has a major impact now, but it's interesting that caches can cause unfairness like this.
[1] https://www.google.co.uk/intl/en/ipv6/statistics.html#tab=pe...
Happy eyeballs is more to fix totally broke ipv6 than speed differential.
For many years and even how there are networks that advertise they can do ipv6 and hand out real addresses but nothing works.
The Chinese are having a big push for IPv6 adoption, and, being China, this is likely to actually happen as ISPs follow government orders. But also being China, they are also pushing for 'enhancements' for IPv6 for the usual reasons, which the rest of the world is unlikely to be willing to adopt.[1]
[1] https://www.theregister.com/networks/2026/07/22/china-advanc...
Interesting, never heard of IPv6+. Can't find much in the net about it either. This looks like the offical page, but do you know of any articles where experts anayze it? https://www.ipv6plus.net/IPv6Plus/ipv6plus
What I really don't understand is IPv6 has been around... decades now... why the heck havent we started forcing it more and more?
A large chunk of IT people don't understand it. So they don't demand it from their vendors. The vendors see the lack of demand so they spend fewer resources on it. When someone wants to implement IPv6, they see the limited vendor support and decide against it.
The last three companies I've worked at have all been IPv4 only. I set up IPv6 in our lab, but neither the SCADA software nor the PLCs we use support it at all, and none of my coworkers can troubleshoot it if problems pop up.
I've got a buddy that's a technical manager at an ISP and he'll straight up tell you they don't do IPv6 because he and his people don't know it.
Yep. I run into "enterprise" cloud environments where IPv6 is disabled, all the time. The sad thing is IPv6 is easier to understand than v4, just based on subnetting practices alone. The real problem is the average "IT" person doesn't understand hexadecimal.
Thing is, you can run ipv4 only, dual stack or ipv6 only. Ipv6 only won't work. Dual stack has a larger attack surface and is complex. Ipv4 works but costs a relatively tiny bit of money so far.
Why would you not use ipv4?
At some point, you wont even own the IP, companies will haggle for which IPv4 port you "own" instead.
Not for me. I'm a holder of a legacy IPv4 block.
It's definitely a slight learning curve (a few days at most for basic understanding and troubleshooting). I can't speak to complexities like routing protocol configurations.
But goodness, the infinite-subnets-of-same-size glitch is so amazing. I see companies all the time that struggle to subnet their sprawling enterprise. Different subnet sizes everywhere, fragmented networks, subnet migrations to try to defragment, so on.
Many orgs are so short-staffed and staffed with mediocre talent that they spend their days fighting fires and keeping their flawed current practices operating just well enough to keep the lights on and not cause outages or security breaches. Things like "optimizations" and "redesigns" of the IP stack, even in 2026, would be a 5-10 year journey without a dollar sign benefit attached to it. So they limp along until the transition is seamless and necessary or monetarily desireable.
It's only really a learning curve if you're an expert at IPv4, and try to apply your IPv4 mental model directly to IPv6.
Early bad experiences made a lot of people reluctant to try again.
There's a lot of edge cases to bite people still.
That said, something like 50% of users have working v6 now, which helps to file down the edges. Growth of v6 in the last 10 years has been much more significant than the previous 10 years. I suspect the next 10 years will be pretty significant, too.
I don't think many organizations are in a position to force adoption though.
You have mandates from say US government for government services and vendors and similar in some other countries. Some countries can force it through strong regulations on equipment sales. And then there's Jio (and maybe other ISPs) that have significant market power in some locales and a significant lack of v4 resources and can strongly encourage vendors and partners to support v6 for better service to users on their network.
IPv6 brings more address space but also a whole bunch of other stuff, it is much more complex and changes basically everything to how you manage a network. The fact that it's not been widely adopted after 30 years indicates that people generally think the tradeoff is not worth it.
We're 10 years out from the Epochalypse as well. Past a certain point you need a governing body to intervene to force the issue in advance of problems with systems, and we've got a dearth of functioning governments these days.
Second system effect. It's way more complicated
Replicating even a simple ipv4 lan with mostly stable local addresses and some isp uplink is pretty complex, even assuming all the devices involved support ipv6, which they wont
It's much easier to run a dual stack with v4 for ease of use on the lan and v6 as an additional address that can change whenever and is only used to reach the wan
But the main reason you'd care would be if you can't get a public ipv4 address to NAT to. And if you can't get that, some of the internet breaks anyway.
What I really don't understand is why IPv6 was made so human unfriendly, why not just use 6 three digit blocks? Surely we are not better of now with two parallel IP versions.
There's no way to expand the address space without breaking compatibility. A router is expecting IPv4 addresses, not 10.15.100.252.xxx.yyy addresses. All routers, firewalls, operating systems, programs, smartphones, etc would have to be replaced to support "IPv4 with 56-bit addresses."
Hexadecimal is shorter than the equivalent decimal representation. An 128-bit address would be 10.15.100.252.111.222.333.444.555.666.777.888.999.000.111.222. Use DNS!
Honestly, maybe the real answer is someone needs to make IPv8 or whatever as a better alternative that's easier to adopt? sigh.
Attempts to force it get routed around.
From my readings and limited experience, it's two things.
First, IPv6 in the 90s and 00s is different from IPv6 today. Various extensions and standards have been added that make IPv6 administration easier than it was in the early days. I want to say RDNSS is one of them. Background: one of v6's early selling points was SLAAC, where DHCP could be disposed of and endpoints would auto-configure their own IPs in accordance with the network announced by a router. Problem is, without DHCP, there was no way to get DNS, and DHCPv6 wasn't widely deployed/it was discouraged... so how does one get a DNS server automatically? RDNSS came around to announce DNS servers from the router directly.
TLDR: Early IPv6 sucked more than today.
Second, it's simply a chicken-and-egg problem, particularly at the consumer network level. User-friendly IPv6 router configurations are still rare for home routers, and ISPs have simply dragged their feet. At this point, if we're going to have government mandating all manner of things for consumer products, we should be mandating IPv6 support on home routers and that ISPs delegate at least a /60 to each customer.
You mustn't be on HN very often. People constantly complain about IPv6 being less secure because it doesn't have NAT. And that's part of the reason. Fear and misinformation keeps demand low. The same people don't drive IPv6 implementation where they work, so their fear impacts more than 1 person.
A lot of the original /8 holders have sold off chunks to AWS and other cloud providers.
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.
If you're willing to jump through hoops, you might want to check if it's still possible to setup an EIN and a new SMB T-Mobile 5G internet and get a static ipv4 for a small charge per month.
Personally, I had major issues with the 5g wan equipment and my network as well as a snafu with ordering... Sales rep put in the order for a static ip with a ssn based SMB account, but that got removed during provisioning and couldn't be added back. (And then billing issues because the account didn't get cancelled properly, either)
I converted from residential-class to business-class cable a few years ago. In both cases, I had routable IPv4 addresses.
I was just looking at flipping back, but now it seems the default for new resi accounts is CGNAT. They say they'll give me a real IP upon request at no additional charge, but it's anyone's guess how long that holds out.
They don't do IPv6 at all.
Michigan USA.
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.
I now live in a "western" country and I have CGNAT. It is extremely common here. On the other hand, my ISP (largest provider in the country), in a "developing" country, gave me a public IP so I think there are more moving parts.
I think CGNAT is the default for new connections in .au, since about 5+ years, at least among "younger" ISPs that popped up around the national broadband network crawlout.
You can generally request to get off it though, at ~1-5$/m extra cost.
In my experience they charge for a static IP but not to turn off CGNAT. Obviously depends on the isp but I’ve tried a few.
One of them I had to call phone support and they asked me why I wanted to turn it off. I said I wanted to run a server and they turned CGNAT off on my account.
Bell in Canada continues to offer only IPv4 on their fibre network. I fully expect for them to somehow crap up the transition to IPv6 by putting up CGNAT because fuck you, customer.
Fascinating. The resellers, particularly TechSavvy have ipv6. For TechSavvy I believe it was dynamic /64 by default but static /56 for free on request.
> For TechSavvy I believe it was dynamic /64 by default but static /56 for free on request.
"On request" meaning you told your CPE equipment to send a DHCP-PD packet, i.e., you didn't have to call them and ask for something special with your account.
I did phone them to request the static /56, and to assign PTRs. I didn't try requesting the /56 before I called them so I can't say whether that would have worked or not. If you're saying it would have I'll believe you.
> "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.
and one of the countries has an over-reported while the other is underreporting
China mandates IPv6. So does the US, but the US drags their feet. Meanwhile in Europe it's near universal even though not mandated and no v4 shortage.
>Meanwhile in Europe it's near universal
False: https://stats.labs.apnic.net/ipv6
On HN, 'In Europe' means in one person's particular locale based on their experience and generalised across a continent of about 30 countries. But it's always better than in the US of course.
Can we stop this europe/us fight? This remark was completely unwarranted
I wrote this as a European (British) who is living in another European country (Finland). People happily write ‘in Europe’ whilst being quite selective in their definition of Europe - usually their very close neighbourhood, and it usually means North and Central Europe. If that.
I’ve seen some truly unhinged takes here, my favourite ever being something along the lines of European cars not having cup holders because we don’t have drive-throughs in Europe… I have driven my Volkswagen across this continent and enjoyed many a hot beverage on the move.
I’ve come to learn that discussions on a lot of things, in English, usually end up as a comparison to the States, especially if it involves the healthcare sacred cow.
Downvote me more for trying to be peaceful, redditors
I wish, just 37.73% of IPv6-capable users in Europe according to APNIC despite much higher availability in transit AS. Highest subgroup is Western Europe at around 72.09%, which is still far from near universal. Similar per-country numbers from Cisco.
Unless I've missed something, the US only mandates it for government networks. I don't think there is any mandate for private entities to implement it.
I thought they now nominate TSIP trump super IP
A residential network that can't connect you to government websites is called a fraudulent business model. No different from selling a car that only transports up to 20kg.
I guess I should clarify: the government mandate is that government sites are dual-stack. They have to support IPv6 in addition to IPv4.
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.
CGNAT is awesome, you cant IP ban me anymore and I dont need a VPN turned on for silly things, and I can control fingerprinting (mostly), CGNAT is great for anonymity. If I want a static it cost me ~10.00 a month, im fine with that.
On the other hand, sometimes you get randomly banned due to someone else’s action on the CGNAT IP. Wikipedia is an obvious example.
Thats the only site Ive encountered issues. Im okay with that. I dont think they just let anyone edit anymore anyways.
i purchased a dedicated ipv4 from my isp.
an ipv4 for every man woman and child!
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
"swept under the rug with CGNAT" is a really funny way to say "solved by IPv6"
what is the meaning (or units) of your first numbers?
Diamonds and IPv4 share a common trait.
Lab-grown diamonds found a strong role as industrial components, which expanded overall demand for diamond materials and widened their use cases. IPv6 may follow a similar path, with adoption concentrated in newer and novel applications where IPv4 addresses were scarce.
IPv4 seems likely to remain in place for many existing applications, much like natural diamonds in jewelry, regardless of policy/advocacy views.
From a Georgist perspective, IPv4 is actually a form of land (it's a finite "natural resource", although that's not quite proper), and you could make a case for "land rent" being taxed on the addresses. This is the same as radio broadcast frequencies, web addresses, actual land, un-mined gold/oil/coal/whatever, and other finite natural resources that create monopolistic tendencies.
Wait do georgists describe any "finite natural resource" as "land"? Is clean drinking water "land"? Are radio frequencies "land"? Are domains "land"? (I mean domain names aren't "natural" but neither are IPv4 addresses????)
Weird-ass ideology
Georgists don't literally think that other scarce natural resources are actually land, but instead think that all scarce natural resources, if untaxed, lead to economic rents being extracted. Land/location ownership is probably the most damaging form of this, so it's the one that Henry George focused on, but the same basic principle applies to other natural resources.
This is why people refer to Norway's taxation of natural resource mining as "Georgist in principle" even though no land value tax is involved.
I (and I'm not original here) extrapolated that to other not-natural resources like IPv4 addresses, domain names, and so on that function much like a limited natural resource.
You even have cases of "land-banking" like nissan.com, although I don't believe Mr. Nissan ever intended to profit from owning the domain name; probably more akin to the main character of the movie Up.
Money is a scarce resource and should therefore be taxed.
You could say that it's intentionally kept scarce, and that is somewhat true, but currency is kept scarce because it only functions if it's scarce. Currency without scarcity ceases to be currency.
The ideology is amazing.
The terminology is terrible.
But yes. When they say land they actually mean "natural resource".
The idea is that human-made resources should have their profits go to humans, but natural resources (most notably location value) do not belong to humans because humans did not make them, and also, the economic incentives normally associated with markets such as supply/demand management and price discovery don't apply because supply can't change.
Its extremely economically efficient and is endorsed by many economic thinkers on both the right and the left, as well as many social justice activists.
This is a decent recent video on the concept as it pertains to location value: https://www.youtube.com/watch?v=suiU5b9tmoE
Nah the ideology is just rich people or wannabe rich people wanting less taxes. Having a land value tax makes sense, removing all other taxes does not.
No - it would have exactly the opposite effect.
Many georgists propose LVT + citizens dividend which is in effect a better version of a wealth tax with UBI - meaning it would be highly re-distributive from the asset-rich class to the asset-poor, and therefore very positive for inequality.
Nobody who claims to be Georgist or support Georgism seem to agree what it actually means. I'm following the traditional definition of having only a land value tax. If you want to propose something completely different you can do that, but I don't even know what "Georgism plus a bunch of extra taxes" is supposed to be mean.
Please stop spreading misinformation.
Citizens dividend has been a core idea since literally Henry George: https://en.wikipedia.org/wiki/Henry_George#Citizen's_dividen...
Just because you don't know what it means doesn't mean they don't.
Nowhere in what you linked describes this as a wealth tax. That link just describes paying people a UBI from the income generated by the land value tax. There's no mention of additional taxes.
Seems my understanding of Georgeism was correct after all. Maybe you're the one who should stop spreading misinfo?
Or did I miss the part where it proposes non-land-value types of tax?
Whereas IPv6 is effectively unlimited, so by Georgist principles should be free. I wonder if charging 'rent' on IPv4 addresses would be enough to get people to switch over?
My hosting providers gives you IPv6 for free, whereas IPv4 costs ~3€/month. It seems like a no brainer, until you realise that many clients wouldn’t be able to find you with IPv6 alone.
So I don’t see how to fix this except at the ISP level (forcing them). No one is preventing this but the providers.
If you tax it, you get less of it.
Yes, but 'use' rather than 'get'. If you tax land or other natural resources, people use less so there is more for everyone else. It doesn't pay to hoard or speculate.
Incidentally, auctions of time bounded licenses, which are what we use to allocate frequency spectrum, have the same theoretical pareto efficiency as a value tax.
Surely that would assume low/predictable volatility thought right?
If the probability changes over time that the price might go up and back down for a 6 month period which is bounded inside of a single auction-able period, then the auction would not have ever captured it correctly... Low frequency auctions assumes perfect risk prediction which isn't realistic and comes with large insurance and analysis overheads.
>IPv4 is actually a form of land (it's a finite "natural resource", although that's not quite proper),
It's closer to radiofrequencies I think, these are heavily regulated.
However radiofrequencies are purely natural resources, while IPv4 have a specific copyrightable spec design, domains have trademarkable TLDs
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.
> 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.
ah yeah, golden times of crawling google when they actually didn't monitor ipv6 traffic properly against scraping (seo monitoring tools were first to drive 'adoption', lol)
I don't know what you count as “golden times”, but at least when we started the measurements, there was no indication bot traffic would drive up these stats at all. (You wouldn't trigger it just by fetching a search result page.)
I wonder how they measure.
I don't know exactly how they _measure_ since I'm not working in IPv6 in Google anymore, but I know how we _measured_ when we started these stats:
https://research.google/pubs/evaluating-ipv6-adoption-in-the...
Thank you. It's been a while since that paper was published )
I was interested in the number for Russia; 2 out of 4 mobile networks do not provide ipv6, and wired network ipv6 availability depends on provider; provider-supplied routers generally disable ipv6 anyway. So the 78% seems high.
Could be that this is measured from youtube; people use vpns to go there, and those typically have ipv6. That would mean that country is tracked by account, not source ip.
(apparently, the same page showed 9% for Russia in early 2025, so, yeah, low trust)
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.
That's very surprising. Cloudflare supports ipv6 and it would be surprising if only 10% of websites you visit use Cloudflare.
I guess a lot of sites just turn it off. Even if Cloudflare proxies it over IPv4 the IPv6 source address still shows up in server logs. Features like geolocating users or fraud prevention might need additional work for IPv6.
> ...IPv6-only should be plug-and-play by now.
The obsession about "IPv6 only" has never made sense to me. Any decent firewall software will let you write rules that apply regardless of IP version. The "software complexity" argument is bunk... you already have v4 and v6 IP implementations in your OS, and every major OS has provided IP-version-agnostic socket interface code for much more than ten years. If you are using software that is IPv6-capable, it's very likely that it's using IP version agnostic library functions.
Unless stewardship of the Internet is wrested from the hands of the responsible, level-headed type of folks that run it now and transferred to the hands of folks who think nothing of making backwards-incompatible changes every six months, IPv4 won't stop running across the Internet within the lifetime of anyone who's currently reading HN. This delay is fine. The only thing about IPv4 that's a problem is that its address space is 32 bits wide. Had it been defined with a 128+ bit address space, we wouldn't have seen another version of IP on the Internet. Now that IPv6 is around to reduce address pressure, there's no big need to do anything about IPv4.
I believe the folks worrying about IPv6 only are just looking ahead to a possible future. Especially when they are looking at the question of do all the pieces work locally, vs do popular domains support it.
There are domains like T-mobile US that are IPv6 only already. T-mobile runs NAT in the network so that all of IPv4 is NAT'd to IPv6.
I do think it is reasonable to expect there will become a time when IPv6 is pervasive enough, that new deployments will target users with IPv6 rather than IPv4.
Once IPv6 becomes the choice to support to get new customers, it is reasonable to expect that IPv4 support will start deteriorating and will eventually fade away.
I will be very surprised if we don't hit that tipping point in my lifetime. Say the next 30 years.
> I believe the folks worrying about IPv6 only are just looking ahead to a possible future.
I'm certain that that is not what the folks who scream very loudly about how IPv6 has been and continues to be a colossal failure because it's not the only version of IP on the Internet are doing.
> I do think it is reasonable to expect there will become a time when IPv6 is pervasive enough, that new deployments will target users with IPv6 rather than IPv4.
Sure. That's the future I find most plausible: For "residential" connections, provide IPv6 GUAs and IPv4 via CGN... [0] for "commercial" connections, provide IPV6 GUAs and give the customer the option of one or more IPv4 GUAs.
> I will be very surprised if we don't hit that tipping point in my lifetime. Say the next 30 years.
I do hope we get to that point within the next five years, if not ten! But notice that my claim is that IPv4 will still be crossing the Internet after everyone reading HN today is dead. [1]
[0] I'm calling the various mechanisms that only provide an IPv6 address to an end user and do fancy gyrations to provide IPv4 access "CGN", even if might not strictly be CGN.
[1] ...as long as the the responsible, level-headed type of folks that run it now aren't replaced with the "making backwards-incompatible changes to everything every six months is A-OK!" type of folks.
I can totally understand why. IP addresses are hard to get for a large chunk of the global population. There's twice as many people as there are IP addresses.
Plus dual-stack means more work, and more possibilities for misconfigurations or vulnerabilities in your network. It'd be way easier if you only had to worry about one or the other.
I live in the US and my ISP gives me one address I have to share across all the machines in my house. That's a tragedy - by all rights I should have a subnet or two. You can't directly address any of my servers from the outside on IPv4 which means I have to do hacky crap like port forwarding and can't use a lot of the older protocols that aren't NAT friendly. And I've got it good compared to most of the world!
IPv6 gives us back a large chunk of the original premise of the Internet - that all nodes are peers. IPv4 hasn't been able to do that for decades, and it's warped the way we think about networking by separating everyone into consumers and providers.
> Plus dual-stack means more work, and more possibilities for misconfigurations or vulnerabilities in your network.
Nope. Your OS vendor already did the work to make both versions of IP work. And as I mentioned, if you're using a decent firewall you can write IP-version-agnostic rules just as easily as you can ones that depend on the version.
Plus, most SOHO firewalls default to dropping unsolicited non-ICMP traffic. That's the exact same security stance that IPv4 + NAT gives you. You have to go out of your way (or be using fancy gear that is aimed at people who know what they're doing) to expose your LAN hosts.
My OS vendor didn't set up my firewall rules, lay out my subnets, or configure my routing. I did that. Twice. Because I've got a slightly more advanced network layout than your typical home user. And that's all much less complicated that what your typical corporate network would be, which is much less complicated than what an ISP or COLO provider has to deal with. And then there's the cloud...
Yeah, sure, if your requirements can be met by a cable modem, then you're basically good to go. Until DNS breaks for some machines and not others, and it's because your ISP screwed something in their IPv6 routing but it still works on IPv4. Or Microsoft's authentication servers decide they don't like your IPv6 subnet anymore and Minecraft refuses to start unless you turn IPv6 off. Or... You get the idea.
> My OS vendor didn't set up my firewall rules, lay out my subnets, or configure my routing. I did that.
Wow! Me too!
> Because I've got a slightly more advanced network layout than your typical home user.
Mine's quite a bit more advanced, if we're being frank. Though, the way I have things set up should be the default for SOHO stuff. This sort of configuration really is something whose setup can be automated, but never will be for as long as dumbswitches are the go to for SOHO equipment.
Anyway. I guess you and I just have dramatically different opinions on what's difficult. ;)
Possibly. Or maybe you and I did a dramatically different amount of work on our networks. My setup is very much not what should be default for SOHO, for instance.
My point wasn't ever about home users anyway.
And Windows 11 now supports CLAT.
But it's not really useful until it has critical mass at say 80 or 90%.
IPv6 is dead. Nobody cares about it.
I will believe otherwise once even one US hotel chain supports it. I have _never_ seen a hotel in the US with IPv6 WiFi. Not once.
And I once stayed in a hotel (in Mountain View, CA) that gave out public IPv4 addresses.
Last time I was in a California hotel, it had IPv6 just fine. That was 2012. Perhaps you choose the wrong hotels :-)
You should try staying at small boutique hotels. They tend to just sign up for a regular business internet and you’ll get IPv6 that way. Large chain hotels want central management and their management isn’t modern enough to support v6.
> IPv6 is dead. Nobody cares about it.
Except for everyone on T-Mobile US:
* https://www.youtube.com/watch?v=d6oBCYHzrTA
Or all of FaceMeta's internal infrastructure:
* https://engineering.fb.com/2017/01/17/production-engineering...
Or 86% of France:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
Okay, if you say so. Hotel Wifis are known for being on the bleeding edge of technology, and as the main innovator pushing new internet technology. Everything starts with hotel Wifis. /s
Exactly my point. IPv6 failed to reach the "boring, just works" level after 30 years of deployment. So much so that we are now deploying solutions with 10+ years of expected service lifetime that do not support IPv6.
Meanwhile, CGNAT really solved most issues with IPv4. Yes, even the voice/video chat issues.
Want another fun example? Try to find a SIP telephony provider in the US that supports IPv6. Go on. I do this exercise about once a year.
> IPv6 failed to reach the "boring, just works" level after 30 years of deployment.
/me glances over at my phone, which only has an IPv6 address when connected via cellular modem.
/me thinks back to the decade+ of incredibly boring IPv6 service from the residential ISPs I've used.
Sure.
If an ISP wants to provide only IPv6 addresses to CPE, they can set things up so that happens. But if you won't be satisfied until IPv4 no longer passes over the Internet, then you're going to die unhappy about that. The goal for our lifetime is one where every residential site has a global /56 and is behind IPv4 CGN, and servers hosted by commercial entities get to choose whether they assign IPv4 addresses, IPv6 addresses, or both to their servers.
/me searching through all the mobile network providers in Switzerland (a technologically advanced country) and not finding any.
Seriously, this drives me mad. There is NO WAY to get IPv6 on mobile networks in Switzerland. Neither Swisscom, nor Sunrise, nor Salt, and of course no reseller.
And Android handles this particularly poorly. I have some servers set up in my tailscale network on private IPv6 addresses, but android doesn't query AAAA addresses if it has no ::/0 route, so I HAVE to route all my traffic through my VPN which often creates other complications (with corporate wifi etc.)
I am in the same situation. However, I have found that there's a workaround/hack to make Android 'think' it has IPv6 connectivity. Instead of routing ::/0 through your VPN, simply add these two routes to your devices:
They don't need to be actually accepted by your VPN. They only need to exist in Android's routing table for it to start using AAAA lookups.The drawback is that this breaks happy eyeballs, and you may notice slower response times on requests (since now your phone will start by quering AAAA results first which always fail for sites not on your VPN, and then fall back to the A result). In practice however I haven't really noticed any difference.
I get your frustration. But not having access to IPv6 personally does not mean IPv6 is dead. It's very much alive and handles considerable amounts of traffic.
Well ok, not dead. Dead sounds final and I still think that we will get more IPv6 deployed in the future. And I set up all my servers as IPv6-first. So no, I don't think IPv6 is dead.
But I'd claim it failed completely. Many very public services (eg. github.com, sentry.io, office365.com, archive.org) outright don't support it. And the fact that infrastructure providers (like mobile network carriers) don't support it either, proves that it is far from "alive". In fact, I'd say it is deader than MMS, Fax and landline. For these I can still get service. For IPv6 (on the phone) I can't.
It only failed to fully replace IPv4. But it runs perfectly fine along IPv4 and is very much alive. It replaced IPv4 where it was needed and didn't where it doesn't matter yet.
Email didn't replace letters on paper. But I wouldn't say email failed completely.
> ...and didn't where it doesn't matter yet.
Given the number of scaredy-ass ISPs out there who refuse to offer IPv6 service, I disagree with this. But I do strongly agree with the rest of your comment.
I also very strongly assert that claims of the form "IPv6 is not the only version of IP used on the Internet, therefor it is a complete failure." maybe with a side of "And this 'failure' means that IPv6 is a dead protocol." are just plain stupid. v4 and v6 were very deliberately designed to coexist, and if v4 continues to run on the Internet until the day the Internet is shut down, that's totally fine.
In my opinion, the most plausible future is one I mention in my second paragraph here. [0]
[0] <https://news.ycombinator.com/item?id=50297244>
To be clear, 'TobTobXX' isn't 'cyberax'. 'cyberax' is claiming that IPv6 is dead, whereas 'TobTobXX' is -quite justifiably- complaining that both his local cellular ISPs and Android suck.
You're welcome to try to solve the challenges from my sibling post. Both of them are solved in IPv4 by a $100 router from a nearby store and with zero configuration.
> You're welcome to try to solve the challenges from my sibling post.
Check my reply to your post. [0] I wrote it up before I noticed your message here. ;)
[0] <https://news.ycombinator.com/item?id=50295293>
I don't get your point. IPv6 is at "boring, just works". The majority of the worlds devices run on it dual-stack and it handles a considerable amount of traffic. A lot of 5G networks run on IPv6 single stack with IPv4 compatibility on top.
IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
> I don't get your point. IPv6 is at "boring, just works". The majority of the worlds devices run on it dual-stack and it handles a considerable amount of traffic.
Most of the world runs on IPv4. If we shut down IPv6 on the core routers tomorrow, pretty much nobody is going to blink an eye. And now I believe that we should do it and start again.
The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6. Mostly because there's not enough private or even squattable IPv4 space available for many large mobile phone operators.
> IPv6 is very much alive. And it's so boring and working so well, that you don't even notice it.
Sigh. No, it's not. In a thread a couple of weeks ago, I gave several examples:
1. You're a SOHO-type business. How can you do multiple WAN uplinks with IPv6 without NAT?
2. How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
For context: I deployed IPv6 in my networks in 2006. I have war stories.
> How can you do multiple WAN uplinks with IPv6 without NAT?
Advertise the addresses offered by the primary uplink, then retire those addresses [0] and advertise the secondary when the primary fails. Or are you talking about load balancing, which is its own thing? Either way, this situation is inherently not boring, so the way you solve it is going to be quite a bit more complex -regardless of IP protocol version- than the very boring single-upstream situation.
> How do you prevent your printer on IPv6 from breaking when your Internet connection goes down?
I'll flip this around on you:
How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Obviously, you use the ISP-assigned globally-routable IPv4 address and also assign an RFC 1918 address to the printer.
How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world. Just like in IPv4, IPv6 globally-routable addresses are for global communication and can be used for LAN-local communication. And -just like 1918 addresses- ULAs are for LAN-local communication. Just like with IPv4, if you can't control the addresses that you get from your upstream provider, and/or if your router is set up to retire your upstream provider's delegated address space when your upstream link goes down, then you use ULAs. [1]
I know that OpenWRT has a setting in LuCi to enable advertisement of a ULA prefix, and fifteen seconds of searching revealed that at least some Linksys combination router/APs seem to just generate and advertise a ULA prefix by default. [2]
So, if you're not configuring your LAN this way and upstream provider renumbering is getting in your way, then you really should bother to.
[0] ...by advertising their valid lifetime as zero seconds...
[1] ...or if you happen to like to be able to assign fixed IP addresses to certain pieces of hardware...
[2] <https://support.linksys.com/kb/article/3744-en/>
> Use ULAs
Isn't that the default for modern routers? They just generate a random ULA during setup and assign it.
Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps. Everyone setting up their LAN on 192.168.0.x makes it quite a mess on IPv4.
> Isn't that the default for modern routers?
I assumed so because it's the obviously correct thing to do, but I haven't used a SoHo router in so many years, so I don't know.
> Random ULAs are also great for LAN-to-LAN VPNs, because there aren't any private IP overlaps.
Yep! Extremely low chance of prefix collision is their most important purpose. I've been part of several corporate acquisitions, and it inevitably took 6->18+ months to do enough of the IPv4 renumbering and server-discommissioning [0] process to begin to merge the LANs of the merging companies. Had they used ULA addressing, the odds of having to do that massive amount of work would be effectively zero.
And if collisions aren't something you give any shits about, nothing stops you [1] from setting your ULA to fd00::/48 and advertising fd00::/64 on your LAN for static IP addresses that are notably shorter than you can get with IPv4!
[0] ...because there's so little space in the 1918 range...
[1] ...well, unless your router's configuration system doesn't let you specify your ULA prefix...
ULA are useless for most practical purposes because of the source address selection rules.
There is some truth to it, because they only work well if used directly (either hard coded IPs or DNS).
This problem seems to be addressed already and might be solved in the future: https://datatracker.ietf.org/doc/draft-ietf-6man-rfc6724-upd...
(once again it's surprising how long it takes to clear up all IPv6 quirks)
> ULA are useless for most practical purposes because of the source address selection rules.
/me glances over at my LAN which has been happily using ULAs for local communications and GUAs for global for the past I don't even know how long.
_Sure_.
The problem is real. In IP discovery GUA is prioritized over ULA. And if the GUA goes away or changes regularly it leads to connectivity issues.
ULA work well in combination with DNS though.
> In IP discovery GUA is prioritized over ULA. And if the GUA goes away or changes regularly it leads to connectivity issues.
Sure, but you're generally not going to get both addresses associated with a single host unless you either hard-code them or use DNS. For any non-stupid network, source address selection for reaching LAN hosts doesn't really matter. And for many-to-most SOHO networks, you're going to be running dnsmasq, which will quickly set you right after any GUA change.
And like, the thing to be noticing here is that source address selection priorities for both IPv4 and IPv6 seem to give us the same actual behavior. Consider a pair of hostnames served up by BIND 9 and some applications running on bog-standard Gentoo Linux whose '/etc/gai.conf' contains only comments and blank lines:
Notice how actual application behavior doesn't match what folks in this thread are saying that source address selection dictates. Android behaves the same way, and -weirdly- my OpenWRT hosts have the exact opposite behavior and prefer using global addresses to ULA or 1918 ones, regardless of IP protocol version.Anyway. If he put both IPv4 GUAs and 1918 addresses in DNS or his '/etc/hosts', he'd be having the same problem he's complaining about here... depending on -I guess- the OS he's using and how his resolver treats the ordering of entires in '/etc/hosts'.
This isn't an IPv6 problem, this is a "Things break for a little while when I use addresses to communicate with a host that can change out from under me instead of addresses that I control and those addresses happen to change." problem.
> ULA work well in combination with DNS though.
Yep! Most everything works great with DNS. Remembering IP addresses is for the birds.
The 'getent ahosts' output remains unchanged.
When dealing with IPv4, all Linuxes, Android, and Windows 10 intermittently switch between preferring the GUA or the 1918 address. I seem to have gotten unbelievably (un?)lucky when testing v4 on Android, Gentoo Linux, and OpenWRT the first go around.
When dealing with IPv6, Android and Windows 10 always preferred the v6 GUA to the ULA. Every Linux I tried -and I tried several, each from different distros, some with and some without systemd, spread across years of releases- always preferred the ULA to it... except for OpenWRT, which always preferred the GUA. The only way I could get OpenWRT to prefer the ULA was to remove its GUA address but keep its v6 default route in place. Odd behavior. I wish I had a Steam Deck to see if "prefer the GUA" is something that appliance vendors tend to do, or if it's just a dubious OpenWRT customization.
The IPv6 behavior of all the OSs I tested is far better than the v4 behavior... predictability is always good. But it is remarkable that even many years ago, Linux was doing the sane thing for v6 address selection, while its commercial cousins and competitors -apparently- hadn't [1] bothered to think through how best to arrange things for "residential" users.
[0] ...even when no 6to4 addresses are configured on the host!
[1] ...and still haven't...
OK, do you _think_ my questions were that easy?
> Advertise the addresses offered by the primary uplink, then retire those addresses
Prefix withdrawal doesn't work reliably on Android. And neither is it required to work, btw. Neither does this solution allow for load balancing, as all traffic will just go through one connection.
Bonus points: triangular routing to your local NAS through the router.
> How do you prevent your printer from "breaking" when its ISP-provided DHCP lease on its globally-routable IPv4 address expires? How about when the ISP refuses to renew the lease on the printer's current globally-routable IPv4 address and forces it to get a new one?
Printers get an RFC1918 address and don't care about global connectivity.
> How to solve this with IPv6? Use ULAs! They're the equivalent of 1918 space in the IPv6 world.
They're not. IPv6 is nothing like IPv4 operationally. Back to my challenge, ULA will NOT work.
The scenario is very simple: the printer gets a ULA prefix and a GUA prefix. Your computer also gets a GUA and a ULA from the same router.
So far so good.
Now the uplink goes down, and the router withdraws the prefix. The printer sees the withdrawal and removes its GUA address. Your computer misses it, and still has the GUA and the ULA addresses.
Whoops. The printing is now broken somehow. Why?
> Prefix withdrawal doesn't work reliably on Android.
Works fine on the Android hardware I have. Are you attempting to retire prefixes that have an infinite lifetime? That doesn't work, and I don't think it's supposed to work.
> Neither does this solution allow for load balancing...
As I said
> Printers get an RFC1918 address and don't care about global connectivity.Okay, so why are you complaining about your printer being broken by GUAs that you're not permitting it to have? ;)
> IPv6 is nothing like IPv4 operationally.
For anyone who's not an IP stack developer, network hardware developer, or Enterprise sysadmin it absolutely is. And other than the fact that every endpoint is able to get a global address in v6, the sysadmin-visible differences between v4 and v6 are minor. RAs instead of... well, nothing, and DHCP for both.
> Whoops. The printing is now broken somehow. Why?
Exactly.
Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server? This Just Works™ on dnsmasq, which is one of the most widely-deployed DNS+DHCP servers on SoHo gear. [0] dnsmasq's default TTL for hosts added to the DHCP lease file appears to be 0, so -worst case- your sleepy computer tries to continue its conversation with the printer a couple of times, does ND and discovers that the IP it was using is gone, then looks up the hostname again and gets the new address of the printer. I think the trendy term for this back in the 2000s was "self-healing".
If you're going to retort "But we don't use dnsmasq in the companies I'm sometimes talking about!"... well, if you can't figure out how to not register upstream-controlled GUA addresses for your LAN hosts in your DNS, then do what dnsmasq does and serve them up with a TTL of 0.
[0] To head off the "Android doesn't really do DHCPv6" retort: Even though Android refuses to use anything other than DHCPv6-PD for managed address assignment, -AFAIK- Android still sends DHCPv6 ADDR_REG_INFORM messages for addresses it autogenerates on networks with either the "OtherConfig" or "Managed" flags set. I haven't bothered to set up my Linux systems to do this, but I'd be surprised if Windows and Darwin systems didn't do this.
> Why isn't your DHCPv6 server putting either both the GUA and ULA, or -better- only the ULA addresses in your LAN's DNS server?
I don't have a LAN's DNS server or a DHCPv6. BTW, I have had an IPv6-only home network for 10 years, with NAT64 and 464XLAT.
You still haven't solved my puzzle or even understood what's happening. The current source address selection rules result in hosts prefering a GUA address pair over ULA. This _will_ result in broken connectivity when GUA addresses change.
There is currently no standards-compliant way to solve my challenge, except getting an ASN, an IPv6 assignment, and announcing it through your uplinks. Which I've also done in my home network, btw.
There's an in-progress RFC to change this, by preferring ULA-ULA address pairs over GUA-GUA. So it might be usable some time in the 2030-s ( https://www.ietf.org/archive/id/draft-ietf-6man-rfc6724-upda... ).
And no, this is not a theoretic problem. It affects protocols like SIP or even mDNS that exchange the IP addresses. They will consistently prefer unstable GUAs over ULAs.
> I don't have a LAN's DNS server or a DHCPv6.
Yeah, that's why you think that this is a "puzzle".
Though, it does invalidate every complaint you've made about IP source address priority. The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS [0]. Given that you're not using DNS, then you either have automation to update all those hard-coded configs, or you do it all by hand. Either way, you're deliberately recording addresses that you don't control for your LAN hosts, and considering it a "puzzle" when you have trouble reaching those LAN hosts when your upstream provider changes their address.
[0] Given that every resolver I've ever used pulls data from '/etc/hosts', I'm considering that to be part of DNS for the purposes of this conversation. I'm also considering Avahi and friends to be DNS. [1]
[1] And if you've talked to any long-term Avahi user, you've certainly heard about its habit of -on daemon or host restart- erroneously considering host name of the machine it's running on to be "in use" and appending a "-N" to the end of it. The remarkable eagerness of Avahi to engage this collision-avoidance mechanism makes it entirely unsuitable for discovery of LAN hosts whose hostname is actually important. This fact breaks my heart, but Avahi has been doing this shit for a very, very long time, so it's probably never going to get fixed.
> The only ways you'll get multiple addresses for a given host are to either hard-code them, or use DNS
mDNS exists. As does SIP and SMB.
I first discovered the ULA/GUA issue when my TimeMachine backup dropped mid-session when I was testing Internet connection failover. Apple later fixed it by allowing multiple SMB sessions in parallel and preferring IPv4 connections. I have a pure IPv6-only network, as I said.
The same issue happens with SIP, as phones send their own addresses during the media connection negotiation.
(I have another funny story about SIP: Asterisk used to send a Cartesian product of available codecs and IP addresses, so if you had IPv6 privacy addresses on, it eventually accumulated enough of them to overflow the MTU, causing connections to silently drop)
> I first discovered the ULA/GUA issue...
Check out my research on this issue. [0] The results might surprise you.
[0] <https://news.ycombinator.com/item?id=50299152>
> The 50% stat is really mostly mobile phones on cellular networks, which remain the _only_ major success story for IPv6.
The largest ISPs in the US are Comcast, AT&T, Charter, Verizon, T-Mobile, Starlink, and Google Fiber. They all support IPv6. The only top-10 US provide that didn't support it is Frontier Communications, who is rolling it out.
In other words, the biggest companies who actually do this for a living all demonstrate that you're wrong.
As to your questions, read up on IPv6 ULA which solves all of them. None of the hosts on my LAN depend on having an outbound connection.
> For context: I deployed IPv6 in my networks in 2006. I have war stories.
Early IPv6 was a mess. It took a surprising amount of time for IPv6 to become mature and usable.
I'd argue that it's still not mature. ULA/GUA mess is one example, I recommend reading this delightful thread with beer and popcorn: https://mailarchive.ietf.org/arch/msg/v6ops/7-SuigPyP0R-C6ZC...
Having to waste 64 bits for the local part of the address is another one. There's an RFC in progress to allow neighbor discovery with shorter prefixes, so we might be able to use it by 2045.
And Android _still_ doesn't support DHCPv6.
https://doc.didww.com/voice/outbound-trunks/outbound-sip-inf...?
The only thing that surprised me was that Canada was so small compared to other Western countries. But I suppose that might be an artifact. The map shows IPv4 proportional to land area, but a "fair" allocation would have IPv4 proportionate to population, not land area, and I'd assume Canada is (overall) less densely populated than most other developed countries.
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:
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.
... and yet IPv6 still taking its sweet time.
Point being that patterns on small scales match patterns on larger scales.
but climate change is not up to the tech industry
Depends on what you mean by 'tech'.
Decreasingly the case it would seem.
The datacenters certainly aren't helping their case.
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.
AFAIK you all use imperial pints, which are a little bigger than the ones used in countries that still use the customary system (US and I assume Liberia). I'm pretty sure your pints are the same as those used in the rest of the commonwealth, but corrections are welcome.
That goes back to the fact that the imperial system replaced the older customary system after the American revolution. The US legislated a somewhat simplified version of the Customary System the English were using at the time, which was a piecemeal system based on several different acts of parliament over hundreds of years. We (much) later made slight changes so that our measurements are based on metric.
The Imperial System was instituted in the UK in 1826 and most of the measurements stayed the same, which is why our foot and pound are the same as your foot and pound. The biggest change was that imperial simplified the various liquid measurements to make them uniform. Before then, different liquids used different measurements. The gallon used in the US was originally based on the wine gallon whose value had been last set by parliament in 1709.
Babies would be measured in pounds and ounces, as they weigh roughly ½ stone at birth.
Canada also changed over in the 1970s. I was told as a kid that the US had planned to switch with us but backed out at the last minute. I'm not sure if that's true or not. Today, the imperial system holds on in a few places, like heights and weights of people (although not at the hospital) and cooking temperatures.
> Today, the imperial system holds on in a few places, like heights and weights of people (although not at the hospital) and cooking temperatures.
Construction: "two-bys" are used, with 16/19.2/24" offsets for studs and such (though the building code has millimetre equivalents).
IPv4 is better than IPv6, and imperial is better than metric. I would like something to replace IPv4, but that thing shouldn't be IPv6 and probably won't be at this rate.
How are they better?
IPv6 has a huge amount of bloat created by guys in cargo shorts and pony tails being flown out to exotic locales 3x a year for IETF conferences to argue about minutia and try to get their name on some IPv6 spec document. All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
> All they needed to do was add a couple more dots onto IPv4 and maybe switch to hex.
There is no 'just' extending the address length:
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
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.)
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 extended-address-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
Wasn't it from academics in their ivory towers? That's kind of the opposite of flying out to exotic locales.
Of course, back here in the real world you can look at the RFCs yourself and see that they're credited to places like Ipsilon Networks, Xerox and Sun Microsystems. Boring corporate network companies.
No literally, the IETF meets 3x a year in a different location each time and all the guys from with cargo shorts from the companies you named argue about IPv6 minutia all day and spend their per diem by night. It's actually a lot of fun.
Ah yes exotic locations like San Francisco, New York, London, Prague, Sydney, and Tokyo. Totally not major business hubs or anything.
Some of those locations probably did feel more exotic back in the early 90s than they do today... but they're also sensible places to hold international conferences. Where are you supposed to do them, if not there?
That's what they did and you're here complaining about it
IPv6 invalidated the existing IPv4 addresses, changed the addressing scheme, and de facto got rid of DHCP and NAT in favor of SLAAC and global routing. It doesn't share any state with v4. This was a very different set of choices from just adding more bits to v4.
Nobody's stopping you from using DHCP and NAT on IPv6, it's just not the norm.
The protocol itself is literally very similar to IPv4. They got rid of the IP header's checksum, but I don't think that's something you're complaining about, right? They renamed Time-To-Live to Hop Limit because that's what it actually does - is that a complaint you have?
What do you mean it doesn't share any state with v4?
By not sharing state, I mean v6 doesn't honor v4 routes/addresses, DHCP state, and DNS entries. They made all-new address blocks. This seemingly never gets talked about for how big of a deal it is. That makes it so enabling v6 instantly means reworking your entire network, not just speaking a different protocol.
Say I have 1.2.3.4/32 in v4. Let me keep that in v6. Just getting everyone onto v6 is a big enough change without also changing the routes. If I talk to 9.8.7.6 and it's v4-only, fine, the last v6 hop translates to v4. Even DNS doesn't strictly need to change yet. Then let's say enough people get on v6, so I hand out 1.2.3.4.5 to some host. If 9.8.7.6.5 wants to send to that, but there are some v4-only routers in the middle, no problem. The last v6 router translates to v4 dst=1.2.3.4 and puts the extra address bits in the payload, then when it reaches my router, it knows to rewrite as 1.2.3.4.5. Even in this later state, you really only need v6 support on the ends and any routers going deeper than /32.
DHCP and NAT on LAN could share state too. A host at 192.168.1.2 should be able to just turn on v6, it's still 192.168.1.2, some other host gets leased .3 instead, and the router knows to translate if .2 and .3 want to talk. I don't want it to suddenly be FC00::whatever.
I have no complaint about the v6 header, and a subset of the v6 protocol is fine because it's indeed just v4 w/ extra bits like you said. That ipv5/whatever proposal people keep making is doable with most routers/hosts just seeing it as ipv6 w/ DHCP+NAT.
And yeah, today I could use DHCP6 if I really wanted, but it'd mean lots of incompatible devices get either booted off my network or put on a separate SLAAC one, so it's not a serious choice. NAT66 is way more doable but also rare on consumer routers. So my only complaint about the protocol is that the defaults are backwards.
Nah, the details in the spec all have good reasons, but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
> […] but it's based on the original mistake of making it an entirely separate network from v4 with new address blocks.
This was not a "mistake":
* https://github.com/becarpenter/misc/blob/main/why6why.md* https://datatracker.ietf.org/doc/html/rfc1671
Yes it's 3A. They didn't need to make the new protocol have separate state from the old one. Let me keep my old address on the new protocol.
Have you got your address tattooed on your forehead or why's it so important to keep it?
> Yes it's 3A. They didn't need to make the new protocol have separate state from the old one.
Except there will be a period of time when many 'network elements' (routers, firewalls, servers (web, SMTP, DNS, etc), clients) will not be updated for the new protocol so you may also need 3B.
And this will be true for any IPng, and not just the one that just happened to be chosen to be for "IPv6" (which was SIPP, over CATNIP and TUBA; see RFC 1752).
> Let me keep my old address on the new protocol.
You can/could. You can encourage people who have addresses in the older protocol to use the new one with "free" "automatic" address assignments in the new one to encourage translation and tunnelling:
> For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.
> For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.
* https://en.wikipedia.org/wiki/6to4
And the 'old' IPv4 addresses are available in the new IPv6 world:
> Addresses in this group consist of an 80-bit prefix of zeros, the next 16 bits are ones, and the remaining, least-significant 32 bits contain the IPv4 address. For example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. A previous format, called "IPv4-compatible IPv6 address", was ::192.0.2.128; however, this method is deprecated.[5]
* https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
There is no way around this limitation: you must have a separate network space because of physical limitations.
Your supposed solution, and many others, have been thought of already. Have been tried. You are not thinking of anything new in your proposal.
6to4 and NAT64 are not what I'm saying. Those involve a relay server and v4 translation, and there's an entire memo on why that's unreliable and abandoned. I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
> I want to switch to fully native IPv6 without changing any of my addresses. There's no reason this should be impossible.
… except for the fact that you have to have completely new data structures and packet format to fit more address bits, and once you change the structures you need a new version field so any gear that sees a packet knows where to use the old code paths or new ones.
Then you're at the point where you have to push new code everywhere to handle these changes, and some nodes will have only the old code and some the new code, so now you're into translation and/or tunnelling to make sure the old addresses can talk to new addresses. Depending on their risk tolerance, some operators will enable the new code and some will not.
You also have to update DNS with new records, as A records are hard-coded to 32 bits. So now you're updating DNS libraries and user land.
There is no way to expand address space without going through all the same issues as what we call "IPv6" (originally SIPP) has gone through.
* https://github.com/becarpenter/misc/blob/main/why6why.md
I know. All these things were possible and completed for IPv6, but that's only part of the battle. The rest is making it easy for users at various levels to migrate. IPv6 didn't do that, that's why we're stuck in today's situation.
IPv6 added an unnecessary requirement to change all existing routes, which is huge. If still using old v4 addrs in v6, there should be no need to change DNS yet. You shouldn't need a different DNS or DHCP server, only one that supports both protocols (also shouldn't be forced to use SLAAC). V6 translation to/from v4 should be doable at any hop instead of relying on a flaky anycast relay. The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then. Even still there should be no requirement for every hop along the route to be v6, only the ones that go deeper than /32 near the ends. But we got all these extra constraints because of ipv6 design decisions.
But v6 did most of what you're asking for there??
It has "IPv4-compatible IPv6 address"es: https://datatracker.ietf.org/doc/html/rfc2373#section-2.5.4, and then a way to get them over networks where not every hop supports v6: https://datatracker.ietf.org/doc/html/rfc2893#section-5. You don't need new DNS or DHCP to use these, or SLAAC. There's no anycast relay. They can go over v4 hops.
Why spend all this energy complaining about v6 not doing something that it did do?
> The later stage of migration should just be that people start using longer addresses given that both ends are v6 and DNS etc supports it then
It seems your only real problem is that you completely missed the early part of the transition. We've been in what you're calling the later stage for twenty or so years now.
IPv4-compatible v6 address was only for dual-stack hosts talking over a v4 network. They still had their own v6-native addresses that they had to use if they wanted a v6 network. So this isn't what I described where the v6-native route is the same as the v4 route, or a superset in the later stages (shared down to /32, v6-only in deeper subnets).
The thing I want to solve isn't just v4 routers in the middle, that's more of a bonus. All the routers between my machine and any service probably support v6 anyway, but a bunch of services are v4-only because of the migration effort. They should be able to turn on v6 without having to change everything about their networking.
Wasn't "dual-stack hosts talking over a v4 network" what you wanted?
v4 routers don't understand and can't route v6 packets, so you can't use the same route for both of them. v6 packets have to go to a router that understands v6, and v4 packets have to go to a router that understands v4.
I have no idea what "or a superset in the later stages (shared down to /32, v6-only in deeper subnets)." is trying to say.
It's perfectly possible to turn v6 on without changing anything at all about your networking. When e.g. Windows Vista came out, hundreds of millions of people did exactly that.
Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
I wanted switching to v6 to involve the minimum necessary changes. You keep your old /32. If you're sending from a /32 to a /32, it follows the same path of routers that an ipv4 packet would follow, that's what I meant by same route. There could be a v4-only router in the middle requiring translation, but I'm not even assuming that's a common issue at this point.
"or a superset in the later stages (shared down to /32, v6-only in deeper subnets)": The ipv6 state would be a superset of the ipv4 state. So if a router owns 1.2.3.4 in v4, it also owns that in v6. The ownership of 1.2.3.4.5 below that would only be part of v6 state.
What we got instead was two separate states, or parallel networks. Switching to v6 means changing everything all at once.
> Why can't the service just set up NAT64 to accept your v6 connections on their v4 servers?
It's not that simple, otherwise they would've done it. They have stuff like multiple addresses, geo DNS, and rate-limiting. Separate issue, AWS was v4-only for a long time and still treats it as more first-class because of how many internal things need to change for v6, well beyond just having hardware + OSes support it.
IPv4 is inherently more user-friendly. IPv6 was designed for a world, in the 1990s, where it was expected that every host wanted to be routable. SLAAC etc were all natural consequences of that. For today's use cases, the v4 NAT public/private thing actually turned out to be nicer than v6 global routing. There's still confusion today about whether devices are exposed on a v6 network because the spec itself says default-deny firewall is optional. They had to recently add privacy addresses. The other kinds of v6 addrs like link-local and ULA add more complexity. V4 addresses are easy to remember, which v6 advocates keep saying doesn't matter but it does. There are all these little network management details that are messier in v6, as you will find on online help forums for v6 advocates who you cannot write off as just being too used to v4.
The v6 spec also has all these alternative ways to use it more like v4, commonly brought up as a cop-out against the above criticisms, but that's actually part of the problem. The spec is too big, and things only implement a subset of it, see Android not supporting DHCP6. Realistically you'll have 99% of people using anything like this the default way, and the spec does define SLAAC, no-NAT, etc as default.
But you could say v6 is better just cause it has more addresses, and that's fair.
...Imperial is better than metric because it lines up with everyday usage better unless you're specifically concerned about the physical properties of water. Especially ˚F vs ˚C. Not a big deal though.
Can you give some examples of where Imperial works better from first principles and why you think so?
0-100˚F lines up well with weather ranges, and 1˚F is about the smallest diff someone can feel. Many digital thermostats use integer ˚F and introduce 0.5 steps if you switch to ˚C, even in countries where ˚C is default, so they kinda admit it.
Pounds vs kg, similar story as F vs C. Pound is pretty much the human-discernible granularity. Otherwise doesn't matter.
0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
I'm not sure common urban/highway speed limits like 30mph/70-75mph line up better than the 50kmh/100-110kmh you see in Canada.
As a Canadian I have no idea what 72˚F means or feels like: is it warm or cold? I do know what 22˚C feels like and how to dress for it. How "intuitive" a temperature number is completely learned behaviour and cultural acclimation.
Pounds vs kg: see above. All the non-American people seem to have "intuitive" grasp of metric measurements.
> 0-100 MPH lines up well with car speeds, which is usually the thing you're measuring with that. KPH is excessively granular for that. Probably not by design, but yeah.
So 'more granularity' is good for temperature but not for speed. Got it.
> The feet/inches vs meters/cm thing matters less. It's base-12 vs base-10. You can do decimal feet or fractional meters of course, but it's less common, so apparently both ways are fine.
By "foot" do you mean 'regular' foot or survey foot:
* https://www.nist.gov/pml/us-surveyfoot
Because there are two different units in the US customary system, used for basically the same purpose, that use the same name. And the "foot" isn't the only unit like that:
* https://en.wikipedia.org/wiki/Pound_(mass)
* https://en.wikipedia.org/wiki/Pound_(force)
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces".
[1] https://en.wikipedia.org/wiki/Avoirdupois
[2] https://en.wikipedia.org/wiki/Troy_weight
I didn't say it's about being used to one. It can be "in the 20s" C for multiple months, kinda silly. 22.0˚C also feels different from 22.5˚C. There's a right amount of granularity for temperature and for speed.
Foot and pound have unambiguous meanings in the US. There's a reason the whole survey foot and gold-pound thing is trivia that nobody knows, they're niche or abandoned systems that you only use if you're being clear that it's not regular feet or pounds. I also know that the US system is technically not "imperial," but nobody cares.
I'm not the person you were replying to, but I can answer this one. And yeah, I can see all the metric fanboys (a very small subset of metric users, mind you) hovering over that downvote button, but I don't get paid in Internet points so here goes:
The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
It's difficult to explain to metric folks because it's really something you have to experience. But here's an example:
Reservoir volume in the US is measured in acre-inches. An acre is a unit of area used for measuring property, usually farmland. It's a bit less than half of a hectare. And of course an inch is 2.4cm. Acre-inches sounds totally bizarre when you first hear about it. But for the people that need to work with this value, it's an extremely useful way to measure reservoirs and gives you an intuition that you just don't get from cubic meters.
It's true that you can't just convert that to other units of volume without doing some math or looking up the conversion rate, but that rarely matters. If you're trying to figure out how fast the lake will rise or fall with a given inflow and outflow, you're going to have to have some way to account for the fact that the lake is a) an irregular shape and b) takes up more area the higher the water gets. You already need to know the area of the lake at any particular height to work out the evaporation rate anyway, so that's a number you're going to have. The units are designed to make that calculation easier, which was really important back in the days when slide rules were the state of the art.
All the customary units are like this in one way or another. They're units designed for a particular domain, and when used in their domain they work very well and calculations can be done in your head. They use fractions because that's what people have historically used (seriously - my grandfather could work fractions in his head faster than I could type them into a calculator, and he made asphalt for a living. Imagine what a carpenter could do.).
Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Bonus challenge to the fine folks clicking that downvote button: give me a real practical reason to prefer Celsius to Fahrenheit, besides the fact that Celsius is part of the metric system. No, the freezing and boiling points of water don't cut it - I work with hydrocarbon fuels, I salt my driveway and patio, I don't live at sea level, and quite honestly every American 8-year-old can spout off 32° and 212°. There's a Fahrenheit equivalent to Kelvin (Rankine) so the Kelvin to Celsius equivalence doesn't count either. My claim is that both scales are completely arbitrary, and only advantage one has over the other is that you're used to one of them. Go ahead, prove me wrong!
> Reservoir volume in the US is measured in acre-inches.
Never heard of an acre-inch before, and I'd have to get out a calculator to work out how much water that actually is in pints or gallons, or how much it weighs.
The metric equivalent would be a hectare-meter or a hectare-mm. I know a hectare is 100 m x 100 m, so 10,000 m². So I instantly know that a hectare-meter is 10,000 m³ (10 ML, or 10,000 tonnes of fresh water). A hectare-mm is 10 m³ (10 kL). If my 1 ha block gets 1 mm of rain, then that's 10 kL or 10 tonnes of water. So easy i can do it in my head.
> And of course an inch is 2.4cm
2.54 cm.
> Never heard of an acre-inch before
I only know of it because it's a unit used by the US Army Corps of Engineers, who maintain the local reservoir. A buddy of mine's dad worked for them when I was a kid so that lake was my stomping ground.
> 2.54 cm
Oops! You're right! My bad.
A couple more to add to your list: an inch is about as long as your thumb joint (with some variation between individuals obviously). It's an easy way to gauge the size of everyday objects without needing to carry around a tape measure.
The recommendation for emergency supplies is about a gallon of water per person per day - or 3.7 liters if you're using metric.
I've also heard it claimed that the 0-100 Fahrenheit scale is more functionally useful because the endpoints of 0 and 100 represent the tipping point of serious danger for humans from hot or cold weather. The closer you get to 100 degrees the more care you need to take about heat stroke and keeping hydrated, and similarly the closer you get to 0 degrees the more care you need to take about retaining heat and staying out of the elements - the freezing and boiling point of water isn't a necessary marker for survival. And people like nice round numbers to serve as markers for such things, divisibility be damned.
Metric is sterile and functional for calculation and consistency, which is fine and necessary for many things, but that's not a reason to completely ditch Imperial.
> The nice thing about imperial (as well as the customary system used in the US) is that it's based on measurements that people have found useful over thousands of years. They're human units, adapted to what people need to do with them, not the other way around.
US customary is not "thousands" of years; temperature (Fahrenheit) only came out in 1724 for example, and many other units were only standardize much more recently:
* https://en.wikipedia.org/wiki/History_of_measurement#History...
* https://en.wikipedia.org/wiki/System_of_units_of_measurement...
Second, even with-in the system itself there was also sorts of inconsistencies. Until just a few years ago there were two "foot" units; one was recently retired:
* https://www.nist.gov/pml/us-surveyfoot
Here's another one: which weighs more, a pound of feathers or a pound of gold? A pound of feathers. Because feathers use one 'pound-system' [1] and is 453g, while gold uses another pound-system [2] and is 373g. But of course an "ounce" of gold (31g) is more than an "ounce" of feathers (28g), because Troy is 1/12 of pound but Avoirdupois is 1/16. In addition to the above "ounces" there is also "fluid ounces". And let's not forget about the third system [3], which got replaced by… the metric system in 1971.[4]
[1] https://en.wikipedia.org/wiki/Avoirdupois
[2] https://en.wikipedia.org/wiki/Troy_weight
[3] https://en.wikipedia.org/wiki/Apothecaries'_system
[4] https://en.wikipedia.org/wiki/United_States_Pharmacopeia
Also:
* https://en.wikipedia.org/wiki/Pound_(mass)
* https://en.wikipedia.org/wiki/Pound_(force)
> Think about it. Imagine you were never taught a measurement system. You find yourself needing to come up with a unit to make measurements for wooden planks you're going to use to build a house. Would you choose a unit as long as a meter? Or one as short as a centimeter or even a decimeter?
Millimeters. That single unit gets you down to very small scales (finer than 1/16") and to large lengths: four significant digits (9999mm) gets you to the equivalent of >32' (~11yd).
* https://web.archive.org/web/20200516223819/https://themetric...
As evidence for this Australia/NZ/EU do everything in millimetres in construction.
> US customary is not "thousands" of years
You misunderstood me. It's based on measurements that people have been using for thousands of years. The Romans had feet and miles, for example - not exactly the same lengths, but for the same purposes. The Japanese shaku is almost exactly the same as a US foot. A Japanese Shō is about half a gallon. A Chinese jīn is just slightly larger than a pound. There's a reason for this.
> there was also sorts of inconsistencies
I never claimed otherwise. But do notice that the survey foot and standard foot weren't used for the same purposes, and the difference between them wasn't likely to confuse anyone except maybe people new to the field.
> Here's another one: which weighs more, a pound of feathers or a pound of gold?
Yep, Troy weights. And no one's sure where the Troy system came from. The main reason for its use is because of international trade. Also not something regular people (i.e. people that didn't work directly with precious metals) would have had contact with.
> Millimeters
Hah! Yeah right. Look at all the various non-metric systems that have existed throughout history. Did any of them use something like millimeters to measure wooden planks? Why not?
> As evidence for this Australia/NZ/EU do everything in millimetres in construction.
They do it because the metric system is mandated there and it doesn't give you reasonably sized unit for that scale of work.
Try this: go to a home center (or whatever it's called there - the place you buy building supplies) and measure some drywall. Do the measurements you made agree to the advertised ones within half a millimeter? Compare the dimensions of drywall sheets from different pallets and manufacturers. Do their dimensions agree to within half a millimeter? If not, that's a sure sign you're using units poorly adapted for purpose.
They are better for human consumption/understanding. Have you ever had to type an IPv6? It's awful.
How could you ever have really long addresses without having that problem?
They don't need to be really long. Adding one more octet to v4 makes it 1 trillion addresses. Sure the header should support longer than that, but it doesn't mean everyone needs to use all of it.
1 trillion addresses isn't anywhere near enough[1]. Remember that we're not talking about L2 here. (...I don't think 1 trillion MACs would even be enough if we want to ensure they're unique, and it seems the IEEE agree with me since they expanded MACs to 64 bits, but that's a different conversation.)
And you already don't have to use all 128 bits in v6. You're forced to use about 48 of them, but the rest is your choice. You can just... not use some of them. It's fine.
[1] https://www.rfc-editor.org/info/rfc1715/
The world is already managing with 32 bits of addresses plus NAT, and NAT most likely gives you less than 256 concurrent users per address. But sure, if some cheap ISP only owns a few /32s and needs to use more octets, let them do that, doesn't mean my 4-octet address needs to be super long too.
You're kinda forced to use 128 bits in v6 if you're an end user, cause that's the lowest common denominator. SLAAC is default, DHCP6 is widely unsupported. Most ISPs also only give out a /64 per spec minimum.
NAT is something you use when you're not managing.
The spec minimum is more like /56, so maybe you're forced to use slightly more than 48, but not all 128 bits.
Will you repeat the whole dance when you need a second extra octet? There are good reasons IPv6 is designed the way it is.
They considered 64 bit addresses at first but they didn't want to ever risk running out again so they doubled it again.
Try to remember it's not just about the sheer number of addresses - you also want to allocate them in big blocks so that few people ever need to expand their blocks, and they can split their big block into more blocks that are still big.
No, the field should be 128-bit to have headroom, but you don't need to hand out /128s to everyone. Everyone with a /32 now would be fine with /32 or /40.
How about /48
Oh wait that's the standard recommendation so it's already exactly how you said
My digital calipers can display freedom fractions. It makes my eyes bleed.
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
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.
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…
IPv6 discussions keep having this scenario - which is barely relevant to how nearly all IPv4 LANs operate.
It's assuming a huge zero-trust point-to-point network where it's a rare scenario for IPv4 LANs. IPv4 LANs tend to assume the internal network is semi-trusted and route through hubs, so merging networks is a bad idea even when the mapping does not conflict (which often doesn't if the companies are tiny like most are). Even in a zero-trust point-to-point environment you'd want to review the other side, convert it to your software, etc. And the people on the being acquired side have little reason to care too.
It's a scenario that's only relevant for a huge company constantly acquiring other companies that operates via zero-trust point-to-point networking and strongly tries to minimize human review - basically Google/Alphabet.
In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
The thing is, asking nicely doesn't always work. Sure, automated tools like docker/incus/wireguard/tailscale will respect it. But admins who don't want to be stuck typing long addresses? Not so much. I've lost count of how often I encounter a network admin that manually set their prefix to some fcXX::, when it's not outright fc00::.
Of course you can (and should) blame this on admins and not on IPv6, but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
> In theory IPv6 solves the problem by putting all of this under a single prefix (fc00::/8) and asking nicely that implementation/admins add 40 random bits to form their prefix. Which is plenty to prevent (almost all) eventual conflicts.
IPv6 solves this by making it easy for everyone to get their own 200::/3 address so that when two companies get together they have completely different /48s (or whatever).
> […] but then the same could be said of IPv4 where adding entropy to 10.X.X.0 is the usual recommended way of doing things.
There has never been a recommendation to add entropy to 10/8 addresses. At least I have never heard of such a thing. Can you provide a citation for this (alleged) recommendation? Is there an RFC of some kind?
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.
The "solution" is that IPv6-only servers do not exist and will never exist.
I have encountered multiple IPv6-only domains - certain random domains were accessible through Chrome, but unreachable from any command line tools. Turns out they were IPv6-only, and Chrome was doing its own DNS resolution, while anything that was using the platform DNS stack was hitting a black hole between OPNsense and my ONT.
Alternatively, IPv4 simply does not scale effectively on the LAN, whereas IPv6 allows much simpler addressing and routing topologies. Simple = good.
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.
It's impossible for a long address system to be compatible with a short address system. No one has ever found a way to make it work. Plenty of people think they have, but upon closer inspection, they haven't.
NAT is the only one that actually does work, and it's terrible.
Dual stack?
That is not compatibility, that's accepting the lack of it
It's one of the ways to do backwards compatibility. One of the most compatible ways, even.
i find NAT64 acceptable
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
That is a fun exercise! However the reality is that public IPv6 is always given out in 48 or 64 bits prefixes (minimum).
The math is a lot less impressive when you do it with 2^48 or 2^64.
Yep. IPv6 should be thought of as 2^64 subnets, each with "enough space for everyone" within each subnet.
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
You can still control access. Most home routers have firewalls that work a lot like V4 port forwarding except they don't have to maintain NAT tables or use as much CPU .
[dead]
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.
Unsurprisingly, the map is very similar to the World Population Density Map: https://luminocity3d.org/WorldPopDen/#3/20.00/10.00
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.
Fun fact: At the Assembly demoparty, every system wired to the party network receives a dedicated, publicly routable IPv4 address. It's a lot of fun, but can lead to some interesting moments. One year as I was getting my setup ready, I had a bit of a heart dropping moment when I realized that the raspberry pi I use to bridge ethernet to my Mac Plus over SCSI, the very same one that usually lives on my home network with all kinds of exciting old daemons running, was in fact reachable on the public internet!
The only real use-case for IPv6 is self-hosting, and that's just very niche. Other than that the arguments in favor of IPv6 turn to stuff like latency and network complexity. That's not nothing, but it won't make anyone change ISP, and so ISPs don't have to care about it.
From the ISP's POV a complex IPv4 network plus a simple IPv6 network is more work than just having a complex IPv4 network. IPv6 is optional, and IPv4 isn't.
The only way I can imagine IPv6 succeeding is if somehow big websites decide to slow things down for IPv4 users enough that they complain to their ISPs.
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.
One thing that was always a curious anomaly for me is Brazil having the second largest number of autonomous systems (ASNs) in the world. [1]
I've been told that this is actually because Brazil has a very competitive local ecosystem of small ISPs competing with eachother on the regional scale.
[1]: https://bgp.he.net/report/world
There is federal funding available to finance the connection of underserved areas, specially rural, so the nature of the problem makes it natural to be fragmented. Also considering how bureaucratic Brazil is, most of the red tape was greatly streamlined for small providers.
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.
NAT is the solution so far
NAT is a terrible solution with major downsides.
We are close to not having enough just for the servers people really want much less random things that should be contactable peer to peer.
NAT should not replace a firewall
Sure, but it's evidently not that bad. And actually safer than firewalls because the default is so strongly deny-inbound. Most people absolutely don't want random devices on LAN to be exposed to WAN, and those with servers can get a public IP.
Or perhaps we should be distributing the land more fairly.
IPV4 per traffic usage would make even more sense.
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.
Yes, the whole address is 128 bits.
Hence my having a /64 (/48 in fact, should I ever enable more than the current /64) shows that 64-bits is enough for global addressing. If it wasn't then giving me a /64 would be part of a path to creating an address exhaustion problem just like the one with IPv4 (which was exacerbated somewhat by handing out /8 ranges unnecessarily in the early days).
Ah, I misunderstood while skimming the comment thread. Reasonable claim. Thanks for explaining.
> Thanks for explaining.
No worries, I'm happy to have very slightly reduced the amount of confusion in the world (especially if it might have been caused by my previous message not being as clear as I thought it was at the time of writing!).
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.
IPv6 is 16 bytes, the person I replied to gives a 8 bytes scheme
However many bytes are used in the scheme, you could in theory use decimal or hexadecimal to represent an address in string form for either scheme. Once the string is unpacked and interpreted, the address is just a number.
Though I've never seen a v6 address represented that way, it would make then noticeably longer, so I don't know if anything will accept such a string as a valid address. Though IPv4-mapped addresses are sometimes show as a mix (::ffff:10.5.2.1 for 10.5.2.1) so maybe I'm wrong there.
Likewise I've never seen IPv4 addresses written in hex in the wild, but the relevant specs say it is valid. `ping 0xc0a82bc2` works just as well as `ping 192.168.43.194` but I doubt many forms accepting IPv4 addresses will validate that and allow it.
I have a script that does takes an IPv6 address and displays it as dotted decimal that I like to bring out any time this discussion pops up. As an example, Facebook's IP address:
Or good old 2600::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.
much easier than `cafe.local` with mDNS :)
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".
> 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!
That isn't the hardest part. We already got software and hardware supporting IPv6, and yet...
It still is. A lot of IoT and "smart" devices are still dreadfully slow in updating their software.
Iot isn't what's holding ipv6 back. There are tons of websites and even cloud platforms with totally ipv6-capable hardware and OSes, but the services are v4-only or strongly v4-preferred.
IoT was an example, a glaring one at that.
IPv6-lacking hardware and software definitely do exist in the wild, have you seen how some programs from incompetent developers accept only IPv4 addresses in the config files? I think all of us have seen at least one such program.
Often times it's just a matter of using another function to parse the address string. But you are shit outta luck if the program is closed source.
Yeah it's in the wild, but random crappy software isn't the reason all these big services are v4-only. Transitioning from v4 to v6 requires redoing your entire network, except you still have to maintain the v4 side until everyone else has done this. So it's not worthwhile unless you have an easy way to go v6-native and only use v4 at the ends, eg cellular networks.
Tbf there are always bad implementations. Good "smart" devices nowadays should be based on the Matter standard, which natively uses IPv6 addressing
https://en.wikipedia.org/wiki/Matter_(standard)
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
It’s a draft RFC.
So is this: https://datatracker.ietf.org/doc/html/draft-meow-mrrp
Being an IETF draft means nothing at all, as covered in this IETF draft: https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/
Yes, that was my point.
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.
There's still quite a few pockets of the industry where IPv6 just isn't available. Industrial control systems, for instance - there's lots of PLCs and SCADA software that are still IPv4-only. It's changing slowly, but industrial computing runs on thirty year time scales and there's still a lot of stuff out there that won't even run on modern operating systems. We use 32-bit Windows XP VMs or sometimes even FreeDOS for some of the software we use.
Those devices run in a private network and usually don't have any internet connectivity at all. If they do access the internet, it's usually limited to a few hosts that can easily be routed over some compatibility layer or a proxy.
You'd think that, but for the last decade there's been a huge push to move all the SCADA software into the cloud. "Run your plant from your phone!"
And that's not even counting the various integrators that just don't implement any kind of security at all.
I fight against this sort of thing all the time. Sometimes I get my way.
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.
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?
You don't need 192.168.0.0.0.0.0.1. 40 bits covers the world easily, like 1.2.3.4.5. This doesn't mean the field has to be only 40 bits, could be 128 and you don't write the trailing 0s. Of course this means no SLAAC.
But I don't get why the other commenter was proposing putting the 0s at the beginning instead of the end. Shouldn't the new address space be under the existing subnets?
5
> 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.
Don't forget you want extra bits for hierarchical routing. Companies like Amazon and cloudflare have many separate address blocks instead of one big one because that's what was available, but it means every router in the internet has to remember all their blocks instead of just one.
My blog's hosted on either 3106689564 or 42540619367231808600192856535952785520 depending on your addressing scheme.
See, no colons in sight!
whoa you got a 310 number
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?
Everything in v6 was for a good reason, but it was targeting now-outdated use cases. Separately, there's no good migration path from v4. They should've kept the v4 address blocks in v6, and following the natural consequences of that, it'd be way easier to migrate. But they didn't do this with v6 because they were trying to solve the address fragmentation issue upfront, which again had valid reasoning but in hindsight wasn't the right move.
> 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.
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. :-)
That's literally what ipv6 does.
This gets brought up on every ipv6-related submission, and the basic idea is sound. https://news.ycombinator.com/item?id=48781622
Not really, it assumes people will make IPv5 devices without a reason to. If you can get them to make IPv5 you can use the same mechanism to get them to make IPv4/6 dual-stack.
People already make ipv6 devices, that's not the problem though. It's also maybe possible to do ipv5 with ipv6 hardware at least on the hosts, since the v6 header is totally fine for this.
Well then how's that different from just v6?
V4 address blocks, DHCP, and NAT, not SLAAC. So if I have 1.2.3.4 in ipv4, my ipv5 address is also 1.2.3.4. Ipv5 isn't a separate network from v4, it shares all the v4 state, and I can enable without giving it much thought. And once there's enough adoption, I can start handing out addresses like 1.2.3.4.5 that are incompatible with v4-only hosts.
Except you can't enable it because your software doesn't support it. What you're describing sounds very similar to a NAT64 network. You can address an IPv4 host by 64:ff9b::8.8.8.8
It's not NAT64 or 6to4. An ipv6 host doesn't own such an address; it goes to a relay, and the v6 host is using a random unrelated v6 address. The ipv5 thing is ipv6 natively using ipv4 /32s.
So how does an ipv4 host address an ipv5 host that has a 64 bit address
You can do this in IPv6
Not really. My home IP is 71.177.17.171, how do I get an equivalent v6 that gets routed directly to me? NAT64 and 6to4 don't do this.
It's not clear what you're asking for exactly.
You have 2002:47b1:11ab::/48. If your ISP supports it, packets sent to that /48 will be delivered to you as native v6 packets, otherwise they'll be stuffed into a v4 packet which will be sent to 71.177.17.171. Or there's ::ffff:71.177.17.171 which will reach you using unmodified v4 packets.
That's two different ways your v4 address is present in v6.
I would like 71.177.17.171, encoded as 2002:47b1:11ab:: or whatever static prefix, to go directly to my router as v6 packets without ever being translated to v4. 2002:47b1:11ab:: doesn't do that, it goes to a 6to4 relay and is translated to v4. I'm pretty sure every ISP will at best give you a v4 /32 and an unrelated v6 /64. I don't want that separate v6 address, I want the same logical address for both.
2002:47b1:11ab::/48 will go to your router if you announce it in BGP. It only goes to a 6to4 relay if there's no more-specific route.
(On home Internet you'll probably need your ISP to handle the announcements, like they already do for your v4 address.)
Even if I owned my ISP, pretty sure no other ISP would honor that announcement. That's a reserved 6to4 range.
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
There already is a subnet. Actually a few. ::ffff:192.168.0.1 is reserved for when you need to pass an ipv4 address through an ipv6 API (e.g. v6 client application on a dual-stack OS on a dual-stack network) and 64:ff9b::192.168.0.1 is reserved as an actual address for NAT64 gateways to use (v6-only client, network has a NAT64 gateway somewhere on it)
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.
I thought IPv5 was a protocol designed for telecoms to route voice data over packet networks, though? It wasn't supposed to be a replacement for IPv4.
Noone pointing out that it's a mistake to use a Mercator projection for thjs
It's not. It's something like Equal Earth (I'm not familiar enough with all the projections to say for certain, but it's a long way from Mercator).
As a small WISP operating within the RIPE region, Are there ways to obtain usable IPv6 address space for customer connectivity (to provide e.g. /56 to customer CPEs) without becoming a LIR and paying the associated fees (Which frankly are unfair considering that companies that hold millions of ipv4 addresses pay the same amount... but that's another topic)? I currently own a single IPv4 PI /24 prefix, but I am not a LIR.
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.
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.
Meanwhile I’m here carving out a couple of /64s from the /48 block of IPv6 addresses Comcast gave me.
The scrolling scaling-controller on the map is genius. I wish more maps would add this dynamic ability to scale the logical size when there is a considerable ratio delta to the land size.
Yeah, but it’s not land and the analogy quickly breaks down given that’ ya know, NAT exists and DNS servers are under soverign control.
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.
introducing asland, the mythical lion daemon.
not really sure what it does, resurrect itself when dead?
(Fun fact: Aslan is canonically Jesus)
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.
Interesting. I think this can be used a measure of prosperity of a nation. like GDP.
What an interesting critter the UK is in terms of its shape
Can't we use AI to rewrite the whole internet (including flashing of routers) so it supports IPv6 everywhere?
Can I have an AI look at my ff::ee::::fa345::32sdfklasd ipv6 address and translate it to something like 192.168.1.4, and have another AI make sure my frikin Amazon Stick isn't exposed to WAN
I can't tell if this is a joke or not lol
And fix all vulnerabilities while we're at it.
This should be scaled by population. would make the India/china numbers more drastic.
was fun at college to plug in a laptop into the dormroom's ethernet jack and get assigned a public address. (i went to a /16 school, not a /8 sadly)
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.
Amsterdam, specifically Science Park, is basically the biggest internet hub in Europe. Frankfurt is second. A lot of stuff is there. It also helps they don't have overly strict policing like in Germany.
Sure, but even if a provider peers through Amsterdam it doesn't mean their IPs must be geolocated and registered there. It's probably because of favorable legislation.
Also some car entertainment systems with integrated 4G/5G use Dutch IPs. Which leads to the weird situation that I sometimes get dutch radio ads on TuneIn or some websites redirect to the Dutch version.
Alaska seems to have a lot of IP addresses...
What, you've never seen a moose with a beowulf cluster?
at a certain point in time there has to be a forcing function or event that causes people to migrate from ipv4 to ipv6.
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.
> 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.
My experience is more the opposite. I keep seeing people say things like "I don't do v6 at home because I don't need it". These people are outright telling us that they're not going to start using v6 unless we make them need it.
Note that I didn't say "migrate to" v6. They're not even willing to do the first step of that ("start using v6"), even with no pressure to do the last step ("stop using v4").
I read an anecdote from Facebook that they had huge trouble getting their developers to stop writing v4-only code. Eventually they ended up removing v4 from their developer machines, who all of a sudden were able to write v6-capable code -- and it didn't take long for them to start asking when they could drop support for v4.
People will moan and moan and moan about v6 until you make them use it, at which point they discover that it was never as bad as they imagined it being.
So you admit that IPv6 people routinely create the problem if it doesn't exist. Maybe there's some nuance where you need to go backwards in order to go forwards?
In any case it's not relevant to the case from the root comment, since the ISP doesn't offer IPv6. IPv6 folk are siding with the ISP here or getting distracted with IPv6.
Essentially IPv6 people are delusional about the state of support of the tech and the extent of issues it brings, there's regions where there's no IPv6 support, so when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.
One of the thing the ISP did was try to upgrade the connection from copper to fiber optics, like instead of understanding the issue, "let's just try upgrading from your OLD technology which is OUTDATED, no wonder you were having issues? Also have you tried turning it off an on again that helps? Talk to you tomorrow.". IPv6 guys so far have been a distraction, get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.
No? It wouldn't be taking this long if they could do that.
The problem in this thread stems entirely from v4: they're being moved onto CGNAT (which is NATed v4), because the v4 address space is exhausted, and this is only a problem because the hospital relies completely on v4. None of these problems were created by "IPv6 people". The IPv6 people created the thing that solves these problems.
This hospital has had twenty years to gradually move things over to v6 which would have rendered the CGNAT a non-issue, but instead they've done zero work towards that and are completely unprepared to deal with the realities of v4 running out. Had they been forced to use v6, they would've be fine.
> when a network with IPv4 has an IP related problem, IPv6 folk will blame it on IPv4 even if it's entirely unrelated, even if the infrastructure isn't even at dual-stack phase.
Another opposite. What usually happens is that IPv6 gets blamed for any network problems, even on networks that don't use it.
I've seen people run software that failed to connect to a server's v4 address over a v4-only network due to broken v4, that have then blamed v6 for the problem. The error message from the software was somewhat misleading (it only prints the last connection failure instead of all of them), but even so.
It's usually the people not doing v6 that are delusional about it. Even on HN there's a steady stream of people complaining that v6 didn't do <thing that v6 did do> or that it's impossible to do <thing that's possible to do in v6>.
I do realize that you're likely to hit bugs or lacking support or something somewhere or another, but that's what the past twenty years of gradual transition were for. We've all put a ton of effort into buying you more time to figure this stuff out in. If you squandered all that time and then need to deal with everything after it becomes a big emergency, that's not v6's fault.
> get walmart to run their website on IPv6 before you push it to a hospital in southamerica who is having downtime.
If you wanted a nice orderly transition, you needed to start doing it earlier. Instead everybody is fighting to be the last person to transition, and you probably won't be able to beat Walmart on that fight.
I will reiterate, the ISP does not offer IPv6
The professional services that I work with give plenty of notice (years) before turning off services. Were you using an internet connection that's intended for hosting servers? (As in you were paying for a dedicated static IP.) If so, then you have a case.
Otherwise, your arguments about what "internet" is are flawed. IPv6 has been a thing for about 30 years, with a well-publicized problem with IPv4 address space and migration plan. I suspect that it's (IPv6) older than your hospital's contract. Even in the IPv4 world, your IP can change at any time and you can be put behind a NAT. That's why ISPs will sell you a static IP if you need one.
>> why do you need to stick with IPv4?
> To support devices and routes that do not have ipv6 support?
> Are they being removed from lower priority users in order to serve high priority usecases? If so is a hospital a low priority user?
After reading your response, I suspect the real problem is attitude and experience. The hospital should have IT staff that know to purchase a static IPv4 IP. This should be part of the contract with the ISP. If it wasn't, ultimately it's up to the IT staff to approach the ISP and arrange to purchase one.
> The hospital should have IT staff that know to purchase a static IPv4 IP
I purchased a static IPv4 IP, and they made the CGNAT IP static.
I thought about making a blog post about it, but I realize there's so much nuance and details. I can't tell if it's just venting about work, or a genuinely interesting clusterfuck in some forlorn corner of the new world.
> I purchased a static IPv4 IP, and they made the CGNAT IP static.
Thank you, I needed a good laugh today, that is amazing!
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;
- dictate that starting on December 1st, all new devices and VMs have IPv6 addresses with all userspace services listening on IPv6 addresses or some nftables rule to kludge IPv6:$port -> 127.0.0.1:$port if necessary, with firewall configured to block that IPv6 traffic, then at a later date firewalls not blocking those IPv6 addresses, then at a later date prohibit any new IPv4 addresses being assigned anywhere with special exception to devices tagged "legacy" or "end of life" requiring documentation of such;
- use a combination of IPv6 GUA addresses assigned by whatever ISP and IPv6 ULA addresses chosen by your team -- in IPv6, multiple local gateways and multiple addresses on a network interface issued by those local gateways via RA is relatively a norm rather than an 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.
Many network engineers at many ISPs would gladly drop all IPv4 traffic if they thought they could get away with it.
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.
Thanks, I'll take a look into the recommended protocols.
One clarification I'd like to make is that IPv6 is not offered, I can only get IPv4 addresses through the ISP DHCP, there is no ipv6 being offered with command 'dhclient -6' for example on linux, neither does window pick any ipv6 up so it doesn't seem to be an us problem.
It's often that Argentinians miss nuances when copying ethical gray areas from the Americans, and without those slight nuances the debate often gets mixed up with a much more subtle debate.
To make a parallel, Trump issued a memecoin days before entering office, it wasn't technically while being president, it was a memecoin so there was no underlying asset, a gray area, see? America.
Now Milei saw and culted the cargo, he made a coin during his office mandate, and he mentioned it would be used to fund Argentina tech projects, so it's an unregulated security. The nuances are lost, and it's just plain bad.
EDIT1:
>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.
>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.
I appreciate the candor
>You and I are total strangers on different corners of the globe.
This is true and it might impact the nuances and extra-technical semantics of the protocol. For example, in here dropping IPv4 support might mean dropping support for older devices, which might be less common in America, ISPs might not support it, so it's not just about the device but the network, to give you an idea I just got off the phone with the ISP which is THE biggest ISP in Argentina, they don't offer IPv6, period.
>If my team were consulting with your organization's execs
Here might be a big disconnect, my organization execs would probably be way out of budget for whatever your org may charge, that would never happen.
If you want to point the salesmen of your org to try and stir some shit up like that with the ISP, then that may make a bit more sense, the budgets may align for importing American consulting, and berating a big org chart that includes engineers might make more sense than trying to replace a 'team' of 1 or 2 fractionalist generalist IT guys on <500$ month contracts.
The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company. IPv6 is not offered to consumers right now.
>we would advise the executive team to start developing a plan to flush out the replacements for the internal team ASAP.
go nuts
Everything I am suggesting here is what an internal team with full ownership of the network should do. An external team could chisel little by little, and progress the network in phases.
What is shared here is a general direction. I am sure some people I know where all they do is networking could tell me harshly some of these ways could be done better, and often these people are right ; but sometimes these same people are actually wrong and don't fully consider the positions of people in IT roles at companies that aren't ISPs.
All suggested below is not necessarily the ultimate way but a general direction.
_
>> can only get IPv4 addresses through the ISP DHCP
ISP-owned IP addresses, either of legacy IP or IPv6, are capricious and can suddenly change, as you experienced recently.
I suggest to adopt a mindset of "our network" and "their network", rather than functionally have your network be a passive extension of their network by using their IP addresses.
The router announcements (IPv6 RA) or DHCP (IPv4) for any IP addresses within your network should always be issued by devices controlled solely by our organization.
NAT64 and tunnels exist, any upstream ISP is not a blocker.
Modern Linux has eBPF and eXpress Data Path. Both Linux and FreeBSD (use HardenedBSD if you can) have DPDK. They can make for surprisingly high performance edge routers on x86_64 server boxes over a decade old, exceeding what most campuses or even datacenter footprints actually need and at low cost. Even without eBPF & XDP or DPDK, these on x86_64 are often "good enough" for router and firewall.
DNS running on these or adjacent boxes internal to the organization is essential.
The addresses at the gateways, either of IPv4 or IPv6, can be made highly available with VRRPv3.
IPv6 has an elegant way to handle multiple upstream ISPs without VRRP or CARP at the gateways, but even Linux is just recently implementing what may only be a piece of them (the BSDs will later), some mention of them here https://news.ycombinator.com/item?id=50143420
_
What I would do, which is opinionated so I'm not necessarily suggesting others do it, assuming tunneling will be involved: if the organizational wherewithal is there to register an AS and do BGP, is pay the AUD 500 fee to register an AS and have a chunk of IPv6 space for to use IPv6 GUA addresses that officially belong to the organization.
If not, which is often enough the case because we know how some organizations can be slow (not making any assumptions about your's), the remaining avenue is to use IPv6 ULA addresses which are the spiritual counterpart to IPv4 RFC1918 addresses.
You can embed MAC addresses in IPv6 ULA addresses, like the MAC 82c6.7943.acb2 put in an IPv6 like
and use DHCPv6 to always assign a specific IPv6 ULA address to a specific MAC address, where you have thought through the potential information-disclosure implications and you are certain you want to do that.Then I would use IPv4-only ISP paths for what they're good for: dumb paths to tunnel IPv6 packets to where there is proper internet.
For the option with an AS, BGP announcements on the other side of the tunnel. Personally I would do SCION on the gateways and out the other side of the tunnel, but you don't want to do SCION unless you are also crazy (like a fox).
For the IPv6 ULA option, PAT which is the spiritual counterpart to IPv4's NAT but is also technologically simpler.
With IPv6 ULA and no tunneling, NAT64 and DNS64 can work for outbound.
Site to site tunnels will be tricky no matter what. Tailscale, ZeroTier, Netbird, and similar may be able to do much of the work for you ; these should run in a DMZ on another side of a router/firewall that filters the appropriate IPv6 ULA prefixes.
I would try to see if I could make vanilla Wireguard work with NAT traversal techniques using some cloud-hosted VMs that help with the "hole punching", but not everyone would do that.
There aren't many options that will all work well but almost always more than one option that can work well, all subject to the specific site and inter-organizational resources.
_
>> dropping IPv4 support might mean dropping support for older devices
For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.
With Salt or Ansible, such a scheme with NAT, DNS, DHCP configuration may all be templatized and in perfect alignment, and is scalable.
Authoritative inventory of canonical identifiers/names versioned with Git, what Ansible calls "inventory", is imperative.
Sometimes this looks like a couple of old x86_64 boxes doing CARP (similar to VRRP) on the IPv4 side for a few dozen or couple hundred devices downstream.
Sometimes this looks like, in a handful of distant corners of the larger network, a cheap single-board computer between a single device and the rest of the network ; without a wifi chip or the wifi chip removed by heating (board-repair style), unless downstream of a wifi AP.
_
>> the ISP which is THE biggest ISP in Argentina, they don't offer IPv6 >> The ISP brand is Personal, local corp is Telecom Argentina S.A, Asynchronous System Number AS7303, trades as TEO in NYSE I think, owned by Grupo Clarin which comes is a traditional Media and news company.
I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.
Something like this will probably start happening sooner than people think.
>I can think of some service provider network engineers that would gladly drop all of Argentina's IPv4 off the entire internet and "IPv6 prefix announcements welcome", if the business sides would let them do it.
Yes, there's no shortage of employees that would vote to reduce their workload by removing their service offering, if you ask a physician here if the hospital should stop taking patients of X type, they'd be onboard, less work for them.
It's a dream though, try to make an AAAA request for any website, it's not there, even government websites.
>Something like this will probably start happening sooner than people think.
I'm even trying american companies, like citi.com, walmart.com, there's no AAAA records there.
>For as long as it makes organizational sense to continue using these devices, put them behind an OpenBSD box that performs NAT46 and DNS46, with IPv4 addresses statically mapped to IPv6 addresses, maybe ones that contain the MAC addresses of the devices.
This is an external facing service, so we don't control the devices or routes that patients and external physicians will be accessing the website.
>Tunneling
Yeah, I'm going to go this route, IPv4 tunnel, it's a horrible hack, but this is hacker news after all.
If the www. is prefixed or not, results for domains of Argentina differ. The results aren't almost-perfect like US, but IPv6 is apparently already somewhat prevalent in Argentina.
The list from ChatGPT:
"This 2026 list ranks organizations by LinkedIn employee count, not revenue, and includes public bodies and universities as well as companies. I’ve kept the listed order; entries without a domain in the source are omitted."
Almost all large companies in the US are on IPv6 and more of the smaller companies are on IPv6 than not.
If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1
and run this bash command:
and this one too Then maybe call up your ISP and rant about them allowing your country to devolve into some 3rd world shit hole stuck on legacy IP and over two decades behind the Western countries.Argentina deserves better!
>If your device isn't able to reach 2606:4700:4700::1111, try using the DNS server 1.1.1.1
We run a public facing server, we aren't going to ask patients and external physicians to configure a DNS or run a (linux) script
>Then maybe call up your ISP and rant
You wouldn't be surprised how unhelpful and unfun that is
those are CNAMEs not AAAA, and the CNAME chain doesn't end up resolving to IPv6, only IPv4.
Yeah I had later noticed that too. Much of the US companies do end up resolving to IPv6.
100% of the aforementioned US gov domains resolve to IPv6.
More 5G networks than not are using IPv6 and 464xlat. Many ISPs are IPv6 only too so closer to half the time than not there are IPv6 packets to reach to those IPv4 addresses.
You're a hospital. You have an actual contract with the ISP, right? Does it say you get an IPv4 address? If not, ask them for one, and pay up.
You don't need an address block from an RIR. You just need your ISP to give you an address.
You could also update to IPv6.
>You're a hospital.
I work for the hospital, occasionally, they are my client.
> You have an actual contract with the ISP, right?
They do not, it's an implied consumer contract, like when someone buys a hot dog from a stand.
I'd like a written contract too, but when trying to negotiate one, they want a lot more money for them, it depends of the nuances of the terms, but I've talked to sales reps, and it comes down to having a 1Gbps line that works right now vs a 100Mbps line that's more expensive, with the only difference being that the contract is now written and there's a symbolic SLA with some 10% penalty, and a single professional beration receiver instead of multiple anonymous on call rotation.
It's not a clear choice, especially considering that the dedicated route with SLA means introducing change risk to the operational and SLA benefit of the ISP, fiber, new holes, new lines, etc..
>You could also update to IPv6.
I would, they don't offer IPv6
>You don't need an address block from an RIR. You just need your ISP to give you an address.
Yeah, maybe. If I get an IPv4 block though what I'd do is a regional entity whether for profit or NFP to offer emergency regional tunneling, potentially while finding alternative revenue streams like collecting lists of wronged ISP customers and notifying them of class action lawsuits they may participate in. A 25K check, or a 5K check with an ipv4 block and I'm golden.
In fact as an IT service provider you should try to get an ISP to give you a contract to provide internet to all your customers as needed.
Well if your hospital is running on the cheapest possible internet made for houses, then you have no rights. You should GET a contract that includes what you actually need.
Service was marketed to corporations, (FiberCorp, business branch of FiberTel)
Also, in technical terms the tech is the same, the internet connects corporations with consumers so it's not surprising that the connective tissue is homogeneous, and there is no strict protocol asymmetry (unless you posit that there's an upload/download semantic association with upload producers and download consumers) so if there's any difference between an consumer and a corporate connection, it comes down to raw traffic volume, which in this case is 1Gbps, which both theoretically and empirically has been fine for years.
Actually, the difference is how much the ISP gives a shit about you. On a residential connection, they do not.
Email sent!
Wow, Japan has a lot
> Wow, Japan has a lot
Of course: it's long been a developed country and it's densely populated.
Apply Now - https://docs.google.com/forms/d/e/1FAIpQLSfcU2Yu3S5sqDvrmv5P...
Interesting.
IP6 babe!
[dead]
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!
> https://xkcd.com/1172/
Here I am complaining that I lose my static address, but your problem is that the address is static!
Bottom line is that once a system is a certain way for a while, other systems and people grow dependency on that
>https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...