With IPv6 do we need to use NAT anymore?

Question

I'm wondering how to use NAT with IPv6. It seems that you don't even need NAT anymore.

What exactly is the concept behind firewall configurations in IPv6 environments?

Answer 1

There is some widespread confusion about NAT.

NAT has never been meant to be used as a security feature. However, it so happens that in most cases (not all), when a machine has access to the Internet through NAT only, then the machine is somehow "protected". It is as if the NAT system were also, inherently, a firewall.

Let's see how it works:

• An IP packet has a source and a destination address. Each router, upon seeing the destination address, decides to which subsequent router the packet shall be sent.
• When a router implements NAT, it forwards outgoing packets under a guise; namely, the packets bear the router's external IP as source address, not the actual source. For incoming packets, the router does the reverse operation. The TCP/UDP port numbers are used to know to what internal host the packets relate.
• However, from the point of view of the router, the internal hosts have (private) IP addresses which are directly reachable. NAT is for communications between the internal hosts and machines beyond the router.

Let's take an example:

Inner <---> HomeRouter <---> ISPRouter <---> The Internet

"Inner" is your PC. "HomeRouter" is the router which does the NAT. "ISPRouter" is the router at your ISP.

The "firewall effect" is the following: Usually, even if "Inner" has an open port (it runs a remotely reachable service, e.g. a local web server on port 80), people from "the Internet" will not be able to connect to it. The reason is the following: There are two ways by which an IP packet may be transferred by HomeRouter to Inner:

1. An incoming packet may come with HomeRouter's address as destination, and targeting a port which HomeRouter knows to be associated with an outgoing connection from Inner to somewhere on the Internet. This works only for a connection which was initiated by Inner, and this implies that the port will not match that of the server which runs on Inner.

2. An IP packet contains Inner's private IP address as destination and is somehow brought to the attention of HomeRouter. But ISPRouter does not know Inner's private IP, and would not forward an IP packet meant for that address to HomeRouter. Source routing could be used to tag a packet with Inner's private IP address as destination and HomeRouter's public IP address as the intermediate host. If ISPRouter supports source routing, then such a packet will reach Inner, regardless of NAT. It so happens that almost no ISP actually supports source routing.

Therefore, the "firewall effect" of NAT relies on two properties:

1. Attackers are far away: Attackers do not inject packets directly on the link between the home router and the ISP; all their attempts must go through the ISP routers.
2. ISPs don't allow source routing. This is the (very) common case.

So in practice there are a lot of machines, in private homes and small businesses, which could be hacked into in a matter of seconds except that they benefit from the "firewall effect" of NAT.

---

So what of IPv6? NAT was designed and deployed (widely deployed) in order to cope with the scarcity of free IPv4 addresses. Without NAT, the IPcalypse would have already destroyed civilization (or triggered IPv6 actual usage, maybe). IPv6 uses 128-bit addresses, instead of the meagre 32-bit IPv4 addresses, precisely so that crude workarounds like NAT need not be used.

You can use NAT with IPv6, but it makes little sense - if you can live with NAT, why would you switch to IPv6 at all?

However, without NAT, there's no "firewall effect", flimsy as it might be. Most operating systems are now IPv6 ready, and will use it automatically if given the chance. Therefore, if an ISP decides to switch IPv6 on, just like that, then a lot of machines which were hitherto "hidden" behind a NAT will become reachable from the outside. This could well turn into a worldwide hacking orgy. It is no wonder that ISP are somewhat... reluctant.

To switch to IPv6 nicely, you have to couple its enabling with some solid, well-thought firewalling rules, which will prevent incoming connections which were not possible in a NAT world (with the caveats explained above), but are now feasible thanks to the magic of IPv6. The operational word here is "thought": This will require some time from some people, and that's not free.

So it can be predicted that IPv4 will be used and maintained as long as it can be tolerated, and, thanks to NAT and transparent proxies, this will be a long time (especially if we succeed at containing human population below 10 billions).

Answer 2

Biggest issue to me in removing NAT is the reduction of privacy. With IPv6 I notice all my LAN devices have a unique public IPv6 address, which allows each device on a LAN to be identified uniquely. Which then allows easier identification of individual devices and users.

Privacy implications like the ability to track your activity across domains. Ad providers obviously do this type of tracking already with cookies, but removing NAT makes their job easier to track an individual device.

Answer 3

Note: the details of this answer will assume you use a Linux box as your firewall. If you use another platform details may vary but most of the principles should still hold.

I'm wondering how to use NAT with IPv6.

Nat for ipv6 is strongly discouraged by IETF. nevertheless there are implementations out there if you really want it. For example linux added it in version 3.7.

The Linux implementation works in basically the same way as the Linux NAT implementation for IPv4. I can't speak to other implementations.

Seems that you don't even need it any more.

People use NAT for a variety of reasons.

1. Address availability, they want more addresses for internal hosts than they have public addresses.
2. Address independence, they want to maintain their internal addresses independent of changes to their connectivity.
3. Privacy, they want to hide the details of their internal network and of which internal host is making the request from the outside world.
4. Security, a NAT ends up acting as a crude stateful firewall (though it may not be a very good one). Furthermore it is likely to fail closed, if the NAT rules fail to load then the likely result is the absence of connectivity rather than wide open connectivity.

