A Retrospective View of Network Address Translation
Total Page：16
File Type：pdf, Size：1020Kb
ZHANG LAYOUT 9/5/08 1:03 PM Page 8 A Retrospective View of Network Address Translation Lixia Zhang, University of California, Los Angeles Abstract Today, network address translators, or NATs, are everywhere. Their ubiquitous adoption was not promoted by design or planning but by the continued growth of the Internet, which places an ever-increasing demand not only on IP address space but also on other functional requirements that network address translation is per- ceived to facilitate. This article presents a personal perspective on the history of NATs, their pros and cons in a retrospective light, and the lessons we can learn from the NAT experience. network address translator (NAT) commonly I also emphasize that this writing represents a personal refers to a box that interconnects a local network view, and my recall of history is likely to be incomplete and to to the public Internet, where the local network contain errors. My personal view on this subject has also runs on a block of private IPv4 addresses as spec- changed over time, and it may continue to evolve, as we are Aified in RFC 1918 [1]. In the original design of the Internet all in a continuing process of understanding the fascinating architecture, each IP address was defined to be globally and dynamically changing Internet. unique and globally reachable. In contrast, a private IPv4 address is meaningful only within the scope of the local net- work behind a NAT and, as such, the same private address How a NAT Works block can be reused in multiple local networks, as long as As mentioned previously, IP addresses originally were those networks do not directly talk to each other. Instead, designed to be globally unique and globally reachable. This they communicate with each other and with the rest of Inter- property of the IP address is a fundamental building block net through NAT boxes. in supporting the end-to-end architecture of the Internet. Like most unexpected successes, the ubiquitous adoption of Until recently, almost all of the Internet protocol designs, NATs was not foreseen when the idea first emerged more especially those below the application layer, were based on than 15 years ago [2, 3]. Had anyone foreseen where NAT the aforementioned IP address model. However, the explo- would be today, it is possible that NAT deployment might sive growth of the Internet during the 1990s not only sig- have followed a different path, one that was better planned naled the danger of IP address space exhaustion, but also and standardized. The set of Internet protocols that were created an instant demand on IP addresses: suddenly, con- developed over the past 15 years also might have evolved dif- necting large numbers of user networks and home comput- ferently by taking into account the existence of NATs, and we ers demanded IP addresses instantly and in large quantities. might have seen less overall complexity in the Internet com- Such demand could not possibly be met by going through pared to what we have today. the regular IP address allocation process. Network address Although the clock cannot be turned back, I believe it is a translation came into play to meet this instant high demand, worthwhile exercise to revisit the history of network address and NAT products were quickly developed to meet the mar- translation to learn some useful lessons. It also can be worth- ket demand. while to assess, or reassess, the pros and cons of NATs, as However, because NATs were not standardized before well as to take a look at where we are today in our under- their wide deployment, a number of different NAT products standing of NATs and how best to proceed in the future. exist today, each with somewhat different functionality and It is worth pointing out that in recent years many efforts different technical details. Because this article is about the were devoted to the development and deployment of NAT history of NAT deployment — and not an examination of how traversal solutions, such as simple traversal of UDP through to traverse various different NAT boxes — I briefly describe a NAT (STUN) [4], traversal using relay NAT (TURN) [5], and popular NAT implementation as an illustrative example. Teredo [6], to name a few. These solutions remove obstacles Interested readers can visit Wikipedia to find out more about introduced by NATs to enable an increasing number of new existing types of NAT products. application deployments. However, as the title suggested, this A NAT box N has a public IP address for its interface article focuses on examining the lessons that we can learn connecting to the global Internet and a private address fac- from the NAT deployment experience; a comprehensive sur- ing the internal network. N serves as the default router for vey of NAT traversal solutions must be reserved for a sepa- all of the destinations that are outside the local NAT address rate article. block. When an internal host H sends an IP packet P to a 8 0890-8044/08/$25.00 © 2008 IEEE IEEE Network • September/October 2008 Authorized licensed use limited to: IEEE Xplore. Downloaded on February 9, 2009 at 17:52 from IEEE Xplore. Restrictions apply. ZHANG LAYOUT 9/5/08 1:03 PM Page 9 public IP destination address D located in the global Inter- RFC 1287 also discussed three possible directions to extend net, the packet is routed to N. N translates the private IP address space. The first one pointed to a direction similar source IP address in P’s header to N’s public IP address and to current NATs: adds an entry to its internal table that keeps track of the mapping between the internal host and the outgoing packet. Replace the 32-bit field with a field of the same size but with a This entry represents a piece of state, which enables subse- different meaning. Instead of being globally unique, it would be quent packet exchanges between H and D. For example, unique only within some smaller region. Gateways on the bound- when D sends a packet P’ in response to P, P’ arrives at N, ary would rewrite the address as the packet crossed the boundary. and N can find the corresponding entry from its mapping table and replace the destination IP address — which is its RFC 1335 [3], published shortly after RFC 1287, provided own public IP address — with the real destination address a more elaborate description of the use of internal IP address- H, so that P’ will be delivered to H. The mapping entry times es (i.e., private IP addresses) as a solution to IP address out after a certain period of idleness that is typically set to a exhaustion. The first article describing the NAT idea, “Extend- vendor-specific value. In the process of changing the IP ing the IP Internet through Address Reuse” [10], appeared in address carried in the IP header of each passing packet, a the January 1993 issue of ACM Computer Communication NAT box also must recalculate the IP header checksum, as Review and was published a year later as RFC 1631 [11]. well as the checksum of the transport protocol if it is calcu- Although these RFCs can be considered forerunners in the lated based on the IP address, as is the case for Transmis- development of NAT, as explained later, for various reasons sion Control Protocol (TCP) and User Datagram Protocol the IETF did not take action to standardize NAT. (UDP) checksums. The invention of the Web further accelerated Internet From this brief description, it is easy to see the major bene- growth in the early 1990s. The explosive growth underlined fit of a NAT: one can connect a large number of hosts to the the urgency to take action toward solving both the routing global Internet by using a single public IP address. A number scalability and the address shortage problems. The IETF took of other benefits of NATs also became clear over time, which several follow-up steps, which eventually led to the launch of I will discuss in more detail later. the IPng development effort. I believe that the expectation at At the same time, a number of drawbacks to NATs also the time was to develop a new IP within a few years, followed can be identified immediately. First and foremost, the NAT by a quick deployment. However, the actual deployment dur- changed the end-to-end communication model of the Inter- ing the next ten years took a rather unexpected path. net architecture in a fundamental way: instead of allowing any host to talk directly to any other host on the Internet, the The Planned Solution hosts behind a NAT must go through the NAT to reach oth- As pointed out in RFC 1287, the continued growth of the ers, and all communications through a NAT box must be ini- Internet exposed strains on the original design of the Internet tiated by an internal host to set up the mapping entries on architecture, the two most urgent of which were routing sys- the NAT. In addition, because ongoing data exchange tem scalability and the exhaustion of IP address space. depends on the mapping entry kept at the NAT box, the box Because long-term solutions require a long lead time to devel- represents a single point of failure: if the NAT box crashes, it op and deploy, efforts began to develop both a short term and could lose all the existing state, and the data exchange a long-term solution to those problems. between all of the internal and external hosts must be restart- Classless inter-domain routing, or CIDR, was proposed as a ed.