Home / Blogs

IPv6 Security Myth #3: No IPv6 NAT Means Less Security

We’re back again with part 3 in this 10 part series that seeks to bust 10 of the most common IPv6 security myths. Today’s myth is a doozy. This is the only myth on our list that I have seen folks raise their voices over. For whatever reason, Network Address Translation (NAT) seems to be a polarizing force in the networking world. It also plays a role in differentiating IPv4 from IPv6.

In IPv4, NAT (technically NAT overload or NAPT) is required for multiplexing due to the shortage of addresses. In IPv6 we have 340 trillion, trillion, trillion addresses available, and therefore no need for address sharing. This means that the NAT we have in IPv4 is not part of our IPv6 world. Some people keep saying this is a security issue, which brings us to today’s myth.

Myth: No IPv6 NAT Means Less Security
Reality: Stateful Firewalls Provide Security (Not NAT)

We can argue the merits of NAT, the end-to-end principle, and security until we’re blue in the face—and many have—but the reality is that NAT does not provide any real network security. Worse yet, it actually prevents many security measures and provides an additional attack surface for your network.

The cause for much of this confusion stems from the fact that NAT requires state. By “state” I mean that the NAT device must remember which internal addresses to swap for which external addresses, and vice verse. This in turn means that any device performing NAT overload must act as a stateful firewall.

A stateful firewall uses state to determine which packets to allow into the network. That is, it remembers when you send packets out and to whom so that it can allow packets back in only from those hosts with which you initiated communication. In other words, a stateful firewall stops all incoming traffic unless it is a reply to valid traffic that you sent.

While the NAT may provide a bit of obfuscation, by hiding your internal addresses, it is really this stateful firewall function that protects your network from unwanted intrusion.

What’s worse than giving NAT credit for the work of our trusty stateful firewall? NAT making you less secure. That obfuscation trait of NAT we mentioned earlier actually prevents IPsec, DNSSEC, Geolocation, and other applications—many of which are designed to provide security—from working.

NAT also introduces its own set of security flaws. NAT devices stand in front of your network as a single point of failure. All NAT’ed packets must terminate on the NAT device and get a new IP header with their new, translated, address. This means that every flow into and out of a NAT’ed network is wholly dependant on the NAT device, and consumes resources on the NAT device. This opens these devises up to many DoS attacks. An attacker can consume available connection state, available addresses or ports, or simply overload the CPU with ALG (Application Layer Gateway) or other requests.

The bottom line is that NAT is not a security feature and removing NAT from your network will NOT make it less secure. In fact, it may actually increase your overall security.

Can’t wait for the next IPv6 Security Myths post? Not to worry, you can check out tons of great IPv6 resources right now!

By Chris Grundemann, Creative|Technologist

Filed Under


It would be interesting to actually test Andrew McConachie  –  Jan 31, 2015 8:15 PM

It would be interesting to actually test the theory that IPv4/NAT is less secure than IPv6/no-NAT. In my mind the question is still open as to whether one is more or less secure than the other. There is something to be said for IPv4/NAT using RFC1918 addresses for internal hosts. It’s more than just obfuscation, attacking them requires using some form of address translation. Which means either compromising the NAT box, or creating fake state in the NAT box through abuse of uPnP or similar mechanism. Either way it requires extra work on the part of the attacker.

I would also never suggest deploying residential IPv6 without some kind of stateful security device between the residence’s hosts and the Internet. So IPv6 doesn’t do away with a stateful middle device(e.g. firewall), it only obviates the address and port translation problem.

As more ISPs roll out IPv6 maybe we can start to see if your theory holds true. There must be ISPs live now with both IPv4/NAT and IPv6/no-NAT. Can we get a comparison study to see which groups of hosts are facing the most security problems? This data should exist at this point in history. And it might finally put this debate to rest.

Security is about so much more than technical possibilities. We like to focus on the technology because it’s where we’re most comfortable, and can exact the most control. However, I’d bet most security breaches relevant to this discussion are more likely to be caused by misconfiguration, or lack of user understanding. In which case the tech is less relevant, and the social/psychological issues surrounding adoption become more interesting.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix

IPv4 Markets

Sponsored byIPv4.Global

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API


Sponsored byVerisign