Application Requirements

There are three types of limitations imposed by AVES that may conflict with an application's behavior, they are (1) limitations due to address translation, (2) limitations due to the need for session creation, and (3) limitations due to the need for consistent state maintenance. In the following, we discuss what rules must an application obey in order to be compatible with AVES.

The first type of limitation is not specific to AVES, but it is a fundamental limitation of any address translation scheme such as NAT, TRIAD [3] and IPNL [6] (discussed in Section 7). The main problem is that some applications break the layering semantics by exchanging lower layer information such as IP addresses and use the information directly. In [10] and [24], some NAT-friendly application design guidelines are given. Because AVES also performs address translation, some of these guidelines are relevant (guidelines that aim to avoid in-bound connections are no longer needed under AVES). Specifically, with respect to address translation, in order to be compatible with AVES coupled with NAT, an application should not pass IP addresses in the packet payload; instead, DNS names should be passed, and name resolution should always be used to determine the IP addresses. Listener port number passing is actually no longer a problem if DNS names are used. Also, applications should not expect the network and transport headers to be unmodified in transit. Clearly IPsec [13] would not work across NAT or AVES. In IETF, there is on-going work on making NAT more IPsec-friendly [2]. In Section 6.4, we will also describe a change to the AVES data path that may make AVES more IPsec-friendly.

AVES fundamentally requires a session to be opened by an initiator before connectivity is provided. Therefore, an application must perform a DNS lookup before communication begins. Moreover, communication must begin immediately after the DNS lookup to work with delayed binding since $T_{wait}$ is typically small. When a connection is rejected, the application must perform a DNS lookup again to restart the session. Note that a $T_{wait}$ of 2 seconds used by our prototype might not work for an application like traceroute, since it progressively probe the network hop-by-hop and this process may take more than 2 seconds to reach the waypoint.

Finally, an application must obey some rules to maintain consistency between its state and the waypoints' state. From a waypoint's point of view, a session is terminated when an idle timeout occurs, or when all connections of the session (assuming they are all TCP) are terminated. Therefore, an application must send periodic keep-alive messages. In addition, it must not reuse DNS lookup results across sessions (as in the web browser example). An application must also begin communication within $T_{wait}$ after a DNS reply is received, otherwise, the application's view is stale. When a connection is rejected, an application must also restart the session by performing another DNS lookup. These rules will prevent the initiator from having a stale view. If an application does not follow these rules, then it may have a stale view, in that case, there are two possible outcomes. First, the connection may get rejected by the waypoint because it has no state for the initiator. Second, the connection may get relayed to the wrong responder because the waypoint has other state for the same initiator. On the other hand, a waypoint may have a stale view if a session has ended (e.g. a UDP session is terminated by the application) but it still keeps state about it. This type of inconsistency only affects performance, not correctness, because it simply makes the waypoint unavailable to the same initiator for a longer period.