IEEE Network • September/October 2008 8 0890-8044/08/$25.00 © 2008 IEEE network address translator (NAT) commonly refers to a box that interconnects a local network to the public Internet, where the local network runs on a block of private IPv4 addresses as spec- ified in RFC 1918 [1]. In the original design of the Internet architecture, each IP address was defined to be globally 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 block can be reused in multiple local networks, as long as those networks do not directly talk to each other. Instead, they communicate with each other and with the rest of Inter- net through NAT boxes. Like most unexpected successes, the ubiquitous adoption of NATs was not foreseen when the idea first emerged more than 15 years ago [2, 3]. Had anyone foreseen where NAT would be today, it is possible that NAT deployment might have followed a different path, one that was better planned and standardized. The set of Internet protocols that were developed over the past 15 years also might have evolved dif- ferently by taking into account the existence of NATs, and we might have seen less overall complexity in the Internet com- pared to what we have today. Although the clock cannot be turned back, I believe it is a worthwhile exercise to revisit the history of network address translation to learn some useful lessons. It also can be worth- while to assess, or reassess, the pros and cons of NATs, as well as to take a look at where we are today in our under- standing of NATs and how best to proceed in the future. It is worth pointing out that in recent years many efforts were devoted to the development and deployment of NAT traversal solutions, such as simple traversal of UDP through NAT (STUN) [4], traversal using relay NAT (TURN) [5], and Teredo [6], to name a few. These solutions remove obstacles introduced by NATs to enable an increasing number of new application deployments. However, as the title suggested, this article focuses on examining the lessons that we can learn from the NAT deployment experience; a comprehensive sur- vey of NAT traversal solutions must be reserved for a sepa- rate article. I also emphasize that this writing represents a personal view, and my recall of history is likely to be incomplete and to contain errors. My personal view on this subject has also changed over time, and it may continue to evolve, as we are all in a continuing process of understanding the fascinating and dynamically changing Internet. How a NAT Works As mentioned previously, IP addresses originally were designed to be globally unique and globally reachable. This property of the IP address is a fundamental building block in supporting the end-to-end architecture of the Internet. Until recently, almost all of the Internet protocol designs, especially those below the application layer, were based on the aforementioned IP address model. However, the explo- sive growth of the Internet during the 1990s not only sig- naled the danger of IP address space exhaustion, but also created an instant demand on IP addresses: suddenly, con- necting large numbers of user networks and home comput- ers demanded IP addresses instantly and in large quantities. Such demand could not possibly be met by going through the regular IP address allocation process. Network address translation came into play to meet this instant high demand, and NAT products were quickly developed to meet the mar- ket demand. However, because NATs were not standardized before their wide deployment, a number of different NAT products exist today, each with somewhat different functionality and different technical details. Because this article is about the history of NAT deployment — and not an examination of how to traverse various different NAT boxes — I briefly describe a popular NAT implementation as an illustrative example. Interested readers can visit Wikipedia to find out more about existing types of NAT products. A NAT box N has a public IP address for its interface connecting to the global Internet and a private address fac- ing the internal network. N serves as the default router for all of the destinations that are outside the local NAT address block. When an internal host H sends an IP packet P to a A A 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. A Retrospective View of Network Address Translation Authorized licensed use limited to: IEEE Xplore. Downloaded on February 9, 2009 at 17:52 from IEEE Xplore. Restrictions apply.