[chatmasta]

I didn't say NAT is a security feature. I said developers use NAT to benefit security. The security benefit of NAT is that it forces developers to assign a predictable, private IP address to each device/container/vm/box behind its "firewall," which the gateway can then use for enforcing QoS policies or port whitelisting. Sure, you can do this on IPv6. But IPv6 is more complicated to implement, because all tools support IPv4, and only some support IPv6.

[api]

How does that help security?

IPv6 has usability problems (I've written on this), but these are unrelated to security in any direct way.

The reason I call it toxic is that the idea that NAT helps security is a harmful superstition that spooks people about IPv6 adoption. It's also driven some to actually implement IPv6 NAT, which is kind of like strapping a horse feed bag on the front of your car.

There's a ton of superstition and cargo cultism in network security, since most people -- even developers -- don't understand much about how networks work.

[yusyusyus]

NAT is so painful. Even the specs are written with grossly overloaded terminology.

>The reason I call it toxic is that the idea that NAT helps security is a harmful superstition that spooks people about IPv6 adoption.

In all fairness, the common NAT implementation involves L4 params and the requisite state for ingress traffic. It makes like a filter that is "drop any" with respect to the NAT IP address (with the exception of in-state traffic). Further, it also limits the IP protocols available. Example, you will not likely be doing SCTP across your NAT and certainly it would be difficult to send directed OSPF packets during this[0] fun thing. It still leaves things to be done (like dropping internal IP space traffic on the external IFs), but the requisite components supply a lot.

I think I've seen the problem though. In general, network engineers have failed to break down the components of NAT: 1) State, 2) Rewrite, 3) A filter dropping traffic not matched by state. Fundamentally, the only thing we need to do in IPv6 is 1) state and 2) a filter. Their failure, combined with the packaging of components that NAT provides, feeds the valid points of the superstition while neglecting the details (what happens when we look at too big of a picture, or philosophical thing).

>It's also driven some to actually implement IPv6 NAT, which is kind of like strapping a horse feed bag on the front of your car.

The ignorance of management and "netwerk sekurity esperts" aside, NAT does have use cases in IPv6. Example, if we're performing renumbering frequently, does it make operational sense to roll over prefixes with RAs/DHCP? Maybe the expectation is for multiple prefix advertisement, but then which IP should be used for internal vs. external? Should all applications always rely on DNS? What are the implications for routing networks that may be designed with separate number spaces? The reasons for why these things may be done are not absolutely "wrong" or "bad design" and should not necessarily adopt a purist model.

[0]https://tools.cisco.com/security/center/content/CiscoSecurit...