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.

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.

While this article doesn’t extensively cover the various types of NAT, the most frequently used ones include Outbound NAT (Masquerade), NAT Port (NAPT), and Bidirectional NAT, offering options to suit various needs and preferences. An example of a basic NAT setup is provided in Figure 2.

That was the answer to the challenges we faced back then, not only for me but also for numerous Internet service providers. As broadband ADSL users rapidly increased and radio-based providers entered the scene,  it became impossible to assign public IPs to all end customers as it was done before.

Many emphasize the advantages of using NAT. Some are highly controversial and have already been the subject of heated discussions involving security and network expansion (or obscurity) due to not being in direct contact with the external world. Please leave your comments.

The truth is, NAT made things much easier and was widely appreciated. It was like having a perfect magic recipe, using Squid proxies and IP/Port redirections and mappings with IPchains and IPtables on Linux. We’ve been using NAT for over 20 years now, and its convenience has become such a fundamental part of our routine that adjusting to a life without it would be a challenge. We became so attached to this practice that many now find it difficult to move away from it.

Is there a solution for this? Do we need a NAT Anonymous group in Brazil?

Yes, there is a solution, and it’s called IPv6. We are presented with the first genuine opportunity to return to the era of the world’s only protocol migration, which occurred in 1983 (40 years ago). With the abundance of IPv6 addresses, there’s no longer a need for address conservation, and we’ll revert to the days of 1996 when each user had a public address at home, now referred to as global.

But the transitional phase for IPv6 is indeed using NAT, and many people inquire about this, indicating that we’re still facing the same challenge. So, it seems we’re stuck in the same cycle. There’s no easy way to break free from this habit.

The translation methods employed in contemporary transition mechanisms, like NAT64, 464XLAT, and SIIT-DC, remain essential today much like they were back in 1996. However, we now realize that a solution is emerging, a way forward, and we can leverage the knowledge gained (or neglected) over these twenty-plus years of dealing with NAT. This understanding has made it clear that it is possible to establish end-to-end connectivity for Internet users.

Therefore, we shouldn’t resign ourselves to a long period of reliance on IPv6 transition tools. We must start envisioning a world where IPv6 is the only choice for services, apps, online gaming, streaming, as soon as possible. The sooner we adopt IPv6 as the remedy, take action, and protect ourselves from the addiction of NAT, the quicker we’ll restore our digital health and witness the resolution and healing of this issue.