Equally though NAT has a number of downsides (and at least some of those downsides have security implications).

1. Some protocols may be broken by the NAT (though this may also be true of stateful firewalls)
2. Every connection has to be tracked and there is a limited supply of ports, this can lead to denial of service vulnerabilities.
3. When abuse is detected NAT can hide the source of the abuse.
4. Handling of incoming services can be troublesome. Access by local clients to external IPs can be a particular point of complexity.

Ipv6 solves the address shortage, it goes some way to solving the problem of ISP-independence by allowing you to run public and private addresses in parallel (though that creates issues of it's own). Privacy extensions hide which computer on a subnet is making a request but they don't hide what subnet it is on.

So what exactly is the concept behind firewall configurations in IPv6 environments?

You can do stateful packet filtering without NAT, for example a basic configuration to allow all outgoing connections while forbidding incoming connections might look something like.

ip6tables -P FORWARD DROP
ip6tables -A FORWARD -i ethinternal -j ACCEPT
ip6tables -A FORWARD -m conntrack –ctstate ESTABLISHED,RELATED -j ACCEPT

The firewall still keeps track of connections in much the same way a nat would but it only uses that information to filter packets, not to perform translation.

One thing you need to be careful about is making sure your firewall fails closed. I would suggest that you DO NOT enable forwarding in sysctl.conf, instead enable it at the end of your firewall script and use "set -e" in your firewall script. That way forwarding is only enabled if the firewall script runs successfully.

If you also want to filter traffic to/from the firewall itself you have to think about ICMP. Some types of ICMP need to be allowed from link local or the network will break badly.

Other than that it's really not that much different from ipv4, decide what you want to allow and allow it.

Answer 4

NATs are not really magically more secure than public addresses (and have a lot of nasty warts of their own, due to the nature of address translation). To route to your private ipv4 address, an attacker simply needs to point at your router, and then it's entirely up to the firewall to filter out that traffic.

The switch to ipv6 won't change anything in that regard, except that your filtered subnet will be world-routable instead of only attacker-routable. Everything else remains the same -- if you need to restrict an ipv6 subnet, you subclass your /64 and apply firewall rules to filter out which traffic is allowed to get to it.

Answer 5

NAT is a technique a router can use to allow the hosts connected through it to share a single IP address.

The router keeps track of which hosts have connections and hosts can ask to have certain data routed towards them. Games for example will typically ask for UDP traffic at a certain port to be redirected.

Reversely any packet that doesn't seem to be for anyone the router knows (like a letter without a readable address) will be discarded. That makes it work like a firewall.

IPv6 has practically unlimited addresses, and households/routers will likely have plenty to distribute. NAT is no longer needed.

That removes the firewall effect. It will likely be replaced by proper firewalls that are equally restrictive and annoying to provide similar security for foolish end users. Having proper firewalls is a big move ahead, and I hope it'll happen sooner rather than later.

Answer 6

The fundamental issue that makes the internet architects uncomfortable with NAT is that it appears to conflict with the end to end principle. This basically says that intermediate layer 3 routers should ignore layer 4 connection state so that packets can be routed efficiently down alternative routes. However, NAT is easy to implement in the context of a stateful firewall, and this is how it should be viewed.

The need for firewalls became apparent as the internet approached its 20th birthday in the late 80s. Nowadays, all data passing in and out of a private network is constrained to pass through a firewall, which needs to track connection state to be able to filter packets effectively.

Although it wasn’t at all clear in 1994, if you take away the address reuse requirement, then NAT is a firewall function whose primary purpose is to prevent private data leaving the private network.

Specifically, when a client initiates a connection to an external server, the private part of the source address (routing prefix, host identifier and port) used within the private network should never be allowed to leak out onto any external network.

The Linux Ip6tables NAT has been available since kernel version 3 and does a thoroughly professional job, e.g. by producing unique random host addresses which are only valid for a single session.

Unfortunately this feature has not been fully documented on the grounds that no one has come up with a use case! Well, here it is. And while you’re at it can you also make sure port numbers are included.

If viewed in this way, it is the firewall that has a requirement to hold state, and NAT is performed by the firewall, so there never has been any such thing as a NAT router. The end to end principle does not apply.

I think the lesson is that internet architects should stick to designing internet protocols, and leave firewall design to security architects.

Answer 7

IPv6 does away with the need for destination NAT for incoming connections, instead delivering them to hosts on the local link with the (public) destination address intact. Outward facing routers advertise externally available prefixes to all internal hosts, and then hosts are free to add addresses with these prefixes on to their interfaces on the local link to receive the incoming connections.

I am not convinced that we have done away with the need for source NAT on outgoing packets. The default appears to require the client to allocate itself a public address in the same way, exposing it to the outside world by using the same host identifier as the link local addresses.

Well I’m sorry, this is leaking private information out to the public (untrusted) internet, which in my book is a breach of confidentiality - one of the three pillars of security as we understand it today.

I believe NAT should be used to translate the private portion of the source address (routing prefix, host identifier and port) to a randomised value on any firewall protecting the boundary between the public internet and a private network.