I have spent most of my career under the thumb of fucking cable and I'd sooner slam a car door on my nuts than go back to paying so much money for such garbage service.
The people who attempt to fill these gaps are commonly rural telephone companies, electric cooperatives, tribal entities, or mom and pop shops where the owner grew up on a Ditch Witch and only knows as much IP networking as essential to light up the fiber and get the packets flowing upstream.
They are enormously resource constrained in ways you might not expect, too, eg operations can grind to a halt because everyone is out with a chainsaw after a storm, or because the Guy that Knew Stuff about their network died suddenly.
They are very, very unlikely to decide to run an IPv6 network just because. There's no upside that makes the juice worth the squeeze for them.
Saline is less than 10 miles from Ann Arbor.
> The people who attempt to fill these gaps are commonly rural telephone companies, electric cooperatives, tribal entities, or mom and pop shops...
That's fair, but at some point, you need to recognize you are competing with a major ISP. No one appreciates it when you come in, tear up the roads, and then pull out once the incumbent ISPs bump up their speeds ever so slightly. (Looking at you, Google.)
> They are very, very unlikely to decide to run an IPv6 network just because.
No one deploys IPv6 "just because," and yet more than half of the traffic to major sites is IPv6.
I live half an hour from a state capital and my only option is cable... the coaxial cable they laid bare on my flower bed decades ago. I dig it up about every other year when planting. It's not even in a conduit!
In an IPv4-only CGNAT setup, all the traffic has to flow through the CGNAT gateways, and that gear is stupidly expensive. Having IPv6 in the mix means that anything that supports IPv6 (such as most streaming services) won't hit the CGNAT gateway and can just be routed natively. This can really save money on CGNAT hardware.
For implementation, you can use NAT64/DNS64 for your CGNAT setup and implement 464XLAT on the CPE. This keeps your whole edge network IPv6-only so you don't have the complication of maintaining two parallel configurations on the edge.
There is also MAP-T, which is even lighter on infrastructure since it pushes all the state into the CPE and avoids the complication of stateful CGNAT. But unfortunately CPE support for it is pretty limited at the moment.
No state at the carrier; IP:6 native network.
If you buy a full IPv4 you get one for yourself but I expect still through the same tunneling machinery to keep the network IPv6-only.
Yeah, what's up with that? I just got switched on to fiber and the CGNAT for IPv4 doesn't shock me much, but what's with the no IPv6 in 2025?
I know enough to deal with it, but what's the deal? Is there something systematic here?
How about not having to pay for (as) beefy CG-NAT hardware because people that go to Youtube, Netflix, MetaFace, TikTok, etc, can directly connect via IPv6.
Even a small number of devices/services not supporting IPv6 can have huge costs:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* Discussion: https://news.ycombinator.com/item?id=35047624
Sadly the post is now behind a login: what happened later was Apple donate a bunch of Apple TV devices to the tribal ISP and that cut their IPv4 usage by an order of magnitude (or some ridiculous number) and there were major savings. The ISP then recommended AppleTV to all of their customers to get the best viewing experience (because of the latency/overhead of CG-NAT when streaming video).
So the more you move over the more headroom you have for the broken IPv4-only systems. AIUI, the rollout of MAP-T/E has helped in that things are more stateless, and more work is done at the CPE, but there's still overhead.
Some people will say monitoring is all that you need, but I do not agree. There are a million different little issues that can and do occur on physical networks in the real world, and there's no way monitoring will have a 99% chance of detecting all of them. When incidents like the partial Microsoft network outage that hit certain peering points occurred, I had to route around the damage by tweaking route filtering on the core routers to prefer a transit connection that worked over the lower cost peering point. It's that kind of oddball issue that active users catch and report which does not happen for barely used services like IPv6.
CPE support for IPv6 has generally been garbage with it taking 15-20 years before the bare minimum was supported by mainstream router vendors. Even today there are still vendors that assume only IPv4 support. In my opinion the IETF really screwed up when they made IPv6 more complicated than just IPv4 with more address bits. The incumbent in my area generally uses PPPoE in their access network, but routers that supported PPPoE and prefix delegation basically didn't exist in 2010, and only started being available circa 2015 (in part due to the required bits not existing in OpenWRT and the hardware vendors' software development kits for their chipsets). Sure, we're 10 years further on now, but there remain a number of vendors that only support IPv4 for management of devices (cough Ubiquiti cough) in parts of their product line.
That said, there are features of IPv6 that are absolutely awesome for carriers. The next header feature that pretty much eliminates the need for MPLS in an IPv6 transport network is one such item that makes building transport networks so much cleaner when using IPv6 than IPv4. No more header insertion or rewriting, just update one field and fix up the delta on the checksum and CRC. They just aren't really applicable for smaller networks.
I do think NAT64/464XLAT is a pretty good architecture for new ISPs that can't get their hands on IPv4 space, though. Or even MAP-T, but CPE support isn't really there yet.
How many ask for IPv4? I understand your situation, it's a lot of work, for something that many won't notice. It's just that saying there's no demand because your average consumer, who also doesn't know what IPv4 is, isn't asking for it, is the mentality that keeps IPv6 from being implemented.
On the funnier side of things, we've also sometimes run into the opposite problem that we can't reproduce an issue, because it's only on IPv4 and 95% of the time everything we do is IPv6. But we're also not serving home users.
Now apply that to IPv6 and you can see the point that (I think) GP is making.
Side note: The claim it is not widely used doesn't track. How many people use Google or Facebook? More than half of that traffic is over IPv6.
https://circleid.com/posts/ipv6-usage-in-the-u.s-surpasses-5...
It's not widely used in my customer base as well as among a number of other small independent ISPs I know of. A significant number of the CPE we have deployed today do not support IPv6, therefore a significant number of our end users will not be using IPv6 resulting in only partial usage. That is what I am referring to: an incomplete deployment of IPv6 across a customer base without their knowledge of change and the end user's ability to identify issues will cause support issues which costs money and time.
Because of how IPv6 is provisioned, going from a no IPv6-deployed state to fully-deployed state will encounter transition issues. It's not provisioned the same way as IPv4, and that's the whole bloody problem!!! Sure, I can turn on handing out IPv6 addresses from our edge routers via PPPoE today, but it's not going to "Just Work" for all customers without CPE config changes (assuming the CPE even supports IPv6 in the first place for which a bunch of them do not!). It's a complete pain that has less than zero benefit for a small provider today since everything is available over IPv4 and nothing is IPv6 only. Heck, another ISP I know had a customer ask for IPv6 support, and then the customer didn't even bother to provision it on their own router!
Another example: take Ubiquiti's AirCube product line. It doesn't support IPv6. To deploy IPv6 it would be necessary to reconfigure things to make the ONU for the customer act as the router for the customer's home network and place the AirCube in bridged mode. That's assuming that the ONU even supports IPv6 yet as it did not when I looked into it on the order of 6 years ago. And yes, there are a few dozen customers on AirCubes that fall under this case. This means moving into a territory where multiple different CPE deployment configs are now required for less than zero benefit.
That there are gaps in IPv6 support has been a problem, is a problem, and will continue to be a problem. The industry isn't 100% IPv6, and I don't see how that is going to be the case in the next 5 years or even the next 10 years. Consumer gear isn't there yet. That was the problem 5 years ago, that was the problem 10 years ago, that was the problem 15 years, and that was the problem 20 years ago... What's different today that's any different than yesterday?
It's easy to deploy IPv6 in data centers where you control all the infrastructure on servers where operating system IPv6 support was mature decades ago. It's not so easy as a small ISP when dealing with pile of random consumer gear that an ISP's customers bring to the table where IPv6 support remains hit and miss.
And then you say `Nobody asks for IPv4` - so nobody asks for IPv4 and 0.5% ask for IPv6?
So, yeah, I don't see IPv6 being relevant as a small ISP today.
Big, evil, hated Comcast has full ipv6, and I doubt any of its customers asked for it either. Instead people complain they’re only getting a /60.
I get the impression that they are still learning to run an ISP, both technically and customer facingly. It's weird - I learned more about them from this article than from actually being living here with them.
Some applications want to open ports and don't have the server-side infrastructure to punch a hole through NAT. Especially P2P apps and some games.
Sometimes I want to run a small, low-traffic web server from home.
Sometimes I'm connecting to my network from a machine that I don't control and can't install Tailscale on.
This sounds like mine. I'm guessing yours doesn't support IPv6 because most fiber providers don't.
For the router, I already build firewalls so that. I pay $10/mo to escape their cgnat.
I've also alerted them to expect regular haranguing from me about deploying IPv6. Especially since bgp.he.net shows they have a /40 allocated to themselves; it doesn't seem to be used.