Summary

  • NAT could conserve globally unique IPv4 addresses at a network border, but applications that depended on address values needed additional repair beyond the translated IP header.
  • RFC 2993’s historical warning was about where that repair landed: application gateways, coordinated endpoint changes, local naming and support—not just a box in a router path.

A translator can perform its configured rewrite correctly and still leave an application unable to connect. The failure is not necessarily a bad translation table. It can begin when the same address has one meaning inside a private network, another outside it, and a third copy inside the application’s own messages.

That distinction was already visible in the 1994 proposal. RFC 1631 presented Network Address Translation as an incremental response to IPv4 address pressure: stub networks could reuse internal addresses, while a border device translated the subset of traffic that crossed into globally addressed space. The memo also acknowledged the exchange. The end-to-end significance of an IP address was reduced and replaced by state in the network. Where a site had more than one exit, the translators needed a consistent view of their mappings. It was a practical bridge, not a claim that the architecture had no cost.

By November 2000, Tony Hain’s RFC 2993 looked at NAT after six years of growing interest and deployment. Its central question was no longer whether a router could substitute one address for another. It was whether a service could keep working when an address appeared somewhere the translator did not inspect.

The answer depended on the application. A simple exchange between two endpoints through one NAT could be manageable. But some protocols carried IP addresses in their payloads; others relied on the packet header remaining consistent for checksums, authentication or security processing. A header-only translator could not repair every such assumption. Application Layer Gateways (ALGs) and proxies could help, but each one had to understand the protocol it was repairing. RFC 2775 had made a related point earlier that year: an ALG or proxy needed an update when a new address-dependent application arrived.

That turned “transparent” into a conditional promise. If the application neither exposed nor depended on the translated address, the border function might stay out of sight. If it did, someone had to coordinate the workaround across the places where that application ran. RFC 2993 contrasted a relatively simple two-endpoint case with redundant NAT paths and multiparty applications such as document sharing. It said the coordination complexity grew geometrically with endpoint count. The memo gives no equation or measured cost curve; the phrase describes the architectural scaling problem, not a benchmark.

Redundancy made the boundary stateful in a second way. Two translators on alternative paths had to agree on mappings for a device. If a connection’s state existed on one path and traffic moved to another, the new path could create a different mapping. Restoring the old route would not necessarily restore the original conversation. The address written into a packet was therefore not the whole state: the translator’s mapping and its location in the path mattered too.

The cost could move between organizations. RFC 2993 noted that an ISP-managed NAT might simplify one support surface while increasing local address and name administration. That is a burden-transfer claim in the memo, not a measured statement that every operator’s total costs rose. A local administrator might now have to reconcile overlapping private addresses after a merger, arrange internal and external name answers, or coordinate an application fix that had previously been invisible to the service provider.

Security sharpened the distinction between translation and policy. RFC 2993 warned that NAT—especially port translation—could create the impression of a security barrier without the deliberate access-control intent of a firewall. It also discussed compatibility problems for IPsec, DNS-related behavior and SNMPv3 authentication. These are protocol- and configuration-dependent mechanisms, not proof that every NAT device defeats every security protocol. A translator changes address-dependent evidence; it does not, by itself, decide which traffic should be allowed.

The later record shows the work becoming more explicit, not the issue disappearing. RFC 3022 replaced RFC 1631 with a description of traditional NAT in 2001. RFC 3235 gave application designers NAT-friendly guidance in 2002. Those documents do not prove that RFC 2993 caused a particular deployment or that all software followed the guidance. They do show how a border technique acquired an application-design literature around it.

RFC 2993’s useful historical contribution is therefore not a verdict that NAT always fails. It separates the border’s address-saving operation from the compatibility work needed above it. The translator might be installed at one gateway; the repair could require an application change on many endpoints, consistent mapping state across multiple paths and local control of names. The network did not make that work vanish. It changed who had to notice it and coordinate it.

Sources