No NAT November: My month without IPv4
blog.infected.systems
blog.infected.systems
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...
"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.
And so have stateful/SPI firewalls,[1] and with those you don't need the convoluted rigamarole of STUN/TURN/ICE infrastructure: a whole class of technology that had to be invented to deal with NAT.
Meanwhile, if you have globally addressable (but not necessarily globally reachable) IPv6 on your clients all of that goes away, and it's just PCP [2][3] that's needed to hole punch on your CPE. Much less convoluted.
[1] https://en.wikipedia.org/wiki/Stateful_firewall
[2] https://en.wikipedia.org/wiki/Port_Control_Protocol
[3] https://en.wikipedia.org/wiki/Hole_punching_(networking)
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.
Your TCP stack is unlikely to accidentally punch port 3398 when you’re browsing hn.
That is not what is meant by "hole punching":
> Networked devices with public or globally accessible IP addresses can create connections between one another easily. Clients with private addresses may also easily connect to public servers, as long as the client behind a router or firewall initiates the connection. However, hole punching (or some other form of NAT traversal) is required to establish a direct connection between two clients that both reside behind different firewalls or routers that use network address translation (NAT).
* https://en.wikipedia.org/wiki/Hole_punching_(networking)
* https://en.wikipedia.org/wiki/Port_Control_Protocol
* https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...
That action creates a public side mapping on the NAT, being Proto/IP/Port - Proto generally being TCP or UDP.
While that mapping exists, any packet within that protocol, from any source address or port in the whole IPv4 Internet can be directed at that mapping, and received by the client computer.
Generally TCP syn's will be dropped by the client (unless they explicitly opened a fixed mapping, and are hence running a TCP server), but any UDP packet for an open UDP mapping will be received.
AFAIK, the various gaming programs tend to run over UDP...
The punching per-se is to coordinate between two clients, each behind NATs, and/or each behind actual firewalls (as opposed to the NAT filtering function).
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.
i.e. assume 192.168.0.1:4567 sends a packet to 12.13.14.15:25, creating a mapping, and keeping that mapping session active. Assume the public translation for that client is 5.6.7.8:7777
Now anyone, e.g. 23.24.25.26:7654 can send a packet to 5.6.7.8:7777 and it will be received by 192.168.0.1:4567.
That behaviour is what is relied upon in order to make the NAT hole punching work.
It is only 5-tuple stateful firewall punching (of ADPF NAT - which are uncommon) which require that the return packets come from a target punched first. Hence needing the coordinated punching from both sides to the public address:port mapping of the peer.
However, continue with your belief...
This is a new and unfamiliar term/acronym to me. It seems to be from RFC 7857, "Updates to Network Address Translation (NAT) Behavioral Requirements":
* https://datatracker.ietf.org/doc/html/rfc7857
People may be more familiar with the various "cone" NAT variation definitions:
So once the BEHAVE terms came out, I adopted them, as they were (at least to me) more obvious. They're also more flexible in that they can describe real behaviours which can not be mapped to "cone" terms.
It is the state tracking that does the protection, which you do not need NAT to do:
* https://en.wikipedia.org/wiki/Firewall_(computing)#Connectio...
* https://en.wikipedia.org/wiki/Stateful_firewall
And by getting rid of NAT, you also remove the need for the convoluted bullshit of STUN/TURN/ICE, and all you're left with is PCP:
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?”
If you don't have NAT:
- the packet with your IP in dst_ip would be thrown out
If you do have NAT:
- the packet with your IP in dst_ip would be thrown out
In both cases the decision to drop the packet were carried out by the firewall and not NAT.
So puh-lease, stop.
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.
In my Fritz!Box, i have to configure IPv6 ports the same way i used to forward ports for IPv4.
If NAT is done on the router, then it gets to make a decision on every packet regardless.
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.
Nat alone doesn’t protect you from 100% of threats. Neither does a firewall btw.
But it does add an extra layer of safety.
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
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.
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.
All an attacker needs to do is send packets from any source address and port, but using the same protocol (TCP/UDP) targeting that public 3-tuple, and the NAT box will allow the packet in.
I was not suggesting that the attacker resort to spoofing its source address, but use its real one. The attacker itself could be a zombie controlled by the real CnC entity, so mitigating against detection.
Finding the 3-tuple is the challenge, but not too great a one. One would start by seeing what info could be leaked from the public sites such NATed clients are connecting to.
Feel free to read that to broaden your horizon
> 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 ....
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.
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.
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.
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.
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.
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.
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:
interface vmbr1
{
AdvSendAdvert on;
AdvDefaultLifetime 0;
MinRtrAdvInterval 3;
MaxRtrAdvInterval 10;
prefix fdae:5594:90d5::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
RDNSS fdae:5594:90d5:0:215:5dff:fe01:d119 {
AdvRDNSSLifetime 3600;
};
};
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.
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 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.
I feel like <random big game> could have killed IPv4 ten years ago if they had just introduced this sort of latency difference.
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 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, ...
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.
Because from a user's perspective, my relationship is with news.ycombinator.com or whatever - I don't (have to) know or care if the site uses Cloudflare, that's some other company, maybe I haven't even heard of it or have any other relationship with it. But now it is a company that the one I knowingly have a relationship with is causing to be made aware of information which uniquely identifies me.
I didn't know there were anti-abuse/spam exceptions though, so I suppose that's it.
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.
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).
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
That still needs a gateway that can access IPv4 network, doesn’t it?
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-...
N=1 but T-Mobile US appears to be IPv6 enabled, not IPv6-only: https://i.imgur.com/ZPi398P.jpeg
"On handsets".
If you look at the HTML source of that page you'll see:
<p id="ipv4-head" class="public-ipv4-address">
My Public IPv4<!-- -->
:
<span id="ipv4">Detecting...</span>
</p>
</div>
<div class="ip-address-details-inline ip-address-ipv6">
<p id="ipv6-head" class="public-ipv6-address">
My Public IPv6<!-- -->
:
<span id="ipv6">Detecting...</span>
</p>
The "Detecting" is replaced by JavaScript (see "commons-[hash].js") that goes out and tries to hit some hostnames:
$ dig +short -t a api.whatismyip.com
34.117.39.86
$ dig +short -t aaaa api.whatismyip.com
$ dig +short -t a apiv6.whatismyip.com
$ dig +short -t aaaa apiv6.whatismyip.com
2600:1901:0:d110::
* https://www.internetsociety.org/deploy360/2014/case-study-t-...
The fact that some services on the Internet are (sadly) IPv4-only means they had to use a technology to allow connectivity, which is why you're seeing an IPv4 address: it's not on your handset but the translation box.
Also, I simply menion T-Mobile as one example, but given they have 32% marketshare in the US:
* https://www.statista.com/statistics/199359/market-share-of-w...
that means that one-third of all Americans with (smart)phones are using IPv6-only, without being allocated an IPv4 address, everyday: 125 million people.
Verizon Wireless has a similar situation:
> Verizon Wireless proactively deployed IPv6 even though they had an existing IPv4 network. Per reports, they had at least 70 internal instances of the same private address space, and found themselves spending effort and money on the resulting network complexity; IPv6 deployment was a solution that simplified their network and reduced the cost of operating it. Over 80% of traffic from Verizon Wireless to major online content providers now uses IPv6.
* https://www.internetsociety.org/resources/2018/state-of-ipv6...
They initially (2014) had private IPv4 addresses on handset and NAT44ed them: not sure what they're doing in 2024. So that's another ~125 million people.
250 million people using something daily would qualify as a thing being "ready" in my mind.
I think both of these are much closer to reality than IPv6 adoption.
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.
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".
mkdir /etc/jool
echo '{"instance":"nat64-minimal","framework":"netfilter","global":{"pool6":"64:ff9b::/96"}}' > /etc/jool/jool.conf
apt install jool-dkms jool-tools
curl --resolve one.one.one.one:443:64:ff9b::1.1.1.1 https://one.one.one.one
# 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
> one.one.one.one:443:64:ff9b::1.1.1.1
--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 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...
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?)
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.
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'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 2030 flag day for ipv4 is just a dream.
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.
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.
... VDSL (ie up to 100Mbit), surely? I can't imagine there are many ADSL (ie up to, at most, 24Mbit) users left.
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.
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.
I was CGNAT at first, but their implementation breaks consoles as well, so you can complain about your XBox not working and they give you a static IP.
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
But it requires an engineer visit to talk to their NOC so I can be without internet for a couple of days.
Sucks.
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.
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 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 wish I could use it though.
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.
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.
As far as IPv6 is concerned, there is no entry in the routing tables so IPv6 packets can't leave the network.
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.
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.
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.
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.
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.
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.
Do the latest versions include a cloud service that exposes things like passwords to Unifi? Looks like that’s what Unifi Cloud is.
Seems a bit hugged to death to me.