I disagree with this strongly. The intended use case of NAT or the existence of inbound connections being blocked by routers is irrelevant.
For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.
If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.
The important bit here is not NAT or firewalls, but layer 3 network segments!!!
An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!
If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.
IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.
You can support the adaption of IPv6 nonetheless and I would have no disagreement there.
The problem is, as I understand it, is this hypothetical network where there is a NAT but no firewall just does not exist.
>In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
This is typically handled by the firewall, not the NAT. You can easily come up with scenarios that without the firewall, the NAT could be trivially defeated, e.g. by port scanning.
It is not, you guys are talking from a specific american ISP perspective where you have these modem+router+gateway+firewall combo devices. Not everyone gets that.
Many get just a modem and buy a cheap router which may not have a firewall. MANY more get just a modem and their laptops are directly exposed to the internet (!!!), those you can't do much about, but many put a "router" that's just a cheap wifi access point with layer 3 routing and NAT. If you chose to "bridge" a device (like those internet exposed laptops) or port-forward, it will just work (even with ISP routers!!) there is no firewall rule change required.
I've worked in this space supporting consumer grade routers, and then worked in enterprise networking. But don't take my word for it, you all can take a trip to shodansafari, how many devices are listening port 3389 and 445 with consumer grade laptop names?
But it isn't a popular thing to say for whatever reason. I guess IPv6 is a political ideology now lol.
>Many get just a modem and buy a cheap router which may not have a firewall
What cheap router are you buying that doesn't have a firewall. I think the problem is when people hear "firewall" they think the router is running pfSense or something. Even cheap routers will have a basic, non-configurable, firewall that will block inbound connections. That is separate from NAT and has nothing to do with IPv4/IPv6.
It's an AP that serves DHCP addresses on the lan port. that's it. It has some port forwarding too if you set it up, no firewalling there. For modems, most cable ISPs let you buy a DOCSIS modem, there is no router, whatever device you connect gets a DHCP lease right on the internet (and ipv6), most people buy cheap "routers" like that one to add "wifi" to it, and it works great for the money. And honestly, I have yet to see one that does have a firewall, but then again I've never tried the $500 router options or seen someone who did.
These devices are not meant to firewall, they have no need to firewall. if you do "bridge" or "portforward" they assume you want everything forwarded, they don't let you configure any firewalling by design, and they don't have any firewalling because it isn't needed. They have a dedicated WAN port, the management interface doesn't listen on that port and LAN devices are NAT'ed with IPv4 so there is no need to firewall anything even behind the scenes. Their main use is to either extend wifi coverage or add wifi capability to modems.
Most people with fiber or *DSL get an ISP provided gateway which has a firewall,that's not the same as what I'm talking about.
I hate to complain about downvotes, but you all need to realize that it is the poorest and most vulnerable around the world that get hurt over this stuff. yes, ipv6 can cause unintended internet exposure of internal devices. period. that's not a dismissal or disapproval of ipv6, it is what it is, and that needs to be considered when deploying it. It assumes you'll configure your network properly, unfortunately the people who made ipv6 didn't consider consumers or people who screw up, they wanted to force people to configure firewalls, that works for corporations (until it doesn't) but not for most regular internet users.
The Archer BE3600 Pro you linked definitely has a stateful packet inspection firewall (SPI) https://www.tp-link.com/us/home-networking/wifi-router/arche... and the capabilities go well beyond state tracking (HomeShield Security enabled more on it + a few userspace tools). The Archer BE3600 Pro is also not a particularly cheap device in the first place, certainly well out of reach of the poorest in the world, it's just low cost for having such a high speed
Regardless, even with actually cheap devices, you'll find they also have the same. This is because nearly everyone, particularly the cheapest piece of crap CPU forwarding 100 Mbit routers, implement NAT using netfilter https://www.netfilter.org/ on Linux. Netfilter is most commonly known for being the firewall backend of iptables/nftables rules, but the conntrack database of nf_netfilter is also what drives the NAT state of nf_nat. It's a similar story in BSD, but it's all contained in what's called "pf" (packet filter) instead of netfilter.
I.e. one, literally, cannot implement NAT on these types of devices without first invoking a firewall and populating said firewall with the connection state. The _only_ difference in defaults between IPv4 and IPv6, on even the cheapest home routers, is whether or not the NAT is enabled on top of the stateful firewall. In no case is NAT able to be enabled on these types of boxes without having the stateful firewall functionality in place. The port forwarding is also done via netfilter. I.e., an entry in the firewall.
High end devices (most people in the US do not have home routers better than the one you linked) tend to have hardware offloads for these systems (i.e. the netfilter rules can be accelerated by dedicated hardware in either the SoC or the NIC) but otherwise are identical in implementation to the cheap ones, barring the additional crap they might bundle with the device too. It's not until you get into enterprise firewalls from companies like Fortinet you start seeing truly unique custom implementations, and even then they build it the same way at the end of the day (because why would you implement state tracking twice just to be able to build NAT with less security than normal?).
There is a common conflation that a firewall is this big beefy high end appliance which has all sorts of high end features and a dedicated config interface because it's so honkin' complex. The reality is a firewall is just a network stack implementation which tracks connection state and lets you perform actions on that (drop, deny, rewrite, send to userspace for an app to handle). NAT relies on the rewrite capabilities combined with the state table, and ticking NAT just implements a bunch of firewall rules on your behalf. Similarly, a port forward is just another rule entry which gets added to the firewall. The same ruleset which gets you NAT on home routers, minus the address & port rewriting, is what gets you a normal firewall which denies inbound.
It's possible to do NAT without firewalling in netfilter. I gave the rules for it in this comment: https://news.ycombinator.com/item?id=46709150 -- you literally only need the first one for NAT. Inserting it will make netfilter track connections, but you need the other, separate rules to do firewalling based on that state.
Most home routers will ship with those firewall rules in place, because not doing so is a security vulnerability, so in practice you're going to have the firewall, but it's not a strict requirement and routers have been discovered to not have them in the past.
At least with v6 it's more obvious that you need these rules, so it's more likely people will be checking for them.
> It's possible to do NAT without firewalling in netfilter.
That's not the claim I was making, which is that if you have netfilter/pf you are already using a device which ships a stateful firewall (and if you have NAT on a cheap home router you have netfilter/pf). This is in response to GP's claim there are cheap home routers which can NAT but not be configured as a stateful firewall, whereas your response seems to be more about how NAT can be configured.
Whether or not netfilter/pf is configured with NATs, port forwards, or block entries is a separate topic all together, somewhat split between vendor default config and what the user has changed. Regardless of what rules it's configured with at a given moment, netfilter/pf doesn't stop having the capabilities of a stateful firewall already bundled.
The nat is a belt and braces approach - especially when combined with rpf. How will your packet reach 192.168.0.1 from the internet without having a nat rule to translate the packet, even if there is a firewall rule allowing all traffic
(If you control the next hop and the router doesn't have rpf checks on the wan interfaces you can forge a packet with a destination of 192.168.0.1 and route it via the public IP of 40.50.60.70)
For NAT, of course it isn't meant for security, but it has a side-effect of creating a network boundary, and that has positive security implications.
If your router doesn't have a firewall blocking any connections, NAT still has security implications as it is deployed typically on consumer networks, which is a one-way port-address-translation for outbound traffic.
The important bit here is not NAT or firewalls, but layer 3 network segments!!!
An RFC1918 private addrerss space is not internet routable. Furthermore, routers shouldn't "default route" traffic from arbitrary connected networks by default. But "should" aside, the typical default consumer router behavior is that they don't NAT translate inbound traffic, they can't!
If a random internet IP wanted to connect to port 80 on a device at 192.168.1.200 in your home network, it doesn't know how to tell your router what IP to translate it's request to the router's public IP to. That is the essential positive security implication. In commercial grade routers, the same applies except even if the external IP knew to direct the router to the right internal IP, or if the route knew to direct the traffic to the right external IP for outbound connections, unless you configure a default route, or a more explicit route, it won't forward such traffic.
With IPv6, end devices in your network get a globally routed address, someone can try to connect to that same internal device as my earlier example and succeed with the same exact default behavior in place.
IPv6 is thus, by relative metrics, insecure by default. It does not mean it cannot be secured, but it is less secure than IPv4 in typical deployments where extra care isn't taken to secure it properly. If your answer to this is "well that's just because people who deploy networks are dumb" then save your self the effort or arguing that, it is irrelevant. That is how networks are deployed in the real world, period. People make mistakes in the real world. People don't know best practices in the real world. So out of the box, things need to consider real world hazards, and IPv6 does not do that.
You can support the adaption of IPv6 nonetheless and I would have no disagreement there.