In this section, we first review some well known partial work-arounds to cope with the lack of in-bound connectivity. Then we discuss a solution that is currently proposed in the IETF. Finally, we discuss other related work that are not directly addressing the in-bound connectivity problem.
A common work-around for the lack of in-bound connectivity is to forward a port number of the NAT gateway to a specific host inside the reusable-IP network. For example, in-coming traffic to port 23 (i.e., telnet) of the NAT gateway can be blindly redirected to port 23 of a particular reusable-IP host. With this transport layer work-around, although more than one reusable-IP host is reachable, no two reusable-IP hosts can offer the same service (e.g. no two reusable-IP host can simultaneously support port 22 ssh login), thus unacceptable connectivity is provided. Tedious per application manual configurations are also required.
A related technique is to take advantage of a new type of DNS resource record proposed in [9], called the SRV resource record, which can specify the port number of a service. When both the service provider and the client support DNS SRV, the client can retrieve both the IP address of the host that is offering the service and the exact port number it should use to use the service. Suppose the port number binding can be dynamically assigned by a NAT gateway, then better in-bound connectivity to non-IP hosts can be achieved than port number forwarding. Unfortunately most applications and operating systems today do not support this feature.
Another work-around exists for UDP communication. Assume both the initiator and the responder are behind NAT gateways. The idea is to have both the initiator and the responder contact an IP server to exchange their NAT gateways' IP addresses, then both initiator and responder simultaneously send each other UDP packets with the same source and destination port numbers. Assuming the NAT gateways do not alter the source port numbers of these packets, bi-directional communication can be achieved. This work-around has been applied to some networked games [12]. Note that this scheme only works for UDP, requires a third party connection broker, and both parties must be actively involved, which is not suitable for client-server applications.
Another possibility is to insert a globally unique host name into packets so that a NAT gateway can dynamically determine the destination of a packet by looking up the host name. Host Identity Payload [17], proposed in the IETF, may be used for this purpose. Existing IP hosts or edge routers must however be modified to insert such host names into packets. With HTTP/1.1 [7], it is possible to embed the name of the destination in the HTTP header. This technique has been used to perform HTTP virtual hosting. This is however not a general solution for applications that are not based on HTTP.
Recently, a solution based on the SOCKS protocol has been proposed in the IETF [14]. The idea is that, when an application performs a DNS lookup for a responder, a ``fake'' IP address (e.g. 0.0.0.1) is returned to the application. When the application actually makes a socket call to communicate with the ``fake'' IP address, the SOCKS library on the initiator intercepts the call and connects to the SOCKS server on the responder's NAT gateway. The DNS name of the responder is communicated to the SOCKS server, and the SOCKS server connects to the real responder. Data packets are then copied between the two spliced connections at the NAT gateway. The downside of this scheme is that existing IP hosts need to be upgraded. It is conceivable that the initiator-side's SOCKS processing can be pushed to the initiator's edge router; in that case, existing edge routers need to be upgraded.
Next we discuss two on-going research projects that are closely related to AVES. In [3], Cheriton et al. propose a solution called TRIAD that can solve the IP address scarcity problem. TRIAD makes it possible to expand the Internet by arbitrarily connecting an unlimited number of IP network realms, each with its own 32-bit address space. TRIAD uses DNS names rather than addresses for global identification. During DNS name resolution, a sort of realm-to-realm source route is computed. A simple ``shim'' protocol header is added to every packet to carry this realm-to-realm source route to assist routing across multiple realms.
IPNL [6] is another recent proposal to provide an alternative to IPv6. IPNL also uses DNS names as global identifiers and allows multiple IP realms to be connected. However, rather than allowing IP realms to be connected arbitrarily as in TRIAD, IPNL allows IP realms to be organized hierarchically, with a single global ``middle realm'' and many smaller realms connected to the ``middle realm''. This allows IPNL to have better routing efficiency compared to TRIAD. IPNL introduces two extra levels of optional headers to permit communication across realms. To communicate, the initial packet contains the DNS names of the source and the destination. As the packet traverses the realms, various addresses are resolved and stored in the packet headers. These addresses are then used for fast packet forwarding and the DNS names can be omitted.
While the goal of TRIAD and IPNL is to provide an alternative to IPv6, the goal of AVES is to maintain connectivity between today's IP Internet and emerging networks of IPv6 and reusable-IP address spaces. In contrast to AVES, TRIAD and IPNL only allows hosts within realms running those respective protocols to communicate with each other. However, unlike TRIAD, AVES cannot route packets over an arbitrary number of IP networks, nor can AVES achieve the level of connectivity of TRIAD or IPNL. Nevertheless, we believe that maintaining connectivity between existing IP hosts and IPv6 or reusable-IP hosts is an important problem, therefore the trade-off is justified.