Retiring Test-Ipv6.com
retire.test-ipv6.com
retire.test-ipv6.com
Thanks for the site for the last 15 years, it's helped me a number of times.
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
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.
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.
Edit: n/m I guess I confused PD with having a larger subnet. :(
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.
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.
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.
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.
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).
Today's situation: https://i.ping.pe/j/9/img_j99kbqkn.png
Really sad for a first world country in 2025.
Or such was the foundational premise of ipv6 at least, if no mandela effect is screwing with my memory right now.
It is sad.
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.
If you are using 24.0 or 24.1 of OpenWRT, there is a catastrophic bug affecting IPv6 throughput. Most recent version fixes it.
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 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.
But yes it uses colons instead of dots. Sorry about that.
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.
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.
Still like NAT, but better.
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.
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.
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.
Do you remember what sites didn't load for you?
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.
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.
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.
What, specifically, about the above do you take issue with? These are all issues I've seen personally and up close.
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 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.
Why is this an advantage? As in, what's the downside to having to port forward?
It really isn't, it's the same declaration in your config, and then your automation makes your devices make it happen.
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?
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.
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.
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.
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.
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.
Or are you trying to say the ipv4 is what is natted? 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?
And you agree the non-oligarch internet is ipv4, along with a large part of the oligarch internet.
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.
Exceptions are so unusual you should provide a specific example of an ISP with this configuration.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Users ask about prefix delegation and advanced configurations, but all start from being allocated a /64.
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...
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.
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.
The ad hominem, nice.
What does this mean at all? I went tot he page for info on my IPv6 connectivity, not a politician's campaign doublespeak.
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.
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 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’ve used it for years and find it incredibly useful (& am appreciative of its existence) - just didn’t realize it needed much upkeep.
I can totally see why shifts in other priorities would make it attractive to decommission.
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.
netq -6 p
netq -4 p
Also, kudos to jfesler for his works on maintaining the website through the years.
Side note: I find ipv6 complex and very difficult to use. Might be because of the poor experience with my ISP, but still...
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.
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.