[HN Gopher] Using the Internet without IPv4 connectivity
       ___________________________________________________________________
        
       Using the Internet without IPv4 connectivity
        
       Author : jmillikin
       Score  : 246 points
       Date   : 2025-06-29 08:23 UTC (14 hours ago)
        
 (HTM) web link (jamesmcm.github.io)
 (TXT) w3m dump (jamesmcm.github.io)
        
       | thexa4 wrote:
       | 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.
        
         | daneel_w wrote:
         | 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.
        
           | czbd wrote:
           | 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
        
             | appreciatorBus wrote:
             | That was an amazing read, thank you!
        
         | Biganon wrote:
         | 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.
        
       | simonjgreen wrote:
       | 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.
        
         | danappelxx wrote:
         | Mirrors my experience. IPv6 issues are frustratingly hard to
         | triage and reproduce, lots of "works on my machine" etc.
        
           | jeroenhd wrote:
           | 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.
        
         | kalleboo wrote:
         | 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.
        
           | paulddraper wrote:
           | GitHub is definitely a part of that long tail.
        
         | jeroenhd wrote:
         | 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.
        
           | mananaysiempre wrote:
           | 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
        
           | elcritch wrote:
           | 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.
        
           | mikepurvis wrote:
           | 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.
        
           | immibis wrote:
           | 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?
        
         | msgodel wrote:
         | 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.
        
           | ikiris wrote:
           | [citation needed]
        
           | umanwizard wrote:
           | > 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.
        
             | bombcar wrote:
             | Majority mobile and majority ipv6 are basically the same
             | thing.
        
             | immibis wrote:
             | And developing countries don't have much choice since they
             | have to share about 5 addresses per city.
        
       | JimDabell wrote:
       | 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.
        
         | Gigachad wrote:
         | Is github accessible by v6 as long as you use the app?
        
           | Sesse__ wrote:
           | "v6-only" in this context generally means "with NAT64", so
           | only kind of.
        
           | neilalexander wrote:
           | No, their policy is that you have to use IPv6-capable sockets
           | and APIs, not that the remote endpoints are accessible over
           | IPv6.
        
           | xvilka wrote:
           | GitHub doesn't support IPv6 yet[1]. Ridiculous but true.
           | 
           | [1] https://github.com/orgs/community/discussions/10539
        
         | the_mitsuhiko wrote:
         | Yes, but it does not require your server to have an IPv6
         | address.
        
       | czbd wrote:
       | 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 :)
        
       | hashworks wrote:
       | 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.
        
         | jeroenhd wrote:
         | 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.
        
         | Tijdreiziger wrote:
         | 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.
        
       | avhception wrote:
       | 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.
        
         | somidscr21 wrote:
         | 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.
        
           | avhception wrote:
           | 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...
        
             | somidscr21 wrote:
             | Yeah I've been using it daily for almost a year as have
             | many other people at work
        
               | avhception wrote:
               | 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?
        
               | somidscr21 wrote:
               | 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.
        
       | sylware wrote:
       | 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).
        
         | hashworks wrote:
         | I can confirm that Steam requires IPv4. Also some games that
         | require authentication to play do too.
        
           | sylware wrote:
           | 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.
        
         | miyuru wrote:
         | > 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
        
           | sylware wrote:
           | CDN, not DNS.
        
             | miyuru wrote:
             | It mostly matches domains of CDNs at the DNS level.
             | 
             | It should be really called a DNS proxy.
        
         | encom wrote:
         | >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).
        
           | sylware wrote:
           | 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.
        
         | jcgl wrote:
         | 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.
        
         | jeroenhd wrote:
         | 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.
        
           | somidscr21 wrote:
           | 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.
        
             | nadermx wrote:
             | https://www.whitehouse.gov/wp-
             | content/uploads/2020/11/M-21-0...
             | 
             | Is it on schedule? 80% by 2025.
        
       | pumplekin wrote:
       | 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/
       | 
       | <loads github>
        
         | rfv6723 wrote:
         | Using Cloudflare WARP would be much faster.
         | 
         | And you can connect directly to ipv4 addr via WARP.
        
       | nurettin wrote:
       | Past 10 years I just do ssh -R to the vps and use that as a
       | socks5 proxy. Takes 2 seconds to set up.
        
         | ta1243 wrote:
         | ssh -D for socks proxy
        
           | nurettin wrote:
           | yeah I had it in a script, forgot what was in it. Testament
           | to Asimov's Feeling of Power
        
       | theandrewbailey wrote:
       | 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.
        
       | b0a04gl wrote:
       | 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
        
         | tatersolid wrote:
         | 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.
        
       | Toorkit wrote:
       | 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.
        
       | throw0101c wrote:
       | 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...
        
         | daneel_w wrote:
         | 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.
        
           | cebert wrote:
           | > 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?
        
             | daneel_w wrote:
             | 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.
        
               | xyzzyz wrote:
               | 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.
        
               | daneel_w wrote:
               | 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.
        
               | xyzzyz wrote:
               | Yes, and why did people ask for these oversized networks?
               | That's right, because addresses were free.
        
               | daneel_w wrote:
               | 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.
        
               | xyzzyz wrote:
               | 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.
        
               | wizzwizz4 wrote:
               | 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".
        
               | homebrewer wrote:
               | 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/
        
         | jeroenhd wrote:
         | 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.
        
         | pQd wrote:
         | 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.
        
           | Abekkus wrote:
           | Strange. This sounds like something Hurricane Electric
           | specifically limited. There's nothing in CGNAT that would
           | naturally break such a tunnel
        
             | TechDebtDevin wrote:
             | I use tunnels all day like this with cgnat on multiple
             | devices.
        
             | pQd wrote:
             | 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.
        
           | Shadowmist wrote:
           | 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.
        
         | toast0 wrote:
         | 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.
        
       | allyourdatas wrote:
       | 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?
        
         | neilalexander wrote:
         | 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.
        
         | kstrauser wrote:
         | 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.
        
           | ok123456 wrote:
           | 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!
        
             | bigstrat2003 wrote:
             | > 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.
        
         | p1mrx wrote:
         | 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.
        
       | xacky wrote:
       | 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?
        
         | crims0n wrote:
         | 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.
        
           | kstrauser wrote:
           | 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.
        
             | tsimionescu wrote:
             | 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.
        
               | jcgl wrote:
               | 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.
        
               | riobard wrote:
               | 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.
        
           | bigstrat2003 wrote:
           | IPv6 is not actually hard to implement or maintain. A lot of
           | people have repeated that meme, but it isn't true at all.
        
             | murderfs wrote:
             | 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)) {
             | // ...         }
        
               | bigstrat2003 wrote:
               | 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.
        
               | p1mrx wrote:
               | https://beej.us/guide/bgnet/html/ section 5.6
        
         | arp242 wrote:
         | It's just a lot of work/churn with little to no concrete
         | benefit for many people involved. There is no IPv4 cabal.
        
         | cesarb wrote:
         | > 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.)
        
         | __turbobrew__ wrote:
         | > 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.
        
       | benchess wrote:
       | The irony of posting this on GitHub which remains shamefully
       | without IPv6
        
       | johnklos wrote:
       | 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
        
       | the_real_cher wrote:
       | This is interesting at all but couldn't you just pay five bucks
       | and use Mullvad.
        
       | chaz6 wrote:
       | If you only need outbound connectivity then you can use a public
       | NAT64 gateway. You can find a list at https://nat64.xyz/
        
       | shmerl wrote:
       | It's weird some major sites like Github still don't support IPv6.
       | There is no excuse.
        
       | xyst wrote:
       | 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?
        
         | heffer wrote:
         | 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.
        
       | ornornor wrote:
       | 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?
        
         | bigstrat2003 wrote:
         | 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).
        
           | nyrikki wrote:
           | 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.
        
         | roody15 wrote:
         | 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"
        
         | hylaride wrote:
         | > 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).
        
       | andix wrote:
       | I would just hook up a router to any VPN service that is
       | reachable via ipv6. Done.
        
       | FredPret wrote:
       | 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
        
       ___________________________________________________________________
       (page generated 2025-06-29 23:00 UTC)