3 ms·

This doesn't change with the vast majority of residential IPv6 deployments. Many people conflate having a public IP address with not having a firewall. This is

by anderiv 12y ago

This doesn't change with the vast majority of residential IPv6 deployments. Many people conflate having a public IP address with not having a firewall. This is not the case at all. Yes, internal clients will get public, routable IPv6 addresses. They are still behind a firewall, though, and you have just as much control over ingress and egress traffic as you did before.

userbinator 12y ago
The difference is in the isolation factor: there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet, and likewise a packet with a public IP will never be accepted by a device that has been configured with an internal one. The failure modes are different - although firewalls can be configured to provide an "outgoing connections only" default like NAT, they are also software and thus not immune to bugs; a buggy firewall letting packets through which shouldn't be is far worse than a buggy NAT.
- oasisbob 12y ago
  there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet That very much depends on your definition of "public internet." My service provider doesn't properly filter RFC1918 space at their border. From my home on the west coast, I can hit 10.0.0.0/8 devices on the east coast in a separate AS. Is a reachable printer web interface 3000 miles away in New York on the public internet? The "Internet" is a very tough entity to define succinctly, but I'd argue yes.
  - graylights 12y ago
    Why would you need to filter an internal IP as a destination IP, routing should handle that. I understand filtering the source address as internal IP because that could be malicious spoofing of internal host (and destination can't legitimately reply.)
maxhou 12y ago
The problem is that all NAT related issues are not because of NAT itself, but because of the required stateful firewalling for NAT. To be able to NAT and un-NAT, you first need to classify traffic (that NEW, ESTABLISHED, RELATED,... stuff in Linux netfilter), changing the destination or source ip addresses is only the second part of that process. Protocols don't break only because of NAT, but mostly because of stateful firewalling, you'll face the same problems with IPv6 if you enable it.

by anderiv 12y ago

userbinator 12y ago

The difference is in the isolation factor: there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet, and likewise a packet with a public IP will never be accepted by a device that has been configured with an internal one. The failure modes are different - although firewalls can be configured to provide an "outgoing connections only" default like NAT, they are also software and thus not immune to bugs; a buggy firewall letting packets through which shouldn't be is far worse than a buggy NAT.

oasisbob 12y ago
there is absolutely NO way a packet with an internal IP can get anywhere on the public Internet That very much depends on your definition of "public internet." My service provider doesn't properly filter RFC1918 space at their border. From my home on the west coast, I can hit 10.0.0.0/8 devices on the east coast in a separate AS. Is a reachable printer web interface 3000 miles away in New York on the public internet? The "Internet" is a very tough entity to define succinctly, but I'd argue yes.
- graylights 12y ago
  Why would you need to filter an internal IP as a destination IP, routing should handle that. I understand filtering the source address as internal IP because that could be malicious spoofing of internal host (and destination can't legitimately reply.)

maxhou 12y ago

The problem is that all NAT related issues are not because of NAT itself, but because of the required stateful firewalling for NAT. To be able to NAT and un-NAT, you first need to classify traffic (that NEW, ESTABLISHED, RELATED,... stuff in Linux netfilter), changing the destination or source ip addresses is only the second part of that process. Protocols don't break only because of NAT, but mostly because of stateful firewalling, you'll face the same problems with IPv6 if you enable it.