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
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.
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.
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.
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.
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.