NAT: A Love and Hate Story
17/10/2023
By Henri Godoy – Computer Network Analyst | Professor Ph.D. | IPv6 Evangelist
In 1996, Brazil was in the early phases of its Internet expansion. Subscribing to an Internet Service Provider, as it was known at the time, meant paying based on the number of hours you were connected. Any additional minutes consumed beyond the subscription incurred extra charges on the monthly bill. Internet connections were through dial-up telephone lines, and each user received a public IP address at their home. Usually, an Internet Service Provider started with around 30 telephone lines and required only a small set of public IP addresses.
Back then, everything seemed to be running smoothly and as expected. We had a very simple user identification system and IP registration through TACACS or RADIUS. It was possible to engage in harmless remote access pranks, like opening and closing a user’s CD-ROM drive using NetBus and BackOrifice, or even execute a Ping of Death attack. This was because every user connected to the Internet via dial-up modem received a globally accessible IP address. Access controls, firewalls and security concepts of how to filter and block threats were still under development and study.
But how did you manage to find the IP address of a connected user? There were various methods, but the simplest one involved using mIRC, an IRC client program (Internet Relay Chat), to start a private chat with your friend. Then, you simply needed to run a netstat command to reveal the remote user’s IP address.
On a global scale, in 1991, the IETF (Internet Engineering Task Force) was addressing the imminent exhaustion of IPv4 addresses due to the rapid growth of the Internet, with a projected depletion date by the end of 1994. As a quick solution, the CIDR (Classless Inter-Domain Routing) was adopted to subnet the class-based IP assignments (A, B, C) into smaller blocks, aiming to efficiently meet the demands of those seeking IP addresses to support Internet expansion. This provided some relief to IPv4, but it proved insufficient.
During my time working for the Internet Service Provider, we had a /24 block of IPv4 addresses assigned to Embratel. Half of these were used for our commercial dial-up users, and the other half was reserved for administrative purposes and the servers that supported the provider. Subsequently, there was an increase in demand from computer labs, a rise in dial-up lines, the expansion of servers, and a growing administrative staff at the university. Soon, we ran out of available IPv4 addresses to support this growth.
Simultaneously, as the internet expanded beyond expectations, an RFC 1918 was published in 1996, outlining “Internet Best Practices” and introducing the concept of private IP addresses. The Internet Assigned Numbers Authority (IANA) reserved three blocks of IP address space for private networks, as described in Figure 1.
(Free access, no subscription required)
The initial idea was to preserve or use public IP addresses only for hosts that required external or global access, with the aim of extending the lifespan of IPv4 addresses. Hosts that communicated with others within the same internal network, local services, printers, file sharing, could now be assigned private IP numbers.
Until then, the difference between private and public networks (internal and external) and the devices associated with each was well-established. However, that’s when frustration set in among us and networking professionals. Altering IP, DNS, and Gateway configurations when a private host suddenly needed an external connection (public IP) became a cumbersome and impractical task.
This is how a brilliant idea emerged to simplify everyone’s life: the development of a technique for translating and routing IP addresses within an internal (private) network, allowing transparent access to an external (public) network, and vice versa, without the need to change host configurations. This concept gave birth to the term NAT (Network Address Translation), which was formally described in RFC 2663 in 1999.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of LACNIC.