Using the Internet without IPv4 connectivity | Hacker News Reader

Using the Internet without IPv4 connectivity

jamesmcm.github.io

296 pointsjmillikin130 comments

Slightly misleading title, this is more “getting to the IPv4 internet via an IPv6 tunnel through a VPS”. Also just called 4in6.

Interesting nonetheless!

We find at our ISP that if we break something with IPv4 we experience a very different type of support issue to if we break IPv6. Breaking v4 results in, broadly, a pretty hard “down” state. While folks are unhappy, it is at least simple. Breaking v6 results in weird, and a partial down, which manifests for the users as partial outages, slow starts due to fall back, etc. Especially if their gateways believe there is v6 when there isn’t.

Mirrors my experience. IPv6 issues are frustratingly hard to triage and reproduce, lots of “works on my machine” etc.

I think it's because of all of those transition mechanisms and fallback code added over the years. IPv6 fails the same way IPv4 does, but because of the terrible bullshit ISPs do to IPv6 connections, you end up with tons of software triggering obscure timeouts and fallback mechanisms that lead to a system of almost working networking code.

If the absence of IPv6 would've been treated the same way absence of IPv4 is, troubleshooting would've become a lot clearer. In fact, it probably would've been easier because ISPs can't just ignore and disable ICMP on IPv6 so you can actually get a hunch where in the network the problem is rather than seeing traffic vanish into the void.

There's certainly a long tail of IPv4, but the last time IPv4 broke at home, my wife didn't even notice since Google, Facebook, Apple/iCloud, and most CloudFlare-hosted properties all still worked over IPv6.

GitHub is definitely a part of that long tail.

When my IPv4 died last time, I noticed it mostly because Github didn't work anymore. These days, most consumer websites just work on IPv6. That said, people whose routers were only provisioned IPv4 DNS servers did have a full outage.

If Microsoft would get off their incompetent assets already, my biggest concern would've been remembering the mDNS hostname I've assigned to my router so I could log in and see if IPv4 is back already.

The POSIX bug tracker is not accessible over IPv6, either, because their AWS setup does not support it. The website administrators refused to fix this[1].

[1] https://austingroupbugs.net/view.php?id=1623

The Meta Quest software also sucks at this. You’d expect an essentially new platform struggling with this. Valve is basically all IPv4 afaict too.

Pretty annoying and lazy if you ask me.

The Valve stuff is extra infuriating because a lot of their assets seem to be hosted on CDNs that do have IPv6, but their backend servers are stick with IPv4. When IPv4 breaks, you can look and buy games, but actually playing them will fail because of DRM checks.

My ISP (TekSavvy) manages to semi regularly screw up ipv4 and what I notice is that "big" sites like Amazon, Google, Facebook, SO, etc all work as before, but it's the in-between sites, someone's blog on a search result, etc— that's the stuff that breaks.

It's easy enough to port forward v6 on some server to v4 GitHub - i'm doing it right now but can't remember the address. Think there's any demand for this, considering you can save $0.50-$2 per month per server by not having v4?

Some VPS providers already provide free IPv4 solutions.

Setting up a server works fine for server stuff, but it'd get you blocked and banned everywhere for having a data center IP while just browsing or trying to watch Netflix.

For my servers I could do it the other way around and save a dollar per month, but then I'd be sending emails from a residential IPv4 address, which will never ever make it past any spam filter.

Most ISPs still just block IPv6 altogether because most small businesses seem to try IPv6 once and then forget to eg update their AAAA records so to the user it looks like their favorite niche thing works when they're on <low quality ISP at friend's house/coffee shop> but not on the one they're paying for which creates problems.

It's kind of a weird issue, I don't know if there are nice solutions other than hoping IPv4 just goes away eventually. Happy eyeballs was supposed to solve this but often the problems manifest way up in the application layer and there's no general protocol for solving that without some kind of very leaky abstraction because the application can do anything.

The compromise I personally have to make things smooth is enabling ipv6 in the network and then disabling ipv6 DNS on all of my browsers which is pretty unsatisfying.

[citation needed]

> Most ISPs still just block IPv6 altogether

That’s increasingly not true, at least in developed countries. Traffic to Google in the US has been majority IPv6 since a few months ago.

Majority mobile and majority ipv6 are basically the same thing.

My mobile carrier here in the Netherlands doesn't do IPv6. Mobile traffic doesn't automatically mean IPv6, unfortunately.

I have my VPN permanently enabled for Pihole reasons anyway, so my IPv6 access works that way, but it's pretty stupid.

It's not just mobile. My previous (Verizon Fios in NYC) and current (Cox in Tucson) home ISPs both support IPv6.

And developing countries don't have much choice since they have to share about 5 addresses per city.

I mean, basically every major mobile in the developed world adopted IPv6 when they were rolling out new core infrastructure to handle LTE (T-Mobile USA being notable as one of the first to go IPv6 only). When you consider the deployment of VoLTE (and now VoNR for 5G networks) in particular, rolling out IPv6 internally removes a lot of nastiness that SIP/IMS have with NAT (and CG-NAT in particular), so it's little surprise that it happened.

