Our AVES-aware NAT gateways are based on Linux PCs as well, and they are assumed to be already configured to perform defragmentation of in-bound packets and IP masquerading (i.e. out-bound NAT), which is fully compatible with AVES. Similar to the waypoint daemon, the AVES NAT daemon also filters selected packets to user-level for manipulation. To handle NAT gateway dynamic IP address assignment, periodically, the NAT daemon sends authenticated registration messages via UDP to the AVES-aware DNS severs to report its current IP address. These messages are sent more frequently when an address change is detected to ensure with high probability that the update is completed promptly.
The basic operations performed by the NAT daemon is as described in Section 3.2. The NAT daemon by default filters all in-coming encapsulated packets. When an authentic encapsulated packet is received and the connection has not been seen before, a filter is installed for the corresponding out-bound packets, and a translation table entry is created. Several other noteworthy features of the NAT daemon are summarized below:
Protocol Specific Timeouts - Similar to the waypoint daemon, different timeout values for the translation table entries are used for different protocols. The policy is exactly the same as that in the waypoint daemon.
ICMP Handling - For traceroute, even though the in-bound packet is UDP, an out-bound ICMP packet is triggered. To support traceroute, when an in-bound UDP connection is received, we install an extra filter and translation table entry for the potential out-bound ICMP packets. The timeout is set to 5 seconds so that if no ICMP packets are triggered, the state is removed quickly. In addition, since many ICMP message types carry IP addresses and port numbers in the packet payload, the AVES NAT daemon translates the payload accordingly as well.
Multi-Homing Support - To support multi-homing as described in Section 3.2, the source address and port number (or ICMP Identifier) of an in-bound packet are translated. To choose a suitable port number, we simply pick a port number between 1024 and 65535 at random, and test to see if that port number can be bound to a TCP and a UDP socket. The process repeats until a port number that is free is found. This makes sure that our port number allocation will not interfere with the other operations of the NAT gateway. However, notice that our straight-forward implementation does not achieve the theoretical highest connectivity as discussed in Section 4. In our implementation, only 64,512 in-bound connections (TCP or UDP) can be simultaneously active regardless of the destinations of the connections. This is however more than sufficient for the purpose of our prototype.
Limitations of Multi-Homing Support - When multi-homing is enabled, only one reusable-IP network can be connected to a NAT gateway because when there are multiple reusable-IP networks attached, our implementation is not yet capable of translating the source address of an in-bound packet to the address of the correct output network interface. Also, some applications, most notably ftp, will not work when multi-homing is enabled because the reusable-IP ftp server cannot open the data connection to the IP client since the IP client's address has been translated. And because the server passes its reusable-IP address, say 10.0.0.1, to the client, even if ``passive mode'' [1] is enabled, the client will attempt to open the data connection to the address 10.0.0.1 instead of the waypoint IP address. The only way to get around this is to translate ftp control packets' content.