This and the comments highlight how bad many ISPs in North America and Western Europe are at IPv6, still, in 2025, and the lengths to which people will go to treat that as damage and literally route around it.
One of the biggest ISPs in my country has been promising IPv6 since 2016. Another, smaller, competitor, advertised on "World IPv6 Day" in 2011 that it was way ahead of the competition on supplying IPv6; but in fact does not supply it today.
One of the answers I see given a lot over the years is: Yes, I know that I could do this simply with IPv6. But ISPs around here don't route IPv6, or even formally provide statically-assigned IPv4 to non-business customers. So I have had to build this Heath Robinson contraption instead.
Pretty much! My ISP was founded by https://en.wikipedia.org/wiki/Rudy_Rucker and is somewhat cheap and delightful and happily routes me a good amount of IPv6, and every 48 hours or so it RAs me an entirely different range even though I still have validity on the lease for the old one and everything breaks, so I've had to turn IPv6 off entirely (I sent dumps of the relevant lease traffic to support, they said they'd look into it, and then the ticket auto closed after being inactive for two years). I spent a while trying to make things work with IPv6 but the combination of it being broken at my end and also there still being enough people I want to provide access to who don't have it means it just wasn't a good option.
One of my places uses Frontier FiOS (soon to become Verizon again). They have zero support for IPv6, and it isn't even on their roadmap.
I use a static HE (Hurricane Electric) IPv6 tunnel there, and it works great.
The only issue is that YouTube thinks the IPv6 block is commercial or an AI dev scraping their content, so I can't look at videos unless I'm logged in to YouTube.
I’m also on FiOS, and despite repeated statements to the effect I’d never get IPv6 on my (20 year) old ONT, I’ve got a nice little /56 block assigned on my kit via DHCPv6. Problem is that, as it’s a DHCP block, it changes, and Namecheap presently does not offer any sort of Dynamic DNS for IPv6 addresses.
Still, it let me tear down the HE IPv6 tunnel I was also running, since the sole reason I needed IPv6 was so our household game consoles could all play online without cursed firewall rules and IP reservations. I’m pretty chuffed with the present status quo, even if it’s far from perfect.
One other thing I’d note about OPs article (for folks considering it as a way to work around shitty ISP policies) is that once you have this up and running, you also have a perfect setup for a reverse proxy deployment for your public services. Just make sure you’re watching your bandwidth so you don’t get a surprise bill.
For a long time, I operated from home with a auction-purchased IPv4 /24 just so I could get around all this BS and have my own AS.
There's nothing nicer than being able to BGP peer and just handle everything yourself. I really miss old Level 3 (before the Lumen/CenturyLink buyout).
Kind of kicking myself for selling my netblock but it was a decent amount of money ($6000).
I'm doing exactly this. I got my netblock for free in 1993, back in the Internic days before ARIN existed. I have a couple of VPSes running BGP and tunnel traffic back to my home over wireguard.
Mine officially supports it. However having configured the Prefix as they define and using SLAAC etc all my devices get their IPv6 addresses and can access the internet, I can even connect from outside the network so it all "works", but I have a bunch of issues. Neither of my ISPs defined DNS servers is available, I can't route one of the OpenDNS routers but the other works fine and then I have these periods where the entirity of IPv6 routing breaks for about a minute and then restores. Having done this with two different routers on completely different firmware now I can't help but think my official support from my ISP is garbage and they have major problems with it. I had to turn it off because it causes all sorts of problems.
Fellow Branestawm enthusiast here. That is the first time anyone has ever mentioned Professor Branestawm on HN, as far as I can tell! It's triggering deep memories.
I'm in western Europe and every ISP but the ultra cheap ones and the niche use case ones have stable IPv6 prefixes. Some do /48, others /56.
IPv4 is getting CGNAT'd more and more, on the other hand. One national ISP basically lets you pick between IPv4 CGNAT and IPv6 support (with IPv6 being the default). Another has been rolling out CGNAT IPv4 for new customers (at first without even offering IPv6, took them a few months to correct that).
This isn't even an "America and Western Europe" thing. It's a "whatever batshit insane approach the local ISP took" thing. And it's not just affecting IPv6 either.
Once again I voice the only sane option:
Skip IPv6 and the insanity that it is, and do IPv8 and simply double (or quadruple) the address space without introducing other new things.
It'll be objectively worse. IPv6 is at least sort of supported by a non-negligible number of devices, software and organizations. This IPv8 would be a whole new protocol, that no one out there supports. The fact that version 8 was already defined in [an obsolete] RFC1621 doesn't help either.
Even if you decide to try to make it a Frankenstein's monster of a protocol, making it a two IPv4 packets wrapped in each other to create a v4+v4=v8 address space, you'll need a whole new routing solution for the Internet, as those encapsulations would have issues with NATs. And that'll be way more error prone (and thus, less secure), because it'll be theoretically possible to accidentally mix up v4 and inner-half-of-v8 traffic.
Nah, if we can't get enough people to adopt IPv6, there's no chance we'll get even more people to adopt some other IPvX (unless something truly extraordinary happens that would trigger such adoption, of course).
Are you saying you believe it's truly impossible to create a new backwards compatible standard that expands the address space and doesn't require everyone to upgrade for it to work?
It isn't possible to make backwards compatible standard that expands the address space. Where are you going to put the extra address bits in the IPv4 header?
It also can't be backwards compatible with IPv4 networking and software. The network gear will drop extra address, the OS will ignore it, and software will blow up.
It would be much better to make a new version. But if going to make new protocol, might as well make the address big enough to not need expansion again.
Then you have to update every networking device to support the new standard. And update all the protocols (DHCP, etc) for more address space. That part is what took a lot of the time for IPv6. Then you have to update all of the software to support 64-bit addresses. Luckily, most of the work was already done for IPv6.
Then you have to support a transition mechanism to talk to IPv4. Except there isn't enough space in new address. IPv6 on the other hand, has enough address space to stuff the IPv4 host and port in the IPv6 address for stateless NAT.
> Where are you going to put the extra address bits in the IPv4 header?
The optional part. EIP proposed using 16 bits (minimum) to bump the address space to 40 bits (the EIP extension portion is variable-sized so it can go higher until you reach header option limits): https://archive.org/details/rfc1385/page/4/mode/2up
The effort is a bit smaller because existing stacks can already read what's in the EIP part as it disguises itself as an option header. The change is behavioral not structural.
Also with the extra octet added we'd get ~254 current-IPv4-sized clusters of addresses. If a unit inside one of these doesn't really care about the others they can skip supplying this information entirely, i.e. not all participants need to understand the extension. LANs, internal networks and residential use comes to mind as examples in which case only the gateway has to be updated just like the RFC says.
With IPv6 participation is all or nothing or dual stack, but then this is ~1.1 stack :)
That RFC glosses over a LOT of details. I'm skeptical the effort would be a bit smaller, once you consider what is required for routing and the "translation service." That's totally glossed over in the RFC, by the way.
Unless you're planning on doing all IP communications in user space (or within your network "cluster"), the OS and IP stack still needs to be updated, you need a new addressing format, applications need to be aware of it, etc. If you want to actually make use of the new address space, it all needs to be updated... just like IPv6.
No, sorry. Very few switches and not all routers do that in software. If all that is in an ASIC then that part just can't be added to the address without new hardware.
So no, good attempt but it's pretty much still a 'upgrade all the routers and switches' kind of issue just like IPv6.
I'm not going to say it's truly impossible, but it's practically just-about impossible.
There's no straightforward way of getting old hosts to be able to address anything in the new expanded space, or older routers to be able to route to it.
So you have to basically dual-stack it, and, oops, you've created the exact same situation with IPv6...
If it's possible, why has no one done it? Most of the backwards compatible "solutions" that are presented just run into the same issues as IPv6 but with a more quirky design.
This is a pipe dream in the current century. IPv6 adoption has been slow but it’s approaching 50% and absolutely nobody is going to go through the trouble of implementing a new protocol; updating every operating system, network, and security tool; and waiting a decade for users to upgrade without a big advantage. “I don’t want to learn IPv6” is nowhere near that level of advantage.
The reason IPv6 adoption is lacking is that there's no business case for it from consumer-grade ISPs, not that there's an inherent problem with IPv6. Your proposed IPv8 standard would have the exact same adoption issues.
Your IPv8 is what IPv6 should have been. Instead, IPv6 decided to re-invent way too much, and is why we can't have nice things are are stuck with IPv4 and NAT. Just doubling the address width would have given us 90% of the benefit of V6 with far less complexity and would have been adopted much, much, much faster.
I just ported some (BSD) kernel code from V4 to V6. If the address width was just twice as big, and not 4x as big, a lot of the fugly stuff you have to deal with in C would never have happened. A sockaddr could have been expanded by 2 bytes to handle V6. There would not be all these oddball casts between V4/V6, and entirely different IP packet handling routines because of data size differences and differences in stuff like route and mac address lookup.
Another pet peeve of mine from my days working on hardware is IPv6 extension headers. There is no limit in the protocol to how many extension headers a packet can have. This makes verifying ASICS hard, and leads to very poor support for them. I remember when we were implementing them and we had a nice way to do it, we looked at what our competitors did. We found most of them just disabled any advanced features when more than 1 extension header was present.
IPv6 reinvented hardly anything. It's pretty much IPv4, with longer addresses, and a handful of trivial things people wished were in IPv4 by consensus (e.g. fragmentation only at end hosts; less redundant checksums).
The main disagreements have been above what to do with the new addresses e.g. some platforms insist on SLAAC. (Which is good because it forces your ISP to give you a /64).
Devices operating at the IP layer aren't allowed to care about extension headers other than hop-by-hop, which must be the first header for this reason. Breaking your stupid middlebox is considered a good thing because these middleboxes are constantly breaking everyone's connections.
Your sockaddr complaints WOULD apply at double address length on platforms other than your favorite one. The IETF shouldn't be in charge of making BSD's API slightly more convenient at the expense of literally everything else. And with addresses twice as long, they wouldn't be as effectively infinite. You'd still need to be assigned one from your ISP. They'd still probably only give you one, or worse, charge you based on your number of devices. You'd still probably have NAT.
IPv6 is often simpler to administer than IPv4. Subnetting is simpler for the common cases. SLAAC eliminates the need for DHCP on many local networks. There's no NAT to deal with (a good thing!) Prefix delegation can be annoying if the prefix changes (my /56 hasn't in almost 3 years.) Other than that, it's mostly the same.
I frequently see this claim made but it simply isn't true. NAT isn't inherent to a protocol it's something the user does on top of it. You can NAT IPv6 just fine there just isn't the same pressure to do so.
Technically, you are correct. Practically speaking, NAT is an inherent part of using IPv4 for 99.99% of end users. I haven't seen an end user or business with a public IP on the desktop in nearly 25 years.
You can NAT IPv6 but it is rarely done since there is simply no need.
I nat IPv6 on one of my servers because having seperate ipv6 for VMS but the same IPv4 has caused some issues with running mail servers and certificates. If only I could drop IPv4 completely
One of the biggest ISPs in my country has been promising IPv6 since 2016. Another, smaller, competitor, advertised on "World IPv6 Day" in 2011 that it was way ahead of the competition on supplying IPv6; but in fact does not supply it today.
One of the answers I see given a lot over the years is: Yes, I know that I could do this simply with IPv6. But ISPs around here don't route IPv6, or even formally provide statically-assigned IPv4 to non-business customers. So I have had to build this Heath Robinson contraption instead.