Figure 4 shows a typical data path between an initiator and a reusable-IP responder . is a waypoint and is an AVES-aware NAT gateway. virtualizes for . Thus, to , the IP address of is . To correctly relay packets from to , 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|
That is, when a packet from is received by (recall that the binding is initiator-specific), the destination address of the packet is translated to , and the resulting packet is tunneled from to . 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 can process each in-coming data packet purely based on its packet headers. This eliminates the need for a control path mechanism to configure 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. initiates a connection to by sending the packet (step 1). When receives such a packet, it transforms the packet into and encapsulates the packet with the header . We denote the final packet by . To enhance security, this packet is authenticated by . The packet is then forwarded (step 2) and later received by . In addition to supporting the basic functionalities of a NAT gateway, is extended such that when receives an authentic encapsulated packet from , 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, creates a local translation table entry such that, when a corresponding out-bound packet (with matching port numbers, if any) is received, it will modify this out-bound packet to before forwarding it out of the reusable-IP network. After creating this translation table entry, removes the encapsulating packet header from the in-coming packet and forwards the inner packet to (step 3). Finally, when sends a reply to (step 4), the packet is modified by to and then forwarded to (step 5). Through these mechanisms, a connection from to 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 (), and the source port number is translated to a chosen number () to maintain the binding. The resulting packet for step 3 is , and the packet for step 4 is . As a result, out-bound packets are guaranteed to traverse the same border gateway as in-bound packets. For an in-bound ICMP  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.