What surprises me more is the very mixed state of small to midsized ISPs. Sparklight (regional cable provider) still does not support IPv6 in any fashion even though it would be financially beneficial to auction off a significant portion of its v4 holdings (nearly 1.3mm addresses), deploy DNS64+NAT64 (plus CG-NAT as a fallback) and hold onto a chunk for their business customers who still need inbound v4 connectivity. My local fixed-wireless ISP that's my only real option (love them, but this is a bugbear of mine) since I moved last year only offers CG-NAT, and I know their equipment can handle v6 fine which would save them some resources (no expensive state tracking on edge equipment or dedicated CG-NAT gateways) and provide a better customer experience (multiplayer games, VoIP traffic, etc.)

Astound still doesn’t either and they are large.

Your information is either outdated or very specific to your locale.

Not only do ISPs here support IPv6 by default these days but they have even started only giving IPv4 connectivity via carrier grade NAT for new customers - you can still ask for a real IPv4 address for now but it's not there by default and the ISP reserves the right to take it away.

If anyone wants to try / use IPv6, but their ISP does not provide it, Hurricane Electric (HE) has offered a tunnel service for many years now:

* https://tunnelbroker.net

* https://ipv6.he.net

There are scrips available to bring up a tun device on your system (or router) and route traffic over it:

* https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele...

* https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica...

* https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_...

* https://forum.mikrotik.com/t/auto-update-script-for-hurrican...

* https://docs.rockylinux.org/guides/network/hurricane_electri...

Happy "customer" here. I've been using their free 6in4 tunnel through OpenBSD for about five years and have had no mentionable problems. I configure mine solely with OpenBSD's network interface files, e.g. /etc/hostname.gif0:

  tunnel <my current IPv4> <HE's IPv4 endpoint>
  inet6 <my desired IPv6 address> 128 alias <HE's IPv6 gateway>
  !route -n add -inet6 default <HE's IPv6 gateway>

I use the connectivity to reach a cluster of VPSes in AWS deliberately set-up without public IPv4 addressing, which would otherwise represent a large part of the monthly costs because of buttholes like Jeff Bezos actively monetizing IPv4 address space.

> because of buttholes like Jeff Bezos actively monetizing IPv4 address space.

IPV4 addresses are finite and rapidly being depleted. What other solution do you have to manage demand of a finite resource other than charging for it?

My stance is that common connectivity shouldn't cost an additional $3.70 a month on top of already egregious traffic costs. The price per IP today is about $30. The lifetime of the investment is infinite and upkeep is in the grand scheme of things nothing. The markup profit is insane. It's a new behavior, pure usury, seizing an opportunity to profit on a crisis. To offer some contrast (without getting into the sizes of their respective turfs) Oracle doesn't charge a dime.

We are in crisis precisely because nobody charged for IPv4 addresses in the past, and so overwhelming majority of those are wastefully allocated. What you want would exacerbate the crisis.

We're in this crisis because we failed to anticipate the explosive growth of the Internet. It took a bit into the 2000s until we stopped doling out generously oversized networks to everyone who asked. Vetting the need would've been the right requirement. Shutting the door for organizations with not enough money would've hampered progress.

Yes, and why did people ask for these oversized networks? That’s right, because addresses were free.

That's a depressingly shallow knee-jerk-y way of reasoning around something so fantastically open as the Internet... You're offering the deplorable solution of "let the money vote" instead of reason and restraint. The consequence if we had asked for money from the get-go would've been a corporate-ruled scenario where connectivity and Internet foothold were primarily in the hands of the businesses that had the most money. Smaller businesses, and non-profits in particular, would effectively have been shut out and innovation and growth in the Internet's most sensitive phase would have suffered greatly.

The fact of the matter is that “let the money vote” works much better than alternatives. “Reason and restraint” is precisely how we got to where we are.

Have you looked at the state of the world? "Let the money vote" works better than "let anyone just commandeer the finite resource, but only once", if nobody immoral enough to exploit it learns about vulnerabilities in your system.

If I can use my money to vote for "give me more money" at a profit, and I have no qualms about doing so, then I win – and if we play multiple such games with the same money, then we end up with a situation that's worse than "let anyone commandeer the resource".

The world is not black and white, and paid service can easily coexist with subsidized service. There are many examples of “it costs you $XX but ask us if you need it badly” policies. The best varieties probably do some degree of vetting (because otherwise would slightly defeat the point or make it impractical, especially while LLMs are cheap enough that anyone can use one to write a convincing tear-jerker) and have objective criteria.

I haven’t thought enough to say whether it makes sense for specific cases like IP address allocation, though.

Don't worry, we've learned nothing and will repeat the same mistake with IPv6:

https://news.ycombinator.com/item?id=42671847

https://www.theregister.com/2024/12/06/apnic_huawei_ipv6/

One annoying caveat with these is that for streaming services, you will need to figure out how to disable those tunnels, because they're blocked as if they're VPNs for getting around region restricted content blocks.

