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;
};
};
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.
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.
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-...
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.
I feel like <random big game> could have killed IPv4 ten years ago if they had just introduced this sort of latency difference.
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).