Thankfully, even though the Mastodon post that triggered this made the usual mistake of implying that disabling NAT results in "exposed" LAN devices (NAT has nothing to do with it, that's the firewall's job), the author of the article does not.
What does the Steam Deck's OS use for networking? If it's NetworkManager and NM has been configured to check an IPv4-only URL for connectivity (*), that might be the problem. Though of course, since Steam services themselves don't support v6 (as the author notes later), working v6-only network on the Deck won't help with playing games anyway.
Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole.
Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them.
If those applications want to be reached over the network, they can use Hole Punching to turn what would otherwise be an inbound connection into an outbound one. But that requires an effort on both ends of the conversation: if I want a remote client with IP 1.2.3.4 to connect to my server that's behind a NAT, then my server first needs to send a packet to 1.2.3.4. (That's the hole that's punched.) But that doesn't change anything about the reliability of the NAT's protection, because other clients on the internet still can't reach my server. If 1.2.3.4 is not malicious, then nothing bad can happen here. If 1.2.3.4 is malicious, then I was already in trouble when I punched the hole in the NAT, before an inbound connection from 1.2.3.4 even arrives - simply because I created an outgoing connection to 1.2.3.4, over which they could have sent me exploits anyway.
I know you know all of this, but I wanted to add some context to your misleading and pedantic comment for other readers of this thread.
It's enough to keep the Shodan skiddies at bay. I distinctly 'member the modem/ISDN era and trolls shooting off unpatched machines of other gamers. In ye olde days remote RCE exploits were a regular issue...
Resist the urge to be that guy. There actually is a deny: it’s what your NAT system does when an incoming packet doesn’t match a connection initiated by a device behind it.
Trying to be pedantic about this isn’t adding anything to the conversation – people have been trying to make this seem like a useful distinction for decades but it’s never worked because anyone who cares about security is focused on “can an attacker initiate a connection to my system?” rather than “did I lovingly handcraft the packet filtering rule which dropped their attempt?”
Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem). Assuming the firewall is configured correctly in the first place, which is by no means guaranteed in consumer/SOHO settings.
> Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem).
How is one your problem and the other your ISP's?
In both cases the bits are coming down your connection and hitting the CPE. Whether the CPE does only SPI firewalling or SPIFW+NAT seems to be irrelevant to me, as the same thing happens: packet's header tuple is examined, a state table is looked at, and the packet is passed or dropped depending on the contents.
"NAT Device" = "Firewall" (in this context) = "What you'd normally have with a public address plus the translation part".
There tends to be conflation that somehow you need an additional device to filter you've not had in place before. In order to do NAT a device has to be at the edge of your network (your device or the ISPs) which tracks connection states to automatically translate outbound ones and allow the reverse mappings through while that is open. Getting rid of NAT simply means dropping the "translate" part from that device. The conntrack and allow outbound initiated connection part remains. Instead of port forwards for inbounds you just have inbound allows. There is no big swap of security roles between devices or special additional configuration needed, just the independent removal of the translation configuration from the device.
The NAT device itself also is a firewall and can enforce policies comparable to what NAT would do. I had the impression that this is the default behavior in 2024.
In my Fritz!Box, i have to configure IPv6 ports the same way i used to forward ports for IPv4.
Assuming CGNAT, sure, it is the ISPs problem. But that just underscores the utility of IPv6 where defective CGNAT results in a hair pulling experience for the customer. Things don't get forwarded, and there isn't a thing you can do about it except call the ISP (provided you were able to troubleshoot it to that point in the first place).
If NAT is done on the router, then it gets to make a decision on every packet regardless.
If your firewall is disabled, an incoming v4 packet on the WAN interface with destination IP = a NAT'ed LAN device's address like 192.168.1.2 could cross over to the LAN interface and reach said LAN device. It is the firewall's job to filter such bogons.
That's essentially how NAT hole punching works. It doesn't work on all routers, but most do just route the packet. You just need to know the exact configuration of the network and send the correct packet through a valid port and it goes through
Having implemented a commercial hole punching mechanism, and having tested it on home and commercial deployments (various UK and USA ISPs), I have to agree.
For most deployments (home and commercial) the NAT function (its session table) employs Endpoint Independent Mapping, and Endpoint Independent Filtering (see BEHAVE RFCs).
As such once something behind the NAT (say at IP:Port) has connected to an external node, any external node can connect back to that internal IP:Port location by targeting packets at the public IP':Port' mapping. This applies even if the node behind the NAT was not expecting, nor desiring it.
For home deployments, there is generally no additional firewall.
For commercial deployments, there is usually a firewall working in an Endpoint Dependent Filtering manner (usually full 5-tuple, Port and Address Dependent Filtering).
This additional firewall blocks off the unexpected connection allowed by the home scenario above, but still allows for hole punching if the behind NAT node(s) can coordinate punching via a third party to exchange their public mappings.
Notably in the home deployment case, if the attacker is working with known public ports and addresses (i.e. itself being none NATted), then it can easily bypass the filtering logic of the home NAT once it learns of the existence of the 5-tuple public flow from the home NAT.
But even if the attacker knows the 5-tuple (which is a big if), how would they send a package with the correct headers? Pretty much every ISP firewall will just drop your packages if you send them with a source IP that's not yours.
Note that if you can fake source IP addresses, then a proper firewall won't protect anymore either, because all rules of the form "allow inbound connections from 1.2.3.4 only" are now broken.
Just checked my Steamdeck and from the kde desktop settings ipv6 was entirely disabled. I just re-enabled ipv6 to let it auto configure an address and got ipv6 connectivity.
> usual mistake of implying that disabling NAT results in "exposed" LAN devices (NAT has nothing to do with it, that's the firewall's job)
However technically correct from a certain point of view you may be, I was supporting home users for a small ISP in the very early 2000s and you’re wrong in any way that matters. In practice NAT on its own made remote attacks on home networked devices far harder.
NAT didn't make remote attacks harder, the default inbound deny rule did. NAT is not the firewall itself, it's just one of the things the firewall can do. Telephone companies are also ISPs, and they are and continue to be quite inept when it comes to securing their own networks, so NAT without a default inbound deny rule is not secure.
This matters in a very meaningful way. Have you seen how many enterprising but clueless consumers click random buttons until whatever they are trying to do works? They often don't know or care about other ramifications until it's too late.
If you live in a country rich enough that every ISP customer gets a dedicated IPv4 address you won't see many of the downsides of deploying IPv4 these days. If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly. Even in rich countries, CG-NAT is starting to get used more and more as prices for IP ranges go up. CGNAT also affects people trying to do something silly like "open a port" for a Minecraft server or a VPN back home, which is impossible without a public address.
Outside of CGNAT, just about any protocol works better without standard IPv4 NAT. Xbox and PlayStation have invented their own terminology (what the fuck is a "type 2 NAT" anyway) and have written custom code to work around the different ways in which NAT fucks up your connection. Linux and BSD based routers will do deep packet inspection to figure out if you're trying to do FTP or SIP or H363 and rewrite traffic on the fly while opening holes in the firewall just so you can use basic internet functionality. This has also led to an attack dubbed "NAT slipstreaming" where generations of routers will allow Javascript running in your browser to open any port on your device to the outside, or even any port on any device in your network, despite what your router's firewall may say.
For larger networks (with more than ±250 devices), you get a working connection without having to figure out what a DHCP pool is.
And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.
In Germany, the TV-cable based ISP all have started deploying CGNAT.
If you live in a densely populated area with many Vodafone customers, their CGNAT gateways tend to be overloaded, so in peak hours you sometimes experience packet loss.
Of course Vodafone won't admit that it's a structural problem instead of isolated cases.
At one point, I was forced to use a shitty DSL provider, "e-on highspeed" (formerly "Innogy") because they had exclusive rights to the VDSL DSLAM in my area.
For a while, they didn't even offer IPv6 alongside the CGNAT v4.
And when they did, it broke randomly (remote gateway dead).
By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?
I can't create static records because my current ISP keeps changing my assigned prefix.
I'm still on v4 for my local fileservers and stuff like that because of this problem.
> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?
As others have mentioned, ULA is one option.
> I can't create static records because my current ISP keeps changing my assigned prefix. I'm still on v4 for my local fileservers and stuff like that because of this problem.
The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA. It sucks having to use NAT with IPv6, but at least it'll be stateless NAT. Then when your delegated prefix changes you will only need to update the NAT rule, meanwhile everything within your LAN that was using ULA-prefixed addresses to talk to each other will continue working.
For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS, and memorize them in the worst case.
> The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA.
You don't need to not use your ISP-assigned globally-routable prefixes. You can use both a ULA and a globally-routable prefix. In my years of experience with fully-functional IPv6 service, I've never noticed an address selection problem... machines always use the globally-routable address as the source for off-LAN communications and (because it's what's in my local DNS) the ULA address for on-LAN communications.
The single pitfall I've seen is if your ISP ever "shuts down" [0] that globally-routable prefix, and your border router isn't configured to reject traffic from fc00::/7 going out through the WAN interface, your border router will happily pass traffic out the WAN interface from your not-globally-routable ULA range.
> For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS...
I just configure my machines to use either MAC-based or DUID-based SLAAC address generation, rather than that stupid "privacy addressing" stuff.
[0] By this I mean by stopping advertising it, refusing to renew a DHCPv6-PD lease, or similar.
> does anybody have a clue on how to get SLAAC addresses into local DNS
I use an ULA for that (a private /48 that's not routable through the internet). I have a random server in my network (doesn't need to be a router) advertise it through radvd (though some routers also offer that ability). I then put the static address (not the random IPv6 privacy address) in local DNS. If you don't pick any "easy" ULAs, you can have multiple devices announce multiple ULAs on the same network and everything will keep working just fine (unlike multiple DHCP servers).
The benefit of an extra ULA inside your network is that you don't need to set up NAT or NAT66. The downside is that your ULA services won't be reachable from the outside. I solved that with a Wireguard VPN, but you may need something more complicated. You could consider using something like HE.net's free IPv6 ranges to add an extra prefix into your network that's reachable even when your prefix changes, but that needs some automation (and you want to configure it in a way that devices won't try to route to the internet over that prefix, or streaming services will stop working and your network will probably slow down a bit).
Maybe some of those timeouts aren't correct, I don't know for sure, but this seems to work fine for me. The RDNSS entry is for automatically assigning a DNS server, that's optional as well of course.
Alternatively, using mDNS also works more often than you'd expect, either over IPv4 or IPv6. Try `yournashostname.local` and you may just find it works out of the box. If it doesn't, you can probably install avahi-daemon on there to make it work.
> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?
The main difference between v4 and v6 (which reaaally trips v4 entrenched folks) what it's absolutely normal to have dozens of different addresses on the interface.
As other said, just pick your own ULA subnet and use addresses from it.
> And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.
I feel like <random big game> could have killed IPv4 ten years ago if they had just introduced this sort of latency difference.
> If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly.
Is this really related? I'm on IPv4 and get these "checking if your connection is secure" all the time as well. I think that this is unrelated to CG-NAT, because, after all, Cloudflare does mostly use the browser's properties to determine if a manual check should be done (click the button...).
> Cloudflare does mostly use the browser's properties to determine if a manual check should be done
Cloudflare uses the threat score of each IP address as a signal to determine whether additional checks are necessary. A shared IP address is more likely to be associated with "issues", such as a compromised IoT device being used for DDoS attacks, one of your neighbours spamming a forum, ...
How is it not a GDPR violation? Before I've even connected to the site I intended and had the opportunity to consent, an IP address that potentially uniquely identifies me (plus whatever else) is shared with a third-party data processor?
There is generally exceptions for anti-abuse/spam to some of the provisions of GDPR and the like.
That said, is there really any 3rd party here? You are connecting to cloudflare and they are the ones that have seen this IP before and judging its behavior.
> What benefits has ipv6 beside that ipv4 addresses for public servers are in short supply?
What more benefits do you need?
It's a major issue for many folks, especially if you (a) didn't manage to get in early on the IPv4 land rush, or (b) aren't a mega-corp with money to buy a whole bunch of addresses:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
Do you think we'd have as much mobile/smartphone connectivity without IPv6? T-Mobile US went to IPv6-only on handsets because of exhaustion, and they're only one carrier (in the US).
No, too much software and hardware relies on fitting the IP address into 32 bits. That means the only way to increase the number of addresses is in a way a clean break, so we might as well increase the number to a ludicrous size, far beyond what we can imagine practically exceeding, like IPv6's 128 bits.
IP packets are like a C struct that only have 4 bytes allocated per address. If you want to have more space, you need to change that struct, and that's what IPv6 does. Together with a new Ethertype so the different structs can be reliably differentiated.
My personal opinion is to skip dns64 in the transition path and instead rely on clat completely. The intersection of devices that support op108 but don't have clat is pretty small, so you are not really gaining much with dns64 imho.
It is noteworthy that there are many ways to accompish the sort of ipv4 service that nat64 does. I believe map-t/map-e and lw4o6 are the main contenders these days. In theory at least I don't see why you couldn't do clat style thing with those too. The main advantage of these newer technologies is that they allow service provider side to be stateless, whereas naive nat64 requires similar stateful connection tracking as traditional nat44 (=plain ipv4 nat).
For those if us who do want to run our own NAT64 box, is there a decent Linux option these days? Last time I looked, your options were variations on "this isn't packaged so just compile this source tarball and feed it this non-obvious config"... or OpenBSD which just treats it as a first-class option in pf(?) exactly like nat44. (And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...)
# apt search jool
Sorting... Done
Full Text Search... Done
jool-dkms/stable 4.1.9-1 all
kernel-based SIIT and NAT64 (IP/ICMP translation)
jool-tools/stable 4.1.9-1 amd64
userspace utilities for the Jool kernel modules
I suppose it is packaged, but dkms is still very much in the "why is does my router need a compiler installed" vibe.
It's the argument to --resolve, not the desired URL.
--resolve <[+]host:port:addr[,addr]...>
Provide a custom address for a specific host and port pair. Using this, you can make the curl requests(s)
use a specified address and prevent the otherwise normally resolved address to be used. Consider it a
sort of /etc/hosts alternative provided on the command line.
I haven't tried NAT64 on a Linux router, so I can't say authoritatively.
I did a similar experiment as the submitted article back in 2020, though that was on a pfSense (FreeBSD) router, not Linux. I used tayga for NAT64 there, which was last released in 2010, but it probably still works on modern Linux. At the very least it's still packaged in Debian.
The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware.
Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in.
I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies.
(What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)
So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work.
The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.
At the rate it's going, IPv6 should be ready for prime time around the same time we have nuclear fusion power plants and real self-driving cars that don't rely on a human driver.
Well, it did go from single digits in 2014 to 40-something percent adoption in 2024. Who knows where a tipping point is, though, or the emergence of more utility for it.
Something to consider about those statistics is that they don't include mainland China's massive IPv6 adoption, because the great firewall of China isn't going to "just" let you use Google. The Chinese government is actively pushing ISPs to deploy IPv6 to the point where [it's banning IPv4 NAT devices starting next year](https://www.lightreading.com/regulatory-politics/china-direc...). If you do see traffic from mainland China, it'll probably be through a VPN, and VPNs tend to be IPv4-only.
Most companies and servers probably won't care about Chinese visitors, but that still comes down to 763 million internet users that don't show up in the IPv6 statistics for companies like Google.
I was surprised to learn from the submitted article that Discord and Reddit also don't support v6, because those two ought to have a large mobile phone userbase, and mobile networks are the biggest cases of publicly routable v6 addresses and CGNAT for v4.
Reddit is an odd half mix. It seems like most everything they have is dual stack, including the CDN and "reddit.com"... but the "www.reddit.com" page you get redirected to is itself IPv4 only (and maybe some authentication endpoints or something, I haven't looked lately). They'll probably get there shortly.
Discord is an interesting one. On GitHub they've more or less straight out said "we built our backend with a bunch of hardcoded ipv4 addresses and logic and it hasn't been a priority to go back and fix vs build out the app".
Depends where, though. Here in Switzerland I think that only one of the three main mobile operators (Swisscom) has IPv6 on their networks (and it's a 2024 thing, so not even sure it's already reaching all customers).
Indeed. Here in New Zealand none of the mobile carriers have deployed IPv6 on mobile (and there are apparently no plans to do so) so we are at 0% for Mobile IPv6. Meanwhile all except one of the major fixed line carriers have IPv6. I don't have % figure but I would estimate >50% of fixed line connections here have IPv6 enabled (at least at the provider's end).
AWS provides a dual stack option that lets you run ipv4 and ipv6 simultaneously. We used it to help aid in a mostly uneventful migration over to ipv6 for most of our applications
I've been trying to go IPv6 in my network for several years, but it is really impossible. My ISP (Movistar, one of the big ones in Spain) does not enable it on its fiber network, although there is a beta program that does not allow new joins.
I've obviously configured HE's Tunnelbroker, and technically it works great. The downside is that their closest tunnel endpoint is in Paris and then all the usual web services identify my traffic as VPN/proxied/bot and it makes a constant flow of captcha solving requests or directly service refusal.
Adding to that, my wife cannot work from home, as the VPN her company uses fails when on IPv6.
If nothing big and dramatic happens in the close future, we'll be on IPv4 beyond my retirement.
The business case is that networks are getting better but NAT hardware isn't keeping up. Dual-stack users are increasingly likely to have a good v6 connection and very marginal v4, and just abandoning v4 support entirely lets you stop caring about that.
It hasn’t arrived yet but the trend is there and the cutoff point exists.
It's not enough to be dual-stack, happy eyeballs only really handles the broken v6/good v4 case and is too eager to fall back to a broken but minimally functional v4. You have to run v6-only services to not pay the NAT tax.
> The business case is that networks are getting better but NAT hardware isn't keeping up.
Network improvements are not distributed evenly. Most US broadband users are still on ADSL or DOCSIS and I would guess most use the cheapest (and slowest) available plan. With bandwidth per user being stagnant for years they don't need to upgrade CGNAT hardware (if they use it). Wireless providers grow faster and they are adopting IPv6.
But there is another side - server operators have much less reasons to adopt IPv6 than wireless/broadband ISP. Many high traffic sites are IPv4 only and I don't think they are loosing money because of this.
Yes VDSL likely is more common nowadays but in publicly available stats they are counted together so better to call it xDSL or just DSL. E. g. https://www.fcc.gov/reports-research/reports/measuring-broad... talks about DSL and DLS speeds not that high.
Odd that they lump them together; they're related, certainly, but _used_ very differently (in practice, VDSL is nearly always FTTC, ADSL tends to be fibre to the exchange). If an ISP offered me VDSL, well, I wouldn't be thrilled, but it would be usable. If they offered me ADSL I'd be wondering if I'd accidentally stepped back in time a decade or so. Based on the figures above, though, looks like there actually _is_ still a good bit of ADSL in use in the US!
In practice it also means literally running out since there are less IPv4 addresses than there are people (and much less computers that might want to connect to the Internet).
The people who would truly benefit from it have already switched. What's left is mostly either people who aren't even aware it exists (like home users), or admins of small/medium-sized networks who are either scared of change, or have a budget which is barely large enough to keep the lights on.
This can also be because they bought hardware from a bad vendor, like Ubiquity, which used to support IPv6… in software routing only giving it a max throughput of something like 50mbps on their small business/prosumer hardware. There are also routers by brands like Microtik that have garbage IPv6 throughput unless you flash OpenWRT which packages the driver that enables hardware IPv6 routing, something that somehow wasn't included in the official firmware.
All of these devices claim to support IPv6 and technically they do, so shopping for decent hardware quickly becomes a minefield. Seems to me like consumer hardware has better IPv6 support than the supposedly professional tiers.
IPv4 isn't going anywhere soon. I live in a country with 80 million people and a very Internet-using population, yet no ISPs currently offer IPv6, and I'm sure there are many more similar countries.
I got curious, and there are only three countries with around 80M population: Iran, Turkey, and Germany. If I had to guess by username, I'd bet Turkey :)
I lived in Russia and used HE tunnel for IPv6 in my home network for several (10?) years. With endpoint in London.
Then I've moved to the Netherlands, and I'm privileged enough to take all my network equipment with me.
I setup same tunnel in the Netherlands. And now I'm in Russia again. I mean, all sites who support IPv6 and bother to detect country, think I'm in Russia. As result, I got lot of bans ("This site is configured to reject requests from your country"), additional CAPTCHAs, refused orders in internet shops ("Your delivery address is XXXX km from your IP address), etc.
I need to remove this tunnel and "order" the fresh one. It is so frustrating.
I went on holiday to Germany for one week and left the VPN to my home network on. When I came back, I had to wait two weeks before Google believed that I was no longer in Germany. The language settings were easy to change, but the "this content is not available in your country" message that Youtube seems to default to in Germany was rather annoying.
Google was actually reasonably quick. I've had to deal with GeoIP providers marking an eastern European IPv4 block sold to a Dutch ISP which took months, and I think a few services still think that block belongs to some Ukranian ISP.
If you update your HE information, the GeoIP databases will update too, but it can take a while. Every site admin that manually downloads their GeoIP database needs to update theirs before you can visit your site.
This is also a lesson to web admins: if you're going to use GeoIP databases for country blacklisting, update them often. Unless you've containered yourself to hell, your OS distro probably automatically distributes databases in some form.
I think if you update your address and country in your HE account it will also update the geolocation of your ipv6 range, although i do not know how long it takes, especially since it is dependent on the different geolocation services themselves
I also experienced this in the US. My service provider does not provide IPv6, so I used HE's tunnels. Even though it's v4 under the hood, I wanted to see what the illusion of v6 felt like.
I turned it off after a few days because of the same side-effects that you mention.
I am surprised. I guess, even with an an address space so wide that you can almost randomly choose one that is free, websites are still able to identify certain types of actors. I'd imagine that the heuristic is more of an allowlist in IPv6, versus a blocklist in IPv4.
I can't use IPv6 as my ISP (Gigaclear) has an issue where the ISP side routers crash if you enable it.
When doing network troubleshooting they will try and get you to factory reset the home router they gave you, which enables IPv6 and bricks their end and has to get escalated.
But they provide fibre to the premises and aren't supporting BT, so it's not all bad.
> which enables IPv6 and bricks their end and has to get escalated.
So do they have to order new routers every time you do this? Hopefully after you have destroyed all of their routers, they will eventually buy new ones that are actually compatible with IPv6 so just keep doing it. /s
First step of activating any VPN app on Linux: Disabling IPV6... If you don't and just WireGuard towards a ProtonVPN or MullVad exit-node, you'll find that your IPv6 address is nicely un-VPN-ed, and only via IPv4 does your location show you're accessing the internet from the other side of the world.
That was pretty annoying when I first realized that and I have since then fallen back on using the apps of the VPN providers to automate disabling IPv6.
The apps I experienced are meh in quality. They are slow and mess with existing WG connections. Although that is probably what you want. I find the TailScale/Mullvad solution to be particularly elegant and would prefer Proton to offer the same so I can haz access to Home Assistant AND download Linux ISOs.
Mullvad supports IPv6: https://mullvad.net/en/blog/ipv6-support
Seems like ProtonVPN is at least ten years behind Mullvad on this. I'd expect better from a company like Proton to be honest, if any company should know how do to networking it's a VPN company.
Of course your config files do need to apply the routing rules for IPv6 or you'll still leak traffic, but that's a configuration issue and not really a VPN issue.
WireGuard will only forward traffic with dst IPs that match the AllowedIPs setting, if it only has 0.0.0.0/0 and no IPv6 entry, it won't send IPv6 traffic through the tunnel, did your configuration have the IPv6 address there?
A failsafe method is to create a vlan with a gateway that is the VPN. Using Linux routing tables, the vlan device routes to the wgX as the gateway. If the VPN app dies, there isn't a route to the internet for hosts on the vlan.
As far as IPv6 is concerned, there is no entry in the routing tables so IPv6 packets can't leave the network.
I don't really get the point driving attempts to disable IPv4 entirely. Companies like Github and Steam are too shit to add a few AAAA records, so you need to layer hacks upon hacks to make things work.
At that point, just use dual stack, even if it's just CG-NAT. Yeah, it's pretty shit and you get CAPTCHAs out the ass whenever you hit an IPv4 website but at least shit hardware like the Switch will just work. Same with the IoT garbage that couldn't be bothered to spend the quarter of a cent on a megabyte of extra flash so they removed IPv6 supporter.
Let the shit hardware and software suffer from having to deal with NAT and save yourself the trouble. Network administrators around the world decided that they didn't like IPv6, don't bother to learn anything new, and pretend there is no IPv6, so take the easy way and placate them with the shitty NAT over NAT they'd much rather prefer.
I must admit I'm disappointed about the Deck, but I can't be too surprised given that the entire Valve server stack seems to be IPv4 only.
> At that point, just use dual stack, even if it's just CG-NAT.
The motivating factor is the ability to turn off IPv4 within your own core network. For a large-ish ISP, running v6-only to all of your customers and having IPv4 to only a couple of points (your NAT64 gateway) can be attractive, assuming you generally know what you're doing and your CPE can do 464XLAT. This becomes _even_ more attractive when your network is too big for it to reasonably fit within 10.0.0.0/8 (very cell phone companies are in this boat).
For an end user in a home network, there is no practical benefit.
Using IPv6 on the backend is already something ISPs do in many CG-NAT scenarios. This is exactly what DS-Lite does, though that does require a CG-NAT termination solution (then again, if you're an ISP you probably have a box that supports doing that lying around somewhere anyway).
For new networks larger than 10/8 going IPv6 native makes sense I suppose, but for existing networks I'd expect migrations to move towards DS-Lite and similar techniques rather than 464XLAT; it's a less messy solution, and from what I can tell it's also more often present in CPEs.
> Companies like Github and Steam are too shit to add a few AAAA records
Yeah, it's... it's not that. Github has talked about it being difficult because their whole stack expects v4 and IIRC is doing some sort of IP reputation/rate-limiting system. I don't know specifically about Steam but I'd be shocked if they aren't even more invested in reputation systems that are built around v4 addresses. Now to be clear, I agree that both of them should do the engineering work to support IPv6 (dual-stack and single), but claiming it's just a matter of adding AAAA records is wrong.
It's 2024, you should be blocking GitHub (and, arguably, Steam) anyway. And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect).
The issue with trying to run dual-stack is that now you have to learn two kinds of networking, and all the extra complexity (which is actually more than 2x, complexity doesn't scale linearly), which matters since mistakes here can easily become security mistakes.
> And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect).
Well, no. If you have an IPv4 connection then the devices work, therefore they're not e-waste. If you make up a requirement to not use a still-functional technology and thus your gear breaks, that's a you problem.
Perhaps. If that happens, then such devices might become e-waste (assuming that it happens before they're updated, because this can all be fixed in software). But at least where I am I seriously doubt that'll happen anytime soon, to the point that such devices are somewhat likely to have died of natural causes before then anyways.
This blog won't load for me so I was wondering if it's because my isp doesn't support ipv6. But I turned on my vpn which does and it's still not loading so I guess it's the HN hug of death
I never understood the appeal of unifi for network gear... it's like an expensive pieces of technology that does less stuff than an average openwrt-based router ?
Except that Wayland actually increases security instead of doing the opposite. Ipv6 tends to diminish security of networks by defaulting to open access to all devices from the internet. Not the protocol's fault really but how it tends to be implemented.
> Ipv6 tends to diminish security of networks by defaulting to open access to all devices from the internet.
Approximately every device has at least one firewall between it and the internet. If you're getting "open access" it's because you went way out of your way to get it, regardless of IPv4/6
Thankfully, even though the Mastodon post that triggered this made the usual mistake of implying that disabling NAT results in "exposed" LAN devices (NAT has nothing to do with it, that's the firewall's job), the author of the article does not.
What does the Steam Deck's OS use for networking? If it's NetworkManager and NM has been configured to check an IPv4-only URL for connectivity (*), that might be the problem. Though of course, since Steam services themselves don't support v6 (as the author notes later), working v6-only network on the Deck won't help with playing games anyway.
(*): https://networkmanager.dev/docs/api/latest/NetworkManager.co... / https://wiki.archlinux.org/title/NetworkManager#Checking_con...
> disabling NAT results in "exposed" LAN devices
"In theory, theory and practice are the same. In practice, they are not."
NAT was used as a blocking method for all incoming connections for SOHO networks for decades.
It cannot work reliably, that's why Hole Punching is a thing.
If you don’t punch there’s no hole.
> If you don’t punch there’s no hole.
Good luck gaming then, or using BitTorrent (and probably other services). All consumer CPEs support PCP/UPnP for 'dynamic punching'.
And if the app in question doesn't use PCP/UPnP, then you have to stand up an entire STUN/TURN/ICE infrastructure.
Yes they all support punching holes, in fact, I’m punching holes right now, otherwise I won’t be able to reply. But if you don’t punch, then there’s no hole.
Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
No, Hole Punching is a thing precisely because it (the blocking method) works reliably. A NAT router drops all inbound connections by default because it doesn't know where to route them. This reliably protects devices on your network, because no inbound connections ever reach them.
If those applications want to be reached over the network, they can use Hole Punching to turn what would otherwise be an inbound connection into an outbound one. But that requires an effort on both ends of the conversation: if I want a remote client with IP 1.2.3.4 to connect to my server that's behind a NAT, then my server first needs to send a packet to 1.2.3.4. (That's the hole that's punched.) But that doesn't change anything about the reliability of the NAT's protection, because other clients on the internet still can't reach my server. If 1.2.3.4 is not malicious, then nothing bad can happen here. If 1.2.3.4 is malicious, then I was already in trouble when I punched the hole in the NAT, before an inbound connection from 1.2.3.4 even arrives - simply because I created an outgoing connection to 1.2.3.4, over which they could have sent me exploits anyway.
I know you know all of this, but I wanted to add some context to your misleading and pedantic comment for other readers of this thread.
"Applications" including malicious javascript in your browser.
It's enough to keep the Shodan skiddies at bay. I distinctly 'member the modem/ISDN era and trolls shooting off unpatched machines of other gamers. In ye olde days remote RCE exploits were a regular issue...
I hate to be that guy, but: there is no 'deny' action in NAT.
Resist the urge to be that guy. There actually is a deny: it’s what your NAT system does when an incoming packet doesn’t match a connection initiated by a device behind it.
Trying to be pedantic about this isn’t adding anything to the conversation – people have been trying to make this seem like a useful distinction for decades but it’s never worked because anyone who cares about security is focused on “can an attacker initiate a connection to my system?” rather than “did I lovingly handcraft the packet filtering rule which dropped their attempt?”
NAT essentially has a "default deny" rule.
Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem). Assuming the firewall is configured correctly in the first place, which is by no means guaranteed in consumer/SOHO settings.
> Having a publicly routable address absolutely does “expose” your network, which at the very least has the potential to generate load on your firewall (your problem) that would otherwise be absorbed by the NAT device (your ISP’s problem).
How is one your problem and the other your ISP's?
In both cases the bits are coming down your connection and hitting the CPE. Whether the CPE does only SPI firewalling or SPIFW+NAT seems to be irrelevant to me, as the same thing happens: packet's header tuple is examined, a state table is looked at, and the packet is passed or dropped depending on the contents.
I’m talking about CGNAT, where the bits do not enter your premises.
I don't know about your network, but for me that NAT device is sat on my network and so very much my problem :D
"NAT Device" = "Firewall" (in this context) = "What you'd normally have with a public address plus the translation part".
There tends to be conflation that somehow you need an additional device to filter you've not had in place before. In order to do NAT a device has to be at the edge of your network (your device or the ISPs) which tracks connection states to automatically translate outbound ones and allow the reverse mappings through while that is open. Getting rid of NAT simply means dropping the "translate" part from that device. The conntrack and allow outbound initiated connection part remains. Instead of port forwards for inbounds you just have inbound allows. There is no big swap of security roles between devices or special additional configuration needed, just the independent removal of the translation configuration from the device.
The NAT device itself also is a firewall and can enforce policies comparable to what NAT would do. I had the impression that this is the default behavior in 2024.
In my Fritz!Box, i have to configure IPv6 ports the same way i used to forward ports for IPv4.
Assuming CGNAT, sure, it is the ISPs problem. But that just underscores the utility of IPv6 where defective CGNAT results in a hair pulling experience for the customer. Things don't get forwarded, and there isn't a thing you can do about it except call the ISP (provided you were able to troubleshoot it to that point in the first place).
If NAT is done on the router, then it gets to make a decision on every packet regardless.
While technically true I think with Nat enabled it disables access from the Internet by default even if a firewall is misconfigured.
If your firewall is disabled, an incoming v4 packet on the WAN interface with destination IP = a NAT'ed LAN device's address like 192.168.1.2 could cross over to the LAN interface and reach said LAN device. It is the firewall's job to filter such bogons.
How would the package get routed my way unless the attacker hooked up right outside my network?
You've answered your own question.
Such a rare occurrence.
Nat alone doesn’t protect you from 100% of threats. Neither does a firewall btw.
But it does add an extra layer of safety.
In what realistic scenario would a regular individual need to worry about such a threat scenario?
Just by sending the packet.
That's essentially how NAT hole punching works. It doesn't work on all routers, but most do just route the packet. You just need to know the exact configuration of the network and send the correct packet through a valid port and it goes through
https://en.m.wikipedia.org/wiki/Hole_punching_(networking)
Having implemented a commercial hole punching mechanism, and having tested it on home and commercial deployments (various UK and USA ISPs), I have to agree.
For most deployments (home and commercial) the NAT function (its session table) employs Endpoint Independent Mapping, and Endpoint Independent Filtering (see BEHAVE RFCs).
As such once something behind the NAT (say at IP:Port) has connected to an external node, any external node can connect back to that internal IP:Port location by targeting packets at the public IP':Port' mapping. This applies even if the node behind the NAT was not expecting, nor desiring it.
For home deployments, there is generally no additional firewall.
For commercial deployments, there is usually a firewall working in an Endpoint Dependent Filtering manner (usually full 5-tuple, Port and Address Dependent Filtering).
This additional firewall blocks off the unexpected connection allowed by the home scenario above, but still allows for hole punching if the behind NAT node(s) can coordinate punching via a third party to exchange their public mappings.
Notably in the home deployment case, if the attacker is working with known public ports and addresses (i.e. itself being none NATted), then it can easily bypass the filtering logic of the home NAT once it learns of the existence of the 5-tuple public flow from the home NAT.
But even if the attacker knows the 5-tuple (which is a big if), how would they send a package with the correct headers? Pretty much every ISP firewall will just drop your packages if you send them with a source IP that's not yours.
Note that if you can fake source IP addresses, then a proper firewall won't protect anymore either, because all rules of the form "allow inbound connections from 1.2.3.4 only" are now broken.
IP packets originating from or addressed to a private IP address cannot be routed through the public Internet.
But no package would ever make it back as none would be sent to the gateway and even then the gateway would send it to the local network.
Just checked my Steamdeck and from the kde desktop settings ipv6 was entirely disabled. I just re-enabled ipv6 to let it auto configure an address and got ipv6 connectivity.
> usual mistake of implying that disabling NAT results in "exposed" LAN devices (NAT has nothing to do with it, that's the firewall's job)
However technically correct from a certain point of view you may be, I was supporting home users for a small ISP in the very early 2000s and you’re wrong in any way that matters. In practice NAT on its own made remote attacks on home networked devices far harder.
NAT didn't make remote attacks harder, the default inbound deny rule did. NAT is not the firewall itself, it's just one of the things the firewall can do. Telephone companies are also ISPs, and they are and continue to be quite inept when it comes to securing their own networks, so NAT without a default inbound deny rule is not secure.
This matters in a very meaningful way. Have you seen how many enterprising but clueless consumers click random buttons until whatever they are trying to do works? They often don't know or care about other ramifications until it's too late.
What benefits has ipv6 beside that ipv4 addresses for public servers are in short supply?
If you live in a country rich enough that every ISP customer gets a dedicated IPv4 address you won't see many of the downsides of deploying IPv4 these days. If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly. Even in rich countries, CG-NAT is starting to get used more and more as prices for IP ranges go up. CGNAT also affects people trying to do something silly like "open a port" for a Minecraft server or a VPN back home, which is impossible without a public address.
Outside of CGNAT, just about any protocol works better without standard IPv4 NAT. Xbox and PlayStation have invented their own terminology (what the fuck is a "type 2 NAT" anyway) and have written custom code to work around the different ways in which NAT fucks up your connection. Linux and BSD based routers will do deep packet inspection to figure out if you're trying to do FTP or SIP or H363 and rewrite traffic on the fly while opening holes in the firewall just so you can use basic internet functionality. This has also led to an attack dubbed "NAT slipstreaming" where generations of routers will allow Javascript running in your browser to open any port on your device to the outside, or even any port on any device in your network, despite what your router's firewall may say.
For larger networks (with more than ±250 devices), you get a working connection without having to figure out what a DHCP pool is.
And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.
In Germany, the TV-cable based ISP all have started deploying CGNAT.
If you live in a densely populated area with many Vodafone customers, their CGNAT gateways tend to be overloaded, so in peak hours you sometimes experience packet loss.
Of course Vodafone won't admit that it's a structural problem instead of isolated cases.
At one point, I was forced to use a shitty DSL provider, "e-on highspeed" (formerly "Innogy") because they had exclusive rights to the VDSL DSLAM in my area. For a while, they didn't even offer IPv6 alongside the CGNAT v4. And when they did, it broke randomly (remote gateway dead).
By the way, does anybody have a clue on how to get SLAAC addresses into local DNS? I can't create static records because my current ISP keeps changing my assigned prefix. I'm still on v4 for my local fileservers and stuff like that because of this problem.
> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?
As others have mentioned, ULA is one option.
> I can't create static records because my current ISP keeps changing my assigned prefix. I'm still on v4 for my local fileservers and stuff like that because of this problem.
Perhaps worth looking at:
* "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events", https://datatracker.ietf.org/doc/html/rfc8978
* "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-...
The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA. It sucks having to use NAT with IPv6, but at least it'll be stateless NAT. Then when your delegated prefix changes you will only need to update the NAT rule, meanwhile everything within your LAN that was using ULA-prefixed addresses to talk to each other will continue working.
For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS, and memorize them in the worst case.
> The easiest way is to use a ULA on the LAN side instead of the ISP-assigned prefix, and set up NAT66 at the router to convert delegated prefix <-> ULA.
You don't need to not use your ISP-assigned globally-routable prefixes. You can use both a ULA and a globally-routable prefix. In my years of experience with fully-functional IPv6 service, I've never noticed an address selection problem... machines always use the globally-routable address as the source for off-LAN communications and (because it's what's in my local DNS) the ULA address for on-LAN communications.
The single pitfall I've seen is if your ISP ever "shuts down" [0] that globally-routable prefix, and your border router isn't configured to reject traffic from fc00::/7 going out through the WAN interface, your border router will happily pass traffic out the WAN interface from your not-globally-routable ULA range.
> For my own homelab, I give all my machines and VMs static IPs instead of using SLAAC, which also makes it straightforward to register them in DNS...
I just configure my machines to use either MAC-based or DUID-based SLAAC address generation, rather than that stupid "privacy addressing" stuff.
[0] By this I mean by stopping advertising it, refusing to renew a DHCPv6-PD lease, or similar.
> does anybody have a clue on how to get SLAAC addresses into local DNS
I use an ULA for that (a private /48 that's not routable through the internet). I have a random server in my network (doesn't need to be a router) advertise it through radvd (though some routers also offer that ability). I then put the static address (not the random IPv6 privacy address) in local DNS. If you don't pick any "easy" ULAs, you can have multiple devices announce multiple ULAs on the same network and everything will keep working just fine (unlike multiple DHCP servers).
The benefit of an extra ULA inside your network is that you don't need to set up NAT or NAT66. The downside is that your ULA services won't be reachable from the outside. I solved that with a Wireguard VPN, but you may need something more complicated. You could consider using something like HE.net's free IPv6 ranges to add an extra prefix into your network that's reachable even when your prefix changes, but that needs some automation (and you want to configure it in a way that devices won't try to route to the internet over that prefix, or streaming services will stop working and your network will probably slow down a bit).
I used https://it.jason.tools/ipv6-ula-generator to generate a random enough ULA, then put this into my /etc/radvd.conf:
Maybe some of those timeouts aren't correct, I don't know for sure, but this seems to work fine for me. The RDNSS entry is for automatically assigning a DNS server, that's optional as well of course.Alternatively, using mDNS also works more often than you'd expect, either over IPv4 or IPv6. Try `yournashostname.local` and you may just find it works out of the box. If it doesn't, you can probably install avahi-daemon on there to make it work.
> By the way, does anybody have a clue on how to get SLAAC addresses into local DNS?
The main difference between v4 and v6 (which reaaally trips v4 entrenched folks) what it's absolutely normal to have dozens of different addresses on the interface.
As other said, just pick your own ULA subnet and use addresses from it.
> And lastly, while this will probably differ by ISP, my experience is that IPv6 has significantly less latency than IPv4, on the order of 4ms versus 20ms.
I feel like <random big game> could have killed IPv4 ten years ago if they had just introduced this sort of latency difference.
> If you don't, you'll get tired of Cloudflare's "checking if your connection is secure" becomes pretty tiring pretty quickly.
Is this really related? I'm on IPv4 and get these "checking if your connection is secure" all the time as well. I think that this is unrelated to CG-NAT, because, after all, Cloudflare does mostly use the browser's properties to determine if a manual check should be done (click the button...).
> Cloudflare does mostly use the browser's properties to determine if a manual check should be done
Cloudflare uses the threat score of each IP address as a signal to determine whether additional checks are necessary. A shared IP address is more likely to be associated with "issues", such as a compromised IoT device being used for DDoS attacks, one of your neighbours spamming a forum, ...
How is it not a GDPR violation? Before I've even connected to the site I intended and had the opportunity to consent, an IP address that potentially uniquely identifies me (plus whatever else) is shared with a third-party data processor?
How would it work with IP/Internet at all? Doesn't matter if the site is hosted in Cloudflare, aws or random datacenter.
There is generally exceptions for anti-abuse/spam to some of the provisions of GDPR and the like.
That said, is there really any 3rd party here? You are connecting to cloudflare and they are the ones that have seen this IP before and judging its behavior.
> What benefits has ipv6 beside that ipv4 addresses for public servers are in short supply?
What more benefits do you need?
It's a major issue for many folks, especially if you (a) didn't manage to get in early on the IPv4 land rush, or (b) aren't a mega-corp with money to buy a whole bunch of addresses:
> Our [American Indian] tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
* https://community.roku.com/t5/Features-settings-updates/It-s...
* https://news.ycombinator.com/item?id=35047624
Do you think we'd have as much mobile/smartphone connectivity without IPv6? T-Mobile US went to IPv6-only on handsets because of exhaustion, and they're only one carrier (in the US).
Really easy prefix delegations on consumer/small business links without configuration.
End-to-end connectivity, rather than having to think at all about what will one day be a "public server."
Avoiding of crummy CGNAT.
No more collisions between private addresses when a company is acquired or networks otherwise merge.
Avoiding most of the annoyances of DHCP.
There's more, but these are the ones that really resonate with me.
Cost. IPv4 is so expensive to support that one ISP out there is literally giving people Apple TVs with IPv6 support to replace IPv4-only Roku devices https://daringfireball.net/linked/2023/03/06/roku-apple-tv
On Spectrum and AT&T in the U.S. I tend to see a little better latency, on average, on IPv6 (2-4ms). Not sure the exact reason
Little for a typical web client, but p2p connection setup in theory should get better in a world with less NATs.
No need to pay Big Tech to do anything like videochat.
I wonder if we could have just done something simple like add a block to ipv4? Like 255.255.255.255.255
No, too much software and hardware relies on fitting the IP address into 32 bits. That means the only way to increase the number of addresses is in a way a clean break, so we might as well increase the number to a ludicrous size, far beyond what we can imagine practically exceeding, like IPv6's 128 bits.
IP packets are like a C struct that only have 4 bytes allocated per address. If you want to have more space, you need to change that struct, and that's what IPv6 does. Together with a new Ethertype so the different structs can be reliably differentiated.
My personal opinion is to skip dns64 in the transition path and instead rely on clat completely. The intersection of devices that support op108 but don't have clat is pretty small, so you are not really gaining much with dns64 imho.
It is noteworthy that there are many ways to accompish the sort of ipv4 service that nat64 does. I believe map-t/map-e and lw4o6 are the main contenders these days. In theory at least I don't see why you couldn't do clat style thing with those too. The main advantage of these newer technologies is that they allow service provider side to be stateless, whereas naive nat64 requires similar stateful connection tracking as traditional nat44 (=plain ipv4 nat).
RFC 9313 has really good information about this https://www.rfc-editor.org/rfc/rfc9313.html
For those if us who do want to run our own NAT64 box, is there a decent Linux option these days? Last time I looked, your options were variations on "this isn't packaged so just compile this source tarball and feed it this non-obvious config"... or OpenBSD which just treats it as a first-class option in pf(?) exactly like nat44. (And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...)
It's pretty straightforward. On the router (assuming a recent Debian-based distro):
On a box behind the NAT: If you want DNS64, 1.1.1.1 and 8.8.8.8 offer 2606:4700:4700::64 and 2001:4860:4860::6464 respectively or you can configure unbound pretty easily.It's the argument to --resolve, not the desired URL.
I looked right past `--resolve`, so yes that now makes sense.
> And yes I'm tempted, but adding an OpenBSD router is a sharper learning curve...
If you decide to try OpenBSD I hope you will enjoy it! I personally find it easier to understand and configure than Linux, but I could be biased.
I haven't tried NAT64 on a Linux router, so I can't say authoritatively.
I did a similar experiment as the submitted article back in 2020, though that was on a pfSense (FreeBSD) router, not Linux. I used tayga for NAT64 there, which was last released in 2010, but it probably still works on modern Linux. At the very least it's still packaged in Debian.
Someone has made a NAT64 implementation using eBPF, though with quite some caveats: https://github.com/xdp-project/bpf-examples/tree/master/nat6...
The nat64/clat situation on Linux is not brilliant at the moment. There are userspace implementations like Tayga and Tundra. These incur kernel-userspace-kernel transition for each packet so are pretty inefficient and struggle unnecessarily on low-end hardware.
Then there are out-of-tree modules of varying quality, none of those I've looked at being amazingly inspiring code-wise. As out-of-tree modules, they'd need to be rebuilt whenever you rebuild your kernel, but would inconveniently not be built as part of that kernel unless you patch them in.
I'd not seen the eBPF implementation before. That's quite a nice idea. Quite tempted to have a hack at that to fix the minor issues the author identifies.
(What's the story with building eBPF programs nowadays? Are there all kinds of crazy dependencies, or is the situation better than it used to be?)
So tayga was the tool that I came the closest to using last time I looked at this, but rereading http://www.litech.org/tayga/ I still don't really follow the configuration (yes I know it's a skill issue but nat44 wasn't this hard), the tun device is... I guess it should be fine, but I don't like needing it, and the whole thing looks very manual (I'd bet that doesn't persist after a reboot) though I guess I should see if someone's packaged up a nice systemd unit that makes it all work.
The eBPF one is very interesting and does seem to work the way I expect NAT to work (no extra interfaces, just rewriting packets as they come and go), but is 1. unfinished by its own description, and 2. again a 3rd-party code drop that I'd have to package and ship myself if I wanted to use it. And I can do that, but I really don't like my routers to need fiddling.
At the rate it's going, IPv6 should be ready for prime time around the same time we have nuclear fusion power plants and real self-driving cars that don't rely on a human driver.
> At the rate it's going, IPv6 should be ready […]
It's ready now. T-Mobile US is IPv6-only on handsets, as are many other carriers:
* https://www.youtube.com/watch?v=nNMNglk_CvE
Microsoft went towards IPv6-only in corporate networks so that their IPv4 address could be moved to Azure to generate revenue:
* https://www.arin.net/blog/2019/04/03/microsoft-works-toward-...
See also Google and their offices:
* https://www.youtube.com/watch?v=hb98hAb5_W8
Facebook/Meta is IPv6-only in their DCs:
* https://www.youtube.com/watch?v=IKYw7JlyAQQ
According to Google, the US and UK is half IPv6 (France and Germany are >75%):
* https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
> nuclear fusion power plants and real self-driving cars that don't rely on a human driver.
I think both of these are much closer to reality than IPv6 adoption.
Well, it did go from single digits in 2014 to 40-something percent adoption in 2024. Who knows where a tipping point is, though, or the emergence of more utility for it.
https://www.google.com/intl/en/ipv6/statistics.html
Something to consider about those statistics is that they don't include mainland China's massive IPv6 adoption, because the great firewall of China isn't going to "just" let you use Google. The Chinese government is actively pushing ISPs to deploy IPv6 to the point where [it's banning IPv4 NAT devices starting next year](https://www.lightreading.com/regulatory-politics/china-direc...). If you do see traffic from mainland China, it'll probably be through a VPN, and VPNs tend to be IPv4-only.
Most companies and servers probably won't care about Chinese visitors, but that still comes down to 763 million internet users that don't show up in the IPv6 statistics for companies like Google.
I was surprised to learn from the submitted article that Discord and Reddit also don't support v6, because those two ought to have a large mobile phone userbase, and mobile networks are the biggest cases of publicly routable v6 addresses and CGNAT for v4.
Reddit is an odd half mix. It seems like most everything they have is dual stack, including the CDN and "reddit.com"... but the "www.reddit.com" page you get redirected to is itself IPv4 only (and maybe some authentication endpoints or something, I haven't looked lately). They'll probably get there shortly.
Discord is an interesting one. On GitHub they've more or less straight out said "we built our backend with a bunch of hardcoded ipv4 addresses and logic and it hasn't been a priority to go back and fix vs build out the app".
Depends where, though. Here in Switzerland I think that only one of the three main mobile operators (Swisscom) has IPv6 on their networks (and it's a 2024 thing, so not even sure it's already reaching all customers).
Indeed. Here in New Zealand none of the mobile carriers have deployed IPv6 on mobile (and there are apparently no plans to do so) so we are at 0% for Mobile IPv6. Meanwhile all except one of the major fixed line carriers have IPv6. I don't have % figure but I would estimate >50% of fixed line connections here have IPv6 enabled (at least at the provider's end).
Interesting, I had IPv6 on a “beta” Swisscom in 2016 or so. Crazy that it's taken them to long to productionalize it.
AWS provides a dual stack option that lets you run ipv4 and ipv6 simultaneously. We used it to help aid in a mostly uneventful migration over to ipv6 for most of our applications
I've been trying to go IPv6 in my network for several years, but it is really impossible. My ISP (Movistar, one of the big ones in Spain) does not enable it on its fiber network, although there is a beta program that does not allow new joins.
I've obviously configured HE's Tunnelbroker, and technically it works great. The downside is that their closest tunnel endpoint is in Paris and then all the usual web services identify my traffic as VPN/proxied/bot and it makes a constant flow of captcha solving requests or directly service refusal.
Adding to that, my wife cannot work from home, as the VPN her company uses fails when on IPv6.
If nothing big and dramatic happens in the close future, we'll be on IPv4 beyond my retirement.
Unfortunately, there’s just not a driving business force to do it.
The 2030 flag day for ipv4 is just a dream.
The business case is that networks are getting better but NAT hardware isn't keeping up. Dual-stack users are increasingly likely to have a good v6 connection and very marginal v4, and just abandoning v4 support entirely lets you stop caring about that.
It hasn’t arrived yet but the trend is there and the cutoff point exists.
It's not enough to be dual-stack, happy eyeballs only really handles the broken v6/good v4 case and is too eager to fall back to a broken but minimally functional v4. You have to run v6-only services to not pay the NAT tax.
> The business case is that networks are getting better but NAT hardware isn't keeping up.
Network improvements are not distributed evenly. Most US broadband users are still on ADSL or DOCSIS and I would guess most use the cheapest (and slowest) available plan. With bandwidth per user being stagnant for years they don't need to upgrade CGNAT hardware (if they use it). Wireless providers grow faster and they are adopting IPv6.
But there is another side - server operators have much less reasons to adopt IPv6 than wireless/broadband ISP. Many high traffic sites are IPv4 only and I don't think they are loosing money because of this.
> Most US broadband users are still on ADSL or DOCSIS
... VDSL (ie up to 100Mbit), surely? I can't imagine there are many ADSL (ie up to, at most, 24Mbit) users left.
Yes VDSL likely is more common nowadays but in publicly available stats they are counted together so better to call it xDSL or just DSL. E. g. https://www.fcc.gov/reports-research/reports/measuring-broad... talks about DSL and DLS speeds not that high.
Odd that they lump them together; they're related, certainly, but _used_ very differently (in practice, VDSL is nearly always FTTC, ADSL tends to be fibre to the exchange). If an ISP offered me VDSL, well, I wouldn't be thrilled, but it would be usable. If they offered me ADSL I'd be wondering if I'd accidentally stepped back in time a decade or so. Based on the figures above, though, looks like there actually _is_ still a good bit of ADSL in use in the US!
Available IPv4 address space running out in many regions of the world seems like a good business case.
"running out" in practice means "getting more expensive", as many entities who own (unnecessarily) large swaths of the IPv4 space are reselling them.
In practice it also means literally running out since there are less IPv4 addresses than there are people (and much less computers that might want to connect to the Internet).
The people who would truly benefit from it have already switched. What's left is mostly either people who aren't even aware it exists (like home users), or admins of small/medium-sized networks who are either scared of change, or have a budget which is barely large enough to keep the lights on.
This can also be because they bought hardware from a bad vendor, like Ubiquity, which used to support IPv6… in software routing only giving it a max throughput of something like 50mbps on their small business/prosumer hardware. There are also routers by brands like Microtik that have garbage IPv6 throughput unless you flash OpenWRT which packages the driver that enables hardware IPv6 routing, something that somehow wasn't included in the official firmware.
All of these devices claim to support IPv6 and technically they do, so shopping for decent hardware quickly becomes a minefield. Seems to me like consumer hardware has better IPv6 support than the supposedly professional tiers.
IPv4 isn't going anywhere soon. I live in a country with 80 million people and a very Internet-using population, yet no ISPs currently offer IPv6, and I'm sure there are many more similar countries.
I wish I could use it though.
Which country?
I got curious, and there are only three countries with around 80M population: Iran, Turkey, and Germany. If I had to guess by username, I'd bet Turkey :)
I have interesting experience with IPv6.
I lived in Russia and used HE tunnel for IPv6 in my home network for several (10?) years. With endpoint in London.
Then I've moved to the Netherlands, and I'm privileged enough to take all my network equipment with me.
I setup same tunnel in the Netherlands. And now I'm in Russia again. I mean, all sites who support IPv6 and bother to detect country, think I'm in Russia. As result, I got lot of bans ("This site is configured to reject requests from your country"), additional CAPTCHAs, refused orders in internet shops ("Your delivery address is XXXX km from your IP address), etc.
I need to remove this tunnel and "order" the fresh one. It is so frustrating.
I went on holiday to Germany for one week and left the VPN to my home network on. When I came back, I had to wait two weeks before Google believed that I was no longer in Germany. The language settings were easy to change, but the "this content is not available in your country" message that Youtube seems to default to in Germany was rather annoying.
Google was actually reasonably quick. I've had to deal with GeoIP providers marking an eastern European IPv4 block sold to a Dutch ISP which took months, and I think a few services still think that block belongs to some Ukranian ISP.
If you update your HE information, the GeoIP databases will update too, but it can take a while. Every site admin that manually downloads their GeoIP database needs to update theirs before you can visit your site.
This is also a lesson to web admins: if you're going to use GeoIP databases for country blacklisting, update them often. Unless you've containered yourself to hell, your OS distro probably automatically distributes databases in some form.
I think if you update your address and country in your HE account it will also update the geolocation of your ipv6 range, although i do not know how long it takes, especially since it is dependent on the different geolocation services themselves
Nope, it is behavior-based, this address range doesn't have any special geolocation, it is assigned to HE and it's all.
I also experienced this in the US. My service provider does not provide IPv6, so I used HE's tunnels. Even though it's v4 under the hood, I wanted to see what the illusion of v6 felt like.
I turned it off after a few days because of the same side-effects that you mention.
I am surprised. I guess, even with an an address space so wide that you can almost randomly choose one that is free, websites are still able to identify certain types of actors. I'd imagine that the heuristic is more of an allowlist in IPv6, versus a blocklist in IPv4.
I can't use IPv6 as my ISP (Gigaclear) has an issue where the ISP side routers crash if you enable it.
When doing network troubleshooting they will try and get you to factory reset the home router they gave you, which enables IPv6 and bricks their end and has to get escalated.
But they provide fibre to the premises and aren't supporting BT, so it's not all bad.
> which enables IPv6 and bricks their end and has to get escalated.
So do they have to order new routers every time you do this? Hopefully after you have destroyed all of their routers, they will eventually buy new ones that are actually compatible with IPv6 so just keep doing it. /s
First step of activating any VPN app on Linux: Disabling IPV6... If you don't and just WireGuard towards a ProtonVPN or MullVad exit-node, you'll find that your IPv6 address is nicely un-VPN-ed, and only via IPv4 does your location show you're accessing the internet from the other side of the world.
That was pretty annoying when I first realized that and I have since then fallen back on using the apps of the VPN providers to automate disabling IPv6.
The apps I experienced are meh in quality. They are slow and mess with existing WG connections. Although that is probably what you want. I find the TailScale/Mullvad solution to be particularly elegant and would prefer Proton to offer the same so I can haz access to Home Assistant AND download Linux ISOs.
Mullvad supports IPv6: https://mullvad.net/en/blog/ipv6-support Seems like ProtonVPN is at least ten years behind Mullvad on this. I'd expect better from a company like Proton to be honest, if any company should know how do to networking it's a VPN company.
Of course your config files do need to apply the routing rules for IPv6 or you'll still leak traffic, but that's a configuration issue and not really a VPN issue.
WireGuard will only forward traffic with dst IPs that match the AllowedIPs setting, if it only has 0.0.0.0/0 and no IPv6 entry, it won't send IPv6 traffic through the tunnel, did your configuration have the IPv6 address there?
A failsafe method is to create a vlan with a gateway that is the VPN. Using Linux routing tables, the vlan device routes to the wgX as the gateway. If the VPN app dies, there isn't a route to the internet for hosts on the vlan.
As far as IPv6 is concerned, there is no entry in the routing tables so IPv6 packets can't leave the network.
I don't really get the point driving attempts to disable IPv4 entirely. Companies like Github and Steam are too shit to add a few AAAA records, so you need to layer hacks upon hacks to make things work.
At that point, just use dual stack, even if it's just CG-NAT. Yeah, it's pretty shit and you get CAPTCHAs out the ass whenever you hit an IPv4 website but at least shit hardware like the Switch will just work. Same with the IoT garbage that couldn't be bothered to spend the quarter of a cent on a megabyte of extra flash so they removed IPv6 supporter.
Let the shit hardware and software suffer from having to deal with NAT and save yourself the trouble. Network administrators around the world decided that they didn't like IPv6, don't bother to learn anything new, and pretend there is no IPv6, so take the easy way and placate them with the shitty NAT over NAT they'd much rather prefer.
I must admit I'm disappointed about the Deck, but I can't be too surprised given that the entire Valve server stack seems to be IPv4 only.
> At that point, just use dual stack, even if it's just CG-NAT.
The motivating factor is the ability to turn off IPv4 within your own core network. For a large-ish ISP, running v6-only to all of your customers and having IPv4 to only a couple of points (your NAT64 gateway) can be attractive, assuming you generally know what you're doing and your CPE can do 464XLAT. This becomes _even_ more attractive when your network is too big for it to reasonably fit within 10.0.0.0/8 (very cell phone companies are in this boat).
For an end user in a home network, there is no practical benefit.
Using IPv6 on the backend is already something ISPs do in many CG-NAT scenarios. This is exactly what DS-Lite does, though that does require a CG-NAT termination solution (then again, if you're an ISP you probably have a box that supports doing that lying around somewhere anyway).
For new networks larger than 10/8 going IPv6 native makes sense I suppose, but for existing networks I'd expect migrations to move towards DS-Lite and similar techniques rather than 464XLAT; it's a less messy solution, and from what I can tell it's also more often present in CPEs.
The big difference is whether the CLAT part is in the CPE or in the endpoints, right?
> Companies like Github and Steam are too shit to add a few AAAA records
Yeah, it's... it's not that. Github has talked about it being difficult because their whole stack expects v4 and IIRC is doing some sort of IP reputation/rate-limiting system. I don't know specifically about Steam but I'd be shocked if they aren't even more invested in reputation systems that are built around v4 addresses. Now to be clear, I agree that both of them should do the engineering work to support IPv6 (dual-stack and single), but claiming it's just a matter of adding AAAA records is wrong.
It's 2024, you should be blocking GitHub (and, arguably, Steam) anyway. And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect).
The issue with trying to run dual-stack is that now you have to learn two kinds of networking, and all the extra complexity (which is actually more than 2x, complexity doesn't scale linearly), which matters since mistakes here can easily become security mistakes.
> And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect).
Well, no. If you have an IPv4 connection then the devices work, therefore they're not e-waste. If you make up a requirement to not use a still-functional technology and thus your gear breaks, that's a you problem.
At some point you won't have an IPv4 connection, which I hear is already the case for some Asian ISPs.
Perhaps. If that happens, then such devices might become e-waste (assuming that it happens before they're updated, because this can all be fixed in software). But at least where I am I seriously doubt that'll happen anytime soon, to the point that such devices are somewhat likely to have died of natural causes before then anyways.
This blog won't load for me so I was wondering if it's because my isp doesn't support ipv6. But I turned on my vpn which does and it's still not loading so I guess it's the HN hug of death
AFAIK, it isn’t even possible/supported to disable IPv4 on UniFi routers.
Well. I can’t even get a ipv6 tunnel to work on my USG3 so I have little interest in disabling v4.
Didn’t try a tunnel but IPv6 works on my UDM, just not without IPv4. :)
I never understood the appeal of unifi for network gear... it's like an expensive pieces of technology that does less stuff than an average openwrt-based router ?
Don’t forget that because it’s proprietary you have no idea what it’s doing to you network.
Do the latest versions include a cloud service that exposes things like passwords to Unifi? Looks like that’s what Unifi Cloud is.
https://archive.is/9DXlm
Seems a bit hugged to death to me.
At least there's a path forward when IPv4 is truly causing us to regret its limited nature.
My isp filters all incoming ipv6 traffic for me and lets my outgoing ipv6 out. What could possibly go wrong?
[flagged]
This is purely a personal attack without making any argument.
Wouldn't advocating for ipv4 be more boomer-ish?
Never going to update to IPv6, you can't make me.
Okay then, that was always allowed.
The Wayland debate of networking
Except that Wayland actually increases security instead of doing the opposite. Ipv6 tends to diminish security of networks by defaulting to open access to all devices from the internet. Not the protocol's fault really but how it tends to be implemented.
> Ipv6 tends to diminish security of networks by defaulting to open access to all devices from the internet.
Approximately every device has at least one firewall between it and the internet. If you're getting "open access" it's because you went way out of your way to get it, regardless of IPv4/6