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

> NAT gets replaced with a stateful gateway still doing conntrack…

Yeah, blocking incoming connections by default is a bad habit and needs to stop. It's fine for untrusted devices or private VLANs which shouldn't be accepting direct incoming connections in the first place (like cheap IoT gadgets), and should probably be additionally filtered to prevent inter-device connections and access to arbitrary Internet sites, but a laptop, phone, or tablet is perfectly capable of deciding on its own whether to accept or reject an incoming connection, and moreover as a mobile device must assume the network could be hostile anyway.

> Except IPv6 hexadecimal addresses are a usability disaster…

How are IPv6 addresses "a usability disaster" when you never see them? Just use DNS like a sane person.

> …and dual stack will forever be a security disaster.

That's a new one to me. How is dual-stack (IPv4+IPv6) any worse security-wise than any other situation where you have multiple "upstream" Internet connections, e.g. for failover or load balancing?



Blocking incoming connections by default is what I like about the current scenario.

You don't trust "cheap IoT gadgets". I would like to be able to trust any/all my devices. But I don't.

I don't trust M$/Apple/Linux - AND any associated applications people might want to use at home(kodi, plex, screencast, NAS for example) - to be 100% perfect when it comes to "deciding on its own whether to accept or reject an incoming connection".

I see "block by default" as being a layer of security - one bit of defence in depth.

Happy to drop NAT (with it's IP<->port mapping complications) for a straight IPv6 firewall though.

EDIT: concision


If you really want to block all incoming connections by default on your own network you can. Personally I think if a reasonably capable (i.e. non-IoT) host opens up a port to accept incoming connections, and there isn't a specific rule set by the local admin to block that port or host, then incoming connections should be allowed. NAT certainly doesn't stop all incoming traffic given that UPnP is enabled by default on most routers, not to mention all the methods available for UDP NAT traversal. It just makes it more complicated.

If you've ever connected your phone or laptop to a public WiFi network (or for that matter, the cellular data network) then it's been exposed to an environment were there is no extra layer of protection from incoming connections beyond that implemented by the host itself. We generally expect that to work without major security issues. Non-mobile, "appliance"-type devices might need stronger filtering if they weren't designed to be connected directly to the Internet, but that assumption is becoming less common as more devices require authenticated connections rather than trusting the local network.


And that's the thing. With a firewall and IPv6 we can each configure for what we want without the NAT hassle/expectation.

I would aim for a default block with allowList and agree with you that a non-IoT host using a UPnP-like mechanism (does UPnP cover IPv6 firewall like scenario?) is probably ok.

Ideally I'd like some kind of notification system where I can click "allow" for the firewall. (Maybe the firewall notifies my phone?) I think UPnP as it currently stands is a bit too hands off but can understand not every user wants to deal with this.

And we agree regards mobiles being in a default hostile environment and expecting it to work. But I see that as a matter of fit-for-purpose. I don't trust every computer I have to that level.


> does UPnP cover IPv6 firewall like scenario?

The miniupnpd UPnP daemon (used e.g. by OpenWRT) includes code[0] to handle IPv6 "pinhole" requests—not port forwarding, which isn't required for IPv6, but rather just opening a port in the firewall to permit incoming connections to a certain host.

[0] https://github.com/miniupnp/miniupnp/blob/b734f94bdf6ff555a2...


Awesome reference.

I wish I could upvote you multiple times. This interaction with you has been most enlightening. Thank you.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: