If IPv4 were land
iptrust.co
iptrust.co
China: 358M
Both countries have roughly the same population. The IPv4 problem has been swept under the rug with CGNAT and a normal person doesn't even notice it. But it sucks. Forget having a dedicated IP, even on a broadband connection, you don't get a public IP that's truly yours. According to IPInfo[1], there are around 1,000 users sharing my IP. I get flagged for malicious activity, and online gaming is impossible without a Tailscale relay.
Of course, much of this comes down to the bad luck (+ policies) of developing late, when most IPv4 blocks had already been allocated. But it's pretty unfair how US DoD, Apple, Ford, and others [1] are sitting on enormous IPv4 blocks they'll probably never fully use, and may never sell. Meanwhile I am sharing a single public IP with a thousand strangers.
[1]: https://ipinfo.io/223.233.77.184
[2]: https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_addre...
But if you are living in a Western country, then you are probably blessed with CGNAT-free residential internet.
Some carriers in my country have recently started to share the same IP between 4 customers, each having a port range (1-16363, ...), but you can always request a full IP for free.
I, unfortunately, have been on CGNATed residential internet since 2016, though I used to still get a public IP on request (they stopped doing that though.) I live in South East Asia, for context.
Without IPv6 my only choice would have been relying on a centralized service like Zerotier and Tailscale.
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.
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 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.
Me as somewhat of a nerd, even doubt if I need a public IP, seeing how cyber security is looking today.
You can generally request to get off it though, at ~1-5$/m extra cost.
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.
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.
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.
For many years and even how there are networks that advertise they can do ipv6 and hand out real addresses but nothing works.
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.
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...
It's crazy I can get fiber to my house in the US, but not IPv6.
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/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).
And they can always tell your ISP if they don't like paying to connect to the tunnelling server they should just implement v6.
It wasn't always like this, but it was for me the last time I tried.
I've got a 8Gbit symmetric fiber connection (with no IPv6 at all, yay) and regularly make use of all of it, so I'm well connected. Router hardware is more than capable of the encapsulation.
With the HE tunnel up, I was often getting tens of megabits per second for any endpoints that supported IPv6.
Works as a "this endpoint is _only_ available on IPv6" so I can connect to something I couldn't otherwise, but day-to-day the experience is vastly better over IPv4 for me.
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.
It is broken for you by upstream NAT and CGNAT.
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.
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).
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.
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.
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.
CG-NAT breaks all this. iroh relies on relays from people with non-broken internet (no CG-NAT).
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.
Relying on peer-to-peer relays also doesn't scale, which is why Skype dropped its supernode architecture.
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.
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.
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.
Sadly, we'll never know.
> 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.
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.
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?
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.
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."
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.
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.
Otherwise, what are the practical differences?
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.
IPv6 will never replace IPv4 because it is a different protocol rather than merely a new version. The name is a lie.
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.
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.
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
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.
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.
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.
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.
> 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!
If they have enough v4 for all their customers, sure fine.
On v6 you don’t have that problem.
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.
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?
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.
> "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.
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.
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.
"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.
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.
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'm most curious to understand why didn't bad actors gobble up all those /24 blocks already.
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.
That's even what you'd get with IPv6 by default.
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.
Why would you not use ipv4?
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.
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.
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.
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.
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!
[1] https://www.theregister.com/networks/2026/07/22/china-advanc...
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
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.
So I don’t see how to fix this except at the ISP level (forcing them). No one is preventing this but the providers.
Weird-ass ideology
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
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.
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.
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?
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.
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.
Google sees 70-80% from some countries:
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
https://research.google/pubs/evaluating-ipv6-adoption-in-the...
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.
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.
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.
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'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.
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.
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.
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.
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. ;)
My point wasn't ever about home users anyway.
I'd be interested in hearing about it. I expect that you and I disagree pretty strongly on what should be the default. As one example, it's my opinion that -for WiFi clients- RADIUS authentication should be the default, with a PSK SSID as a backup for crappy WiFi devices that don't support it.
> My point wasn't ever about home users anyway.
I reckon that your point applies equally well to the ideal home user setup and Enterprise configurations.
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.
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 is very much alive. And it's so boring and working so well, that you don't even notice it.
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.
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...
/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_.
ULA work well in combination with DNS though.
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
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.
2002:db8::1
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...
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)
> 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?
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.
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.
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.
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.
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)
Check out my research on this issue. [0] The results might surprise you.
Early IPv6 was a mess. It took a surprising amount of time for IPv6 to become mature and usable.
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.
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.
/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.
Check my reply to your post. [0] I wrote it up before I noticed your message here. ;)
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.)
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.
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]
- 2001:4860:4860::/112 (for chrome)
- 2000::/128 (for the system)
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.
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-...
Creating an IPng was always going to be complicated:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
* https://datatracker.ietf.org/doc/html/rfc1671
For anyone curious as to the decision-making process, here are the criteria for what the IETF was looking for in an IPng:
* https://datatracker.ietf.org/doc/html/rfc1726
Here are the candidates that were floating around at the time, and the reason why the winner was chosen:
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.
NAT is the only one that actually does work, and it's terrible.
https://en.wikipedia.org/wiki/End-to-end_principleAlso, that same tech industry has shown remarcable competence in working around IPv4's limitations.
Austria-Hungary adopted the metric system in the 1870s. Back then: no cars, no highways, no speeding laws etc. Oxen-drawn wagons in the countryside were not built to a precise spec.
Only the railway, the architects and the artillery had to really switch. Ordinary people would still ask the grocer for half a pound of ham in the 1930s.
USA in the 1970s would have to remeasure all the land communications etc., or end up with a weird hybrid like the UK.
WHat we have in IPv4 and IPv6 is the weird UK-like hybrid...
* 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?
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.
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.
Construction: "two-bys" are used, with 16/19.2/24" offsets for studs and such (though the building code has millimetre equivalents).
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.
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.
The spec minimum is more like /56, so maybe you're forced to use slightly more than 48, but not all 128 bits.
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.
Oh wait that's the standard recommendation so it's already exactly how you said
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.
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.
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".
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
… 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.
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.
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.
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.
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?
"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.
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?
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.
There is no 'just' extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
* https://datatracker.ietf.org/doc/html/rfc1671
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)
:grimace:
Point being that patterns on small scales match patterns on larger scales.
IPv6 can be selectively applied to say, NAT addresses, but other than that, IPv4 is just fine and your statement is incorrect.
How would an IPv4 client send a packet to an IPv6 server? The IPv4 packet has only 4 bytes to spare for the destination address.
You can't.
Anything longer, even if it's just 1 bit, would require a new IP version.
- 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.
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…
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.
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?
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.
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.
Looking at all countries it ranks 233/246.
On the surface of the Earth [land+water], there are 8.4 IPv4 addresses per km². Not counting the oceans, that would be 28 IPv4 addresses per km² land.
IPv6 gives 10¹⁷ addresses per mm² (yes, square millimetre).
In terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
* So (4x10¹¹)x(2x10¹²) = 8x10²³ stars in the universe.
* Size of IPv6 address space: 3.4x10³⁸
* Find the ratio between addresses and stars: 3.4x10³⁸ / 8x10²³
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe. From Tom Coffee's presentation "An Enterprise IPv6 Address Planning Case-Study":
Much of the IPv6 rollout challenges have been centered around routing and security. It's great that I can personally have (in theory) more IP addresses than I would ever practically need (and I am saying this as someone with 200 IP endpoints just in my house), but if I can't easily manage and control access much of the theoretical benefit goes away.
IMO, IPv6 solved the address pool size part of the issue, but it made managing the v4 to v6 transition very painful.
There is no easy way to transition from IPv4 to any kind of IPng; see my other comment:
The math is a lot less impressive when you do it with 2^48 or 2^64.
Might have to do something horrible like:
- setup an ipv4 tunnel, which will require hacking a VPN to allow TCP listening, and routing connections to some external proxy with a dedicated static ipv4 address
- or do some modem router level nat port forwarding, and use a ddns to avoid ip changes breaking stuff. but that won’t work probably since public ip is shared
will investigate the isp to see if they are truly short in ipv4 or if they are just moving clients off them in order to sell them to higher bidders and plans, which is likely since I’ve been upsold into optic fiber, static ip surcharge, sd-wan, dedicated connection so far
if you have any advice or RIR contacts (or an ipv4 block to donate, invest or sell), I’d be thankful, my email is in my profile
I don't know much about your imaging servers: Do they accept incoming https connections, or is it some other kind of TCP or UDP protocol? Assuming it's https, why do you need to stick with IPv4?
> Hi, I’m helping a hospital in Buenos Aires that has lost their IPv4 due to their ISP moving to CGNAT, putting their on prem imaging servers offline for 7 days. (it’s ok for us though, we have a backup failover isp)
Two more things:
1: If you require IPv4, that needs to be part of the contract with your ISP. If they just arbitrarily turned you off, it means that you didn't contract for the services you thought you had.
2: IPv6 is supposed to solve a lot of these problems... So again, why can't you move to IPv6?
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.
I can tell you that in cicd for production Linux systems today, we have
CONFIG_LEGACY_IP=""
_
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
- 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.
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
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
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.
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 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
for USent in cia congress dhs epa ice fbi fcc nasa nsa whitehouse
do
echo ${USent}
dig +short aaaa www.${USent}.gov
echo ; done
Argentina deserves better!
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
user@host:~$ dig +short aaaa www.citi.com
san.www.citi.com.edgekey.net.
e16976.x.akamaiedge.net.
user@host:~$ dig +short aaaa www.walmart.com
www.walmart.com.cdn-wal.net.
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.
$ 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
apple
www-apple-com.v.aaplimg.com.
www.apple.com.edgekey.net.
e6858.dsce9.akamaiedge.net.
2600:1406:3a00:493::1aca
2600:1406:3a00:492::1aca
2600:1406:3a00:494::1aca
2600:1406:3a00:486::1aca
2600:1406:3a00:48a::1aca
akamai
www.akamai.com.edgekey.net.
2600:1406:2e00:49::172e:d8cf
2600:1406:2e00:49::172e:d8c6
att
prod-www.zr-att.com.akadns.net.
cac2.m.att.com.edgekey.net.
e11697.cd.akamaiedge.net.
berkshire
3tfzq88u2cbx.wpeproxy.com.
bestbuy
www.bestbuy.com.edgekey.net.
e5816.x.akamaiedge.net.
boeing
d1pt7e7bvjlgwo.cloudfront.net.
2600:9000:24bc:7a00:16:a4e1:f600:93a1
2600:9000:24bc:3600:16:a4e1:f600:93a1
2600:9000:24bc:b400:16:a4e1:f600:93a1
2600:9000:24bc:e000:16:a4e1:f600:93a1
2600:9000:24bc:6e00:16:a4e1:f600:93a1
2600:9000:24bc:be00:16:a4e1:f600:93a1
2600:9000:24bc:fc00:16:a4e1:f600:93a1
2600:9000:24bc:c000:16:a4e1:f600:93a1
bofa
redirect.ecglb.bac.com.
burgerking
prod-bk-us-web.com.rbi.tools.
cnn
cnn-tls.map.fastly.net.
2a04:4e42:200::773
2a04:4e42:400::773
2a04:4e42:600::773
2a04:4e42::773
chase
gtm.www.chase.com.akadns.net.
www.chase.com.edgekey.net.
e129412.a.akamaiedge.net.
chevron
www-afd-b9aycqabggbkcsdt.z01.azurefd.net.
mr-z01.tm-azurefd.net.
2603:1061:14:95::1
citi
san.www.citi.com.edgekey.net.
e16976.x.akamaiedge.net.
comcast
www.comcast.com.edgekey.net.
e523.dscb.akamaiedge.net.
2600:1406:3a00:482::20b
2600:1406:3a00:48d::20b
costco
costco.map.fastly.net.
cvs
www.cvs.edgekey.net.
e5769.x.akamaiedge.net.
dell
www1.dell-cidr.akadns.net.
cdn-www.dell.com-v2.edgekey.net.
e13665.x.akamaiedge.net.
disney
www-cdn.matterhorn.app.
fedex
www.fedex.com.akadns.net.
cidr.fedex.com.akadns.net.
ipv6www.fedex.com.edgekey.net.
e111296.dsca.akamaiedge.net.
2600:1406:2e00:49::172e:d8cc
2600:1406:2e00:49::172e:d8c8
2600:1406:2e00:49::172e:d8d0
2600:1406:2e00:49::172e:d8ca
2600:1406:2e00:49::172e:d8c4
fidelity
www.fidelity.com.edgekey.net.
e94446.x.akamaiedge.net.
gatorade
2606:4700:4409::ac40:9261
2a06:98c1:3105::6812:299f
google
2001:4860:482d:7700::
2001:4860:482a:7700::
2001:4860:4828:7700::
2001:4860:4827:7700::
2001:4860:482c:7700::
2001:4860:4826:7700::
2001:4860:4829:7700::
2001:4860:482b:7700::
goldmansachs
www.gs.com.
www.gs.com.edgekey.net.
e17133.x.akamaiedge.net.
gopro
d1h7n50c10z72v.cloudfront.net.
2600:9000:201e:6800:17:765c:a5c0:93a1
2600:9000:201e:4c00:17:765c:a5c0:93a1
2600:9000:201e:a200:17:765c:a5c0:93a1
2600:9000:201e:2400:17:765c:a5c0:93a1
2600:9000:201e:a800:17:765c:a5c0:93a1
2600:9000:201e:fe00:17:765c:a5c0:93a1
2600:9000:201e:ca00:17:765c:a5c0:93a1
2600:9000:201e:c200:17:765c:a5c0:93a1
hellofresh
www.hellofresh.com.cdn.cloudflare.net.
2606:4700:4409::6812:209d
2a06:98c1:3106::ac40:9b63
hilton
www.hilton.com.edgekey.net.
e2904.dscx.akamaiedge.net.
2600:1406:2e00:49a::b58
2600:1406:2e00:4a3::b58
homedepot
www.homedepot.com.edgekey.net.
e301254.x.akamaiedge.net.
infowars
2606:4700:10::6814:1a60
2606:4700:10::ac42:9d27
in-n-out
sw6cs.x.incapdns.net.
jcpenny
www.jcpenny.com.edgesuite.net.
a1441.b.akamai.net.
johnsonandjohnson
prod.jnj.psdops.com.
kaiser
kaiser.com.
2001:1ab0:7e1e:151::58
kroger
www.kroger.com.edgekey.net.
e8023.a.akamaiedge.net.
lulumon
lulumon.com.
macys
www.macys.com.edgekey.net.
e5791.a.akamaiedge.net.
mcdonalds
direct-san.mcdonalds.com.edgekey.net.
e179224.a.akamaiedge.net.
microsoft
www.microsoft.com-c-3.edgekey.net.
e13678.dscb.akamaiedge.net.
2600:1406:3a00:487::356e
2600:1406:3a00:486::356e
2600:1406:3a00:497::356e
2600:1406:3a00:481::356e
2600:1406:3a00:482::356e
nike
www.nike.com-v1.edgekey.net.
e2785.x.akamaiedge.net.
pepsi
g2wh497.x.incapdns.net.
petco
2a06:98c1:3108::6812:20c7
2a06:98c1:310a::ac40:9b39
radioshack
prod.magentocloud.map.fastly.net.
2a04:4e42::380
2a04:4e42:200::380
2a04:4e42:400::380
2a04:4e42:600::380
safeway
htu5x69.x.incapdns.net.
shell
www.nic.shell.edgekey.net.
e200089.dscb.akamaiedge.net.
2600:1406:3a00:33::170b:cfef
2600:1406:3a00:33::170b:cfe6
southwest
www.southwest.com.edgekey.net.
e7466.a.akamaiedge.net.
sprouts
2606:4700:10::ac42:9705
2606:4700:10::6814:2445
statefarm
statefarm.edgekey.net.
e124943.a.akamaiedge.net.
tacobell
www.tacobell-prod.com.edgekey.net.
e78335.b.akamaiedge.net.
target
sites.target.map.fastly.net.
tesla
www.tesla.com.edgekey.net.
e1792.dscx.akamaiedge.net.
2600:1406:3a00:291::700
2600:1406:3a00:280::700
2600:1406:3a00:293::700
2600:1406:3a00:290::700
2600:1406:3a00:296::700
traderjoes
www.traderjoes.com.edgekey.net.
e4528.b.akamaiedge.net.
ups
ev.ups.com.akadns.net.
ev2b.ups.com.edgekey.net.
e13626.dsca.akamaiedge.net.
2600:1406:2e00:986::353a
2600:1406:2e00:98b::353a
2600:1406:2e00:983::353a
2600:1406:2e00:984::353a
usbank
www.usbank.com.edgekey.net.
e374753.a.akamaiedge.net.
uschamber
uschamber.map.fastly.net.
walgreens
walgreens.com.edgekey.net.
e36070.dsca.akamaiedge.net.
2600:1406:2e00:20::45c0:8be8
2600:1406:2e00:20::45c0:8bda
walmart
www.walmart.com.cdn-wal.net.
wellsfargo
www.wellsfargo.com.edgekey.net.
e82164.b.akamaiedge.net.
wholefoods
2600:9000:25ef:c800:8:df9e:eb80:93a1
2600:9000:25ef:e000:8:df9e:eb80:93a1
2600:9000:25ef:7400:8:df9e:eb80:93a1
2600:9000:25ef:6400:8:df9e:eb80:93a1
2600:9000:25ef:ca00:8:df9e:eb80:93a1
2600:9000:25ef:9e00:8:df9e:eb80:93a1
2600:9000:25ef:5400:8:df9e:eb80:93a1
2600:9000:25ef:fa00:8:df9e:eb80:93a1
yahoo
me-ycpi-cf-www.g06.yahoodns.net.
2001:4998:18:800::4003
2001:4998:18:800::4002
aquantuo
2606:4700:20::681a:2e
2606:4700:20::681a:12e
2606:4700:20::ac43:4547
atlanticseafarms
2606:4700:3033::6815:4581
2606:4700:3035::ac43:d0b4
beehivemeals
beehivemeals.myshopify.com.
shops.myshopify.com.
2620:127:f00f:e::
beetlesplumbing
s.multiscreensite.com.
global.multiscreensite.com.
a3c02b2530d6f27ca.awsglobalaccelerator.com.
dynamicautomotive
dynamicautomotive.com.
jamies-farm
shops.myshopify.com.
2620:127:f00f:e::
joeandbella
joebella.myshopify.com.
shops.myshopify.com.
2620:127:f00f:e::
jovyco
jovy-brand.myshopify.com.
shops.myshopify.com.
2620:127:f00f:e::
privacy4cars
2606:4700:20::681a:dca
2606:4700:20::ac43:4af6
2606:4700:20::681a:cca
prosperityehr
2606:4700:10::6814:2f68
2606:4700:10::ac42:94bd
redroostercoffee
cname.vercel-dns.com.
resortlifecarts
sprod-dnn-gce6a8hab5g5bkf6.a03.azurefd.net.
mr-a03.tm-azurefd.net.
2603:1061:14:99::1
sproutlabs
cdn.webflow.com.
2620:cb:2000::1
tradedesignbuild
ext-sq.squarespace.com.
$ for USent in cia congress dhs epa ice fbi fcc nasa nsa whitehouse
do
echo ${USent}
dig +short aaaa www.${USent}.gov
echo ; done
cia
cia.gov.edgekey.net.
e10004744.dsca.akamaiedge.net.
2600:1406:3a00:33::170b:cfeb
2600:1406:3a00:33::170b:cff2
congress
2606:4700:4402::ac40:90ce
2a06:98c1:3109::6812:2b32
dhs
www.dhs.gov.edgekey.net.
e6485.dsca.akamaiedge.net.
2600:1406:2e00:98b::1955
2600:1406:2e00:983::1955
epa
d32i4z0dxazdtp.cloudfront.net.
2600:9000:201e:a600:10:f3db:af40:93a1
2600:9000:201e:f400:10:f3db:af40:93a1
2600:9000:201e:6000:10:f3db:af40:93a1
2600:9000:201e:c400:10:f3db:af40:93a1
2600:9000:201e:b600:10:f3db:af40:93a1
2600:9000:201e:d200:10:f3db:af40:93a1
2600:9000:201e:d600:10:f3db:af40:93a1
2600:9000:201e:6400:10:f3db:af40:93a1
ice
www.ice.gov.edgekey.net.
e6485.dsca.akamaiedge.net.
2600:1406:2e00:98b::1955
2600:1406:2e00:983::1955
fbi
www.fbi.gov.cdn.cloudflare.net.
2606:4700::6810:94f4
2606:4700::6810:95f4
fcc
www.fcc.gov.edgekey.net.
e4909.dscb.akamaiedge.net.
2600:1406:3a00:484::132d
2600:1406:3a00:497::132d
nasa
nasa-gov.go-vip.net.
2a04:fa87:fffd::c000:426c
nsa
nsa.gov.edgekey.net.
e16248.dscb.akamaiedge.net.
2600:1406:3a00:487::3f78
2600:1406:3a00:496::3f78
whitehouse
wh47.go-vip.net.
2a04:fa87:fffd::c000:4233The 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."
$ for argdo in $(cat arg2) ; do echo $argdo ; dig +short aaaa $argdo ; echo ; done
www.tytconsultores.com.ar
www.mercadolibre.com
a35f64fceb718ad27.awsglobalaccelerator.com.
www.es.wikipedia.org
www.dyna.wikimedia.org.
www.techintgroup.com
fdcomm01-egdmdkhuhfbgb9gx.z01.azurefd.net.
mr-z01.tm-azurefd.net.
2603:1061:14:90::1
www.cencosud.com
www.cencosud.com.cdn.cloudflare.net.
2606:4700::6812:247
2606:4700::6812:347
www.ypf.com
ypf.com.
www.gob.ar
www.uba.ar
aijewx4.ng.impervadns.net.
www.coto.com.ar
www.somosjob.ar
somosjob.ar.
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.telecom.com.ar
www.arcor.com
arcor.P0585910867.fortiwebcloud.net.
lb-3.us-east-1.aws.waas-online.net.
www.techint.com
techintcomprd.azurewebsites.net.
waws-prod-cq1-003.sip.azurewebsites.windows.net.
waws-prod-cq1-003.brazilsouth.cloudapp.azure.com.
www.abc.gob.ar
www.century21.com.ar
www.uca.edu.ar
www.galicia.ar
www.osde.com.ar
www.elalmacen.tv
cdn3.wixdns.net.
cfd.wixdns.net.
www.carrefour.com.ar
2a06:98c1:3108::ac40:9379
2a06:98c1:3108::6812:2887
www.unlp.edu.ar
2800:340:0:64::135
www.somosfarmacity.com
farmacitybr02-bzf9h8a2fmbbfyeb.z01.azurefd.net.
mr-z01.tm-azurefd.net.
2603:1061:14:97::1
www.hospitalitaliano.org.ar
www.andreani.com
www.andreani.com.cdn.cloudflare.net.
2606:4700::6812:161a
2606:4700::6812:171a
www.mostazaweb.com.ar
www.aesa.com.ar
aesa.com.ar.
www.claroempleos-aup.com
www.swissmedical.com.ar
swissmedical.com.ar.
www.unc.edu.ar
2801:120:842::5
2801:120:842::4
2801:120:842::6
www.bbva.com.ar
www.bbva.com.ar.edgekey.net.
e6251.a.akamaiedge.net.
www.bna.com.ar
bna.com.ar.
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.accenture.com
4229prod2cf.r53cioaccenturecloud.net.
d13iavm24b37u0.cloudfront.net.
2600:9000:25f2:0:d:5159:5a00:93a1
2600:9000:25f2:7e00:d:5159:5a00:93a1
2600:9000:25f2:bc00:d:5159:5a00:93a1
2600:9000:25f2:2600:d:5159:5a00:93a1
2600:9000:25f2:2e00:d:5159:5a00:93a1
2600:9000:25f2:9000:d:5159:5a00:93a1
2600:9000:25f2:6a00:d:5159:5a00:93a1
2600:9000:25f2:ca00:d:5159:5a00:93a1
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.aerolineas.com.ar
www.bancoprovincia.com.ar
www.ocasa.com
ocasa.com.
www.macro.com.ar
www.arca.gob.ar
www.laanonima.com.ar
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.naranjax.com
2a06:98c1:3105::ac40:95eb
2606:4700:440b::6812:2615
www.informeg.com.ar
informeg.com.ar.
www.gruposancorseguros.com
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.pecomenergia.com
dam5tpv20rcp8.cloudfront.net.
www.santander.com.ar
www.santander.com.ar.edgekey.net.
e90036.dscb.akamaiedge.net.
2600:1406:2e00:28::17cb:a618
2600:1406:2e00:28::17cb:a60d
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.2606:4700:20::681a:4b7
www.2606:4700:20::681a:5b7
www.2606:4700:20::ac43:4b23
www.unr.edu.ar
www.utn.edu.ar
www.cerveceriaymalteriaquilmes.com
ug2aj8e.x.incapdns.net.
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.adecoagro.com
hostweb.adecoagro.com.
www.mendoza.edu.ar
www.veronicapalermo.com.ar
www.uncuyo.edu.ar
www.toyota.com.ar
d14rtqisu6jdh1.cloudfront.net.
2600:9000:211f:7800:e:6ac2:3d40:93a1
2600:9000:211f:c800:e:6ac2:3d40:93a1
2600:9000:211f:2600:e:6ac2:3d40:93a1
2600:9000:211f:b200:e:6ac2:3d40:93a1
2600:9000:211f:3200:e:6ac2:3d40:93a1
2600:9000:211f:7400:e:6ac2:3d40:93a1
2600:9000:211f:6800:e:6ac2:3d40:93a1
2600:9000:211f:a600:e:6ac2:3d40:93a1
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.uade.edu.ar
www.diaonline.supermercadosdia.com.ar
www.pan-energy.com
www.sancorsalud.com.ar
www.ar.linkedin.com
www.cctld.linkedin.com.
www.cctld.es.lnkdns.net.
www.www.linkedin.com.cdn.cloudflare.net.
www.rosario.gob.ar
websrv2.rosario.gob.ar.
www.mpf.gob.ar
www.aysa.com.ar
aysa.com.ar.
www.uai.edu.ar
alb-virt02-umbraco-503988087.us-east-1.elb.amazonaws.com.
www.hospitalsanjuandedios.org.ar
www.telecentro.com.ar
www.nadro.mx
d1j9d2nbk27vjw.cloudfront.net.
2600:9000:21dd:8a00:3:847:5f00:93a1
2600:9000:21dd:7400:3:847:5f00:93a1
2600:9000:21dd:4200:3:847:5f00:93a1
2600:9000:21dd:5a00:3:847:5f00:93a1
2600:9000:21dd:1000:3:847:5f00:93a1
2600:9000:21dd:fa00:3:847:5f00:93a1
2600:9000:21dd:7c00:3:847:5f00:93a1
2600:9000:21dd:200:3:847:5f00:93a1
www.usal.edu.ar
www.hospitalaleman.org.ar
22pt6nf.impervadns.net.
www.pluspetrol.net
environmental-longan-72bw7rzlnwqdk0vjpbrlycnz.herokudns.com.
www.edenor.com
d14d07xru8rz5.cloudfront.net.
2600:9000:21dd:f800:10:d7ce:6840:93a1
2600:9000:21dd:9a00:10:d7ce:6840:93a1
2600:9000:21dd:9600:10:d7ce:6840:93a1
2600:9000:21dd:aa00:10:d7ce:6840:93a1
2600:9000:21dd:8a00:10:d7ce:6840:93a1
2600:9000:21dd:6600:10:d7ce:6840:93a1
2600:9000:21dd:4c00:10:d7ce:6840:93a1
2600:9000:21dd:6400:10:d7ce:6840:93a1
www.cge.entrerios.gov.ar
www.supervielle.com.ar
www.pwc.com.ar
www.pwc.com.ar.edgekey.net.
e675.x.akamaiedge.net.
www.mdp.edu.ar
proxy.mdp.edu.ar.
www.hospitalbritanico.org.ar
ambitious-field-049c5d310.1.azurestaticapps.net.
azurestaticapps1.trafficmanager.net.
msha-slice-1-wus2-0.msha-slice-1-wus2-0-ase.p.azurewebsites.net.
waws-prod-mwh-a269a7b8.sip.p.azurewebsites.windows.net.
www.edu.ar
www.gov.ar
www.gdmseeds.com
wp.wpenginepowered.com.
www.iosfa.gob.ar
2606:4700:3035::6815:25b7
2606:4700:3037::ac43:d3a2
www.unsam.edu.ar
2606:4700:20::ac43:4b64
2606:4700:20::681a:b10
2606:4700:20::681a:a10
www.newsan.com.ar
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.argentina.gob.ar
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
2606:4700:20::681a:4b7
www.edilizia.com.ar
www.edilizia.com.ar.cdn.hstgr.net.
2a02:4780:50:83e3:2d34:afe1:afaf:97bc
2a02:4780:4e:a704:36c6:c5a7:478e:3a77
www.hospitalaustral.edu.ar
adc.hospitalaustral.edu.ar.
www.unne.edu.ar
wwwproxy.unne.edu.ar.
www.bsg.global
www.icbc.com.ar
www.uca.edu.ar
www.uns.edu.ar
uns.edu.ar.
www.fravega.com
www.grupopetersen.com.ar
376ee70d1c774050adbdb0e659a74dd5.v1.radwarecloud.net.
$ echo ; for Argentina_Domain in tytconsultores.com.ar mercadolibre.com es.wikipedia.org techintgroup.com cencosud.com ypf.com gob.ar uba.ar coto.com.ar somosjob.ar argentina.gob.ar telecom.com.ar arcor.com techint.com abc.gob.ar century21.com.ar uca.edu.ar galicia.ar osde.com.ar elalmacen.tv carrefour.com.ar unlp.edu.ar somosfarmacity.com hospitalitaliano.org.ar andreani.com mostazaweb.com.ar aesa.com.ar claroempleos-aup.com swissmedical.com.ar unc.edu.ar bbva.com.ar bna.com.ar argentina.gob.ar accenture.com argentina.gob.ar aerolineas.com.ar bancoprovincia.com.ar ocasa.com macro.com.ar arca.gob.ar laanonima.com.ar argentina.gob.ar naranjax.com informeg.com.ar mseg.gba.gov.ar gruposancorseguros.com axionenergy.com argentina.gob.ar pecomenergia.com santander.com.ar argentina.gob.ar unr.edu.ar utn.edu.ar cerveceriaymalteriaquilmes.com argentina.gob.ar adecoagro.com mendoza.edu.ar veronicapalermo.com.ar uncuyo.edu.ar toyota.com.ar argentina.gob.ar uade.edu.ar diaonline.supermercadosdia.com.ar pan-energy.com sancorsalud.com.ar ar.linkedin.com rosario.gob.ar mpf.gob.ar aysa.com.ar uai.edu.ar hospitalsanjuandedios.org.ar telecentro.com.ar nadro.mx usal.edu.ar hospitalaleman.org.ar pluspetrol.net edenor.com cge.entrerios.gov.ar supervielle.com.ar pwc.com.ar mdp.edu.ar hospitalbritanico.org.ar edu.ar gov.ar gdmseeds.com iosfa.gob.ar unsam.edu.ar newsan.com.ar argentina.gob.ar argentina.gob.ar edilizia.com.ar hospitalaustral.edu.ar unne.edu.ar bsg.global icbc.com.ar uca.edu.ar uns.edu.ar fravega.com grupopetersen.com.ar ; do echo $Argentina_Domain ; dig +short aaaa $Argentina_Domain ; echo ; done
tytconsultores.com.ar
mercadolibre.com
es.wikipedia.org
dyna.wikimedia.org.
2620:0:863:ed1a::1
techintgroup.com
cencosud.com
ypf.com
gob.ar
uba.ar
coto.com.ar
somosjob.ar
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
telecom.com.ar
arcor.com
techint.com
abc.gob.ar
century21.com.ar
uca.edu.ar
galicia.ar
osde.com.ar
elalmacen.tv
carrefour.com.ar
2a06:98c1:3108::ac40:9379
2a06:98c1:3108::6812:2887
unlp.edu.ar
2800:340:0:64::135
somosfarmacity.com
hospitalitaliano.org.ar
andreani.com
mostazaweb.com.ar
aesa.com.ar
claroempleos-aup.com
swissmedical.com.ar
unc.edu.ar
2801:120:842::4
2801:120:842::5
2801:120:842::6
bbva.com.ar
bna.com.ar
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
accenture.com
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
aerolineas.com.ar
bancoprovincia.com.ar
ocasa.com
macro.com.ar
arca.gob.ar
laanonima.com.ar
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
naranjax.com
2a06:98c1:3105::ac40:95eb
2606:4700:440b::6812:2615
informeg.com.ar
mseg.gba.gov.ar
gruposancorseguros.com
axionenergy.com
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
pecomenergia.com
santander.com.ar
2600:1406:bc00:6a::172b:330f
2600:1406:bc00:6a::172b:330d
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
unr.edu.ar
utn.edu.ar
cerveceriaymalteriaquilmes.com
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
adecoagro.com
mendoza.edu.ar
veronicapalermo.com.ar
uncuyo.edu.ar
toyota.com.ar
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
uade.edu.ar
diaonline.supermercadosdia.com.ar
diaonline.supermercadosdia.com.ar.cdn.vtex.com.
d3p7gg3f271ro.cloudfront.net.
2600:9000:204d:5200:9:b144:ad00:93a1
2600:9000:204d:7200:9:b144:ad00:93a1
2600:9000:204d:7800:9:b144:ad00:93a1
2600:9000:204d:9400:9:b144:ad00:93a1
2600:9000:204d:8000:9:b144:ad00:93a1
2600:9000:204d:5000:9:b144:ad00:93a1
2600:9000:204d:6400:9:b144:ad00:93a1
2600:9000:204d:4a00:9:b144:ad00:93a1
pan-energy.com
sancorsalud.com.ar
ar.linkedin.com
cctld.linkedin.com.
cctld.es.lnkdns.net.
www.linkedin.com.cdn.cloudflare.net.
2a06:98c1:3109::6812:2929
2a06:98c1:310b::ac40:92d7
rosario.gob.ar
mpf.gob.ar
aysa.com.ar
uai.edu.ar
hospitalsanjuandedios.org.ar
telecentro.com.ar
nadro.mx
usal.edu.ar
hospitalaleman.org.ar
pluspetrol.net
edenor.com
2600:9000:21dd:4000:10:d7ce:6840:93a1
2600:9000:21dd:fc00:10:d7ce:6840:93a1
2600:9000:21dd:6a00:10:d7ce:6840:93a1
2600:9000:21dd:7a00:10:d7ce:6840:93a1
2600:9000:21dd:2000:10:d7ce:6840:93a1
2600:9000:21dd:5e00:10:d7ce:6840:93a1
2600:9000:21dd:7000:10:d7ce:6840:93a1
2600:9000:21dd:e000:10:d7ce:6840:93a1
cge.entrerios.gov.ar
supervielle.com.ar
pwc.com.ar
mdp.edu.ar
hospitalbritanico.org.ar
edu.ar
gov.ar
gdmseeds.com
iosfa.gob.ar
2606:4700:3035::6815:25b7
2606:4700:3037::ac43:d3a2
unsam.edu.ar
2606:4700:20::ac43:4b64
2606:4700:20::681a:a10
2606:4700:20::681a:b10
newsan.com.ar
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
argentina.gob.ar
2606:4700:20::681a:4b7
2606:4700:20::681a:5b7
2606:4700:20::ac43:4b23
edilizia.com.ar
2a02:4780:84:881e:443e:9364:14fd:ed8f
2a02:4780:84:8c81:c13b:f920:84f2:6f33
hospitalaustral.edu.ar
unne.edu.ar
bsg.global
icbc.com.ar
uca.edu.ar
uns.edu.ar
fravega.com
grupopetersen.com.arOtherwise, 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.
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.
Thank you, I needed a good laugh today, that is amazing!
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.
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.
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.
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.
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.
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.
Anyway, the Netherlands also seems to be an attractive place to build datacenters.
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
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.
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.
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.
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.
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.
(On home Internet you'll probably need your ISP to handle the announcements, like they already do for your v4 address.)
There is no "just" extending the address length:
So it's a matter of mathematical and physical fact that to expand
the address size, you must change the protocol, and that means
[three] things immediately:
You have to change the version number.
You have to add new code to handle the new version.
[…]
You need a coexistence technique so that updated systems,
with the new protocol, can connect to old systems that know
nothing of the new protocol.
Two minutes of thought show that this third requirement has only
two solutions:
(3A) Dual stack, in which the new machines speak both
the old (IPv4) and new (IPng) protocol.
(3B) Translation, in which something translates addresses
between the old and new protocols.
* https://datatracker.ietf.org/doc/html/rfc1671
> Keeps all the nice parts of IPv4, doesn’t require everyone to switch to an entirely new system, backwards compatible with existing hardware/software. Problem solved.
You have to ship new code to every 'network element' to support your "IPv4+" plan. Just like with IPv6.
You also have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (A lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "A+" address (for "IPv4+" addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.)
You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. In any 'address extension' plan the legacy code cannot use the new address space; you have to:
* update the IP stack (like with IPv6)
* tell applications about new DNS records (like IPv6)
* set up translation layers for legacy-only code that cannot be update to reach IPv4+-only destination (like IPv6 with DNS64/NAT64, CLAT, etc)
You're updating the exact same code paths in both the "IPv4+" and IPv6 scenarios: dual-stack, DNS, socket address structures, dealing with legacy-only code that is never touched to deal with the larger address space.
"Just adding more bits" means updating a whole bunch of code (routers, firewalls, DNS, APIs, userland, etc) to handle the new data structures. There is no "just": it's the same work for IPv6 as with any other idea.
Being an IETF draft means nothing at all, as covered in this IETF draft: https://datatracker.ietf.org/doc/draft-wkumari-not-a-draft/
You still need to have routers, clients, and absolutely everything to understand the new scheme to use those new addresses.
Or octal:
* https://networkingtoolbox.net/ip-address-convertor/represent...
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.
$ ./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
$ ./ipv6todecimal.py 2600::
Your IPv6 Address is: 38.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0But 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.
Absolutely not. Existing IPv4 hardware and software expects addresses to be 4 bytes long. They expect packets to have a 4 byte source address at offset 12 in the header, then a 4 byte destination address at offset 16. Everything breaks if you try to give them a header with an 8 byte source address at offset 12 and an 8 byte destination address at offset 20.
As does DNS.
"A" records are fixed at 32 bits, so you have to add a new record type and update all DNS software, plus user-space API/library code and data structures to ask for and store the new record type.
Just like IPv6.
There is no "just" adding more addresses: whatever scheme anyone comes up with is the same amount of work as IPv6.
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
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.
How is this different from ::192.168.0.1? :)
Of all the sins of IPv6, its tied between using ':' as the separator, and the god awful '::' "just skip writing the address because we made them too fucking big lol"
Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
Fine, let's change the question.
Without counting, how many zeroes are there in 192.168.0.0.0.0.0.1?
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?
See, no colons in sight!
The protocol chosen for IPng, SIPP, did actually have "only" 64 bits, but this was deemed not enough as folks did not want to have to worry about running out again (amongst other reasons), and so tweaked it to have a fixed 128 bits:
* https://datatracker.ietf.org/doc/html/rfc1752
SIPP originally was variable-length capable, but it was decided fixed-length was better (e.g., for hardware like ASICs).
> Wouldn't have been a problem if they hadn't given every square millimeter of the planet 100 billion addresses.
For the record: IPv6 gives 10¹⁷ addresses per mm²; in terms of volume, 10⁸ IPv6 addresses per mm³ throughout the Earth.
I woulda thought 18 quintillion would've been enough addresses for the next century or two but good thing we locked in all this extra data we throw away with a '::'.
I'm sure it was all well considered by intelligent people, but it was still a dumb decision.
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.
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.
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.
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".
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!).
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
Yeah, about that part. This is a "now draw the rest of the fucking owl" type of idea.
It turns out when you ignore the hardest part of the problem, you can always make a good-looking proposal!
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.
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?
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.
not really sure what it does, resurrect itself when dead?
(Fun fact: Aslan is canonically Jesus)
You haven't lost your marbles, this looks like straight Claude slop, just look at the fonts.
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.
Of course: it's long been a developed country and it's densely populated.
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.
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...