IPv6 Network Address Translation
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.
About the Author
Jeremy Stretch is a freelance networking consultant, instructor, and the maintainer of PacketLife.net. He currently lives in Fairfax, VA on the edge of the Washington, DC metro area. Although primarily an R&S guy, he likes to get into everything, and runs a free Cisco lab out of his basement for fun. You can contact him by email or follow him on Twitter.
Comments
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
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.
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.
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.
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?
Great blog Stretch, I agree, let NAT die with 4. We can always get extra flash for the bigger routing tables!! :)