Still works great, though. Thanks to the power of RAs, you can get all of your devices hooked up with an IPv6 address even if your router doesn't support HE tunnels, just have any device in your network advertise a /64 and it'll become an IPv6 router (assuming your router doesn't filter out RAs for security reasons).

Very useful for hosting stuff from within your home network without actually needing to mess with port forwarding rules.

aspect worth noting: up to my knowledge HE's tunnel will work only if you're assigned public IPv4 by your ISP. if you're behind a carrier grade NAT - too bad, you'll need to use another solution to get IPv6 to your home.

Strange. This sounds like something Hurricane Electric specifically limited. There’s nothing in CGNAT that would naturally break such a tunnel

I use tunnels all day like this with cgnat on multiple devices.

HE is using plain stateless IPv6 in IPv4 tunnel - it's neither TCP nor UDP, it's not NAT'able.

it's relatively simple for them to implement [ the stateless part ] but due to that puts some requirements on the party establishing the tunnel.

Go Fiber (Shentel) is one such ISP, and they will gladly switch you to a public IP for no cost if you contact their support. Sadly they don’t support IPv6 yet.

Hurricane Electric is great, but as more and more people have ISP provided IPv6, 'normal' users leave the tunnels, and network services have been flagging he.net tunnels as abuse.

I had to stop using ipv6 for most of my network because too many sites decide to put up barriers or simply refuse to work.

If you ever need a quick hack to get v4 connectivity over a true v6 only setup, you can use a public DNS64+NAT64 Gateway. You can find a list at https://nat64.net/public-providers. So for most regular use, all you are doing is changing DNS servers.

This is the combo.

** 1. DNS64

Synthesis of AAAA DNS records for things that don't have them to a NAT64 box.

$ dig +short @2a00:1098:2c::1 AAAA github.com

2a01:4f8:c2c:123f:64:5:141a:9cd7

** 2. NAT64.

Will take this traffic thats been sent to it because of DNS64 and protocol translate + NAT it for you.

$ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] https://github.com/

Using Cloudflare WARP would be much faster.

And you can connect directly to ipv4 addr via WARP.

WARP is a full VPN tunnel. The above poster was suggesting if someone wanted to avoid a VPN tunnel, DNS64+NAT64 is a nice "hack" that just uses DNS as the tool to reestablish IPv4 connectivity. (It's also how most mobile/cell traffic today reaches IPv4, via DNS64+NAT64 gateways.)

I don't use WARP's VPN mode.

I run WARP in socks proxy mode, and using ipt2socks for redirecting traffic to socks proxy port.

https://github.com/zfl9/ipt2socks

Came here to say this. Over Europe, https://nat64.net/ directly, at least, is pretty cool. Only had good experiences with them.

So, those mythical IPv6-only internet users actually exist :) That's some great network engineering.

I once needed something like that for the perhaps more common inverse purpose, to work on something IPv6 from within my happy IPv4-only connection. A more limited, but quicker solution given full control of a server - I set up a SOCKS5 proxy, using:

  ssh -D 1080 -N myserver

and set my browser to use it. I think that it could also be set system-wide, but wonder if that might break the original ssh connection, holding it all up :)

I'm in the same situation myself. It's quite frustrating, since 2 weeks I have been told that "the ticket is open and the technicians will take a look soon". Not sure if stuff like this has a low priority since IPv6 works and it's not considered a total outtage? In Germany there are laws to grant consumers compensation in those cases, but I'll see if this counts soon enough.

One problem with the solution in this blog post is that various endpoints block datacenter IP ranges entirely or make you go through various captcha hoops, but no good way around that. Same for common VPN providers.

Since I wanted to fix this for my entire home network I also had to do this on my router - in those cases it's quite beneficial to have a non-standard device like an Ubiquiti EdgeRouter, not sure how I would have set up all the Wireguard routing and nat rules on something like a FritzBox. The only downside is that the Router isn't powerful enough to handle a lot of connections, so I'll have to switch to IPSec which is supported by hardware offloading.

Fritzbox actually has some very nice GUI steps for configuring a VPN connection, intended for Fritzbox to Fritzbox connections but any compatible VPN will do. It also allows setting up static IPv4/IPv6 routes (Home Network>Network>Network Settings>Additional settings>IPv4 routes/IPv6 routes).

The biggest problem you'd probably run into is figuring out what kind of IPsec encryption configuration the router expects from the other side (Wireguard should be a lot easier but then you may run into hardware acceleration issues).

If you need to get down to it, you can also make a backup of the Fritzbox config file, edit the dump to manually configure the VPN endpoint, recalculate the checksum (there are tools for that), and re-import the config file. AVM has loads of config not accessible to the user that you can tweak that way, but they make it a bit hard to access so you don't accidentally brick your router.

Not sure about the situation in Germany, but in the Netherlands, if you have your fixed + mobile connection with the same ISP and there’s an outage on the fixed connection, you can ask for free mobile data until the outage is fixed.

Perhaps this would be an option to ask your ISP about.

