3 ms·
>In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want t
by pilif 11y ago
>In fact, I would suggest that NAT is responsible for a lot of that centralization, as the workaround for not being able to listen(2) for your friend you want to communicate with is a centralized service to manage that connection.
IMHO, IPv6 won't fix this problem for many cases. Consumer routers still won't allow inbound connections, so there will still be the need for some kind of way to allow the client to tell the router to forward traffic on a specific port (likely https://en.wikipedia.org/wiki/Port_Control_Protocol https://en.wikipedia.org/wiki/Port_Control_Protocol).
Which is exactly the same as we get these days with NAP-PMP or UPnP.
Maybe once listening on all local interfaces will not listen on temporary addresses, we can move to a one-address-per-service model at which point it becomes more feasible to forego the central firewall dropping all incoming connections as port-scanning the machine you just got a connection from will involve scanning 65536 * 2^64 ports
As it stands now, I'm not willing to expose all open ports of my internal machines over IPv6. Instead I still have specific port opening rules on my central firewall.
While I have no issue exposing, say, Skype on some port, I certainly don't want to expose, say, my local NTP port of my Mac, or, worse some local port mapper needed for NFS mounts.
Yes. I could use a local firewall, but these by default only allow a per-application setup. "Do you want to allow NTP to be reachable?" - To my local network? Yeah. Maybe. To the internet? Hell no.
Current simple built-in firewalls don't allow this kind of answer - at least on the mac.
- asdfaoeu 11y agoSure but think about carrier nat. IPv6 can also always guarantee that the external port is also always going to be free.
- pdkl95 11y agoI never claimed anything about IPv6, though it would fix most of the NAT problem. Most of what you're talking about is based on how the current NAT infrastructure works... which was sort of my point: NAT badly limits the scope of how we think about software, because so many designs rely on being being able to even name hosts uniquely. Designing software for the NAT "party-line" suddenly requires inventing things like remapping ports to make anything work. A particularly bad misconception that ubiquitous NAT has encouraged is the conflating of the address-translation step (NAT) with the firewall, when the two concepts are not related at all. You can run either independently of the other[1]. All that is needed for a home router is a simple firewall, and a way to open holes in the router's firewall from the internal hosts. The fact that this software isn't already available on most OS/home-routers is simple lack of demand... and the fact that it would be totally useless for current NATed home networks. You don't need all of UPNP or NAT-PMP; there are no ports that need to be mapped. The difficulty in introducing something to allow certain types of packets through a firewall is trivial compared to the complexity of working around NAT. Concerns about port scanning and "expose all open ports" are just nonsense, and has nothing to do with NAT. This all-or-nothing approach you seem to be assuming misses the entire point of having an external firewall (such as on an home router). You get to pick which packets you let through. [1] This is why NAT doesn't provide security on it's own. Static NAT, for example, is just substituting the address; all packets to the public address are forwarded to the translated address.