In many ways, the NAT classification scheme generated from the BEHAVE wg is a lot better. Splitting it in to "mapping" and "filtering" characteristics, and then indicating if each is "endpoint independent" or "endpoint dependent", with the latter having "address dependent" or "address and port dependent".
That then covers more than the simple, opaque, and inadequate terminology of "cones" used by the earlier RFCs. i.e. see https://www.rfc-editor.org/rfc/rfc4787
As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour.
It is not uncommon for a CGNAT to have EIM and EIF, hence they're "full cone"; so that is what one will generally experience when tethering to a LTE/5G mobile network.
> As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour.
I mean, there clearly is a firewall. If you buy a printer today, you don't really have to worry very much about how safe its network features are or if the firmware is updated, because if you put it behind a NAT router, it's not reachable from the global internet. Which is clearly a kind of firewall. And, generally, a good thing: it would be TERRIBLE for security if every shoddy network enabled device that anyone's bought for the last 30 years were reachable from the public internet. In the utopian "every device has a unique IPv6 address!", that would be the case.
It's true that an IPv6 gateway/router/whatever could have an explicit firewall that provides the same security, but the fact that this comes "by default" with a NAT router is honestly pretty nice for most users. And it's silly to deny it's an "implicit firewall", it clearly is. That's why I called the IPv6 version an "explicit firewall" two sentences ago.
The effect of EIM + EIF is that if a private port reaches out to somewhere on the Internet, then anywhere on the Internet can reach back to that port. So a port scan can find it. Off the shelf consumer NAT "routers" tend to have an "allow out by default" policy.
Now given the garbage one tends to find in the software of lot of off the shelf devices, the only way to ensure they don't "reach out to the Internet" is with an explicit outbound firewall, which prevents them reaching out.
A web browser these days opens so may connections, and is so vulnerable, that one should view those sitting behind a consumer NAT is not behind a firewall.
FWIW - My day job includes implementing and maintaining (i.e. writing the software) for commercial NAT and firewall devices.
> In the utopian "every device has a unique IPv6 address!", that would be the case.
No - every device would be routable. Routability is not the same thing as reachability.
This whole implicit / explicit thing is a bit silly. A DSL router doing NAT on IPv4 has a firewall, and a DSL router that's on IPv6 has a firewall. If you throw packets with an RFC1918 destination address at the WAN port on a router doing v4/NAT, it will drop them because of its firewall - nothing to do with NAT.
Absolutely not. NAT was created to help with the limited IPv4 space, and only that. The separation into routable wan and non-routable lan was a nasty side effect of this work around. IPv6 doesn’t have this issue, even though for some reasons it also has the NAT mechanism. Every device should be globally routable and the access should be policed by the firewalls.
> NAT was created to help with the limited IPv4 space, and only that.
Irrelevant. It's paramount that LAN operators should have tools for configuring LAN routing policies properly.
It so happens that NAT is the tool usually used for this.
(Not necessarily, though; we don't use NAT on the corporate LANs I'm responsible for, we have two interfaces and OSPF and wireguard to tie it all together.)
In a just and sane world IPv6 should have solved the tunneling problem so we don't have to rely on the myriad of incompatible and broken solutions just to bridge two network segments. Alas, we got the useless solution to a non-problem instead.
> Every device should be globally routable
That is literally insane, like I said. People who propose this should be banned from ever doing IT again.
> ...the access should be policed by the firewalls
Of course that too, but that issue is vastly less important than the routing issue.
> Irrelevant. It's paramount that LAN operators should have tools for configuring LAN routing policies properly.
It so happens that NAT is the tool usually used for this.
No, it is absolutely relevant. There is no “routing policies” enforced by NAT whatsoever. NAT has nothing to do with routing, it’s literally the address translation mechanism. Routing doesn’t change whether you’re using NAT or assigning addresses to devices within LAN from the provider’s network or your own PI range. There’s no “routing issue” in either case, the only meaningful difference is the LAN address range.
The only issue I can think of is using the provider’s range for LAN addressing - it will be unnecessary difficult to use multiple uplinks in this case. And having to renumber your network in case of provider change also quite a disadvantage. PI addresses and BGP peering with uplinks would be the right solution in this case (and getting your own v6 subnet is currently trivial).
> That is literally insane, like I said. People who propose this should be banned from ever doing IT again.
This is an amazing argument, thank you for that, I have immediately changed my mind after reading it. Also check the address of the cellular interface of your mobile, chances are it is in fact global, despite of your disagreement.
>That would imply that NAT is some kind of firewall. It's not. NAT doesn't block connections, so it's not a firewall.
I know. I am arguing with the people who think NAT is a good security mechanism. I called it an accidental firewall because without configuring NAT, you do not have a path from the Internet to a private network. I'm speaking on their terms.
>In the first place, NAT is something you apply to outbound connections, not inbound ones
Where in the literature did you read this? You absolutely can NAT in any direction you wish. Source NAT, Destination NAT, many-to-one NAT, 1:1 NAT, etc.
Source: multi-decade network and security engineer
I'm talking about the kind of NAT that everybody else is talking about here, the one you get in Linux by running "iptables -t nat -A POSTROUTING -o wan0 -j MASQUERADE".
It has "-o wan0" so it only applies to outbound connections.
> I know. I am arguing with the people who think NAT is a good security mechanism. I called it an accidental firewall because without configuring NAT, you do not have a path from the Internet to a private network. I'm speaking on their terms.
But you do normally have that. Your ISP gives you address space to use for your network and routes that space to your router, and your router routes it to your end machines. People far prefer using the Internet this way over using proxies.
Of course, if your ISP can't give you enough address space then you're stuck using RFC1918 (which is very common on v4, but it's hardly a normal way to run a network, just one you're forced into due to v4 being so exhausted.) The Internet won't be able to reach your network... but this isn't due to NAT because RFC1918 isn't NAT. It's not a firewall either because any inbound connections that do reach your network will work fine.
At this point, you'll add NAT so you can actually make working outbound connections. This is the opposite of a firewall. Your ISP will still be able to connect in too.
If you really wanted to, you could add NAT even when not using RFC1918. Any inbound connection that worked before you added it would keep working afterwards.
Having or not having NAT doesn't make any difference on who can connect in. That's why it's not a firewall, accidental or otherwise.
That then covers more than the simple, opaque, and inadequate terminology of "cones" used by the earlier RFCs. i.e. see https://www.rfc-editor.org/rfc/rfc4787
See the following article, with the table "NAT Cone Types" for an easier to understand piece, and the sub-set of combinations which the cone terminology covers. https://tailscale.com/blog/how-nat-traversal-works/#naming-o...
As to "implicit firewall", as has been indicated, there isn't really such a thing, just the filtering behaviour.
It is not uncommon for a CGNAT to have EIM and EIF, hence they're "full cone"; so that is what one will generally experience when tethering to a LTE/5G mobile network.