Switching to IPv6 implies dropping NAT. Is that a good thing?

Ernie asked:

This is a Canonical Question about IPv6 and NAT


So our ISP has set up IPv6 recently, and I’ve been studying what the transition should entail before jumping into the fray.

I’ve noticed three very important issues:

  1. Our office NAT router (an old Linksys BEFSR41) does not support IPv6. Nor does any newer router, AFAICT. The book I’m reading about IPv6 tells me that it makes NAT “unnecessary” anyway.

  2. If we’re supposed to just get rid of this router and plug everything directly to the Internet, I start to panic. There’s no way in hell I’ll put our billing database (With lots of credit card information!) on the internet for everyone to see. Even if I were to propose setting up Windows’ firewall on it to allow only 6 addresses to have any access to it at all, I still break out in a cold sweat. I don’t trust Windows, Windows’ firewall, or the network at large enough to even be remotely comfortable with that.

  3. There’s a few old hardware devices (ie, printers) that have absolutely no IPv6 capability at all. And likely a laundry list of security issues that date back to around 1998. And likely no way to actually patch them in any way. And no funding for new printers.

I hear that IPv6 and IPSEC are supposed to make all this secure somehow, but without physically separated networks that make these devices invisible to the Internet, I really can’t see how. I can likewise really see how any defences I create will be overrun in short order. I’ve been running servers on the Internet for years now and I’m quite familiar with the sort of things necessary to secure those, but putting something Private on the network like our billing database has always been completely out of the question.

What should I be replacing NAT with, if we don’t have physically separate networks?

My answer:

RFC 4864 describes IPv6 Local Network Protection, a set of approaches for providing the perceived benefits of NAT in an IPv6 environment, without actually having to resort to NAT.

This document has described a number of techniques that may be combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Local Network Protection, retain the concept of a well-defined boundary between “inside” and “outside” the private network and allow firewalling, topology hiding, and privacy. However, because they preserve address transparency where it is needed, they achieve these goals without the disadvantage of address translation. Thus, Local Network Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages.

It first lays out what the perceived benefits of NAT are (and debunks them when appropriate), then describes the features of IPv6 which can be used to provide those same benefits. It also provides implementation notes and case studies.

While it’s too long to reprint here, the benefits discussed are:

  • A simple gateway between “inside” and “outside”
  • The stateful firewall
  • User/application tracking
  • Privacy and topology hiding
  • Independent control of addressing in a private network
  • Multihoming/renumbering

This pretty much covers all the scenarios in which one might have wanted NAT and offers solutions for implementing them in IPv6 without NAT.

Some of the technologies you will use are:

  • Unique local addresses: Prefer these on your internal network to keep your internal communications internal and to ensure that internal communications can continue even if the ISP has an outage.
  • IPv6 privacy extensions with short address lifetimes and not-obviously structured interface identifiers: These help prevent attacking individual hosts and subnet scanning.
  • IGP, Mobile IPv6 or VLANs can be used to hide the topology of the internal network.
  • Along with ULAs, DHCP-PD from the ISP makes renumbering/multihoming easier than with IPv4.

(See the RFC for complete details; again, it’s much too long to reprint or even take significant excerpts from.)

For a more general discussion of IPv6 transition security, see RFC 4942.

View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.