Using the Internet without IPv4 connectivity(jamesmcm.github.io) |
Using the Internet without IPv4 connectivity(jamesmcm.github.io) |
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?
IPv6 global adoption is on the rise whether you see the point in it or not. The religious arguments and nitpicking no longer matter.
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.
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!
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.
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.
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.
Pretty annoying and lazy if you ask me.
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.
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.
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.
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.
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...
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>
And you can connect directly to ipv4 addr via WARP.
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
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.
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.
Perhaps this would be an option to ask your ISP about.
Once that connection is set up, point your browser to use localhost:8080 as a socks proxy.
Don't forget that this function needs "AllowTcpForwarding" to be enabled in your sshd_config.
This simple solution versus the article reminds me of McIlroy and Knuth: https://news.ycombinator.com/item?id=35915169
- 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).
What am I missing?
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?
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.
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.
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 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?
Having a stateful mapping device inline in the network sucks for reliability in general. Native IPv6 removes the requirement.
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.
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.
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>
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?
This is one of the (imo several) downsides of people using GitHub has a software distribution mechanism.
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).
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.
I have created a DNS proxy for this problem, it will add the correct AAAA records on such domains.
Don't forget IPv4 is favoring hardcore centralized online services.
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.
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.
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“
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).
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.)
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.
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.
V6 was designed by the engineers who realized what they got wrong in V4.
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.
I run WARP in socks proxy mode, and using ipt2socks for redirecting traffic to socks proxy port.
it's relatively simple for them to implement [ the stateless part ] but due to that puts some requirements on the party establishing the tunnel.
Is it on schedule? 80% by 2025.
It should be really called a DNS proxy.
> 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.
> 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.
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 have my VPN permanently enabled for Pihole reasons anyway, so my IPv6 access works that way, but it's pretty stupid.
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.)
[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.
I haven’t thought enough to say whether it makes sense for specific cases like IP address allocation, though.
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".