Potential Extensions

IPv6 Support - Our implementation currently does not support IPv6 header conversion, this is an important extension that is needed.

Coexisting with Ingress Filtering - Consider the example in Figure 4 again. In step 5, $R$ is effectively spoofing $IP_W$. This is done for simplicity and performance reasons. Routers that implement ingress filtering [5] will drop such packets. AVES can easily be enhanced to work with ingress filtering by making $R$ tunnel the packet to $W$, and let $W$ forward the packet to $A$. The disadvantage is that the load on $W$ is increased.

Coexisting with IPsec - To make NAT IPsec-compatible, RSIP [2] has recently been proposed in the IETF. In order for AVES to be compatible with IPsec, packet content must not be altered in transit. This can be achieved if the responder is made aware of the fact that it is being virtualized by a waypoint. This idea is in-spirit similar to that in RSIP. Using the example in Figure 4 again, the waypoint can generate the packet $[IP_W \rightarrow IP_R [IP_A \rightarrow IP_W]]$ (step 2), $R$ can forward the packet $[IP_R' \rightarrow IP_B' [IP_A \rightarrow IP_W]]$ (step 3), and the responder itself can generate the packet $[IP_B' \rightarrow IP_R' [IP_W \rightarrow IP_A]]$ (step 4). The reusable-IP responder now needs to be heavily modified, although there are some incentives to do so.

Connectivity for Non-IP Initiators - AVES is designed to solve the connectivity problem of cases (a) and (b) in Table 1. Since other cases are reducible to either case (a) or (b), AVES functions correctly in all cases. However, because AVES perceives all non-IP initiators belonging to the same non-IP network as a single IP initiator (since they are masked by their NAT or NAT-PT gateway), the connectivity provided by AVES to each individual non-IP initiator is correspondingly reduced. Precisely, with $N$ IP addresses allocated for AVES waypoints, each non-IP network can simultaneously reach up to $N$ non-IP responders. Although the connectivity is reduced, it is important to realize that this is perhaps the best one can achieve if the initiating non-IP network has no incentive to make any upgrade. If upgrading is acceptable, higher connectivity for these cases can be achieved by extending the NAT or NAT-PT gateways to implement a more sophisticated solution such as TRIAD [3] or IPNL [6]. A discussion on TRIAD and IPNL can be found in Section 7.