Smart Tunnel Union for NAT Traversal

Authors: Tzu-Chi Huang; Ce-Kuen Shieh; Wen-Huang Lai; Yu-Ben Miao

Complete Citation

• Tzu-Chi Huang, Ce-Kuen Shieh, Wen-Huang Lai, Yu-Ben Miao. Smart Tunnel Union for NAT Traversal. Department of Electrical Engineering, National Cheng Kung University. Appears in: Fourth IEEE International Symposium on Network Computing and Applications. Publication Date: 27-29 July 2005
• Digital Object Identifier: 10.1109/NCA.2005.50

Abstract

Network Address Translator (NAT) is the well-known, transitional method to mitigate the problem of IPv4 address depletion in today's Internet. However, the assignment, translation, and export of address/port in a NAT at run time affect application functions. Accordingly, application servers behind the NAT cannot accept requests directly from public networks. Sensitive applications cannot hold their end-to-end security mechanisms. Applications lose connections after the NAT reboots or changes the binding address/port. However, current proposals for NAT traversal hardly solve the problems. Against the problems, we propose Smart Tunnel Union for NAT Traversal (STUNT) in the paper. STUNT permits applications behind the NAT to be actively contacted by Internet clients, keeps end-to-end security mechanisms, and avoids the risk of exporting binding information of the NAT to connection endpoints. Meanwhile, it permits applications to traverse the NAT and keeps the NAT intact.

Annotations

This paper proposes a method of making a NAT that does not require all connections to originate on the inside of the NAT. In essence, a second translation server is set up with access to all traffic coming in the NAT box and access to the internal network. Using a sort of IP-in-IP tunneling, clients who know the internal address of machines in the NAT may put a second header in front of the usual IP header. These packets' external IP header directs them to the STUNT/NAT proxy. The STUNT machine strips the external header, revealing the internal network address header, and sending the packet on its way.

Thus, with knowledge of the internal network IP address of a machine, someone outside the NAT can contact them without being first contacted. One problem with this approach is that it requires all systems seeking to initiate this cross-NAT traffic to adopt and implement STUNT.

This paper is interesting to me because I have implemented network multiplexing for the Click-based router project. In my case, I use subnets and packet forwarding, but this is another approach that was considered. Fortunately in our case, we are not nearly short of IPv4 addresses and so IP-in-IP is not needed.

-- DavidMoore - 15 Aug 2007