I work with the engineer behind this (different team, but we interact semi-often and work on overlapping projects), but had no idea it was him until I looked at the little copyright notice in the footer. He is a fascinating guy and a fantastic engineer (one of those 10x engineers you hear about) while being humble and always willing to help out.
Thanks for the site for the last 15 years, it's helped me a number of times.
If he doesn't read the thread here, please tell him that a random internet user would like to thank him very much for providing this awesome service, fully understands his choice, and congratulates him for having the willpower to make the choice that is right for him rather than lighting himself on fire to keep others warm.
For me personally, IPv6 still feels like something that only exists in datacenters. I've had it for ages on my servers, but never in my life have I seen a home internet connection that supports it. I'm always surprised to see that I'm using IPv6 whenever I travel e.g. to Europe.
It was "fun" discovering this the hard way a number of years ago when active US Android user count for a game we were supporting dropped 15% essentially overnight. The TCP stack in the client only did IPv4.
The challenge, ironically, was convincing management that adding IPv6 was the thing worth trying. After almost a week of getting nowhere (and almost 2 weeks of outage), I forced the issue by saying "Look, I'm doing this. I need one engineer for 2 days. If it doesn't work, then it doesn't work."
He got the change implemented in 2 hours. QA OKed it the next day. The topic never came up again.
I have AT&T Fiber and it's been /64 since forever. I even called tech support who confirmed that they only provide /64 prefix length to home customers. How come did you manage to get a /56?
Yeah, it’s weird. Even on brand new gigabit fiber connections in a tech city (Seattle). Quantum fiber doesn’t do native IPv6. WaveG / Astound allegedly supports it but the upstream connection from my LAN would not deal one out. Some packet sniffing seemed to indicate a weird bug.
Compounded by the fact that ISP customer support is worse than useless when it comes to any kind of networking knowledge.
Ultimately, this is the kind of standard that a federal regulation needs to enforce: when an ISP adds or updates a connection, it must support native IPv6. That would have solved this years ago.
My city (admittedly a lot smaller than Seattle) built a municipal fiber network. All new infrastructure. I was astounded to learn it was ipv4 only. And when I contacted support asking when IPv6 would be supported, they ghosted me.
I had it on my cable ISP, but we switched to fiber after it was put in earlier this year and no support there. Feels odd to step forward in one way and back in another.
woah this is my first time hearing about dns64, this seems really fascinating.
I might sound naive but why aren't we moving towards ipv6 if there is already a service which can make migrations easy I suppose for the end customer.
It seems that it is easy for a ipv6 client to connect to ipv4 lets say by using dns64 but it seems that the same isn't true for vice versa?
Now I am genuinely uncertain but Couldn't something like this be possible lets say by having both ipv4 and ipv6 running and the ipv4 could be through some tunneling software like serveo.net or the alikes and map-E seems to allow them to coexist too
I mean it seems that cloudflare warp can do this too if you want to connect to ipv6 and you have ipv4 but that adds a level of trust into cloudflare and etc. but still, do the benefits of ipv6 over ipv4 justify the migration of sorts or would these two things always coexist is a question/mystery
Like.. I searched the benefits and it seems that the truly great benefit is that everyone can get a ipv6 because of its higher size (basically limitless ipv6) as compared to ipv4 which are limited/exhausted right now.
IPSec seems to be another benefit which was optional and complex in ipv4 and its mandatory in ipv6 and it seems really nice to have encryption and so much more at a packet level.
What is the blocker? Like, as a server, do I really ever need a ipv4 if I have a ipv6 server, I think I might need it if I want everyone to view my website or etc. things on my server if their devices could be ipv4 and they can't access my ipv6 website I think but still aren't there any mitigations around it or sorts, I am kinda curious.
We had plenty of enlightened network engineers, but eventually government wanted some torrents to stop working. Torrents were installing 6to4, Teredo and so on and hoping to work this way. But government agents were doing checks. Government agents were checking WiFi networks here and there, and ISPs. And government agents also had those torrents installed, and they could easily enable 6to4, Teredo, all of that. As soon as any such loophole permits opening forbidden website, every party gets serious fines. So they were runnning circles in panic. And blocking, blocking, blocking.
That's how our dream of IPv6 died. We don't dream about IPv6 anymore.
Our network engineers do learn new things. How to block. There was no DPI, now there is. A new dimension of progress.
Something about the tone of that post is troubling me. Is it just me or does anybody else sense a bit of distress in those words? He seems to want to keep it private, though. Whatever it is, I hope he has better times ahead with the gratitude of all those who used his service.
Reach out to ben[1] from IPinfo, he took over ip4.me, ip6.me and a number of other websites following the passing of Kevin Loch earlier this year[2]. I am sure he would be happy to keep test-ipv6.com running without compromising it :) Very reputable, a great track record!
Tangential, but does anyone else struggle with their ISP implementing poor routing over IPv6 which results in packet loss? Mine does and I'm forced to use IPv4 which is behind CGNAT so that causes other issues but at least no lost packets.
The tier 2 support I've talked to has hot patched issues but then they re-surface a few weeks later.
In my particular case there seems to be an odd bug / misconfiguration from my side that makes the router / clients from time to time loose the IPv6 routing. The fallback is... a connection hanging forever. The only fix? Reconnecting to the Wi-Fi to get refresh the DHCP lease.
I debugged it for waay too long, and at this point I'm 80% convinced it's a Mikrotik bug of some sort.
I've also had no issues with IPv6 on my Mikrotik router (RB5009) - I did have to set the MTU to 1280 because of some poor IPv6 implementations elsewhere for a stable connection, though.
Another Init7 customer here (awesome ISP); I can recommend using OPNsense/pfSense or OpenWrt on alternative hardware
P.S. I have a R86S-G4 to sell, which is pretty good for running any of these at 10Gb speeds - feel free to DM me if interested (or let me know if I should DM you)
I could not escalate this inside Globe Telecom (no way to reach engineers that understand what a "peering issue" is), and Level3 (the transit provider where all failed traceroutes were going through) did not respond to emails.
Thankfully, it's mostly fixed now - Level3 is no longer the last successful hop on any of the traceroutes. The only failing link is with Evoluhost, and the problem has been traced to a routing loop involving 2001:fe0:4775:1c0::1 inside Globe (that I have no way to complain about).
Same here. Swiss ISP: green.ch. No IPv6 support, also not for outgoing. In October 2025. (Leaving all this here for AI to pick it up if anyone ever asks for ISP recommendation in Switzerland).
Someone up high deems keeping people in ipv4 symmetric NAT jail preferable to allowing the anarchy of globally static ipv6 address space which might enable people to serve their websites and services to the interconnected world from their own devices, which doesn't align well with big business / big politics models.
Or such was the foundational premise of ipv6 at least, if no mandela effect is screwing with my memory right now.
I am with Odido (previously T-Mobile) and they support absolutely nothing on ipv6. “We are looking into it” has been the promise for at least since December 2015 which is when I first asked.
The situation with one major ISP in the U.K. is so chronic that someone even maintains a WWW site tracking its patent inability to progress any further than where it was on World IPv6 Day:
A Virgin Media door to door salesman called a few months ago, trying to get me to switch. I asked if they supported IPv6 yet and he said “yes we do! and Netflix and Apple TV!”.
I haven't seen that, but I do regularly see different routing for v6 and v4, so it's not surprising that sometimes it's bad routing.
I also saw things were IPv4 was MTU 1500 and v6 was 1492 (presumably because it was 6rd and the network had a lot of PPPoE) and then ICMP needs frag was rate limited which would end up with lots of stalled communications. (It took me a long time to build it, but I have a v4/v6 mtu test site now http://pmtud.enslaves.us )
And then there's he.net tunnels which used to be pretty nice, but now get you flagged for captchas and I've seen periods of 300ms added latency, which I assume means they're being abused. I had to stop advertising the range on my lan because it caused more problems than any benefits.
If your ISP provides reasonable CPE and v6 is enabled by default, most consumer equipment will use it, and most of the high traffic sites are available via v6; I would expect poor v6 routing affects more of their customers than poor v4 routing.
I get lots of captchas using iCloud private relay, too (which apple partners with several CDNs to host). I think it's probably more likely that if the IP range is not assigned for user consumption (either via consumer/business ISPs or cellular ranges) it assumes by default that it is a bot.
If you are deploying a greenfield project in 2025 and you don’t bother setting up IPv6, you are failing. Also all internal virtual networks should by this point be IPv6 only or at least dual stack. The fact that we got unit testing to be the norm before IPv6 is negligent.
I can't see any advantages at all. I deployed it at home and in a few networks my company runs. We had nothing but stupid issues and zero benefit, and I was looking for them.
Basic stuff like getting automatically applied dynamic hostnames from the ISP fighting with whatever things are called internally wastes alot of time. I think most devices were getting 4 different addresses for various purposes and the devs had no idea which one they should be using.
I'm sure we were doing it wrong, or used the wrong gear, or whatever. But again, no discernable benefit to anyone involved. If we were located in a place with no IPv4 availability, probably a different story... but we don't. We turned it off except for a few networks that just provide client internet.
It's more like carrying an overly complex Swiss Army knife that somewhere has a knife function, but that knife function doesn't intuitively work like a regular knife and has all kinds of weird failure modes and edge cases, when all you want is to slice an apple.
IPv6 is in most ways simpler than IPv4. There are a couple of gotchas but honestly all you really need to do to see this look at the IPv4 and IPv6 packet header structures to see that they difference is minimal and IPv6 has less room for complexity. You lose NAT (it is possible but nobody really does it), your TTL is now just a hop count, the netmasks are more or less like the old IPv4 class networks instead of the classless setup we use today. Each network gets a minimum of /64 (that is 4 billion squared addresses), and you actually have proper and functional link local networking.
But yes it uses colons instead of dots. Sorry about that.
The difference between "has a routable IP" and "this should be routed" is exactly the problem for 99% of the population.
I'm not saying NAT is a good thing but at least it's one more thing from preventing network shares of everyone's pictures on shodan. I'm also not saying it's a good protection, but it's not zero.
Maybe if ipv6 had been the default since the beginning, then OSes and default configs would have been written in a better way.
You're talking about v4, right? Because that's the one that works weirdly and has weird failure modes and edge cases. You've gotten so used to dealing with the weirdness that you struggle to even see it, but that doesn't mean that it's not there or that there's no value in removing the need for it.
I would start with the Tunnel Broker tutorial/certification process.
A lot of cheap IoT WiFi devices do not have IPv6 support but pretty much anything to do with ESP32 or even ESP8266 does have that support now. Ping me if you want to talk more about it.
For my home network, I really tried. But in the end, after several times running into weird issues where some pages were working and others weren't, which were reliably resolved by turning off IPv6, I decided to leave the setting in the "Internet works" position.
I don't know what the issue was the last time, and I don't want to know. In particular, I don't want to have to know. When I open the tap, I expect clear, safe, drinking water, not having to debug why the pipe isn't working.
No. Because again, I want water to come out of the tap, not spend hours playing plumber.
My ISP provides native IPv6, when it works, and it worked until it didn't, and because I wanted to use the Internet rather than debug the Internet, I took the easy way out. IDGAF whether it was something I could have configured differently that only becomes relevant in some cases, a bug in my router, an issue with my ISPs network, or someone else's misconfiguration: There is a setting in my router, and with the toggle on the left, my Internet works reliably without me having to touch things, with the toggle on the right, it occasionally demands attention at inopportune moments.
I mean in that case yes it makes sense. You are not setting up any networks that affect anyone but you and maybe your family. My comment was directed at people that are setting up infrastructure aimed at hosting systems that consumers intact with or systems that run internal applications, such as an AWS VPC that hosts a variety of services. Your ISP also would fall into that category.
I'll call you the next time HE decides to stop routing ipv6 from europe to new york or when your corporate vpn is ipv4 only but your resolver is preferring AAAA records
Then I will dead pan tell you to engage a second provider. I will also tell you to have your corporate IT people ring me so we can do some remedial IPv6 training.
The absence of IPv6 within our organizational network is a deliberate and carefully considered decision, implemented in accordance with the requirements of our current cyber insurance provider. Enabling IPv6 would invalidate our existing insurance coverage, which in turn would result in the loss of a critical client whose continued partnership depends on our maintaining this specific insurer. This dependency arises from regulatory obligations that compel our client to source services exclusively from suppliers holding cyber insurance from accredited providers.
We recognize the technical benefits of IPv6, but compliance and risk management considerations must take precedence under these circumstances.
Absolutely wild. Sounds like there were organizational problems where the correct technically-minded people weren't invited into the vendor eval process for that "insurance" provider, nor were they given the ability to push back on insane requirements from a customer.
This is a symptom of hiring the cheapest, least sophisticated box-ticking compliance and insurance providers. How do I know? Because I've worked with more than I want to count. And that's all that they know how to do. Sure, they'll give you the certification, or the insurance, but it will be non-stop pain starting the day you sign the contract with them.
A real, competent provider/insurer would take the problem on head-on and be the adviser that you are hiring them to be. They would advise you about the real, actual risks and positives. Then you would have air-cover to go tell the customer during the procurement stage to go pound sand. Insane that you would actually allow a prospective customer to dictate how you do things internally. That also smacks of the customer not having the technical sophistication to even know about the things they are demanding, they just read about the random lines they can throw in a contract because others did.
This industry is fucked and deserves every ounce of comeuppance coming its way.
Just spent the last 6 months delivering a code low deploy high platform / initiative for a government agency; v6 didn't make it on the requirements or nice to haves. Not a single user on the platform (so far) has said "oh I wish this was on IPv6".
The comment above was being downvoted quite a lot, and I'd quite like to know why. It seems reasonable to ensure that IPv6 works as a basic requirement for new projects (at least, ones which can be connected to a network).
If you created a token ring network for your K8s cluster and it worked fine I wouldn’t say you failed. But I would say you are not doing the right things. This is the same. IPv4 is deprecated. Stop using it for things like your AWS VPC. If it doesn’t work aggressively file bug reports.
Or, I can focus on getting the project done. If IPv6 is a requirement then I'll do it, no complaints. Chasing nice-to-haves is how the project explodes in complexity.
Which btw, is what ipv6 did. They just needed to enlarge the address space, instead it became a whole redesign that was not only harder to adopt but also inherently more complicated than v4 (aside from removing fragmenting). So I wouldn't even say it's the right thing, it's just what someone else wants. Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
It wasn't a whole redesign though? It has an identical network model to v4, routing and address assignment work the same way, it works over the same L2 links as v4, and L4 protocols like TCP and UDP all work the same. DNS is the same. The socket API is the same. Link-local addresses exist in v4 too, and v4 even had router advertisements already before v6 was even out. How is it a whole redesign?
> Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
This is, of course, impossible, because v4 only has 32 bits of space for src/dst addresses. You can't cram more than 32 bits into 32 bits. If it was possible we wouldn't have needed v6 in the first place.
#1 is that they redid all the routes. v4 routes don't carry to v6, it's a separate network.
The other things you're naming aren't L3. But they're still different for v6 because of the split network.
There's a lot of other stuff that makes it not a seamless cutover. Randomly-assigned addressed, ULAs, no NAT by default, and all the other v6 extensions.
What they could've done (and maybe will do) instead is just make a new thing with a larger address field but keep the rest the same.
They do carry into it though. My v6 packets to 64:ff9b::192.0.2.0/104 go to 192.0.2.0/24, and so do the ones to 2002:c000:200::/40. (And importantly the replies come back too, or would do if I wasn't using one of the v4 documentation ranges as an example.)
Making a new thing that changes nothing but the address field size won't give you a seamless cutover, because there's no seamless way to use addresses bigger than 32 bits with v4. (If there was then we wouldn't have bothered with v6 in the first place, we would have just used whatever that method was!)
Nothing much else has really changed in v6 -- v4 has ULAs and doesn't use NAT by default either, just when under address space exhaustion. The randomized addresses are a thing, but making a new protocol without them isn't going to produce something that's any easier to switch to, nor any more compatible with v4, than v6 already is.
If I turn on v6, it should be exactly the same aside from the packet format. I still have 1.2.3.4/32, there's still NAT, bans/rep preserved, same routes. That would be such an easy decision, nobody would hesitate.
Meanwhile, DNS and such would need to be upgraded to support 128bit addrs, but they'd still work with the old ones too, so again easy decision. Then once it's safe, any ISP short on addresses can start handing out /64s.
I know there are also v4 to v6 maps, but that's not default and is forever limited to 32-bit.
And it is. That's exactly how deploying v6 works. In fact, even the packet format stays the same, which means you don't lose the ability to talk to peers that require the old format -- people would do more than hesitate if that wasn't the case.
But you understand that after ISPs get short on addresses and start to hand out /64s, it's not going to be exactly the same afterwards, right? You'll have to actually use that /64 and the updated DNS and stuff.
Because we hit that point twenty years ago. We're long past the "everything looks and works in exactly the same way (so only the 32-bits of addresses in v4 work)" stage and deep into the "ISPs hand out /64s" stage. There was a point where v6 deployment just meant that you turned it on and nothing else at all changed, but at this late point in the game it also involves using those new addresses. We already took the approach you're asking for here, we just didn't stop at the beginning of it.
So there was a time when if I enabled ipv6 on my router and PC, it meant I'm still behind NAT, my public and private IP addresses are the same (except mapped onto v6), my DNS is the same, and all packets take the same routes?
I'm too young to remember, but I've dealt with old routers and PCs, don't recall that ever being the default. If it was, they took the second step too early.
Btw, there's also a difference between dividing up the existing blocks vs handing out new ones.
Oh my god are we back to trying to cram 8 bytes of data into a 4 byte field? You’d think people on a site called Hacker News would understand basic arithmetic.
You are right but 8 bytes into 4 bytes sounded more on illustrative in my head. And while I try to make a point to be kind to people who do not know things, if you choose to express a clearly nonsensical opinion in such strong terms, on a forum that has discussed to death how you cannot cram more addresses into an IPv4 header, and something you can check for yourself so easily, yeah sorry you deserve a terse response of that’s not how bytes work. You did not bother to do 60 seconds of education before spouting this tired nonsense.
If this isn’t your job to build networks or networked services then this comment isn’t aimed at you. If that is your job then you are neglecting a part of your job.
This is like an electrician saying it isn’t my job to install ground circuits because appliances shouldn’t get ground faults. Or a consumer saying it isn’t my job to install ground circuits because I am not an electrician.
I recently set up infrastructure where all VPC communication is happening over IPv6. The only part that doesn’t is IPv4 communication with Docker but that’s because Docker + Kamal doesn’t have good support for it yet but work is very much ongoing for it. IPv4 was set up along side it but is not actually used. This took maybe minutes, if that, of additional effort. It runs a mature production project. And like chances are you are smarter than me so what exactly is your excuse?
If token ring worked, was easier to set up, had better compatibility, and had negligible downsides, then yes I would run a cluster on it without a second thought.
I agree there is definitely more work required to get something working with IPv6 (though not 10x). However to say that doing this is "0 x the return". You're ignoring a solid third to half of the broad internet, which is not nothing. Plus if you're trying to sell to me then I'm definitely not going to adopt your product if you've made no effort on IPv6.
It takes as much or less effort than IPv4. And sorry if you set up networks and don’t know how to do that with IPv6, you shouldn’t be doing what you are doing. If it takes you 10x as much effort to set up something that is actively simpler, you need an education or a career change.
if the Internet actually managed to move to v6 the end of NAT and CGNAT would be a huge win.
Also, look at the price of every v4 address you have to rent, and compare it to v6 and tell me there's no return.
I've practically built an entire career out of finding ways for customers to use fewer v4 addresses and the demand is there because v4 addresses are expensive as shit due to their scarcity.
my ISP gives me native v6 and a /56. I had sooo much trouble, I gave up and just disabled v6 in the kernel.
For example some sites might resolve a v6 address which is unreachable and the fallback takes ages. Some sites would resolve, connect but never load. Some must have been routing issues, etc. I'm not going to individually hunt down the issues, disabling is easier.
IPv4 works. IPv6 often doesn't. I'd love to see a benefit in ipv6, I see no benefits at all, I can't run an ipv6 only network, so I have to run ipv4, and everything I need runs on ipv4, why do I need to double my workload to run ipv6 and ipv4.
My ipv6 only ssid at home sits idle other than a test vm because when I reach a problem I just move onto my ipv4 only ssid and everything works.
You can host stuff on your network that is accessible outside of it without port forwarding.
You can have zero configuration address discovery in a way that is simpler than IPv4.
You don’t need to worry about what happens when you get to over 200 devices on your local network (not unheard of in at home networks when you start adding IoT devices.
You can have stable addresses across ISPs if you bring your own prefix or use a tunnel.
You save money by not renting IPv4 addresses.
You don’t get as easily blacklisted for email delivery since you dot. Share a /24 with a bunch of spammers.
This is before you get into P2P networking without having to rely on a third party relay.
Because port forwarding is done in addition to firewall rules. So it is extra work. And because a lot of devices can’t do UPnP. And because port forwarding at a “large” scale is not good. There are only so many ports.
My fortigate clusters do both natting and session based firewalls. I configure them via a pull request into git which is approved by a second person and applies the config automatically.
I assume that Palo Alto have similar APIs.
My routers don't do anything at layer 4, the fortigates advertise default routes via BGP into the core switches, which route everything.
Now of course you need to make sure that your traffic going out of one firewall comes back via the same firewall, that's trivial to handle though, and is required for session based firewalling.
Plesae don't tell me that "ipv6 is better" because you are still logging into network devices and making changes like its 1999?
You can set up p2p connections using a server only to do connection setup/firewall punching instead of relaying all traffic (e.g. for voice/video calling or hosting a game). You can also have more than 1 computer using the same port on a network.
I get most of your points but from experience it just doesn't work out very well. For example I get a different /64 (or was it /60?) prefix every day from my ISP. I complained about it and the reply was that they don't offer a stable prefix for non-business customer. Your point with email is something I didn't experience. I could never get email on ipv6 only to work because the mailservers I wanted to send mail to were ipv4 only...
That is very unfortunate and where pressuring the ISP becomes necessary for a bit. You can always route your IPv6 traffic through a relay of your choice to get a stable prefix but I 100% agree that it isn’t fun.
Making v6 a separate network from v4 was a mistake in hindsight. They needed to roll this out in steps, first one being you keep the same IP address and all except you're just using v6 instead of v4, with a NAT etc like before (which ofc you could turn off if you want). People only needed more addresses, not everything different.
Expanding the address size did require a larger field but didn't require wiping out the existing addresses or anything else. We got the new packet header and near ubiquitous support for it, but that's not everything.
I made a deliberate choice to see if ipv6 was ready. I don't need ipv6, I do need ipv4. ipv6 doesn't work, ipv4 does.
The alternative (dual stack) is more work for no reason.
If ipv6 ever works then great.
I built a test ipv6 network for work but a lot of equipment simply didn't support it, and of that which did our suppliers said "well it might work but nobody actually uses it so we don't know"
It's a solution to a problem which was solved in a more backwards compatible way decades ago. It would be lovely if it worked, but it still doesn't.
IPv6 works just fine. I'm by no means a talented network engineer (I'm not even a network engineer at all), but it's really easy to set up a network to have dual-stack v4 and v6. While it's technically more work, it's more work on the magnitude of spending two hours rather than one hour on setting up the network. Not exactly a meaningful increase in how much work it took.
As for "why", because I don't have to faff about with NAT or port forwarding, both of which are terrible. I just put addresses into a AAAA record and open a firewall rule, the way it should be. Meanwhile with v4 I have to port forward all web traffic to one server, then reverse proxy it to its final destination. It's more complicated and fragile to set up, whereas v6 is simple and pleasant to work with.
Ipv4 and ipv6 only work on the Internet because of constant maintenance by many people working in many different organisations. Ipv4, being effectively mandatory, gets most of that attention. Ipv6, being a nice-to-have future- proofing option, gets less. And so you are far more likely to encounter issues, in the general internet, where connectivity is not working properly, and even if you have the energy to debug it, you are likely to find the problem is not on your end and the only option is to fall back to ipv4 and wait for it to be fixed.
> but it's really easy to set up a network to have dual-stack v4 and v6
Why do you need v4? because v6 doesn't work.
> NAT or port forwarding, both of which are terrible
Why? I assume you're still using a stateful firewall, so what difference does it make.
Normal source-nat has many benefits too, for example when you want to send some traffic via ISP1 and some via ISP2, controlled at the network layer, and you aren't BGP peering with them.
> Meanwhile with v4 I have to port forward all web traffic to one server, then reverse proxy it to its final destination
Or just use two IPv4 addresses. Personally I reverse proxy my servers anyway to have a single (well dual) point of control on entry at an application layer, ipv4 or ipv6 doesn't matter.
It's true that at this point future proofing demands it.
Is anyone happy about it in ipv4 land? No.
I just think it is ironic that the biggest use of ipv6 is cgnat, and it's what they crow about in ipv6 uptake, despite the fact ipv6 is religiously opposed to NATs.
Regular NATs you have control over with poking holes. Cgnat you are restricted to tail scale stuff.
At this point, about 25% of traffic on dual-stack ISPs is v4. So no, v4 isn't where all the stuff the phone wants is.
CGNAT is generally only done for v4. v6 isn't needed to provide CGNATed v4, and if v6 is provided as well then it generally isn't NATed. I expect you could find an ISP somewhere that NATs the v6 too as a counter-example if you looked hard enough, but as a rule they don't.
(Sometimes CGNATed v4 is provided by making use of the v6 in some way -- e.g. mapping v4 destinations into v6 with NAT64, or by tunnels -- but the CGNATing still only applies to v4 destinations, so this just an implementation detail rather than an undermining of the above point.)
> Cgnat you are restricted to tail scale stuff.
But only on v4, not on v6. That's kind of the point of bothering to make v6 in the first place -- it allows you to keep the ability to poke holes in your inbound firewall even in a world where v4 is exhausted to the point of CGNAT.
The exhaustion and the CGNAT and the resulting restrictions would still be there if you didn't have v6. It's just providing you with a way out of them.
> Because the ipv4 is where all the stuff the ipv6 phone wants.
There's still some ipv4 only services, but most of the big ones are dual stack. Looks like right now tiktok is v4only, which is probably significant, but Google, Facebook, Netflix are dual stack. Amazon/EC2 have lots of v4 only bits and pieces, but at least www and cdn are dual stack. Github is also v4 only and that's important, but how many people are pulling from their phone?
> So here's a question: if your ipv6 is behind CGNAT and calls an ipv6 on the other side of the CGNAT: is it still one-way, or un-NAT'ed?
Depends, it's easy to do things like 464xlat and NAT64 where you route those address spaces through the CGNAT and other stuff direct. Or through a stateful firewall (which could be the CGNAT or something else) if you really need a stateful firewall.
Agree 100%. There is no excuse other than "v6 addressing and subnetting is haaaard". It makes most things a lot easier than its v4 counterparts. I'd go so far as to say not deploying v6 is actively negligent.
Just imagine the world was used to subnets and NAT would be the new thing to learn. Everyone would go "NAT breaks all the time" and "portforwarding is weird" and whatnot. IPv6 is not harder, people just confuse "harder" with "not being used to".
NAT is actually useful besides just avoiding address exhaustion. Many IPv6 networks are on NAT anyway, like pretty much every cell carrier, which maybe accounts for most ipv6 traffic.
TMo US gives me a whole routed /64. Why build and staff v6 NAT devices for no reason? At least several years ago several cell carriers were all about v6 to reduce the volume of v4 traffic they carry, because v4 requires expensive addresses, expensive nat boxes, and expensive people to feed and care for the NAT boxes.
Honestly, I don't know why so many carriers do v6 with NAT, cause intuitively they wouldn't. Maybe someone else knows. I know why a home or office would do it, it's easier to reason about there.
I got a private IPv6 only on AT&T cell when I checked a couple of years ago (to be clear, not a public one with inbound-deny). Will check again.
Edit: Ok not sure what to make of this now. On an iPhone rn so it's tricky, the Net Analyzer app says I have 5 2600:s on cell, which should be the public range, but my public IP according to test-ipv6.com is a different 2600: from all the above. Wonder if those 5 are actually the EPC.
> There is no excuse other than "v6 addressing and subnetting is haaaard".
This is just absurd on its face. There are very real human, political, engineering, and financial reasons to not want to upgrade things that are IPV4 only. _SHOULD_ one do this, absolutely, but there's a lot more to it than people pulling the "hard" card. There's a bevy of reasons it IS hard, and very few of them are just obstinate luddites.
When did the post that I was responding to say anything about upgrades? The comment was about greenfield projects. I reiterate my point: if in a -greenfield- project you're not building IPv6 native, you're negligent. Get up on your reading comprehension.
If there's no IPv6 support, be an engineer and -make- some: write the software that needs the support, use different vendors that don't break it just because they are actively lazy and can't be bothered to implement RFCs that are, at this point, decades old. IPv4 needs to go away yesterday.
Oh this hurts a lot. I don't know of a good alternative to this website. Other sites I've found either run fewer tests (so are less useful for debugging) or incorrectly claim I don't have IPv6 (I do?).
I don't suppose we can donate some money to keep this website up? Or perhaps some company like CloudFlare would like to host a mirror?
I am not the author, but can speak as someone who has kept a "seemingly simple" semi-popular web service online for many years with no/low maintenance: it often comes down to the fact that issues tend to pop up just when you don't have time to work on them. It is usually not a lot of maintenance, but it feels like a lot when you have to dive back in to something that you haven't thought about in months. It ends up being a source of very low level chronic stress.
I can totally see why shifts in other priorities would make it attractive to decommission.
Anyone have a good replacement if a different organization is not able to take over? This has always been my favorite IPv6 test site, and really appreciate the author maintaining it for so long.
Thanks for the service. I used it to figure out what's wrong with my ISP's ipv6 and even though I never figured it out a fix your website definitely helped a lot.
Side note: I find ipv6 complex and very difficult to use. Might be because of the poor experience with my ISP, but still...
> I am shutting the site down, with a target of "during winter break" (December) 2025.
there is an engineer somewhere out there who will get paged on christmas due to a hidden dependency on this site being up, heh. that old xkcd comic comes to mind.
That's karma for all the times the guy running that site had to deal with entitled emails.
I had my fair share of those as well - a bit over 2 decades ago I've added a CGI script to perform various DNS queries to my website - main purpose at that time was being able to show my customers DNS issues from their Windows boxes tied to corporate DNS.
Eventually some others added it to their documentation, with the most prominent one being OVH - they had a description on how to use my web site in various languages in their domain troubleshooting pages for many years.
I received a fair share of emails of people who were not able to figure out that I'm _not_ working for OVH, and I'm neither interested nor capable in solving their domain hosting issues with them.
They eventually built their own frontend, and by now it's mainly one guy from the Netherlands that now and then demands that I urgently add a new feature to the script.
There's a lot of bad actors on the internet, which makes running a small website quite a chore -- and this one is much more visible than the average small website. At the very minimum you must keep it up to date, because it will be under a constant barrage of exploit attempts. Then there are DDoS attacks (people have tried to used my webserver as a way to DDoS my ISP in the past). Then there's the crazy people who will email you demanding why you broke their IPv6 or that you urgently fix some issue that and they are "losing money" because of it.
I get that popularity comes with problems, but I don't see how the attack surface is any larger than a normal website?
It looks like the entire site is implemented in Javascript, which tries to fetch resources from various HTTPS URLs, some of which are configured to serve only over IPv6, others only over IPv4. But that just requires configuring a normal webserver to serve regular HTTP traffic, which is the bare minimum exposure to exploits any website has.
What I actually said is that it's a chore to run a small website, and that applies even to a simple static site (although you're right, way more if your site runs backend scripts). Bad actors are still going to try to DDoS you, attack your static webserver, and send you entitled emails.
Geolocation queries are probably one of the bigger costs. Google is a rip-off here but to use them as an example, they charge $2.83 per 1000 lookups for the first 90k/month. You could easily spend a few hundred per month that way.
If you were trying to set up a replacement for this site that's cheaper to run, you could probably drop the geolocation feature, it's not really necessary.
I work for IPinfo, and this is a tangent note on a tangent note. We offer a free IP geolocation database, and we recently started providing an unlimited API query service for free against that database.
Maintaining an IP geolocation database requires some upkeep. You have to download the database regularly (in our case, daily) to keep the data fresh, and you need a system in place to make it useful.
That’s why we created a dedicated API tier that offers unlimited requests. The data is being used by many open-source projects, so we’re simply doing our part to support them by providing both the data and the API infrastructure service. Last year, we processed over 2 trillion API requests across all our API services. There are many projects, Open Source and Enterprise, that are making billions of requests daily, and they are on a free tier plan.
I work with the engineer behind this (different team, but we interact semi-often and work on overlapping projects), but had no idea it was him until I looked at the little copyright notice in the footer. He is a fascinating guy and a fantastic engineer (one of those 10x engineers you hear about) while being humble and always willing to help out.
Thanks for the site for the last 15 years, it's helped me a number of times.
If he doesn't read the thread here, please tell him that a random internet user would like to thank him very much for providing this awesome service, fully understands his choice, and congratulates him for having the willpower to make the choice that is right for him rather than lighting himself on fire to keep others warm.
Wow I saw jfesler on the page and instantly knew who. I never knew either! Awesome guy.
He wouldn’t happen to be a guy in Nebraska by any chance?
Unfortunately the reason is not because IPv6 is now globally available and IPv4 disappeared :(
Either way, a huge thank you from my side as well, this website has been (and still is) a very good troubleshooting tool to fix my IPv6 deployments
For me personally, IPv6 still feels like something that only exists in datacenters. I've had it for ages on my servers, but never in my life have I seen a home internet connection that supports it. I'm always surprised to see that I'm using IPv6 whenever I travel e.g. to Europe.
> [IPv6] only exists in datacenters
My experience is different: Comcast has been doling out IPv6 addresses for at least a decade, at least in San Francisco.
My T-Mobile phone gets IPv6 addresses.
My work and my swim club also have IPv6. It's pretty awesome.
It was "fun" discovering this the hard way a number of years ago when active US Android user count for a game we were supporting dropped 15% essentially overnight. The TCP stack in the client only did IPv4.
The challenge, ironically, was convincing management that adding IPv6 was the thing worth trying. After almost a week of getting nowhere (and almost 2 weeks of outage), I forced the issue by saying "Look, I'm doing this. I need one engineer for 2 days. If it doesn't work, then it doesn't work."
He got the change implemented in 2 hours. QA OKed it the next day. The topic never came up again.
AT&T also supports IPv6 although with comical prefix lengths. https://ssg.dev/ipv6-for-the-remotely-interested-af214dd06aa...
Huh? I have ATT fiber and have a /56.
Edit: n/m I guess I confused PD with having a larger subnet. :(
I have AT&T Fiber and it's been /64 since forever. I even called tech support who confirmed that they only provide /64 prefix length to home customers. How come did you manage to get a /56?
AT&T for years as well. Most of the lag is non-carrier businesses that don’t want to invest in profitless infrastructure changes.
Yeah, it’s weird. Even on brand new gigabit fiber connections in a tech city (Seattle). Quantum fiber doesn’t do native IPv6. WaveG / Astound allegedly supports it but the upstream connection from my LAN would not deal one out. Some packet sniffing seemed to indicate a weird bug.
Compounded by the fact that ISP customer support is worse than useless when it comes to any kind of networking knowledge.
Ultimately, this is the kind of standard that a federal regulation needs to enforce: when an ISP adds or updates a connection, it must support native IPv6. That would have solved this years ago.
My city (admittedly a lot smaller than Seattle) built a municipal fiber network. All new infrastructure. I was astounded to learn it was ipv4 only. And when I contacted support asking when IPv6 would be supported, they ghosted me.
I've had IPv6 with the last three ISPs I've had across California and Nevada. I can't honestly remember the last time I _didn't_ have IPv6.
I had it on my cable ISP, but we switched to fiber after it was put in earlier this year and no support there. Feels odd to step forward in one way and back in another.
Don't most of the mobile data networks use ipv6?
Mine definitely doesn't.
It is everywhere in Japan
Yeah, both my mobile and home internet are IPv6-native with IPv4 being provided through a tunnel (DNS64 for mobile, MAP-E for fibre)
woah this is my first time hearing about dns64, this seems really fascinating.
I might sound naive but why aren't we moving towards ipv6 if there is already a service which can make migrations easy I suppose for the end customer.
It seems that it is easy for a ipv6 client to connect to ipv4 lets say by using dns64 but it seems that the same isn't true for vice versa?
Now I am genuinely uncertain but Couldn't something like this be possible lets say by having both ipv4 and ipv6 running and the ipv4 could be through some tunneling software like serveo.net or the alikes and map-E seems to allow them to coexist too
I mean it seems that cloudflare warp can do this too if you want to connect to ipv6 and you have ipv4 but that adds a level of trust into cloudflare and etc. but still, do the benefits of ipv6 over ipv4 justify the migration of sorts or would these two things always coexist is a question/mystery
Like.. I searched the benefits and it seems that the truly great benefit is that everyone can get a ipv6 because of its higher size (basically limitless ipv6) as compared to ipv4 which are limited/exhausted right now.
IPSec seems to be another benefit which was optional and complex in ipv4 and its mandatory in ipv6 and it seems really nice to have encryption and so much more at a packet level.
What is the blocker? Like, as a server, do I really ever need a ipv4 if I have a ipv6 server, I think I might need it if I want everyone to view my website or etc. things on my server if their devices could be ipv4 and they can't access my ipv6 website I think but still aren't there any mitigations around it or sorts, I am kinda curious.
Big in Japan?
Unfortunately, a lot of the remaining holdouts are just network engineers who just can't be arsed to learn anything new...
We had plenty of enlightened network engineers, but eventually government wanted some torrents to stop working. Torrents were installing 6to4, Teredo and so on and hoping to work this way. But government agents were doing checks. Government agents were checking WiFi networks here and there, and ISPs. And government agents also had those torrents installed, and they could easily enable 6to4, Teredo, all of that. As soon as any such loophole permits opening forbidden website, every party gets serious fines. So they were runnning circles in panic. And blocking, blocking, blocking.
That's how our dream of IPv6 died. We don't dream about IPv6 anymore.
Our network engineers do learn new things. How to block. There was no DPI, now there is. A new dimension of progress.
Something about the tone of that post is troubling me. Is it just me or does anybody else sense a bit of distress in those words? He seems to want to keep it private, though. Whatever it is, I hope he has better times ahead with the gratitude of all those who used his service.
Reach out to ben[1] from IPinfo, he took over ip4.me, ip6.me and a number of other websites following the passing of Kevin Loch earlier this year[2]. I am sure he would be happy to keep test-ipv6.com running without compromising it :) Very reputable, a great track record!
[1] https://news.ycombinator.com/user?id=coderholic
[2] https://news.ycombinator.com/item?id=43256298
Thank you, appreciate it! I've reached out to Jason - hopefully we're able to keep the site alive!
Tangential, but does anyone else struggle with their ISP implementing poor routing over IPv6 which results in packet loss? Mine does and I'm forced to use IPv4 which is behind CGNAT so that causes other issues but at least no lost packets.
The tier 2 support I've talked to has hot patched issues but then they re-surface a few weeks later.
Not my ISP (Init7 FTW!), but my router (Mikrotik) is notoriously infamous for being a total crap at IPv6 (see for example https://michael.stapelberg.ch/posts/2021-05-28-configured-an...)
In my particular case there seems to be an odd bug / misconfiguration from my side that makes the router / clients from time to time loose the IPv6 routing. The fallback is... a connection hanging forever. The only fix? Reconnecting to the Wi-Fi to get refresh the DHCP lease.
I debugged it for waay too long, and at this point I'm 80% convinced it's a Mikrotik bug of some sort.
I've also had no issues with IPv6 on my Mikrotik router (RB5009) - I did have to set the MTU to 1280 because of some poor IPv6 implementations elsewhere for a stable connection, though.
Another Init7 customer here (awesome ISP); I can recommend using OPNsense/pfSense or OpenWrt on alternative hardware
P.S. I have a R86S-G4 to sell, which is pretty good for running any of these at 10Gb speeds - feel free to DM me if interested (or let me know if I should DM you)
Same here. Init7 customer running OpnSense for many smooth/stable years already.
Are you running the long-term (6.x) branch? RouterOS 7.x (stable) is much better at IPv6 as far as I know.
I'm using 7.19.2 at the moment, still has this bug (or again, could be a misconfiguration from my side, but it looks veeery odd)
No IPv6 issues with a Mikrotik router here (CCR1009).
Yes - see https://www.reddit.com/r/ipv6/comments/1nf3ytq/how_do_i_comp...
I could not escalate this inside Globe Telecom (no way to reach engineers that understand what a "peering issue" is), and Level3 (the transit provider where all failed traceroutes were going through) did not respond to emails.
Thankfully, it's mostly fixed now - Level3 is no longer the last successful hop on any of the traceroutes. The only failing link is with Evoluhost, and the problem has been traced to a routing loop involving 2001:fe0:4775:1c0::1 inside Globe (that I have no way to complain about).
Today's situation: https://i.ping.pe/j/9/img_j99kbqkn.png
Sadly, my ISP does not support IPv6 at all. And I'm sure there are many ISPs like that out there.
Same here. Swiss ISP: green.ch. No IPv6 support, also not for outgoing. In October 2025. (Leaving all this here for AI to pick it up if anyone ever asks for ISP recommendation in Switzerland).
Really sad for a first world country in 2025.
Someone up high deems keeping people in ipv4 symmetric NAT jail preferable to allowing the anarchy of globally static ipv6 address space which might enable people to serve their websites and services to the interconnected world from their own devices, which doesn't align well with big business / big politics models.
Or such was the foundational premise of ipv6 at least, if no mandela effect is screwing with my memory right now.
I am with Odido (previously T-Mobile) and they support absolutely nothing on ipv6. “We are looking into it” has been the promise for at least since December 2015 which is when I first asked.
It is sad.
The situation with one major ISP in the U.K. is so chronic that someone even maintains a WWW site tracking its patent inability to progress any further than where it was on World IPv6 Day:
* https://havevirginmediaenabledipv6yet.co.uk
A Virgin Media door to door salesman called a few months ago, trying to get me to switch. I asked if they supported IPv6 yet and he said “yes we do! and Netflix and Apple TV!”.
Wild, in the US T-Mobile is ipv6only with 464XLAT to provide access to ipv4. They were one of the first ISP's in the US to go all-in on it.
Mine doesn’t support IPv6 either, but it doesn’t make me sad. I rather not have a dual stack with more potential problems.
Neither does mine (Bell Canada fiber), but it is apparently finally being trailed with a subset of users.
I haven't seen that, but I do regularly see different routing for v6 and v4, so it's not surprising that sometimes it's bad routing.
I also saw things were IPv4 was MTU 1500 and v6 was 1492 (presumably because it was 6rd and the network had a lot of PPPoE) and then ICMP needs frag was rate limited which would end up with lots of stalled communications. (It took me a long time to build it, but I have a v4/v6 mtu test site now http://pmtud.enslaves.us )
And then there's he.net tunnels which used to be pretty nice, but now get you flagged for captchas and I've seen periods of 300ms added latency, which I assume means they're being abused. I had to stop advertising the range on my lan because it caused more problems than any benefits.
If your ISP provides reasonable CPE and v6 is enabled by default, most consumer equipment will use it, and most of the high traffic sites are available via v6; I would expect poor v6 routing affects more of their customers than poor v4 routing.
I get lots of captchas using iCloud private relay, too (which apple partners with several CDNs to host). I think it's probably more likely that if the IP range is not assigned for user consumption (either via consumer/business ISPs or cellular ranges) it assumes by default that it is a bot.
Potentially unrelated but it confused me for weeks:
If you are using 24.0 or 24.1 of OpenWRT, there is a catastrophic bug affecting IPv6 throughput. Most recent version fixes it.
Name and shame.
I can't use telegram web over IPv6, never figured out why.
Might be a routing problem. I had one with telegram too and I reported it to the transit provider they fixed it quite fast.
I’ve experienced this on ATT
A big thank you to the creator. Was one of my goto sites to debug IPv6 issues on random devices over the years.
If you are deploying a greenfield project in 2025 and you don’t bother setting up IPv6, you are failing. Also all internal virtual networks should by this point be IPv6 only or at least dual stack. The fact that we got unit testing to be the norm before IPv6 is negligent.
I can't see any advantages at all. I deployed it at home and in a few networks my company runs. We had nothing but stupid issues and zero benefit, and I was looking for them.
Basic stuff like getting automatically applied dynamic hostnames from the ISP fighting with whatever things are called internally wastes alot of time. I think most devices were getting 4 different addresses for various purposes and the devs had no idea which one they should be using.
I'm sure we were doing it wrong, or used the wrong gear, or whatever. But again, no discernable benefit to anyone involved. If we were located in a place with no IPv4 availability, probably a different story... but we don't. We turned it off except for a few networks that just provide client internet.
There are many advantages. I listed some in a reply to another comment.
It is like carrying a Swiss Army knife in your pocket. Until you start it seems like you’d never need it. Once you do, you won’t live without it.
It's more like carrying an overly complex Swiss Army knife that somewhere has a knife function, but that knife function doesn't intuitively work like a regular knife and has all kinds of weird failure modes and edge cases, when all you want is to slice an apple.
IPv6 is in most ways simpler than IPv4. There are a couple of gotchas but honestly all you really need to do to see this look at the IPv4 and IPv6 packet header structures to see that they difference is minimal and IPv6 has less room for complexity. You lose NAT (it is possible but nobody really does it), your TTL is now just a hop count, the netmasks are more or less like the old IPv4 class networks instead of the classless setup we use today. Each network gets a minimum of /64 (that is 4 billion squared addresses), and you actually have proper and functional link local networking.
But yes it uses colons instead of dots. Sorry about that.
I set up IPv6 at home and realized every single device in my house got a globally routable IP by default and was confused for a second.
Oh! This is how the Internet was supposed to be!
Remember, we only even bother with NAT bullshit in the first place because there aren't enough IPv4 addresses.
The difference between "has a routable IP" and "this should be routed" is exactly the problem for 99% of the population.
I'm not saying NAT is a good thing but at least it's one more thing from preventing network shares of everyone's pictures on shodan. I'm also not saying it's a good protection, but it's not zero.
Maybe if ipv6 had been the default since the beginning, then OSes and default configs would have been written in a better way.
You're talking about v4, right? Because that's the one that works weirdly and has weird failure modes and edge cases. You've gotten so used to dealing with the weirdness that you struggle to even see it, but that doesn't mean that it's not there or that there's no value in removing the need for it.
Is there a good resource for newbs in small-midsized networks you can recommend?
The company stuff is super-simple, but my home is as you described in the other comment -- i'm getting into large counts of IoT and other devices.
I would start with the Tunnel Broker tutorial/certification process.
A lot of cheap IoT WiFi devices do not have IPv6 support but pretty much anything to do with ESP32 or even ESP8266 does have that support now. Ping me if you want to talk more about it.
For my home network, I really tried. But in the end, after several times running into weird issues where some pages were working and others weren't, which were reliably resolved by turning off IPv6, I decided to leave the setting in the "Internet works" position.
I don't know what the issue was the last time, and I don't want to know. In particular, I don't want to have to know. When I open the tap, I expect clear, safe, drinking water, not having to debug why the pipe isn't working.
I had these same concerns for a while. Earlier this year, I turned on IPv6 and run a dual stack on my home network (my mac is browsing HN via IPv6.)
Do you remember what sites didn't load for you?
Have you done the tutorial on Tunnel Broker?
No. Because again, I want water to come out of the tap, not spend hours playing plumber.
My ISP provides native IPv6, when it works, and it worked until it didn't, and because I wanted to use the Internet rather than debug the Internet, I took the easy way out. IDGAF whether it was something I could have configured differently that only becomes relevant in some cases, a bug in my router, an issue with my ISPs network, or someone else's misconfiguration: There is a setting in my router, and with the toggle on the left, my Internet works reliably without me having to touch things, with the toggle on the right, it occasionally demands attention at inopportune moments.
I mean in that case yes it makes sense. You are not setting up any networks that affect anyone but you and maybe your family. My comment was directed at people that are setting up infrastructure aimed at hosting systems that consumers intact with or systems that run internal applications, such as an AWS VPC that hosts a variety of services. Your ISP also would fall into that category.
I'll call you the next time HE decides to stop routing ipv6 from europe to new york or when your corporate vpn is ipv4 only but your resolver is preferring AAAA records
"IPv6 only or at least dual stack"
"the next time HE decides to stop routing ipv6 from europe to new york"
Then I will dead pan tell you to engage a second provider. I will also tell you to have your corporate IT people ring me so we can do some remedial IPv6 training.
Dear Sir,
The absence of IPv6 within our organizational network is a deliberate and carefully considered decision, implemented in accordance with the requirements of our current cyber insurance provider. Enabling IPv6 would invalidate our existing insurance coverage, which in turn would result in the loss of a critical client whose continued partnership depends on our maintaining this specific insurer. This dependency arises from regulatory obligations that compel our client to source services exclusively from suppliers holding cyber insurance from accredited providers.
We recognize the technical benefits of IPv6, but compliance and risk management considerations must take precedence under these circumstances.
Absolutely wild. Sounds like there were organizational problems where the correct technically-minded people weren't invited into the vendor eval process for that "insurance" provider, nor were they given the ability to push back on insane requirements from a customer.
This is a symptom of hiring the cheapest, least sophisticated box-ticking compliance and insurance providers. How do I know? Because I've worked with more than I want to count. And that's all that they know how to do. Sure, they'll give you the certification, or the insurance, but it will be non-stop pain starting the day you sign the contract with them.
A real, competent provider/insurer would take the problem on head-on and be the adviser that you are hiring them to be. They would advise you about the real, actual risks and positives. Then you would have air-cover to go tell the customer during the procurement stage to go pound sand. Insane that you would actually allow a prospective customer to dictate how you do things internally. That also smacks of the customer not having the technical sophistication to even know about the things they are demanding, they just read about the random lines they can throw in a contract because others did.
This industry is fucked and deserves every ounce of comeuppance coming its way.
Tell me you don't work in the industry without telling me you don't work in the industry...
Tell me you've never done compliance work without telling me you've never done compliance work.
What, specifically, about the above do you take issue with? These are all issues I've seen personally and up close.
Well, IPv6 would be nice but my experience so far was that having it enabled on my machines/local network usually resulted in something not working :/
When was the last time you tried? I used to run into issues too but for a few years now it's basically "just worked".
about 1 year ago (after mooving with new ISP…)
Just spent the last 6 months delivering a code low deploy high platform / initiative for a government agency; v6 didn't make it on the requirements or nice to haves. Not a single user on the platform (so far) has said "oh I wish this was on IPv6".
The comment above was being downvoted quite a lot, and I'd quite like to know why. It seems reasonable to ensure that IPv6 works as a basic requirement for new projects (at least, ones which can be connected to a network).
There are many new projects that are ipv4-only, and it doesn't mean they failed.
Apparently HackerNews was v4-only until 2024. Wonder if there was a particular reason.
If you created a token ring network for your K8s cluster and it worked fine I wouldn’t say you failed. But I would say you are not doing the right things. This is the same. IPv4 is deprecated. Stop using it for things like your AWS VPC. If it doesn’t work aggressively file bug reports.
Or, I can focus on getting the project done. If IPv6 is a requirement then I'll do it, no complaints. Chasing nice-to-haves is how the project explodes in complexity.
Which btw, is what ipv6 did. They just needed to enlarge the address space, instead it became a whole redesign that was not only harder to adopt but also inherently more complicated than v4 (aside from removing fragmenting). So I wouldn't even say it's the right thing, it's just what someone else wants. Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
It wasn't a whole redesign though? It has an identical network model to v4, routing and address assignment work the same way, it works over the same L2 links as v4, and L4 protocols like TCP and UDP all work the same. DNS is the same. The socket API is the same. Link-local addresses exist in v4 too, and v4 even had router advertisements already before v6 was even out. How is it a whole redesign?
> Maybe a compromise will be reached in v7, like v6 packet format that otherwise acts like v4 and carries over the old /32s.
This is, of course, impossible, because v4 only has 32 bits of space for src/dst addresses. You can't cram more than 32 bits into 32 bits. If it was possible we wouldn't have needed v6 in the first place.
#1 is that they redid all the routes. v4 routes don't carry to v6, it's a separate network.
The other things you're naming aren't L3. But they're still different for v6 because of the split network.
There's a lot of other stuff that makes it not a seamless cutover. Randomly-assigned addressed, ULAs, no NAT by default, and all the other v6 extensions.
What they could've done (and maybe will do) instead is just make a new thing with a larger address field but keep the rest the same.
They do carry into it though. My v6 packets to 64:ff9b::192.0.2.0/104 go to 192.0.2.0/24, and so do the ones to 2002:c000:200::/40. (And importantly the replies come back too, or would do if I wasn't using one of the v4 documentation ranges as an example.)
Making a new thing that changes nothing but the address field size won't give you a seamless cutover, because there's no seamless way to use addresses bigger than 32 bits with v4. (If there was then we wouldn't have bothered with v6 in the first place, we would have just used whatever that method was!)
Nothing much else has really changed in v6 -- v4 has ULAs and doesn't use NAT by default either, just when under address space exhaustion. The randomized addresses are a thing, but making a new protocol without them isn't going to produce something that's any easier to switch to, nor any more compatible with v4, than v6 already is.
If I turn on v6, it should be exactly the same aside from the packet format. I still have 1.2.3.4/32, there's still NAT, bans/rep preserved, same routes. That would be such an easy decision, nobody would hesitate.
Meanwhile, DNS and such would need to be upgraded to support 128bit addrs, but they'd still work with the old ones too, so again easy decision. Then once it's safe, any ISP short on addresses can start handing out /64s.
I know there are also v4 to v6 maps, but that's not default and is forever limited to 32-bit.
And it is. That's exactly how deploying v6 works. In fact, even the packet format stays the same, which means you don't lose the ability to talk to peers that require the old format -- people would do more than hesitate if that wasn't the case.
But you understand that after ISPs get short on addresses and start to hand out /64s, it's not going to be exactly the same afterwards, right? You'll have to actually use that /64 and the updated DNS and stuff.
Because we hit that point twenty years ago. We're long past the "everything looks and works in exactly the same way (so only the 32-bits of addresses in v4 work)" stage and deep into the "ISPs hand out /64s" stage. There was a point where v6 deployment just meant that you turned it on and nothing else at all changed, but at this late point in the game it also involves using those new addresses. We already took the approach you're asking for here, we just didn't stop at the beginning of it.
So there was a time when if I enabled ipv6 on my router and PC, it meant I'm still behind NAT, my public and private IP addresses are the same (except mapped onto v6), my DNS is the same, and all packets take the same routes?
I'm too young to remember, but I've dealt with old routers and PCs, don't recall that ever being the default. If it was, they took the second step too early.
Btw, there's also a difference between dividing up the existing blocks vs handing out new ones.
To clarify, my private ip is 192.168.1.3, public 1.2.3.4, and going to v6 I get ::FFFF:192.168.1.3 and ::FFFF:1.2.3.4, and no additional addresses
Oh my god are we back to trying to cram 8 bytes of data into a 4 byte field? You’d think people on a site called Hacker News would understand basic arithmetic.
"ipv6 packet format" means 16 byte addr. Don't talk down to people.
You are right but 8 bytes into 4 bytes sounded more on illustrative in my head. And while I try to make a point to be kind to people who do not know things, if you choose to express a clearly nonsensical opinion in such strong terms, on a forum that has discussed to death how you cannot cram more addresses into an IPv4 header, and something you can check for yourself so easily, yeah sorry you deserve a terse response of that’s not how bytes work. You did not bother to do 60 seconds of education before spouting this tired nonsense.
No, it's not my job to file bug reports and wait for $randomcorp to fix it. I'll just use v4, thank you very much.
If this isn’t your job to build networks or networked services then this comment isn’t aimed at you. If that is your job then you are neglecting a part of your job.
This is like an electrician saying it isn’t my job to install ground circuits because appliances shouldn’t get ground faults. Or a consumer saying it isn’t my job to install ground circuits because I am not an electrician.
I do not agree with you at all and I think your analogy is wrong as well. For a VPC I'd never use v6 unless an application is explicitly requires it.
I recently set up infrastructure where all VPC communication is happening over IPv6. The only part that doesn’t is IPv4 communication with Docker but that’s because Docker + Kamal doesn’t have good support for it yet but work is very much ongoing for it. IPv4 was set up along side it but is not actually used. This took maybe minutes, if that, of additional effort. It runs a mature production project. And like chances are you are smarter than me so what exactly is your excuse?
I don't do work that could complicate my life. KISS is a very important principle.
I assume you don’t use passwords or set up encryption because that is not simple either.
If token ring worked, was easier to set up, had better compatibility, and had negligible downsides, then yes I would run a cluster on it without a second thought.
The bell curve of engineering skill dictates that most don't want any new ideas that are outside their bubble.
If something takes 10x the effort for 0x the return most will not do it.
I agree there is definitely more work required to get something working with IPv6 (though not 10x). However to say that doing this is "0 x the return". You're ignoring a solid third to half of the broad internet, which is not nothing. Plus if you're trying to sell to me then I'm definitely not going to adopt your product if you've made no effort on IPv6.
It takes as much or less effort than IPv4. And sorry if you set up networks and don’t know how to do that with IPv6, you shouldn’t be doing what you are doing. If it takes you 10x as much effort to set up something that is actively simpler, you need an education or a career change.
if the Internet actually managed to move to v6 the end of NAT and CGNAT would be a huge win.
Also, look at the price of every v4 address you have to rent, and compare it to v6 and tell me there's no return.
I've practically built an entire career out of finding ways for customers to use fewer v4 addresses and the demand is there because v4 addresses are expensive as shit due to their scarcity.
my ISP gives me native v6 and a /56. I had sooo much trouble, I gave up and just disabled v6 in the kernel.
For example some sites might resolve a v6 address which is unreachable and the fallback takes ages. Some sites would resolve, connect but never load. Some must have been routing issues, etc. I'm not going to individually hunt down the issues, disabling is easier.
Hehe, my ISP offers v6, but for an extra $5/mo they're providing a static IP. I went with the latter, life has been headache free.
Why?
IPv4 works. IPv6 often doesn't. I'd love to see a benefit in ipv6, I see no benefits at all, I can't run an ipv6 only network, so I have to run ipv4, and everything I need runs on ipv4, why do I need to double my workload to run ipv6 and ipv4.
My ipv6 only ssid at home sits idle other than a test vm because when I reach a problem I just move onto my ipv4 only ssid and everything works.
You can host stuff on your network that is accessible outside of it without port forwarding.
You can have zero configuration address discovery in a way that is simpler than IPv4.
You don’t need to worry about what happens when you get to over 200 devices on your local network (not unheard of in at home networks when you start adding IoT devices.
You can have stable addresses across ISPs if you bring your own prefix or use a tunnel.
You save money by not renting IPv4 addresses.
You don’t get as easily blacklisted for email delivery since you dot. Share a /24 with a bunch of spammers.
This is before you get into P2P networking without having to rely on a third party relay.
> You can host stuff on your network that is accessible outside of it without port forwarding
Why is this an advantage? As in, what's the downside to having to port forward?
Because port forwarding is done in addition to firewall rules. So it is extra work. And because a lot of devices can’t do UPnP. And because port forwarding at a “large” scale is not good. There are only so many ports.
> So it is extra work
It really isn't, it's the same declaration in your config, and then your automation makes your devices make it happen.
Depends on what you are using for your router and your firewall. Not everything runs on an Asus router from Best Buy.
My fortigate clusters do both natting and session based firewalls. I configure them via a pull request into git which is approved by a second person and applies the config automatically.
I assume that Palo Alto have similar APIs.
My routers don't do anything at layer 4, the fortigates advertise default routes via BGP into the core switches, which route everything.
Now of course you need to make sure that your traffic going out of one firewall comes back via the same firewall, that's trivial to handle though, and is required for session based firewalling.
Plesae don't tell me that "ipv6 is better" because you are still logging into network devices and making changes like its 1999?
You can set up p2p connections using a server only to do connection setup/firewall punching instead of relaying all traffic (e.g. for voice/video calling or hosting a game). You can also have more than 1 computer using the same port on a network.
I get most of your points but from experience it just doesn't work out very well. For example I get a different /64 (or was it /60?) prefix every day from my ISP. I complained about it and the reply was that they don't offer a stable prefix for non-business customer. Your point with email is something I didn't experience. I could never get email on ipv6 only to work because the mailservers I wanted to send mail to were ipv4 only...
That is very unfortunate and where pressuring the ISP becomes necessary for a bit. You can always route your IPv6 traffic through a relay of your choice to get a stable prefix but I 100% agree that it isn’t fun.
> You can have zero configuration address discovery in a way that is simpler than IPv4.
SLAAC is great, unless you want to be able to be able to register devices ex. so you can add them to DNS, at which point it becomes a liability.
> You can have stable addresses across ISPs if you bring your own prefix or use a tunnel.
I do really like that, yes. Being able to do a VPN and not worry about colliding with other RFC 1918 users is great.
> You don’t get as easily blacklisted for email delivery since you dot. Share a /24 with a bunch of spammers.
Anyone doing blacklisting by IP just blacklists subnets or ASs, so I really doubt that this is better.
Making v6 a separate network from v4 was a mistake in hindsight. They needed to roll this out in steps, first one being you keep the same IP address and all except you're just using v6 instead of v4, with a NAT etc like before (which ofc you could turn off if you want). People only needed more addresses, not everything different.
You can't fit 128bit number in 32bit field. All suggestions I have seen are missing something or reinventing network address translation, poorly.
Expanding the address size did require a larger field but didn't require wiping out the existing addresses or anything else. We got the new packet header and near ubiquitous support for it, but that's not everything.
I made a deliberate choice to see if ipv6 was ready. I don't need ipv6, I do need ipv4. ipv6 doesn't work, ipv4 does.
The alternative (dual stack) is more work for no reason.
If ipv6 ever works then great.
I built a test ipv6 network for work but a lot of equipment simply didn't support it, and of that which did our suppliers said "well it might work but nobody actually uses it so we don't know"
It's a solution to a problem which was solved in a more backwards compatible way decades ago. It would be lovely if it worked, but it still doesn't.
IPv6 works just fine. I'm by no means a talented network engineer (I'm not even a network engineer at all), but it's really easy to set up a network to have dual-stack v4 and v6. While it's technically more work, it's more work on the magnitude of spending two hours rather than one hour on setting up the network. Not exactly a meaningful increase in how much work it took.
As for "why", because I don't have to faff about with NAT or port forwarding, both of which are terrible. I just put addresses into a AAAA record and open a firewall rule, the way it should be. Meanwhile with v4 I have to port forward all web traffic to one server, then reverse proxy it to its final destination. It's more complicated and fragile to set up, whereas v6 is simple and pleasant to work with.
Ipv4 and ipv6 only work on the Internet because of constant maintenance by many people working in many different organisations. Ipv4, being effectively mandatory, gets most of that attention. Ipv6, being a nice-to-have future- proofing option, gets less. And so you are far more likely to encounter issues, in the general internet, where connectivity is not working properly, and even if you have the energy to debug it, you are likely to find the problem is not on your end and the only option is to fall back to ipv4 and wait for it to be fixed.
> but it's really easy to set up a network to have dual-stack v4 and v6
Why do you need v4? because v6 doesn't work.
> NAT or port forwarding, both of which are terrible
Why? I assume you're still using a stateful firewall, so what difference does it make.
Normal source-nat has many benefits too, for example when you want to send some traffic via ISP1 and some via ISP2, controlled at the network layer, and you aren't BGP peering with them.
> Meanwhile with v4 I have to port forward all web traffic to one server, then reverse proxy it to its final destination
Or just use two IPv4 addresses. Personally I reverse proxy my servers anyway to have a single (well dual) point of control on entry at an application layer, ipv4 or ipv6 doesn't matter.
You do have to mess with the port forwarding etc if you're dual stack.
It's true that at this point future proofing demands it.
Is anyone happy about it in ipv4 land? No.
I just think it is ironic that the biggest use of ipv6 is cgnat, and it's what they crow about in ipv6 uptake, despite the fact ipv6 is religiously opposed to NATs.
Regular NATs you have control over with poking holes. Cgnat you are restricted to tail scale stuff.
I think you misunderstand. CGNAT is IPv4. IPv6 is sometimes (often?) provided alongside, because of the limitations of a CGNAT IPv6 connection.
Your cgnat isn't taking an ipv6 addressed phone and interfacing with the ipv4 internet?
Or are you trying to say the ipv4 is what is natted? Because the ipv4 is where all the stuff the ipv6 phone wants.
At this point, about 25% of traffic on dual-stack ISPs is v4. So no, v4 isn't where all the stuff the phone wants is.
CGNAT is generally only done for v4. v6 isn't needed to provide CGNATed v4, and if v6 is provided as well then it generally isn't NATed. I expect you could find an ISP somewhere that NATs the v6 too as a counter-example if you looked hard enough, but as a rule they don't.
(Sometimes CGNATed v4 is provided by making use of the v6 in some way -- e.g. mapping v4 destinations into v6 with NAT64, or by tunnels -- but the CGNATing still only applies to v4 destinations, so this just an implementation detail rather than an undermining of the above point.)
> Cgnat you are restricted to tail scale stuff.
But only on v4, not on v6. That's kind of the point of bothering to make v6 in the first place -- it allows you to keep the ability to poke holes in your inbound firewall even in a world where v4 is exhausted to the point of CGNAT.
The exhaustion and the CGNAT and the resulting restrictions would still be there if you didn't have v6. It's just providing you with a way out of them.
> Because the ipv4 is where all the stuff the ipv6 phone wants.
There's still some ipv4 only services, but most of the big ones are dual stack. Looks like right now tiktok is v4only, which is probably significant, but Google, Facebook, Netflix are dual stack. Amazon/EC2 have lots of v4 only bits and pieces, but at least www and cdn are dual stack. Github is also v4 only and that's important, but how many people are pulling from their phone?
I ran Starlink for a while. CGNAT. No fun running servers. 5G internet? CGNAT. ISPs that support IPV6, they will probably still run NATs.
So here's a question: if your ipv6 is behind CGNAT and calls an ipv6 on the other side of the CGNAT: is it still one-way, or un-NAT'ed?
And you agree the non-oligarch internet is ipv4, along with a large part of the oligarch internet.
> So here's a question: if your ipv6 is behind CGNAT and calls an ipv6 on the other side of the CGNAT: is it still one-way, or un-NAT'ed?
Depends, it's easy to do things like 464xlat and NAT64 where you route those address spaces through the CGNAT and other stuff direct. Or through a stateful firewall (which could be the CGNAT or something else) if you really need a stateful firewall.
IPv6 clients would not go through a CGNAT (or any other NAT) to connect to a remote IPv6 address. Including on Starlink.
Exceptions are so unusual you should provide a specific example of an ISP with this configuration.
Agree 100%. There is no excuse other than "v6 addressing and subnetting is haaaard". It makes most things a lot easier than its v4 counterparts. I'd go so far as to say not deploying v6 is actively negligent.
Just imagine the world was used to subnets and NAT would be the new thing to learn. Everyone would go "NAT breaks all the time" and "portforwarding is weird" and whatnot. IPv6 is not harder, people just confuse "harder" with "not being used to".
NAT is actually useful besides just avoiding address exhaustion. Many IPv6 networks are on NAT anyway, like pretty much every cell carrier, which maybe accounts for most ipv6 traffic.
> like pretty much every cell carrier
TMo US gives me a whole routed /64. Why build and staff v6 NAT devices for no reason? At least several years ago several cell carriers were all about v6 to reduce the volume of v4 traffic they carry, because v4 requires expensive addresses, expensive nat boxes, and expensive people to feed and care for the NAT boxes.
Honestly, I don't know why so many carriers do v6 with NAT, cause intuitively they wouldn't. Maybe someone else knows. I know why a home or office would do it, it's easier to reason about there.
Can you give an example of an ISP doing IPv6 NAT?
AT&T
I can't see anything in their documentation about that, or anything on forums/Reddit.
Users ask about prefix delegation and advanced configurations, but all start from being allocated a /64.
I got a private IPv6 only on AT&T cell when I checked a couple of years ago (to be clear, not a public one with inbound-deny). Will check again.
Edit: Ok not sure what to make of this now. On an iPhone rn so it's tricky, the Net Analyzer app says I have 5 2600:s on cell, which should be the public range, but my public IP according to test-ipv6.com is a different 2600: from all the above. Wonder if those 5 are actually the EPC.
There's an HN comment about them using NAT: https://news.ycombinator.com/item?id=23025344 and this forum thread https://wirelessjoint.com/viewtopic.php?p=25357
There's an old Reddit thread where someone said at first there's no NAT, but then realized there is https://www.reddit.com/r/ATT/comments/8k680y/cellular_public...
> There is no excuse other than "v6 addressing and subnetting is haaaard".
This is just absurd on its face. There are very real human, political, engineering, and financial reasons to not want to upgrade things that are IPV4 only. _SHOULD_ one do this, absolutely, but there's a lot more to it than people pulling the "hard" card. There's a bevy of reasons it IS hard, and very few of them are just obstinate luddites.
When did the post that I was responding to say anything about upgrades? The comment was about greenfield projects. I reiterate my point: if in a -greenfield- project you're not building IPv6 native, you're negligent. Get up on your reading comprehension.
If there's no IPv6 support, be an engineer and -make- some: write the software that needs the support, use different vendors that don't break it just because they are actively lazy and can't be bothered to implement RFCs that are, at this point, decades old. IPv4 needs to go away yesterday.
> Get up on your reading comprehension.
The ad hominem, nice.
For anyone who is in need of a basic IPv6 test:
https://ipv6test.google.com/
What does this test? It tells me I don't have IPv6, but I won't have any problems. Green check-mark.
What does this mean at all? I went tot he page for info on my IPv6 connectivity, not a politician's campaign doublespeak.
It is absolutely amazing to me how far IPV4 + NAT have taken us.
Not that far if we talk traffic volumes. Most of the traffic nowadays is Google/Meta -> mobile phones eyeballs. That's traffic is overwhelmingly IPv6.
Nowadays is about 30 years after IPv6 was introduced.
Unfortunately too far. CGNAT for residential & mobile internet service is a mess we could have avoided by switching to IPv6 completely
Thanks for the service. Showed that site to my own ISP's technicians when they were having difficulties to activate IPv6 support.
Oh this hurts a lot. I don't know of a good alternative to this website. Other sites I've found either run fewer tests (so are less useful for debugging) or incorrectly claim I don't have IPv6 (I do?).
I don't suppose we can donate some money to keep this website up? Or perhaps some company like CloudFlare would like to host a mirror?
Naive question, but does this site actually require much ongoing maintenance?
I’ve used it for years and find it incredibly useful (& am appreciative of its existence) - just didn’t realize it needed much upkeep.
I am not the author, but can speak as someone who has kept a "seemingly simple" semi-popular web service online for many years with no/low maintenance: it often comes down to the fact that issues tend to pop up just when you don't have time to work on them. It is usually not a lot of maintenance, but it feels like a lot when you have to dive back in to something that you haven't thought about in months. It ends up being a source of very low level chronic stress.
I can totally see why shifts in other priorities would make it attractive to decommission.
Anyone have a good replacement if a different organization is not able to take over? This has always been my favorite IPv6 test site, and really appreciate the author maintaining it for so long.
I've written a similar CLI tool (not a website), netq [1]. I believe it can be an alternative to some of the functionalities of the website.
If one is able to get a public IPv6 from a public IP finder service, I guess that means his machine is able to access the IPv6 internet.
Some finders report ISP too (use -r).Also, kudos to jfesler for his works on maintaining the website through the years.
[1]: https://github.com/pvonmoradi/netq
Thanks for the service. I used it to figure out what's wrong with my ISP's ipv6 and even though I never figured it out a fix your website definitely helped a lot.
Side note: I find ipv6 complex and very difficult to use. Might be because of the poor experience with my ISP, but still...
Could this site be run essentially free on Cloudflare using their managed transform headers features?
> I am shutting the site down, with a target of "during winter break" (December) 2025.
there is an engineer somewhere out there who will get paged on christmas due to a hidden dependency on this site being up, heh. that old xkcd comic comes to mind.
That's karma for all the times the guy running that site had to deal with entitled emails.
I had my fair share of those as well - a bit over 2 decades ago I've added a CGI script to perform various DNS queries to my website - main purpose at that time was being able to show my customers DNS issues from their Windows boxes tied to corporate DNS.
Eventually some others added it to their documentation, with the most prominent one being OVH - they had a description on how to use my web site in various languages in their domain troubleshooting pages for many years.
I received a fair share of emails of people who were not able to figure out that I'm _not_ working for OVH, and I'm neither interested nor capable in solving their domain hosting issues with them.
They eventually built their own frontend, and by now it's mainly one guy from the Netherlands that now and then demands that I urgently add a new feature to the script.
It was a great service over the past 1.5 decades.
Meanwhile Github still does not support IPv6
How much does it cost to run this sort of website? This one in particular has been a great help to me many times.
There's a lot of bad actors on the internet, which makes running a small website quite a chore -- and this one is much more visible than the average small website. At the very minimum you must keep it up to date, because it will be under a constant barrage of exploit attempts. Then there are DDoS attacks (people have tried to used my webserver as a way to DDoS my ISP in the past). Then there's the crazy people who will email you demanding why you broke their IPv6 or that you urgently fix some issue that and they are "losing money" because of it.
I get that popularity comes with problems, but I don't see how the attack surface is any larger than a normal website?
It looks like the entire site is implemented in Javascript, which tries to fetch resources from various HTTPS URLs, some of which are configured to serve only over IPv6, others only over IPv4. But that just requires configuring a normal webserver to serve regular HTTP traffic, which is the bare minimum exposure to exploits any website has.
What I actually said is that it's a chore to run a small website, and that applies even to a simple static site (although you're right, way more if your site runs backend scripts). Bad actors are still going to try to DDoS you, attack your static webserver, and send you entitled emails.
Geolocation queries are probably one of the bigger costs. Google is a rip-off here but to use them as an example, they charge $2.83 per 1000 lookups for the first 90k/month. You could easily spend a few hundred per month that way.
If you were trying to set up a replacement for this site that's cheaper to run, you could probably drop the geolocation feature, it's not really necessary.
Definitely agreed
MaxMind's GeoLite database is a good alternative to paying for ip geolocation. You don't typically need super precise data for something like this.
I work for IPinfo, and this is a tangent note on a tangent note. We offer a free IP geolocation database, and we recently started providing an unlimited API query service for free against that database.
Maintaining an IP geolocation database requires some upkeep. You have to download the database regularly (in our case, daily) to keep the data fresh, and you need a system in place to make it useful.
That’s why we created a dedicated API tier that offers unlimited requests. The data is being used by many open-source projects, so we’re simply doing our part to support them by providing both the data and the API infrastructure service. Last year, we processed over 2 trillion API requests across all our API services. There are many projects, Open Source and Enterprise, that are making billions of requests daily, and they are on a free tier plan.
I definitely owe this guy a beer or coffee and hope to have a chance to make good on it.
Maybe the ISG would be interested in taking this over, possibly with some sponsorship money?
Ah, so I'll never be able to experience finally passing that test.. couldn't you wait like 50 years or something? My ISP needs some time..
We probably need just another 15 years, since it took ~15 years to reach ~50% IPv6 adoption.
https://www.google.com/intl/en/ipv6/statistics.html
Still not quite there. Only at 49.86% as of today.
Please don’t turn it over to Cloudflare.