One thing I appreciate about Apple’s App Store rules is that they require all apps to work on IPv6-only networks. They’ve had that rule in place for many years. It’s a little surprising as a developer the first time you run into it, but I’m glad it’s there as a user.

Is github accessible by v6 as long as you use the app?

”v6-only” in this context generally means ”with NAT64”, so only kind of.

No, their policy is that you have to use IPv6-capable sockets and APIs, not that the remote endpoints are accessible over IPv6.

That's, effectively, a non-policy.

It does more than you think it does. GitHub may not support IPv6 and Apple can't force them, too, but the GitHub App on iOS is in most cases using DNS64 to get an IPv6 address to a NAT64 gateway to the GitHub IPv4 addresses, and all that just works today, in part because Apple forced apps to support "I'm always going to give you an IPv6 address, even if you know your own service isn't going to naturally return one".

I was not proficient enough to understand that on my own. ELI5 is that this requirement forces apps to support running on IPv6-only networks where DNS calls return special IPv6 addresses for IPv4 hosts and ISP (usually mobile) does IPv6 to IPv4 NAT. That does sound useful.

Right. It's useful to point out too that for some of our day-to-day mobile networks this is the present state and not just a hypothetical future. Mobile and cell networks have been a driving force for IPv6 adoption [1] and several of them went IPv6-only infrastructure years ago (hand in hand with 5G rollouts in many cases). Both iOS and Androids efforts in making sure that IPv6-only was standard and worked in all App Store/Play Store apps were critical to getting us here.

[1] IPv6 makes hand-offs between radio towers (cells) a lot easier if the towers don't also have to manage scarce IPv4 addresses/NAT44 configurations and complicated DHCPv4 handshakes to setup/change IP addresses regularly; plus mobile networks in general have a lot of devices today, some have way more than other types of ISPs so IPv4 scarcity was something they could feel directly on their corporate bottom lines.

GitHub doesn't support IPv6 yet[1]. Ridiculous but true.

[1] https://github.com/orgs/community/discussions/10539

Yes, but it does not require your server to have an IPv6 address.

If anyone else runs into this, it's very easy to set up an ssh proxy: ssh -D 8080 user@hostname

Once that connection is set up, point your browser to use localhost:8080 as a socks proxy.

I was just about to offer the same advice. It's a far simpler solution to a temporary problem - and equally, a permanent tool for the times when you want to proxy.

Don't forget that this function needs "AllowTcpForwarding" to be enabled in your sshd_config.

And I just managed to offer the same advice, then upon posting discovered I'd been beaten lol.

This simple solution versus the article reminds me of McIlroy and Knuth: https://news.ycombinator.com/item?id=35915169

That was an amazing read, thank you!

I always do this when I'm using a public wifi. Don't need to pay for a VPN / trust one, I just socks forward everything to my infomaniak server.

Blockers for switching off IPv4:

- I am using alternative search engines, and it seems most do not provide IPv6 connectivity (when they are not wrecked by big tech gigantic network resources, you know "AI"... how to conveniently DDOS alternatives...)

- github.com: zero ipv6 last time I did check. This is microsoft, do not expect anything good, actually expect the worst, for instance they broke recently noscript/basic (x)html for the issues. Can we still create a account with a noscript/basic (x)html browser and self-hosted emails with IP(v6) literals (mailbox@[ipv6:...])?

- steam? games? Did not check lately. I think many CDNs/game servers or good chunks of them are still IPv4 only.

- many email servers: additionnally many blocks self-hosted email servers (often due to the usage of clumsy and inappropriate block lists from spamhaus, a shaddy company from Switzerland and Andore), with a DNS (SPF) or ip literals (even if it is much stronger than SPF).

- A lot of network applications do not leverage the power of IPv6: for instance for the client-server applications (web for instance), a client-server session should be using a randomly generated IPv6 address, if the ISP provides a not to big prefix. Mobile internet IPv6 ISPs seem to provide random IPv6/128 addresses (in their prefixes), but should provide a stable prefix (probably 96bits) in order to let the terminal applications choose "fixed" ipv6 addresses for direct audio/video calls (no central and online name resolution required). A new user-level OS service is required for user application IPv6 address coordination (beware of brain damaged complexity which some vendors and developer will force upon users and app devs for lock-in).

I can confirm that Steam requires IPv4. Also some games that require authentication to play do too.

I think microsoft(github.com)/steam are the main dominant corpos dragging the world backward, well from an IPv6 point of view. I though steam had now IPv6 addresses.

Don't forget IPv4 is favoring hardcore centralized online services.

> I think many CDNs/game servers or good chunks of them are still IPv4 only.

I have created a DNS proxy for this problem, it will add the correct AAAA records on such domains.

https://gitlab.com/miyurusankalpa/IPv6-dns-server

CDN, not DNS.

It mostly matches domains of CDNs at the DNS level.

It should be really called a DNS proxy.

>spamhaus

