It’s tiem*) again: NAT66

Mika/ August 29, 2010/ Internet, Security

ITT *) : NAT66

(picture unrelated)

In this thread we discuss NAT

Maybe the picture is related.

We all want to have our communications as safe as possible and we choose appropriate security mechanisms to achieve this goal. We follow “Best Current Practices”, recommendations from security experts and we follow traditions in our own organization. And there is an old tradition, maybe too old to get it out of our heads:

NAT will add to security.

It will not. Full stop. No Discussion. The topic has been closed long ago and there is no need to microwave it and serve it as a quick midnight-snack just because you feel a little bit hungry, just because you have the feeling there is something missing. We are living on a new diet in the IPv6 world.

NAT has been designed for several reasons and none of those reasons had anything to do with security. NAT was born to ease the pain of renumbering your network in case you switch providers and to make better use of the available address space. The original RFC from 1994 (RFC 1631) states in the security section:

Unfortunately, NAT reduces the number of options for providing security.


On the other hand, NAT itself can be seen as providing a kind of privacy mechanism.

OK, I admit, a  little side effect is there, it adds to privacy. Marginally. It was not the design goal. in RFC 2663  (IP Network Address Translator (NAT) Terminology and Considerations) we can read:

9.0 Security considerations

Many people view traditional NAT router as a one-way (session)
traffic filter, restricting sessions from external hosts into their


The combination of NAT functionality, ALGs and firewalls will provide
a transparent working environment for a private networking domain.

I left out a few lines to get to the point: It’s not NAT which gives us security but the combination of Application Layer Gateways, Firewalls and NAT. Nat contributes only a little bit -and introduces several issues, which I don’t want to discuss here, they are described in the RFCs above.

Hopefully the IAB can clear that out

The IAB (Internet Architecture Board) tunes in exactly at this point: introduced issues versus gained security. Last Month, in July 2010, the IAB published RFC 5902 “IAB Thoughts on IPv6 Network Address Translation” which defends the original design of IPv6 with a an end-to-end communication model and puts the value of NAT in doubt:

As discussed in [RFC4864] “Local Network Protection”, Section 2.2, the act of translation does not provide security in itself. The stateful filtering function can provide the same level of protection without requiring a translation function.

And in RFC4864 the editors write about “perceived benefits” of NAT and how Local Network Protection for IPv6 can bring the same “perceived benefits”.

So get over it, don’t try to introduce the pains of NAT to developers, manufacturers of firewalls and routers and administrators again in IPv6. We suffered enough in IPv4.

If you need privacy: there are other tools designed specifically for that: Gateways, Anonymizers or the TOR Network.

Peace, Michael “MiKa” Kafka

*) Glossary:

ITT: “In This Thread”
Tiem: Time” like in Cute kitten (Safe for Work, just a cute kitten)

Share this Post