Data Path Operations

Figure 4: Data path operations

Figure 4 shows a typical data path between an initiator $A$ and a reusable-IP responder $B$. $W$ is a waypoint and $R$ is an AVES-aware NAT gateway. $W$ virtualizes $B$ for $A$. Thus, to $A$, the IP address of $B$ is $IP_W$. To correctly relay packets from $A$ to $B$, $W$ has been configured by an AVES-aware DNS server via the control path protocol described in Section 3.3 with the following translation table entry (we omit the port numbers as they are unimportant):

Original packet	Translated packet	Encapsulation header
$[IP_A \rightarrow IP_W]$	$[IP_A \rightarrow IP_B']$	$[IP_W \rightarrow IP_R]$

That is, when a packet from $IP_A$ is received by $W$ (recall that the binding is initiator-specific), the destination address of the packet is translated to $IP_B'$, and the resulting packet is tunneled from $IP_W$ to $IP_R$. Note that we propose a tunneling based mechanism here despite the header overhead because the encapsulation header allows complete information about the session to be carried along with each data packet so that $R$ can process each in-coming data packet purely based on its packet headers. This eliminates the need for a control path mechanism to configure $R$ ahead of time, resulting in a simpler protocol. In the following, we describe two versions of the data path operations. The first version applies when the reusable-IP network is connected to the IP Internet via a single NAT gateway. The second one applies when the reusable-IP network is ``multi-homed'', that is, it is connected to the IP Internet via multiple NAT gateways.

The data path operations without multi-homing support are as follows. $A$ initiates a connection to $B$ by sending the packet $[IP_A \rightarrow IP_W]$ (step 1). When $W$ receives such a packet, it transforms the packet into $[IP_A \rightarrow IP_B']$ and encapsulates the packet with the header $[IP_W \rightarrow IP_R]$. We denote the final packet by $[IP_W \rightarrow IP_R [IP_A \rightarrow IP_B']]$. To enhance security, this packet is authenticated by $W$. The packet is then forwarded (step 2) and later received by $R$. In addition to supporting the basic functionalities of a NAT gateway, $R$ is extended such that when $R$ receives an authentic encapsulated packet from $W$, it first determines whether a packet of the same connection (matching addresses in both outer and inner packet headers and port numbers, if any) has been seen before. If not, $R$ creates a local translation table entry such that, when a corresponding out-bound packet $[IP_B' \rightarrow IP_A]$ (with matching port numbers, if any) is received, it will modify this out-bound packet to $[IP_W \rightarrow IP_A]$ before forwarding it out of the reusable-IP network. After creating this translation table entry, $R$ removes the encapsulating packet header from the in-coming packet and forwards the inner packet to $B$ (step 3). Finally, when $B$ sends a reply to $A$ (step 4), the packet $[IP_B' \rightarrow IP_A]$ is modified by $R$ to $[IP_W \rightarrow IP_A]$ and then forwarded to $A$ (step 5). Through these mechanisms, a connection from $A$ to $B$ is established.

The operations above prevent a reusable-IP network from being multi-homed because they do not guarantee that the out-bound packets of a session will traverse the same NAT gateway as the in-bound packets, consequently out-bound packets might not be translated correctly. To accommodate a multi-homed network, we modify the data path operations as follows. In step 3, the source address of an in-bound packet is translated to the reusable-IP address of $R$ ($IP_R'$), and the source port number is translated to a chosen number ($P_R$) to maintain the binding. The resulting packet for step 3 is $[IP_R',P_R \rightarrow IP_B']$, and the packet for step 4 is $[IP_B' \rightarrow IP_R',P_R]$. As a result, out-bound packets are guaranteed to traverse the same border gateway as in-bound packets. For an in-bound ICMP [19] query packet, the Identifier field can be translated instead since there is no port number.

We have implemented both variations of the data path in our prototype system, see Section 5 for details. Limitations of these mechanisms are discussed in Section 6.