3 ms·

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.
- magila 8y ago
  As someone who works on P2P applications, if all I had to do was use PCP to open a pinhole in a firewall it would still be a big improvement over dealing with NAT. For one thing lack of NAT makes it much easier to deal with multi-homed systems. For various reasons, multi-home is much more common with IPv6 than IPv4. Without NAT I can discover thing like what an address's scope is without querying the network. Having to ask a remote server to discover a global address turns what should be an atomic operation into a potentially troublesome state machine. NAT also create annoying corner cases when there are local peers reachable via an address which also has a NATed global address. You may not be able to tell that the peer's address is not globally reachable, which is a problem if you want to advertise that peer to others.
  - yardstick 8y ago
    > For one thing lack of NAT makes it much easier to deal with multi-homed systems. It’s the opposite imo. Lack of NAT makes it impossible to do policy based routing enforced at a router level, eg route VoIP over ISP 1, and Web over ISP 2. Without NAT, each IPv6 PC is issued one or more IP addresses per WAN, but has no idea when it’s appropriate to use one over the other. (SLAAC router advertisements aren’t sophisticated enough)
    - magila 8y ago
      This is the sort of thing I was talking about when I mentioned negative externalities elsewhere in this thread. NAT is nice if you want to do things like that, but those sorts of tricks create big problems for people like me. Being behind NAT with multiple external IPs and an unknown policy for which gets used when is a nightmare scenario for P2P applications.
      - yardstick 8y ago
        The router admin would ideally configure which ISP to use for your P2P traffic, and possibly add some inbound port fowards (if applicable).
- 8y ago
gregmac 8y ago
Think about FTP. Client is behind NAT, so needs to use PASV mode (server opens arbitrary data port for client to connect to, instead of server connecting to arbitrary data port on client). If the server has a firewall that blocks all inbound but 21/tcp, or is behind NAT with just 21/tcp forwarded, no data transfers are possible. These are totally different setups from a network operations point of view, but look identical from application and user point of view. I think this is what the parent was getting at: both setups effectivity prevent a user from accepting arbitrary inbound connections to their machine.

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.

magila 8y ago
As someone who works on P2P applications, if all I had to do was use PCP to open a pinhole in a firewall it would still be a big improvement over dealing with NAT. For one thing lack of NAT makes it much easier to deal with multi-homed systems. For various reasons, multi-home is much more common with IPv6 than IPv4. Without NAT I can discover thing like what an address's scope is without querying the network. Having to ask a remote server to discover a global address turns what should be an atomic operation into a potentially troublesome state machine. NAT also create annoying corner cases when there are local peers reachable via an address which also has a NATed global address. You may not be able to tell that the peer's address is not globally reachable, which is a problem if you want to advertise that peer to others.
- yardstick 8y ago
  > For one thing lack of NAT makes it much easier to deal with multi-homed systems. It’s the opposite imo. Lack of NAT makes it impossible to do policy based routing enforced at a router level, eg route VoIP over ISP 1, and Web over ISP 2. Without NAT, each IPv6 PC is issued one or more IP addresses per WAN, but has no idea when it’s appropriate to use one over the other. (SLAAC router advertisements aren’t sophisticated enough)
  - magila 8y ago
    This is the sort of thing I was talking about when I mentioned negative externalities elsewhere in this thread. NAT is nice if you want to do things like that, but those sorts of tricks create big problems for people like me. Being behind NAT with multiple external IPs and an unknown policy for which gets used when is a nightmare scenario for P2P applications.
    - yardstick 8y ago
      The router admin would ideally configure which ISP to use for your P2P traffic, and possibly add some inbound port fowards (if applicable).
8y ago

gregmac 8y ago

Think about FTP. Client is behind NAT, so needs to use PASV mode (server opens arbitrary data port for client to connect to, instead of server connecting to arbitrary data port on client). If the server has a firewall that blocks all inbound but 21/tcp, or is behind NAT with just 21/tcp forwarded, no data transfers are possible. These are totally different setups from a network operations point of view, but look identical from application and user point of view. I think this is what the parent was getting at: both setups effectivity prevent a user from accepting arbitrary inbound connections to their machine.