Internet centralization and the original sin of NAT

In the days before the Internet, running an FTP, game or web server from one's home was considered unusual. People generally view the notion of an IP address being publicly known online as exotic or even concerning. Understanding the inner workings of the Internet often involves distinguishing servers from personal computers. The concept of peer-to-peer communication, whether through WebRTC or other methods, is an alternative that challenges the status quo.

To address the issues of IP address depletion and routing scalability, Network Address Translation (NAT) was introduced in RFC 1631 in 1994. The short-term solution aimed at alleviating these problems was CIDR (Classless InterDomain Routing), while long-term solutions included various proposals for new internet protocols featuring larger addresses.

Although NAT provided a workaround to address depletion and routing scalability, it fundamentally altered the Internet's original design. Most home routers use NAT by modifying the network address information within IP packet headers. As a result, multiple devices can share a single IP address from the perspective of other devices on the network.

To connect to an external server while utilizing NAT, an intricate process unfolds. The request from an external server first reaches the user's router, which then modifies the packet to match the user's public IP address. In case an external server attempts to initiate communication, the router forwards the packet to the user's internal IP address.

This workaround, known as port forwarding, is commonly employed by users to overcome the limitations imposed by NAT.

Despite the inconvenience of port forwarding, it remains the most widely known remedy to NAT's constraints. However, this solution has its drawbacks. As there can only be one device mapped to a single public IP and port, multiple devices cannot operate a service on the same public IP and port simultaneously. This limitation poses a significant challenge for enterprises and universities that rely on private IP addresses and often result in on-prem hosting being unfeasible without resorting to more complex arrangements.

Moreover, for users with Internet Service Providers (ISPs) employing Carrier-Grade NAT (CGNAT), port forwarding becomes even more challenging, as they do not have control over the device responsible for translation. With CGNAT, users receive a fraction of an IP address, exacerbating the issue.

Another consequence of NAT is the inherent reluctance among users to manage its intricacies. Consequently, UPnP (Universal Plug and Play) and its successors NAT-PMP and PCP emerged as a response to address the issue of users being unwilling to manually configure port forwarding. These technologies enable software to request routers to forward ports directly, circumventing the need for manual configuration.

However, UPnP's reliability is often compromised due to buggy early implementations and security concerns. Furthermore, many users disable UPnP due to misguided security apprehensions, as they view the possibility of unauthorized access to their computers as exotic or even dangerous.

To facilitate communication between devices behind NAT, Session Traversal Utilities for NAT (STUN) was developed. STUN functions by querying a server on the public internet to determine how a packet appears from the perspective of a remote device. Upon receiving a response, STUN returns the user's public IP address and port to which the NAT allocated, such as 146.7.15.85:60612.

The method is particularly effective under "cone NAT" configurations, where identical external port mappings are employed for all outbound connections. In this scenario, the user can share the mapping with peers, enabling them to establish connections directly. This approach is referred to as hole punching.

However, STUN encounters challenges when dealing with "symmetric NAT," a common configuration in Carrier-Grade NAT (CGNAT) and institutional networks. In such instances, distinct public ports are assigned for every unique destination. Consequently, STUN mappings become ineffective for connecting to peers, as each peer perceives the user differently than the STUN server.

To address these shortcomings, Interactive Connectivity Establishment (ICE) was introduced. ICE combines multiple techniques—such as direct connections, STUN-discovered external addresses, and TURN relays—into a sequence that prioritizes the most effective method. This approach employs direct connections wherever possible, STUN mappings when feasible, and TURN relays as a last resort.

Despite the various solutions proposed, the fundamental intention of the Internet remains unfulfilled, as NAT continues to shape our online experiences.