Oh boy Spamhaus. I had to deal with them a few months back. For some reason, my VPS had ended up with its IPv6 addr. on the Spamhaus block list. I have no idea how it happened, the machine runs nothing with the capability to send email, and as far as I know, Digital Ocean even blocks SMTP, so it would be literally impossible for this machine to send any email. Spamhaus was not at all helpful in getting this resolved (and neither was DO for that matter).

Spamhaus is a shaddy company from Switzerland and Andore, VERY SHADDY (I suspect blackmail).

digital ocean? I had to block all of digital ocean because scanners and script kiddies from there were zillions to scan/attacks my email server.

Everything was going just fine with v6-only in my mini homelab...until I needed GitHub for something or other. And thus I set up NAT64+NAT64. It felt like a real shame to have to do that just for GitHub. I would've needed to eventually for my mail server anyway, but this was a super lame reason to need NAT64 sooner rather than later.

This is one of the (imo several) downsides of people using GitHub has a software distribution mechanism.

I don't think moving off IPv4 is on anyone's radar yet, unless you're buying VPS services that often come with a discount when you run on IPv6 only. In practice, you'll probably always have IPv4 connectivity of some sort, even though it's probably going to become more and more likely that that connectivity is attained through CGNAT.

Github is especially infuriating. For a few weeks, they ran a test, everything seemed to work great, and then they reverted to IPv4-only again.

Email servers live a decade or two in the past anyway. Disabling SSL 3.0 or TLS 1.0 support on email servers is still something you can't do without risking email deliverability problems. Microsoft Outlook's support and spam filters don't even seem to be aware of IPv6 capable mail servers (despite their headers showing they've been using IPv6 internally for ages).

I do wish IPv6 would be leveraged more, but the fear that maybe things work slightly less well for a minority of customers seems to be freezing every attempt at actually making use of the tech.

The reason you may be seeing weird IP behaviour from mobile carriers probably has to do with the way IP on mobile networks works, though. If you're on a call driving down a highway or sitting in a high-speed train, your phone will be doing handovers over and over again, and your IP address needs some form of stability. You may even cross a border and switch to a foreign network and the entire stack is supposed to maintain a seamless connection. There are special routing systems set up within cellular networks (some of which make excellent use of IPv6 features) that will make it very difficult to provide "normal" static GUAs to cell phones. Things are made as normal as possible, but it's not as easy to accomplish that kind of stability as you would with a fixed-line home internet connection.

The US government is under a mandate to move to v6 only, so it's very much on some radars. Hopefully some ISPs follow suit.

https://www.whitehouse.gov/wp-content/uploads/2020/11/M-21-0...

Is it on schedule? 80% by 2025.

I'm operating a few IPv6-only VPNs at work, for access to internal infrastructure. The biggest problem so far is that Windows and macOS clients need a v6 DNS server. Otherwise, they won't even try to resolve v6onlyhost.vpn.example.com. Because the client may or may not be in a v6-enabled network, I have to run a DNS server inside the VPN and push that to the client, which can lead to all kinds of problems when the VPN disconnects but the Wireguard app for some reason fails to reset the DNS to the original one.

I've found that using my v4 only network from my ISP and macOS can do v6 only without requiring a DNS server like you have been doing. I don't remember the details now, but after some digging a few years ago I realized macOS will happily work like that as long as it has a v6 address. I can put a ULA address on my host, and it's good to go. Granted this relies on users knowing how to do that. or depending on the VPN application to get to the v6 only network, you may be able to script adding a ULA (any kind even made up). You don't want to leave it wIth a made up ULA because that could screw things up if the user moves to a v6 capable network.

Interesting. Do you actually use that trick in production? I'd have to find a name of an interface that I could safely mess with...

Yeah I've been using it daily for almost a year as have many other people at work

In an automated fashion using some kind of "PostUp" Script (to use the Wireguard term) or do you add the IPs manually after the VPN has been established?

I was able to write an AppleScript that ran on connection to add a dummy ULA and a disconnect script that undid it and went back to auto v6.

This is not Windows. I also had a similar problem on random hotspots, but not on all of them. I believe it's the moronic hotspots that don't return AAAA records when IPv6 is disabled.

After all these years I still don’t see a compelling reason to spend days pulling my hair out switching all my machines and home lab to ipv6. I just find port forwarding and firewall rules more intuitive vs the prospect of spending weeks troubleshooting everything, reconfiguring firewalls, renunbering my network.

What am I missing?

You're missing that it's not that difficult. Unless you have a very complicated home network, setting up IPv6 should take you an evening tops. For my network and my ISP (Comcast), it's literally just turn on IPv6 in the router, it will pick up a prefix from the ISP and advertise it locally, then I add a firewall rule for whatever I want to be accessible from outside (which isn't much).

The problem goes way back to the IPng days. With the project being designed by a committee who would choose random hills to die on, wasn't adaptive to new needs and used sticks more than carrots.

Some of those have been changed but typically after trying to implement it broke so many things that people just quit trying.

Some were well intended like the 'no NAT' in the days of FTP and before reverse proxies etc.

Others were intentional pain points to for adoption like when resolvers were not permitted to return A and forced to return AAAA records even when you ISP didn't support IPv6 etc...

