Dec 022011

Spend 30 minutes with IPv6 every Friday!One big question in the IPv6 world is NAT, Network Address Translation.  IPv6 was built to reinstate end-to-end connectivity on the Internet and all connected networks. The vision was to avoid NAT. While waiting for IPv6, corporations and homes started to add NAT to their toolbox as a solution for all kinds of problems, not all solved by IPV6. This is the source for a lot of discussion and work. My personal opinion is that we should do everything we can to avoid NAT in IPv6 networks. But as long as we don’t have other solutions for some common problems, NAT will be seen in the IPv6 world too.

The reason why many people think you should avoid NAT in network design is that it breaks connectivity between hosts. This is easily seen in VoIP networks, where phones on the inside of a NAT wants to receive calls from phones or PSTN gateway services on the outside. With NAT, a lot of tools is needed and un-needed traffic is generated to be able to handle this situation. Without NAT, the solution would be simpler and much more straight-forward.

When building the new IPv6 network design, we need to separate security from reachability. Every IP host should be reachable from any other IP host, unless security policy prevents communication. Security policy is implemented in firewalls, not in the network design.

Private addresses that are unreachable from the Internet

The other issue is the use of private address space, not routable or usable on the Internet. In IPv4, these networks are specified in RFC 1918 -Address Allocation for Private Internets. In this RFC, the networks 192.168.x.x and 10.x.x.x (among others) are set aside for use inside NATed networks.

I just love NAT. It causes a lot of issues that requires professional assistance.There are many opinions on the use of NAT in IPv6, from the IETF hard core engineers that finally wants to get rid of NAT to network managers in companies that believe NAT and private networks to be part of their security architecture. There’s no simple answer, but I’ll try to give an overview here.


NAT doesn’t help with security. But…

NAT is not about security. It’s about using a shared public IP address for communication. Yes, the internal network is not obvious to people on the outside. But people who really want to know can analyse signatures in packets and figure out much about what’s inside anyway. Yes, computers on the outside can not open connections to the inside. In the VoIP world we have been forced to come up with a number of ways to break that, since you really want calls to come in. As long as there’s traffic going out, there will be oppurtunities to send packets inside. And as long as you read e-mail and surf the web, you’re downloading plenty of files to the inside. NAT feels good though.

IPv6 will add requirements on security for home devices – “routers”, “CPEs” or “modems”  – so that these devices will offer the same level of protection as NAT did for IPv4. This means adding a statefull firewall that has a default configuration that doesn’t allow new connections from the outside, that allows inside devices to set up new connections and allow established sessions to communicate. The IETF has published RFC 4864 and RFC 6092 to explain how these devices should be configured.  From the abstract of RFC 4864:

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of “amplifying” available address space is not needed in IPv6.  In addition to NAT’s many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site.  IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.

Remember: IPv6 hosts have multiple addresses

In IPv6, every host will have many IPv6 addressesIn IPv4, most computers has one address – a public IPv4 address or a private one, inside the NAT. With IPv6 every host has a range of addresses and, in addition, listens to a few multicast addresses. Applications select which address to use for every connection (following the rules in RFC 3484). One of the possible addresses is called a Unique Local Address (ULA), which is an address that is used for local communication in a site – within a company, within a campus or within a set of networks in branch offices.

With IPv6, You will have a vast address space

With IPv6, you will get a vast address space which gives you room to divide your network into many subnets. With a /48 IPv6 network, you can create 65.536 subnets, each with 64 bit addresses. Instead of using private addresses, like you did in IPv4, you can now use a dedicated part of your address space and just not add it to the routing tables. This means that this network will not be reachable from the outside (unless you change the routing tables), but it will still be unique regardless of changes in your network infrastructure. Many network engineers has been facing issues when trying to merge two networks with the same IPv4 address family from the RFC 1918 address space (like two networks named 192.168.0.x). Let’s learn from these mistakes and not repeat them when building the new network. NAT between two IPv6 networks are commonly refered to as NAT66.

IAB: NAT eliminates network renumbering

If you have a large network and change providers, there are no simple tools to renumber all servers, clients and systems. IP addresses sneak in to all kinds of things (even if most of these entries should be replaced by DNS names). This is a problem for IPv4 and will remain for IPv6. When creating IPv6 this issue was part of the problem picture and there was a lot of ideas on how to automatically renumber networks when changing from one provider-assigned IPv6 network to another. There is a lot of work still going on in this area, but so far NAT is still acknowledged as a solution if you have a need for being able to renumber your network.

Other types of NAT for migration to IPv6

In addition to the “old” NAT there are new types of NAT servers defined to assist users in the migration from IPv4 to IPv6. NAT64 works with special hooks in the DNS server so that applications seamlessly can communicate across the borders. We will talk more about these tools in another article.

Summary: NAT is not needed for address sharing, but maybe for other situations

In IPv4 networks, we solved the shortage of addresses by using NAT to share one public IP address between many hosts. In IPv6, we have no address shortage and do not need to share IP addresses any more. For other uses of NAT work is still going on to figure out how to solve these – but we will propably end up using NAT66 in some situations in our networks. By learning how the use of NAT and private address space breaks the network architecture and adds costs to projects like VoIP and causes additional delays in the network we will not add these by default when building IPv6 networks.

Spend some time following up on the links to learn more and form your own opinion. And please read this quote from a recent speech by Neelie Kroes, Vice-President of the European Commission responsible for the Digital Agenda:

We must make this transition. The alternative is that the Internet will begin to suffer; and innovation and economic growth will feel the consequences. These are not things we can afford at the moment. To all of you out there doing business on the Internet: governments, content providers, service providers, my message is clear. Switch to IPv6 as soon as possible. And we can start enjoying the amazing opportunities of the future Internet.


  • IAB, the Internet Architecture Board’s thoughts on IPv6 NAT – RFC 5902
  • RFC 6092:  Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service
  • RFC 6296 (Experimental): IPv6-to-IPv6 Network Prefix Translation
  • The Networking Nerd: What’s the point of NAT66?


  • Thanks to Simon Perreault, Viagénie, for reviewing this article and contributing input.