5 ms·

The thing about NAT that for network operators it is a negative externality. For them it often simplifies their job. They do not feel the searing pain it inflic

• geofft 8y ago
  As a network application developer I haven't felt much pain from NAT - I need to run a central server to relay connections, but that's about it. And oftentimes I need to run a central server anyway for discovery or authentication. (A few years ago I worked at a startup that enabled secure remote access to corporate networks, as in you could connect from a roaming laptop or mobile app into the network, browse the web, access network file shares, etc. We had a straightforward and uncomplicated proxy server with access control that we asked people to install and forward a port on their NAT for; it worked fine. We prototyped a relay server that customers could run in AWS, where our proxy server would connect outbound. I don't think any customers absolutely needed it. And we definitely preferred having one of our servers involved somehow as an intermediary so that customers weren't exposing Windows file shares to the public internet and hoping Windows authentication was enough....) What do you find as searing pain?
  • magila 8y ago
    You're right some some applications are more effected than others. It sounds like you were dealing with business customers, "asked people to...forward a port on their NAT" is not a viable strategy when dealing with consumers. I work on P2P applications, so NAT is the bane of my existence.
    • Gibbon1 8y ago
      I've always thought that facebook wouldn't exist if you had workable P2P for consumers.
  • vvanders 8y ago
    If you use UDP for anything you'll run into a bunch of fun issues. We hit it all the time back when I did networking in gamedev.
  • pixl97 8y ago
    >we asked people to install and forward a port on their NAT for At this point I no longer believe you. Having worked in the ISP industry for quite some time, only a very small portion of the more technically advanced users can do this successfully. Most users dont remember their passwords to even get in their device. Just because windows firewall security is balls doesn't justify writing a nat helper or proxy for every protocol their is. You have just accepted the abuse that nat doles out as a norm.
    • vetinari 8y ago
      Increasingly, even those who know how to do it are unable to do so, because they are behind CGNAT and the PCP doesn't work or is not implemented at all.
• AnIdiotOnTheNet 8y ago
  If NAT is wrong, then firewalls that block incoming connections by default are also wrong. I think you'll have a hard time making that argument.
  • jdblair 8y ago
    You're mixing up NAT and ingress blocking. A stateful firewall doesn't depend on NAT, we're just used to ingress blocking as a side effect of NAT.
    • AnIdiotOnTheNet 8y ago
      If a firewall isn't doing ingress blocking then it doesn't really serve much of a purpose now does it? Ingress blocking being a side effect of NAT is the whole point of equating it to a firewall. It's roughly similar for all intents and purposes except that it also provides socket translation, and socket translation is really useful so every firewall worth mentioning also provides NAT. That ipv6 initially did not address the usecases for socket translation outside of multiplexing addresses is probably one of the reasons it hasn't gained much ground in the decades it has been around. Anyway, the point is that most of the headache that NAT causes application developers is also true of firewalls that block inbound connections by default. Removing NAT from the equation doesn't save you.
      • spookthesunset 8y ago
        It’s late to the party but it is a shame you are getting down votes. Firewalls will still be all sealed up to where inbound connections are strictly limited. You’ll still need something like upnp to request a hole punched through the firewall.
    • geofft 8y ago
      No, I think that argument makes perfect sense. A stateful firewall doesn't depend on NAT but you get all the downsides of NAT from a working stateful firewall in default-deny mode: you still have to talk the firewall into allowing the relevant traffic through, and without that you still have connections that work in one direction and not the other. The only thing that's different is address discovery, but you can solve that by just asking the firewall what public address to use at the same time that you ask it to open the port. (Or curl whatismyip.akamai.com or something.) So if NAT is a problem for your application, so are the stateful firewalls implicitly envisioned by those who advocate for assigning unNATted public addresses to devices on home networks.
• paulddraper 8y ago
  Okay, NAT hurts network application developers. But do you really want to stake the adoption of IPv6 on convincing the world of that? Or should that be a separate battle?
• gregmac 8y ago
  NAT is only painful for applications that implement arbitrary inbound connections, such as peer-to-peer connections, and applications that use separate control/data connections. The former is understandable because it's necessary, the latter is arguably lazy application developers. Peer-to-peer is largely solved with UPnP port forwarding, but most of these apps can also at least be configured to use a specific port range, education can then be configured on the router to forward. Then the are the badly designed protocols. That's perhaps a bit harsh, they have their reasons, but using multiple ports is a bit lazy vs using encapsulated packets (eg where you can send either a control or data packet over a single connection, or even send multiple data streams concurrently, in both directions). FTP is one example, where a separate port is used for data transfers. This is "simple" from the perspective that the data port just contains the raw file contents, no extra encoding, but very painful from a network point of view. I used to support web hosting customers around 2000, when ftp was commonly used for maintaining site content, and people didn't understand when to use PASV mode, server operators didn't always setup the firewall to allow inbound data ports, and occasionally you'd run into the worst case of both client and server behind NAT. SIP is another example. It uses multiple streams, but is built assuming everything has a public IP. The message it uses to setup this stream includes the system's IP address, which is the private non-routable IP when behind NAT. Contrast these to a multiplexing protocol like HTTP/2, where it's basically transparent to network operators (still just a single TCP connection on 80 or 443). There's many other examples of multiplex use in more proprietary systems: online gaming, for example, sends different packet types over a single connection -- it doesn't require a separate "movement" and "shoot" port for each connected player. Most sites/apps using web sockets also work like this, with each piece of data encapsulated inside a message wrapper (usually JSON). I'm being a bit unfair, because FTP predates NAT, and SIP was being created around the same time -- though I'd argue SIP's assumptions about the network environment (and seeming compete ignorance of NAT) were both poor and unnecessary.
  • icebraining 8y ago
    UPnP only works for small-scale NAT, not carrier-grade, which is what ISPs are using when they can't afford to give everyone their own IPv4.
  • 8y ago