Mix in problems like the max prefix size being too large for scanning a local network space to be practical etc... and people have been trained for decades that the pain is worse than any benefits.

Yes, today it isn't hard on small home networks where IPX will an IP gateway would also work fine, but things break as things get more complex.

Somewhere someone probably has a copy of the mail lists where I pointed out in around ~1996 that forcing globally unique IPs was a leaky abstraction and that there was more nuances and tradeoffs that needed to be considered.

It was obvious to me because I was stuck on a Altavisa firewall, but I was roasted.

On the IPv4 side, user needs were addressed through CIDR, carrier grade NAT, FTP passive connections etc...

I still tried to move companies to IPv6 a few more times and was bitten ever time.

Almost every time it was due to arbitrary global decisions, when they should have been focused on maintaining good will and making adoption as easy as possible.

The effort depended on a collition of the willing, and just changing 'must' to 'should' in key RFCs would have dramatically improved the chances of adoption.

I am actually glad you have an ISP that allows you to even do this, mine still does not.

Nothing. In the enterprise world the benefits vs the negatives of implanting ipv6 is not there. I manage around 3500 devices, 7 buildings and have 2 ten gig wan connections and one 4 gig wan connection and use NAT along with about 26 public ipv4 addresses.

To this day I have no compelling reason to adopt ipv6. Dual stack setup adds unnecessary traffic and complexity for little advantage.

To this day it is still hard to get assigned a block of static ipv6 addresses, have applied twice and been denied.

So not only is there little upside it is also still hard to even get allocated a block.

https://www.arin.net/resources/guide/ipv6/first_request/

“Step 1: Verify You Qualify If you meet any of the criteria below, you qualify to receive IPv6 address space:

Have an IPv4 assignment from ARIN or one of its predecessors Intend to immediately be IPv6 multi-homed Have 13 end sites (offices, data centers, etc.) within one year Use 2,000 IPv6 addresses within one year Use 200 /64 subnets within one year“

> What am I missing?

Right now, nothing major. At some point the big companies (Google, cloud flare, etc) may very well tire of having to pay more and more for ipv4 address that they may provide incentives for IPv6 (eg they could start throttling IPv4). There are some early moves going on already here. AWS used to only charge for unused IPv4 elastic IP addresses and now charge for them regardless of their use.

Honestly, the next time you upgrade your gateway/router you may as well set it up to be ready, but you're otherwise not missing anything right now. You can also use IPv4/v6 at the same time. You can enable it on your router and your IPv4-only devices will still work perfectly fine. One note, auto-discovery on IPv6 was a bit of a shitshow (SLAAC, IPv6 auto-addressing, and DHCPv6 all were a thing and the original auto-addressing didn't even support getting DNS servers), but things are settling on SLAAC (though ISPs will be using dhcpv6 for a loooong time).

I have strong opinions about ipv4, especially since I'm forced to use an ipv4 isp. The lack of ipv6 adoption should be considered one of the great failures of tech. Who actually is responsible? Is it router manufacturers writing poor quality firmware, ipv4 advocates in leadership positions at isps, ipv4 address speculators, poor training of network engineers and tech support staff? I think we all need to have a much greater discussion with the internet at large and not just on isolated web posts and subreddits.

For comparison, the internet mostly transitioned off of TLS 1.0 just fine, why can't we do the same for transitioning off ipv4? Maybe AI powered proxies for legacy code perhaps?

We have a saying in the industry… IPv6 is an academic solution to an engineering problem. The reality is it’s just too damn complicated to implement and maintain at scale while also retaining compatibility with v4… which is never going to go away because other than the address shortage, there are no problems with it.

We have no such saying in the industry. IPv6 is generally easier to implement and maintain. If IPv6 were the incumbent and someone came in proposing IPv4, they’d be laughed out of the room for its ridiculousness. “You have to run a stateful server just to assign addresses? Dynamic header length? A tiny address space? And tell me again about this NAT thing, LOL.”

V6 was designed by the engineers who realized what they got wrong in V4.

You still need a stateful server to assign IPv6 addresses for most use cases, through DHCPv6. SLAAC doesn't even give you a DNS server yet. And even if it did, many ISPs assign too small address spaces for SLAAC, or your networks isn't so simple that you can just auto-negotiate some address.

1. You have been able to assign DNS through SLAAC for years 2. Stateless DHCPv6 serves most needs not covered by SLAAC 3. Yeah, some ISPs screw up and don’t assign enough address space. Most likely because they’re still in the address-poverty mindset of v4

> your networks isn't so simple that you can just auto-negotiate some address

I don’t understand what you mean by this…v6 afaik has every tool that v4 does for assignment. If automated assignment through SLAAC or either kind of DHCP doesn’t meet your needs, then there’s manual assignment, just like with v4.

Stop spreading misinformation.

> You still need a stateful server to assign IPv6 addresses for most use cases, through DHCPv6. SLAAC doesn't even give you a DNS server yet.

DNS now comes in Router Advertisement per RFC 8106. No need for DHCPv6 anymore.

