Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Honest question, why are we not all just on IPV6 now? It seems like at this point almost all the underlying hardware and software should support it?

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?



NAT is a strong argument against IPv4 -- it's an absolute pain in the ass for bidirectional communication.

Yeah, NAT acts as a defacto firewall, but you can just... use a real firewall.


It's an absolute pain for even single direction communication, as most NATs are going to be stateful — they have to retain, somewhere, the mapping between internal IP/port & external port. And that mapping is in finite memory, and old mappings are usually timed out of it, killing the connection, if there is one.

(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.)


Question from an ignorant network person: is IP rotation still common on ipv6? My primary fear with IPv6 is the touted "feature" of every device having an IP. While it's possible, yea, it sounds like a nightmare for privacy and tracking.

Do the proponents of IPv6 also advocate for large ranges of IP rotations to deal with this?


Generally you'd get a network prefix from your ISP of 56 to 60 bits, your router would handle deciding how to make a network out of the remaining 4 to 8 bits of the network part, and then devices would automatically assign themselves unique addresses with the remaining 64 bits for the host part. One thing to note is that devices can and almost always do have multiple IPv6 addresses. Commonly: one for a local only address (like a 10. or 176.16., 192.168. address would be for IPv4), one based on the MAC address of a device, and now one (or a few) that is randomly chosen and periodically cycled to prevent some of the tracking issues you mention. The problem overall though is that the network part of the IPv6 addresses would still be the same and would be similar in tracking capability for a customer/household as how an IPv4 address is with NAT.


Every major OS uses the IPv6 privacy extensions by default. Short version: your device frequently picks a new address at random.


a new address from a prefix that still identifies you? or a new address from a mixed pool of customers of your ISP?


A new address from the network that your ISP routes to your house. That's basically identical to the way an ISP routes a single IPv4 address to your house.


is it really? I'm on one right now talking with people across the world.


As a content company who owns ISPs, I would LOVE NATs.

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.


> it's an absolute pain in the ass for bidirectional communication

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.


You could assign your devices IPs from fc00::/7 range otherwise known as "Unique local unicast"[1], which is the IPv6 version of 10/8, 192.168/16 and the like.

[1] https://en.wikipedia.org/wiki/Unique_local_address


> 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.


That's only true if you don't have a firewall, or yours is misconfigured. "Only allow related" as a default incoming rule works just fine for IPv6.


I'd rather just use a proper firewall I think. One thing that's super annoying about NAT is how hard it makes it to host your own server. I remember setting up FTP on my router at one point, but it was so annoying and flaky that I ended up not using it. But I can't say I'd be that afraid of having an SFTP server on the internet with a strong password and every non-relevant port firewalled. The whole NAT thing doesn't make it any more secure, it's just way more annoying to setup


Not one bit of that is true or accurate.


Actually, it is, try the test for yourself in your home over a 30 day period. Drop IPv6 at the router and in your main PC and devices by disabling it. At the end of that 30 days, it will become clear that Ad companies were using IPv6 to track people in the household when Ads for things completely unrelated to their interests and related to the other members of the household start showing on each others PC's and devices.


That's impossible if the devices have privacy extensions enabled, which is the default on all major OSes. My house has a /64 IPv6 prefix. Inside that, the computer I'm writing this on has 8 temporary IPv6 addresses it's using at this moment. An ad company can no more track my individual computer inside my house than it could your computer inside yours. The only difference is that your network is a black box behind public IP 1.2.3.4, and mine is a black box behind public prefix abcd:ef01:2345:6789::/64. (Well, I use IPv4, too, but for the sake of this discussion...)


> That's impossible if the devices have privacy extensions enabled

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


> Wrong. Try what I said. It was recent enough the results are reproducible.

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.


The barrier for our company is that there's simply not much benefit to upgrading our AWS networking stack from ipv4 to ipv6. It's definitely doable, but there's no real benefit (especially when your infrastructure is behind Cloudflare (or any CDN) which adds ipv6 support for end users without needing the underlying infra to be ipv6.

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.


The only reason we're even still on IPv4 is because of NAT. End-to-end connectivity, public IPs everywhere, is how it should work. In the early days, this is how IPv4 worked. I remember having full, publicly routable IPs both at home, school, and work, no NAT. This doesn't mean you shouldn't use firewalls, though many in the early days didn't!


> but I can't think of a technical reason we couldn't do NAT with IPv6

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.


To first approximation, we are. Essentially all mobile networks are IPv6 now. Many wired client drops are IPv4 NAT behind an IPv6 pipe. Most datacenter-internal communication is IPv6, at least at the big players.

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.


I recently switch ISP and the new ISP gives you an IPv6 address and have their router just hand out IPv6 addresses on your LAN as well. It generally works really really well. The only weirdness I've seen is in Firefox when using DoH and IPv6. Sites like Google or Wikipedia just worked, while others simply doesn't and because it's DoH in the browser, you can't actually debug the issue all that well. I believe it may be tied to the combination of a specific DoH service and my ISP, but I haven't tested it fully yet.

Why would you want to use NAT with IPv6 though?


> 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?


IPv6 is still a mess of compatibility issues, and being an early adopter is not always fun.

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.


Big cloud providers have good IPv6 support. The long tail is terrible. We work with ~200 different hosting providers, half of them have no IPv6 support at all, another ~15% it only works occasionally and they clearly don't monitor it.

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.


In large part, because of ISPs. There are big costs to the transition that none of their clients care about.

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.


> but I can't think of a technical reason we couldn't do NAT with IPv6?

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)


The effort required to make a company IPv6-enabled is not to be underestimated.


Good thing people have had years, even decades, to make it happen, then.


I assume IPv6's are less trusted by spam filters




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: