Hacker News new | ask | show | jobs
by theamk 604 days ago
Why do people assume IPv6 means "easy p2p"?

Even if NAT will be gone one day, the stateful firewalls won't. Every every home router would still ship with "deny all incoming" by default, and every corporate network would have the same setting as well.

Same as IPv4, IPv6 serving would still need registration with border device, either manual by user, or via UPnP-equivalent.

3 comments

UDP hole punching works when you don't have symmetric NAT. So e.g. voice and video calls don't need a proxy and can be higher quality. You only need a third party to locate/signal your peer.
"everything gets a global IP, no more NAT headaches" was one of marketing talking points for IPv6. Not necessarily the case nor welcomed by everyone, but that was the intent.
Wide scale deployment of NAT (the "home router" that allowed you to connect multiple devices) was the greatest leap in internet security we ever made. I remember the days when we had "everything gets a global IP," and we do NOT want to go back to that. Look up Conficker, Code Red, Blaster, etc.

People naively assume the large IPv6 address space somehow hides your computer on the internet. That isn't true. Both because v6 host discovery is a solved-ish problem for attackers, and worms have near unlimited resources to throw at the wall.

NAT is technically not a firewall in itself, I believe early/some NAT implementations used deterministic assignments between external range to internal ip:port. They can be more transparent if that is the goal.

But the effect of proliferation of cheap Wi-Fi routers with cheap dynamic NAPTs in conjunction with UPnP did to XP-era PC security - 100% agreed, it was like sunlight self-disinfecting brass door handles.

You'll still need a router to route. It just won't have to do NAT. It can still do a statefull firewall, just like it does with IPv4.
I remember those days too. They had nothing to do with computers not being behind a NAT.
They had to do with computers being directly addressable, routable, and reachable by the entire Internet, which was the default prior to widespread deployment of NAT. NAT isn't the best way to do it, but it probably is the single biggest factor in reducing the external reachability of endpoint IPs.
NAT deployment here is only tangential to the real differentiator: the firewall. I mean, you can make a case that NAT is a poor man's firewall but you should know that it's not a substitute for a security model. Zero trust is now the dominant philosophy, and it allows for firewall rules to be derived procedurally.

It's a shame the likes of Microsoft only care about "zero trust" insofar their compliance checkboxes with the the US government. They see it as a chore. Contrary to Google, Cloudflare, et al.

NAT was originally delivered as a security mechanism.
With how trivial generating new addresses in IPv6 is, it'd be cool to have a host block all incoming traffic on its own and have each service that deserves to be reached over the listen on an address unique to the service.
> have each service that deserves to be reached over the listen on an address unique to the service

It’s already a thing. These unique per-service addresses are called “ports” in IP protocol.

Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.

Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.

> Also, the IP protocol does not care about ports at all. Ports are a thing for UDP and TCP.

You're right, they are one level above.

> Hosting service A shouldn't mean that every user of service A can also figure out you host C, B and D.

It how are ports on a single IP address essentially different from multiple IP addresses within a subnet?

In a /64, enumerating all hosts will not be as practical as enumerating all ports on a single IP. Further, you will not be able to link that two services are running on the same host by just the IP.