> And even if it did, many ISPs assign too small address spaces for SLAAC, or your networks isn't so simple that you can just auto-negotiate some address.

Most residential ISPs allocate in /48, /52, /56, or /60. Even if they allocate in the smallest /64, it's still perfectly fine for SLAAC for most home users utilizing a single subnet.

IPv6 is not actually hard to implement or maintain. A lot of people have repeated that meme, but it isn't true at all.

Okay, then please reimplement the equivalent of the following code to work with both IPv4 and IPv6:

    int fd = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(1234) };
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    bind(fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(fd, 128);
    int client;
    while (client = accept(fd, 0, 0)) {
        // ...
    }

I don't think anyone was talking about the difficulty of implementing IPv6 in software. I certainly wasn't. I meant the difficulty of implementing it as a network admin, which is not really hard.

https://beej.us/guide/bgnet/html/ section 5.6

It's just a lot of work/churn with little to no concrete benefit for many people involved. There is no IPv4 cabal.

> For comparison, the internet mostly transitioned off of TLS 1.0 just fine, why can't we do the same for transitioning off ipv4?

This is a great demonstration of the advantages of the end-to-end principle. The reason the transition off TLS 1.0 (and earlier SSL 3.0) could happen so quickly is that only the endpoints (the server and the client) needed to be updated to understand the new protocol; nodes in the middle of the path (routers, switches, and so on) only needed to care about the IPv4 (or IPv6) layer, which didn't change with new TLS versions.

But that only works for layers above the network protocol; when updating the network protocol itself, every node is affected.

(And the TLS transition also took longer than it should, in large part because a lot of "middleboxes" violated the end-to-end principle by inspecting or even modifying the TLS connection, without taking part in the protocol negotiation. TLS 1.3 had to be modified to pretend to be a resumed TLS 1.2 connection to trick these middleboxes into not incorrectly rejecting the newer version of the protocol.)

> transitioned off of TLS 1.0 just fine

The difference is only the end client and server need to support TLS, all the middleware and networks between just see TCP packets and do not have to be privy to what TLS version is being used.

IPv6 on the other hand has to be supported by every middleware box between the client and the server and therefore its functionality is limited by the lowest common denominator.

Additionally TLS upgrades were largely drop in, whereas IPv6 changed too many things at once to be easily adopted.

Hindsight is 20/20, but I firmly believe that IPv6 should have only changed source and destination addresses to be 64 bits and that was the entire RFC.

The big problem is that there isn't incentive for old companies to migrate. They have addresses and the benefits are mostly for customers who don't know about it. Also, network engineering training is all about IPv4, and it works so they don't want to change.

I think what was needed was organization that could push IPv6. Boring technology needs someone promoting or grows slowly. They could have logo for IPv6 ready devices, and list of ISPs with IPv6. They could write network engineering training for the IPv6 way.

We missed opportunities for cloud computing, Kubernetes, and new companies to be primarily IPv6.

Ha, I actually had to do this last year while setting up Arch Linux on my desktop.

I have to use this wifi dongle, but using IWD to connect somehow only gave me an ipv6 IP.

Most of the big sites worked, but trying to click links from a search engine was a 50/50 chance.

Thankfully, the Arch wiki was accessible, so I got it sorted out pretty quickly.

It's weird some major sites like Github still don't support IPv6. There is no excuse.

When you want to use a public address over a tunnel, IPv6 makes things easier. Instead of setting up a tunnel to a specific IPv4, deleting your default route, adding that deleted route as the other endpoint's IPv4 route, then adding the tunnel's other end's IPv4 as a default route, you can just connect to the tunnel endpoint via IPv6, and all the IPv4 is configured just in the tunnel.

I use this often because IPv6 on phone networks is invariably the same as the author's - native IPv6 plus carrier grade NAT IPv4, and most NAT implementations suck (they time out, for instance).

I haven't tried with WireGuard(r) yet, but I will soon (using NetBSD's clean reimplentation). With tinc [1] though, it's a piece of cake.

[1] https://www.tinc-vpn.org

It would be so cool, and so much cheaper, if I could route all my non-critical websites to my homelab instead of cloud services.

I can’t guarantee five nines but my power almost never goes out, and that’s plenty for a blog and even many online stores

I run my own tailnet (headscale as the coordinator server). Tailscale stack is essentially built on top of wireguard.

I have an exit node setup with dual stack IPv4/IPv6 addresses. So in theory if my ISPs CG-NAT failed or IPv4 was inaccessible, then configuring my device to use my exit node to reroute traffic _should_ work without having to mess with WG internals like the author in this article.

I suppose there are some caveats here since I have discovered many services do tend to flag IPs originating from VPS ASNs as "spammy" (ie, pretty much any service front loaded by CloudFlare). Maybe Hetzner is better in this aspect?

