NAT seems to have been introduced into the Internet in Jacobson's insightful early proposal [9] although the same techniques appear in some earlier distributed systems work [8]. Since 1992, various RFC's [10] have clarified the use of NAT, provided for private addresses [11] and clarified the terminology, use and problems [15]. Industry has deployed a variety of products supporting network address translation, including firewalls, routers and server load balancers.
More recently, work on IPsec and others have recognized the problems with basing identity on IP addresses and the conflict of end-to-end security with the increasing deployment of NAT.
RSIP [13] is an alternative approach to dealing with NAT, where a host in a NAT realm explicitly obtains an external IP address, tunnels packets through the NAT gateway using this external IP address and thus can use IPsec and other protocols without requiring NAT translation. However, RSIP requires host modification to operate in this mode and it does not increase the number of external IP addresses. With all the extra benefits that TRIAD provides, it seems more effective and lower risk to modify the hosts to support native TRIAD, incrementally and once TRIAD has been widely deployed between realms.
The WRAP relay model we use, as an extension of the basic forwarding level of conventional routers, appears unique as we have defined it. WRAP relaying is similar to loose source routing except the packet is forwarded at each relay agent with the source IP address of the packet being one set by the relay agent, not the original source address. Moreover, each specified address is in a separate address realm, with translation between address realms occurring at each realm boundary. Source routing provides a source-controlled path but does not cross realms and does not change the source address on each hop, as is required for inter-realm communication. It is also similar to tunneling except the relay path taken by the packet (analogous to the sequence of one or more tunnels) is effectively recorded in the packet and, as above, translation of addresses may take place. The relay approach also uses a far smaller header than a nested set of IP headers, as required for a multi-tunnel path.
IP tunneling has been used to effectively extend addressing by tunneling from one realm to another. However, tunneling makes layer 4 filtering harder because, with multi-hop tunneling, the location of the layer 4 header involves parsing each encapsulation. Also, unlike WRAP, the path the packet takes is lost with tunneling. Moreover, tunneling incurs greater overhead than WRAP and requires that the source know the path. Moreover, the packet size does not change with WRAP, unlike encapsulation and de-encapsulation that occurs with tunneling.
MPLS [12] provides tagging of packets similar to WRAP,
but below the IP level.
MPLS does not provide more addresses beyond that provided by NAT,
unlike WRAP.
On the other hand, WRAP can be used intra-realm and inter-realm
for traffic engineering and VPNs,
reducing, if not eliminating, the need for MPLS
.
MPLS also requires special support in the forwarding path
of all routers on the path,
whereas WRAP/TRIAD only requires support at the border or relay agents.
MPLS also requires a new mechanism for distributing tags.
MPLS does not save the path a packet followed either.
While the WRAP header does impose a higher overhead than an MPLS tag,
it is less than IPv6 and less than conventional IPv4 tunneling,
especially with multi-path tunnels.
Thus, IP4 plus MPLS is not a solution to scaling
and IPv6 plus MPLS carries all the disadvantages of IPv6 plus
the MPLS overhead.
Both WRAP and MPLS make the offset of the TCP/UDP ports variable
within the packet, affecting the design of access control filters
on packets.
However, with the length field in the WRAP header at a fixed offset,
it is straightforward for even a hardware implementation to determine
the actual offset of layer 4 ports,
as required for access control processing.
Moreover, in initial deployment, we expect that firewalls may simply
restrict WRAP packets to specific WRAP-enabled hosts,
such as WRAPID gateways, which can filter further as needed.
Recent IETF work has promoted ``transparency'' as an important property to achieve in the Internet, defined as ``a single universal logical addressing scheme and the mechanisms by which packets may flow from source to destination essentially unaltered'' [14]. We view that TRIAD provides transparency under this definition, viewing the ``logical addressing scheme'' to be DNS naming and the transmission of data without changing the data or its checksum as ``essentially unaltered''. The changing of the addressing in the packet is not real alteration because corruption by intermediate points is as detectable as with conventional end-to-end delivery.