The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
IPv6 Network Address Translation
By stretch | Monday, July 19, 2010 at 1:12 a.m. UTC
RFC 5902 was published last week by the Internet Architecture Board (IAB) to establish its stance on the potential standardization of IPv6 network address translation (NAT). This informational RFC summarizes popular arguments which have been cited in support of employing NAT for IPv6. A brief review is provided in this article. (For the purposes of this article, the term NAT is meant to include port address translation.)
Arguments for IPv6 NAT
Renumbering Avoidance
Use: Without NAT, an organization which has addressed its network using provider-assigned (PA) public address space must re-address its entire network if it desires to switch to a new upstream provider. This is obviously an incredibly labor-intensive, lengthy, and disruptive procedure. To avoid this, many organizations address their internal structure from private RFC 1918 address space and NAT to public addresses at edge routers. Should they need to switch to a new provider, only the NAT translations rules must be changed.
Alternative: Organizations which utilize provider-independent (PI) address space (which is allocated directly from a registry) are not affected by this, as switching to a different upstream provider does not require renumbering. However, the use of PI address space contributes to growth in the global routing table.
Site Multi-homing
Use: Organizations utilizing multiple Internet service providers may opt to configure NAT on boundary routers. Each boundary router translates the internal address space to the PA space of its respective provider in an effort to preserve aggregation efficiency and avoid contributing to the growth of the global routing table.
Alternative: Although the RFC states that no solution for this dilemma has been deployed to date, this is exactly the problem which the Location and Identity Separation Protocol (LISP) has been created to solve. Over the next few years we should begin to see substantial deployment of LISP for both IPv4 and IPv6.
Homogeneous Edge Network Configurations
Use: A residential and small business ISP serving numerous small sites may opt to employ NAT at the edge of each customer network so that each customer is addressed out of the same private address space (e.g. 192.168.0.0/24). This provides a uniform appearance of all customer networks for the convenience of support personnel.
Alternative: IPv6 allows for multiple IP subnets to be configured on a link; a customer network can be addressed using both deterministic link-local addresses and unique global addresses to meet the requirement for uniformity while preserving end-to-end connectivity.
Network Obfuscation
Use: NAT may be used to obscure the layout and size of a private network. However, the RFC notes that with increased obfuscation comes an increased difficulty in supporting complex higher layer protocols across a translation boundary.
Alternative: The RFC does not mention an alternative to NAT. However, one can argue that the greatly increased IPv6 address space in combination with due diligence in secure design offers a sufficient solution.
Simple Security
Use: NAT is commonly cited, especially with regard to residential deployments, as providing a measure of security in that connections cannot be initiated from the outside through the PAT boundary toward the internal network.
Alternative: Simple stateful filtering achieves the same effect without the need for address translation.
Personal Opinion
Personally, it seems that perhaps we have gotten so accustomed to IPv4 NAT that we are simply making excuses to keep it around for its comfort factor. As RFC 5902 reveals, there really aren't many strong arguments for IPv6 NAT. I would argue that the single biggest impediment to assigning globally routable address space to all organizations large and small is the valid concern regarding growth of the global IPv6 routing table. However, I think we need to see how big a problem it might become, and how effective LISP proves to be, before we begin resorting to NAT. The potential to preserve end-to-end connectivity across the IPv6 Internet is worth the effort.
Posted in IPv6
Comments
July 19, 2010 at 8:37 p.m. UTC
Great blog Stretch, I agree, let NAT die with 4. We can always get extra flash for the bigger routing tables!! :)
July 19, 2010 at 10:46 p.m. UTC
What about security issues? I am not a nat fan boy. Also money ripe arin and all of them owns the space trillions of ips don't meant to be less expensive. I think nat should stay longer in time.
Kind regards
July 21, 2010 at 8:46 p.m. UTC
luismg: Security is easily dealt with. NAT is security by being broken (no end to end connectivity). You can easily replicate this with a stateful firewall, and, really, you should have one of those anyways.
As for cost, it is true that IPv6 will cost money. However, as IPv4 becomes more and more scarce, you will likely see the cost of IPv4 space increase a lot.
July 21, 2010 at 8:58 p.m. UTC
Any security benefits of NAT/PAT can be achieved with a stateful firewall + default deny policy.
My Opinion: The fact that NAT/PAT breaks the end-to-end connectivity model is enough reason to not carry its baggage into a new generation of IP. NAT was a hack developed due to IPv4 exhaustion concerns. Without it, we'd have run out of IPv4 space LONG ago; but IPv6's address space is wide enough we'll not run out of IP space within our lifetimes.
July 23, 2010 at 12:33 p.m. UTC
For those who are really wanting to live in the old public/private address space paradigm, they still have the option of using site-local addressing and application-layer proxies to do so.
It is very likely that some true believer will buld a NAT implementation for IPv6. I don't see it becoming sufficiently ubiquitous that anyone will make allowances for such an animal though... which is good.
August 2, 2010 at 8:50 p.m. UTC
A thought...
NAT (and particularly PAT) does provide you some security. All public space at my job currently exists only outside, between the firewall and the Internet routers. There is no route for Internet traffic to reach an internal RFC1918 address, which might be multiple hops away.
Perhaps it's just me, but it seems safer than an IP space that would be reachable if there were no firewall acls in place to block it. Human error being what it is and all.
...and a question...
With IPv6, how does an organization multi-home geographically? Today we use NAT and PAT to present ourselves as provider-independent IP space that is associated with a particular city. (ex. four locations, four separate /24 blocks) We advertise that space to multiple providers at each location. We have multiple default routes (again, per city) which dictate how our internal users and servers reach the Internet. Everything is tidy, insofar as all traffic goes through translation before it hits the edge, and therefore all the return packets come back to the correct city and (most importantly) firewall.
If we move to v6, without doing NAT or falling back to using only one city to reach to the Internet, traffic would undoubtedly flow asymmetrically with return packets being dropped at the wrong city/firewall.
I'm new to v6, but in what little reading I've done, I don't see a solution to this problem. Doing a PAT per city seems like the only way...
What am I missing?
October 29, 2010 at 8:02 p.m. UTC
NAT IS a usefull tool to address a number of issues. Anyone telling you different is a P2P application developer or trying to sell you something.
1) Simple Security : Many:1 NAT acts as an EXTRA layer of protection, ON TOP of a statefull firewall. It protects many hosts in the typical network that require some OUTBOUND connectivity but should NEVER recieve INBOUND connections. FW filters can be misconfigured. That's what defence in depth is all about MULTIPLE layers of compensating controls.
2) Archetecture abstraction: It allows you to make whatever the heck changes you want to your internal infrastructure without changing anything about your external advertisements and vice versa.
3) Privacy: It makes it difficult to profile both your network and individual devices on it and track thier usage.
December 28, 2010 at 2:30 a.m. UTC
Geographic multi-homing is a real problem without NAT, as Andrew details above. And no implementable solutions have yet appeared to address all the problems. And PI addresses aren't the [full] answer. Still unresolved is how to avoid asymmetrical routing across two geographically diverse firewalls connecting an enterprise to the Internet (even via the same ISP). Communication fails if the source and the destination don't agree on which of multiple firewalls to route their packets through...
December 29, 2010 at 8:42 p.m. UTC
This is absolutely an interesting topic. I just hope everything will be sorted out before we 100% confidently trash v4.
January 24, 2012 at 9:54 p.m. UTC
NAT is very useful on test cluster subnet (with 1 PC, multi-homed, as gateway).
With NAT, I can only create 1 configuration that can easily be duplicated no n number of needed copies, all using exact same configuration.
The test cluster will be easily moved from 1 corporate subnet to another, or even make it standalone if really needed.
It's not about conserving real IP address anymore, it's simply about homogeneous cluster configuration. Simplifying thing with static IP allocation, no DHCP is required.
In my test cluster, I created a virtual Ubuntu server runnning on my PC (multi-homed) gateway. And I only need 1 single master image copy of this virtual Ubuntu server. Simply have multiple copies of it to have n number of test cluster.
Without NAT, I have to have unique Ubuntu Server image of each test cluster. This is crazy and extremely tedious to maintain.
I wish IAB comes to senses and allowing IPv6 NAT.