CloudFlare and friends use a multitude of factors, AS being only one of them. I am a TekSavvy customer (Canada's largest independent, i.e. not owned by one of the incumbents, ISP). Pretty clearly an eyeball network, and I get the CloudFlare captcha multiple times per day on different sites. I'm guessing it may have to do with the fact that I use custom reverse DNS entries (instead of their default schema of 127.0.0.1.dsl.teksavvy.com) for my internet facing IPv4 and IPv6 subnet.

If you only need outbound connectivity then you can use a public NAT64 gateway. You can find a list at https://nat64.xyz/

Past 10 years I just do ssh -R to the vps and use that as a socks5 proxy. Takes 2 seconds to set up.

ssh -D for socks proxy

yeah I had it in a script, forgot what was in it. Testament to Asimov's Feeling of Power

Why not just add the VPS to the Tailscale network and use it as an exit node?

The irony of posting this on GitHub which remains shamefully without IPv6

This is interesting at all but couldn't you just pay five bucks and use Mullvad.

I would just hook up a router to any VPN service that is reachable via ipv6. Done.

There's an IPv6 article that's been on the front page for the better part of a day and to my incredulity, the "IPv6 sucks; why don't we just add more segments to the IPv4 address" guys haven't shown up yet. Where the hell are you, dudes? Do you take the weekend off?

ipv6 only machine still reaches ipv4 sites because dns64 upstream is just faking AAAA records ,makes it look like everything is native ipv6. this part of the trick is happening somewhere else which's not controllable. if dns64 breaks or stops doing the mapping properly then this might break

In IPv4 if your NAT or your ISPs CGNAT stops mapping everything breaks.

Having a stateful mapping device inline in the network sucks for reliability in general. Native IPv6 removes the requirement.

DNS64 exists upstream in your ISP in the same way that CGNAT, does, in a central gateway someone along your rout path. If your CGNAT breaks, it's possible that was also your DNS64 fallback provider. For many ISPs, if you are using CGNAT still for IPv4, it probably means that they haven't even invested in DNS64+NAT64, because you can force devices to be IPv6-only and especially with most consumer devices entirely replace a CGNAT with DNS654+NAT64 today, and it is probably cheaper to do so.

Why would I ever need IPv6 at home or in my office? Explain to me logically why I need it in my house or in my office?

I do not care about using up the last internet address because that is akin to the 'think of the children' crap used to justify things on an emotional level in order to manipulate people.

There's no way I'll exhaust the private address spaces and I not not see NAT as a negative.

I do not want my fridge or toaster on the internet. I do not want my phone always on the internet. Nor do I carry a smrt phone or use WiFi as everything in my house is hard-wired.

So it seems like all I would ever need is a 4-to-6 gateway solution of some sort . Devices in my house or office will not ever really need IPv6 or a 'dual-stack' and all that extra complexity is a waste of time... what problem is it supposed to be solving exactly?

Logically? Because the world’s needs are changing and one day there will be something you want or need that will be accessible via IPv6, at which point you can either move with the times or be left behind.

IPv6 global adoption is on the rise whether you see the point in it or not. The religious arguments and nitpicking no longer matter.

If you don’t understand the engineering benefits, fine, not everyone needs to be an expert. I wouldn’t proudly brag about my ignorance of the subject, though.

What exactly are the "engineering benefits" beyond a larger address space? Most companies rely on private address spaces to logically separate them, and will ultimately end up using NAT66, ending up exactly where they started, but with significantly more complexity.

Every time this comes up, people come out of the woodwork to say, "Well, akually we talked about this exact thing in 1995 and decided this was the right way!" Yet, it's never convincing.

If it were a simple address expansion, we would have completed this upgrade around 1998. Yet here we are, 30 years later!

> Most companies rely on private address spaces to logically separate them...

Which is a hack driven by address scarcity. You can, and should, separate address spaces just fine if they're publicly routable.

> ...and will ultimately end up using NAT66, ending up exactly where they started, but with significantly more complexity.

Then those companies are managing their network very poorly. Which is their choice, but not really an argument against IPv6.

Telling people doing things like SCADA, who absolutely don't want their hot forging press to be globally addressable, that they're "doing it wrong!" is not helpful. This attitude is why nothing short of coercion and blackmail is required to get a large chunk of users to switch.

Literally no one is suggesting this. Having globally unique IPs doesn’t even slightly infer that they should be globally reachable. IPv6 still uses firewalls. It does mean that making an internal resource reachable when appropriate for that specific resource is vastly easier: you open the right firewall port and it’s done.

It's much easier to build an IP layer 6-to-4 gateway (like NAT64) than a 4-to-6 gateway, because the IPv4 header doesn't have room for a 128-bit destination address.

The most practical "4-to-6 gateway" would be a SOCKS or HTTPS proxy, because those let the client connect directly to a hostname and not care about IP addressing. But configuring a proxy for all your home devices is probably more tedious than deploying IPv6.

A few months ago, one of the Linux distros I used released a kernel update with a bug that killed IPv4 connectivity. I tried to set up some kind of VPN to my basement server to work around that, but it didn't work. I even installed WireGuard, so I wasn't too far off. I gave up and decided to use the older not-buggy kernel.

Reply on news.ycombinator.com