It seems like the only argument for sticking with IPv4 is NAT, but I can't think of a technical reason we couldn't do NAT with IPv6?
It seems like the only argument for sticking with IPv4 is NAT, but I can't think of a technical reason we couldn't do NAT with IPv6?
Yeah, NAT acts as a defacto firewall, but you can just... use a real firewall.
(You can hack around this with keepalives, but it's just another PITA because of the original sin of breaking the end to end principle.)
Do the proponents of IPv6 also advocate for large ranges of IP rotations to deal with this?
Why? Keeps P2P like BitTorrent, soulseek, gnutella, and newer protocols crippled. And content creators don't want people consuming content other than through themselves.
And a NAT can also differentiate between "consumer household" and "business" - do you get a real IP or not?
It's also why companies like Comcast zero-rate their own content.
EDIT: for you -1'ers ; you DO realize that most mega-ISP-content companies want the push-style of the television back, right? And these companies will institute NAT, data caps, and "3 strikes" to boot people off.
You're right and that's what I love about NAT, IPv6 in contrast is a hacker/spy tracking digital superhighway right through my front door and straight into my devices.
I'm fairly confident that nobody is ever going to scan a single /64 of IPv6 addresses within our lifetimes.
In comparison, scanning the ENTIRE IPv4 internet on a single port can be done by anybody at all and it's going to take about 40 minutes.
Wrong. Try what I said. It was recent enough the results are reproducible.
> An ad company can no more track my individual computer inside my house than it could your computer inside yours.
Yes, they can and my testing showed me, they do:
https://johannaullrich.eu/assets/papers/ullrich2015_raid.pdf
Nope. What really happened is that an ad company might have started collecting information about your IPv6 prefix, precisely like they might store information about your IPv4 address. That's all the information they can reconstruct about the hosts inside your LAN.
The paper you linked showed that if a host uses the method for generating pseudorandom addresses described in RFC 4941 instead of using completely random one, and if the attacker has a complete history of your generated pseudorandom addresses, and if the attacker has successfully defeated MD5 on a practical time scale, then it's possible that they could guess your future pseudorandom address.
In practice, most OSes generate truly random addresses, and an advertiser doesn't have your complete history of generated addresses, and the advertiser wouldn't spend all those resources to track you specifically anyway. In other words, that 8 year old paper isn't relevant to the situation today.
Even if we were setting up a VPC from scratch, it would probably be ipv4 since it's what everyone knows how to easily do. There's a learning curve with deploying a ipv6 network and very little benefit when it's all behind a ipv6-enabled CDN.
Correct, NAT works fine with IPv6, there just aren't many reasons to use it.
One of the main uses for IPv4 NAT is extending a network without the operator's permission. On IPv6 that can usually be accomplished with ND Proxy.
The only regime that is still "IPv4-by-default" is public facing servers, which (obviously) still need to present the old addresses for compatibility.
But that last 5% will still be around until we all die. There are just too many client devices out there that will never get an IPv6 update, and client devices tend to live much, much longer than you (or their designers!) think they should.
Why would you want to use NAT with IPv6 though?
I imagine it being far simpler for the average person to adopt IPv6 without much research if all of their current firewall rules, including port forwards, work exactly the same as they did with IPv4. You may not need those port forwards without NATs, but do you trust the firewalls on your servers to disallow accessing other ports from outside your local network?
I had a really weird problem where Youtube videos were unwatchably laggy on my home desktop PC. Gigabit hard-wired connection. Every other streaming site worked great, ditto every other device I owned. Even downloading the videos on the same device using yt-dlp worked great. After much tearing of hair, I noticed that in the network tab for attempting to watch Youtube, all of the requests for video data that were laggy were going to IPv6 addresses. So I turned off IPv6 at my network adapter and everything worked great after that. I guess Youtube and that PC and browser were the only things that supported v6, every other site, device, and Python dropped to v4 and worked fine.
I guess I could dig deeper into what really went wrong and try to fix it, but I feel like I've already spent enough time and headaches on it. The off switch is just easier.
There's also a fair number of still popular libraries and frameworks that don't handle IPv6 well. Maybe not in their latest release, but in their more popular older ones.
Besides, NAT gives ISPs insight into their users (number of devices, services running on devices, how much traffic each service uses, etc). So you can probably do regional pricing based on that and some other things.
We absolutely can do NAT with IPv6, but there's no reason why anyone should (aside from stateless NAT66 in case you get a dynamic prefix that changes every now and then, but that's about the only use case)