Using the Internet without IPv4 connectivity (opens in new tab)

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.

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.

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

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.

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.

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.

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.

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.

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

Using Cloudflare WARP would be much faster.

And you can connect directly to ipv4 addr via WARP.

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.

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

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

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.

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.

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.

>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).

> 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

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

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.

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.

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.

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).

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).

> 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.)

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.

> 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.

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

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.

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.

ssh -D for socks proxy

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.

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.

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.

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.