5 ms·

IPv4+NAT still works well, because the internet is more and more centralized. Sadly.

pdkl95 11y ago
No, NAT doesn't work well at all. Everybody that says this isn't taking into account the massive amount of software that wasn't even started in the first place because it wouldn't work behind a NAT. 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. One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority. [1] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/
- m_mueller 11y ago
  > In fact, I would suggest that NAT is responsible for a lot of that centralization (...) Wasn't that exactly GP's point?
- sz4kerto 11y ago
  > In fact, I would suggest that NAT is responsible for a lot of that centralization, They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
- 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 ago
    Sure but think about carrier nat. IPv6 can also always guarantee that the external port is also always going to be free.
  - pdkl95 11y ago
    I 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.

No, NAT doesn't work well at all. Everybody that says this isn't taking into account the massive amount of software that wasn't even started in the first place because it wouldn't work behind a NAT. 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. One of the original benefits of TCP/IP networking was that every peer was equally client and server in the eyes of the protocol. The damage done by NAT has been the de facto removal of that benefit. Even now when reasonably-reliable (but INCREDIBLY complicated) NAT-traversal protocols exist, a centralized service is still required, nullifying the benefit of being able to publish without the permission[1] of a central authority. [1] https://www.fourmilab.ch/documents/digital-imprimatur/ https://www.fourmilab.ch/documents/digital-imprimatur/

m_mueller 11y ago
> In fact, I would suggest that NAT is responsible for a lot of that centralization (...) Wasn't that exactly GP's point?
sz4kerto 11y ago
> In fact, I would suggest that NAT is responsible for a lot of that centralization, They are mutually reinforcing each other. Unfortunately, ISPs would only act on consumer pressure, and consumer pressure won't exist because they don't know of all the other nonexisting software that could exists without NAT. We have centralized internet because of NAT, and we have NAT because centralized services are dominant.
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 ago
  Sure but think about carrier nat. IPv6 can also always guarantee that the external port is also always going to be free.
- pdkl95 11y ago
  I 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.