The universally unique 32-bit address was a central tenet of the original Internet architecture. However, the success of the Internet has proven this approach to be inadequate, at least with 32-bit addresses.
In 1992, with the Internet apparently running seriously low on unallocated addresses, Network Address Translation [9, 10] (NAT) was introduced to effectively allow addresses to be reused. Since then, the use of NAT has proliferated along with the deployment of firewalls, not just for address reuse but for several other purposes. For one, NAT is used for address allocation autonomy, allowing an enterprise to assign addresses independent of the ISP, supporting multi-homing, switching ISPs and decoupling the number of hosts from the number of addresses provided by the ISP. NAT is also used to conceal endpoints when an leaf network does not want its host visible to the rest of the network. Finally, NAT is used to allow a transparent redirect, allowing a cluster of web servers to appear as a single server, a key approach to building scalable web sites. Redirect is also used to support wiretapping of VoIP-based telephone service, as required by law. In these uses, NAT is similar to the use of virtual memory address translation with operating systems, providing protection, concealment, address reuse and remapping.
With all these uses,
NAT has become a valuable part of the Internet
but violates the end-to-end semantics of the original Internet architecture.
In particular, with NAT,
an IP address is only meaningful within one address realm
.
Consequently, application-specific proxies are required
in NAT routers to make some Internet applications function correctly.
For example, a NAT box must rewrite the ASCII-encoded address
passed in an FTP control session as it passes across a NAT boundary.
Similarly, it must modify DNS responses that transit through it.
Since transport-level checksums cover the IP source and destination
addresses, a NAT box must also update the transport checksum of a packet
even if it is only changing the address of the packet,
compromising end-to-end reliability and conflicting with end-to-end security.
With NAT, it is also hard to communicate freely between separate private
realms without renumbering, such as is needed when two NAT-based
enterprise networks are merged.
As a consequence of the use of NAT, there is no clear model of how Internet applications are to be structured. If an application depends on DNS, it can fail because no DNS server is available or reachable even if the communication paths to the application endpoints are functioning. If it uses IP addresses directly, it can fail because of the changing address assignments and translation occurring between endpoints that can arise with NAT, unless an application-specific proxy is deployed at all NAT points. Yet, this proxy precludes end-to-end encryption of the packets and exposes the application to undetected corruption because of a failed or compromised proxy. These ad hoc mechanisms will become even harder to manage as network configurations are forced to use multiple levels of NAT to further scale addressing and there are more applications and more NAT routers.
In this paper, we describe TRIAD,
a NAT- and IPv4-based Internet architecture that
addresses the problems of NAT.
TRIAD provides end-to-end reliability and security by using
a name-based transport-layer pseudo-header.
TRIAD extends the addressing available with conventional NAT
using a shim protocol over IPv4 called WRAP.
And TRIAD provides an router-integrated directory service that
supports multicast channels, mobility, virtual private networks
and policy-based routing.
TRIAD can be incrementally deployed without any changes to end-hosts
or applications beyond that already required for NAT.
The scalability of TRIAD eliminates the need to transition the Internet
to IPv6.