IP Multiplexing by Transparent Port-Address Translator)}

    Heon Y. Yeom, Jungsoo Ha, and Ilhwan Kim 

    Department of Computer Science
    Seoul National University
    Seoul, KOREA 151-742
    TEL : 082-2-880-5583
    FAX : 082-2-872-1858 
    (yeom,huggies,ilhwan)@arirang.snu.ac.kr

ABSTRACT

The address space of IP, a standard Internet Protocol, is
being exhausted by explosively increasing number of demands and the
inefficient address allocation scheme based on the network class
partitions.
Among the short term solutions that have been suggested so far,
IP address reuse through automatic translation between local and
global addresses is considered as an appropriate solution prior to the
launch of a new protocol.

In this paper, we suggest a port-address translator which improves the 
one-to-one translation of local-global address translator by enabling 
several local nodes to share a globally unique address, and discuss 
various problems and their solutions we have encountered in designing 
and implementing the translator.
Also, the problems and the effectiveness of address reuse by automatic
address-address or port-address translator is investigated.

1. Introduction

One of the biggest problem we are facing now on the Internet is the lack
of IP addresses.  The 4 byte long IP address is being used up fast due to
the exponential growth of Internet.  Moreover, a lot of IP addresses are
wasted for Inter-Domain routing~\cite{franc}.  What we need is an efficient
way to use the IP address space.

Even though a new protocol called IPNG is being investigated to replace the IP,
its wide acceptance is still far-fetched and a short-term solution is badly
required. We look at some of the solutions suggested in the literature and
propose a novel idea for this problem.

The rest of this paper is organized as follows: we identify the problem
of IP address shortage and look at some of the solutions provided in the
literature in section 2.
In section 3, we propose our solution by reusing IP address-port pair.
Design and implementation issues are discussed in section 4 and we conclude
the paper in section 5.

2. Background

2.1 Waste of IP address space}

Since there are 4 bytes in IP address, there can be $2^{32}$ distinct
addresses.  However, this address space is wasted due to the following
reasons.
{enumerate}
{IP address space is partitioned into classes(A,B,C,..) and each LAN
has one domain address.  There can not be overlapping addresses in different 
domains.}
{The number of nodes in any one domain which simultaneously communicate
with outside nodes is relatively small.}
{enumerate}

Think of a class C domain which has 150 nodes in it.  Assuming that there
are 50 nodes communicating with outside nodes, this domain only needs 50
IP addresses.  First, since only 150 addresses are assigned, 100s of IP
addresses are wasted.  Second, 100 of 150 addresses do not communicate with
outside world which means that they are also wasted.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{IP address Reuse}

It has been already noted that IP addresses can be reused for private 
network~{rfc:1597}.  In RFC 1597, parts of IP addresses are designated
to be used repeatedly as follows.
*{1em}
{
{tabular}{ll@{ -- }l@{ , }l}
A Class & 10.0.0.0    & 10.255.255.255  & 1   
 Class & 172.16.0.0  & 172.31.255.255  & 16  
C Class & 192.168.0.0 & 192.168.255.255 & 255 
{tabular}
}

Also, in RFC1519{rfc:1519}, it has been suggested to use CIDR(Classless
Inter-Domain Routing) to avoid IP address waste due to IP partitioning.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Proxy Server}

For a local area network where network security is important, a firewall
is often used to separate the inside network from outside networks.
It is usually implemented by selectively filtering packets coming in 
and going out.  However, the users inside the network still want to
use all the Internet services, and it is a major consideration in
using a firewall.

One easy solution is to provide a proxy server through which users
communicate with outside network.  By setting up a proxy server which
can be trusted and assigning a real IP address to it, users can go through
it when they need outside connection.  Refer to figure~{fig:1}.

{figure}
{figure=proxy.eps,width=7cm}
{Connecting through a Proxy Server} {fig:1}
{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Socket Server}

In UNIX systems, application programs use sockets to access the network 
and each kernel of the system manages sockets.  There are some exceptions
where sockets are managed and allocated by a separate server to provide
transparent network access where firewall is used.
In {socks}, a socket server is introduced which manages the socket
of the local machines which do not have direct internet access so that
local machines can acess outside network.  
The socket server should have the capability to communicate with outside
network and it provides sockets which can be used for outside connection 
to the internal hosts which can not directly communicate with outside network.
Internal nodes can get a socket from the socket server using Rconnect() call.
The socket server provides the socket clients its IP port number and transfer
packets through the port.
Using the socket server and the socksified clients, it is possible to transfer 
packets between the internal and outside networks.

Even though this scheme provides transparent solution, it requires modification
of the client programs and can not be used for non-UNIX environment.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Network Address Translator}

As we have seen earlier, it is impossible to connect from a regional network
using replicated IP address to the global IP network without some tweaking.
It is needed to translate the replicated address to a globally unique address
to be able to connect to the global IP network since the regional addresses
are only unique inside that region.  We call these fake IP addresses as 
replicated addresses.

{figure*}
{figure=overview.eps,width=12cm}
{A network with replicated address} {fig:2}
{figure*}

P. Francis of Bellcore has suggested a scheme for IP address reuse by 
transparent address trnaslator using DNS(Domain Name Service) in {franc}.
Figure~{fig:2} shows the network diagram of a regional network with
replicated addresses and the usage of address translator. 

Between the global network and the local network using replicated IP addresses,
there is a Network Address Translator(NAT) which has a couple of IP addresses
which can be used for outside communication.
Whenever a node inside the local network need a global address for outside
communication, NAT provides the local node a global address dynamically.
A global address, once allocated, can be used until the connection is
terminated and the NAT automatically translates between the global address
and local address.  NAT performs the translation by intercepting all
TCP/IP packets to search their header information and refer to the mapping
table between the global and local addresses.


{figure*}
{figure=nat-op.eps,width=12cm}
{Transparent Address Translation (Connection from inside to outside)} 
{fig:3}
{figure*}

As shown in figure~{fig:3}, there is a close relationship between
NAT, DNS and interdomain router or gateway.  Let us look at how NAT works.
When an inside node I wants to send a packet to outside network, NAT intercepts
this packet and allocates a global IP address and relays it outside.
All the packets to the outside network go through the NAT and the packets are 
examined and proper address translation is performed if needed.  Only properly 
translated packets can be relayed to the outside network.

On the other hand, if there is a connection request from outside to the inside
node I, DNS would first notice it and ask the NAT to prepare a global IP 
address for I.  However, there is a set limit on the number of simultaneous
outside connection which is the number of reserved global IP addresses the NAT
has.

There are certain disadvantages in this scheme.
{itemize}
{It can be applied only to the applications using DNS.}
{It is hard to apply it to connectionless protocol such as UDP.}
{The number of global IP addresses might not be big enough for outside 
connections.}
{A special considereation is needed for applications which has IP address 
inside a packet(FTP, ICMP, etc).}
{itemize}

In spite of these drawbacks, this scheme enables a transparent address
translation by setting up the NAT on the border of the network without
a lot of modification.  It has become an Internet standard~{rfc:1631}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Transparent Port-Address Translator} 

Now, we introduce a new technique to re-use address space by transparent
port-address translation.  We note that there are a lot of ports in a node
and only a small portion of them are used at any time.  It is possible to
provide outside connection by translating local address and port pair to
a global IP address and its unused port number.

Let us denote a socket of a node as  address, TCP port number) a TCP packet as , srcPORT, dstIP, dstPORT). that there is no node with the same IP address on the route,
every application using the connection can be uniquely identified in the
regional network -- in the global internet if there is no replicated addresses
-- by the pair $(srcIP, srcPORT)$.  Furthermore, two pairs of sockets, 
$((srcIP, srcPORT)$ and  $(dstIP, dstPORT))$ uniquely identify the 
two endpoints of the communication~{rfc:793}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{One-to-one packet transmission using proxy server}

Let us first find out the minimum information to transmit packets between
TCP peer entities when proxy server is used.  As shown in figure~{fig:4},
a packet from $(S, 1000)$ to $(D, 23)$ is recieved by G and the source
address is changed into $(G, 3000)$ and then relayed to $(D, 23)$.
A packet from $(D, 23)$ to $(G, 3000)$ is again received by G and it is
relayed to $(S, 1000)$ after the destination address is changed.
A port-address translator performs this translation transparently.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Packet relay by automatic port-address translation}

As we have seen earlier, all the packets D received have been changed
from $(S, 1000, G, 23)$ to $(G, 3000, D, 23)$ by G.  Also, all the packets S
received have been changed from $(D, 23, G, 3000)$ to $(G, 23, S, 1000)$ by G.
This translation is done by the proxy server when the user specified the usage
of proxy server.  Now, all we have to do is to transparently perform the
translation done by the proxy server G.

{figure}

{figure=proxy-tel.eps,width=6cm}
{quote}

From node S with replicated address, a remote login connection is established 
by issuing !TELNET G!.  Again from G, ! TELNET D! is used to connect
to D  and we have a indirect telnet connection from S to D.  Proxy server G
relays all the packets between S and D.
{quote}
{A telnet session through proxy server.}{fig:4}
{figure}

Since a port number is represented using 16 bits, an IP node can have up to
$2^{16}$ different sockets.  Therefore, there can be $2^{16}$ different 
entities on an IP node which can be uniquely identified in the Internet 
address space.  In practice, only a small amount of ports are ever being
used by applications.  The remaining unused ports of a node with global
IP address can be allocated to the regional nodes which have replicated
addresses.

{table}


{tabular}
  {|c|@{{1em}({1ex}}
    c@{{1ex},{1ex}}
    c@{{1ex}){1em}}|
    c|}
    
    G.PORT   &  I.IPaddress   & I.PORT & STATUS       
    
    30000    &   172.16.10.1  & 1234   & SYN-SENT     
    30001    &   172.16.10.1  & 3487   & ESTABLISHED  
    30002    &   172.16.30.27 & 12039  & CLOSE-WAIT   
    30003    &   NULL         & NULL   & CLOSED       
    30004    &   NULL         & NULL   & CLOSED       
       &          &  &        
    40000    &   172.16.68.99 &  3465  & ESTABLISHED  
    
{tabular}
{An example of port-address mapping table}{table:1}
{table}

Let us look at table~{table:1}.
This table shows the mapping between sockets $(IPaddr,PORT)$ of nodes inside 
a regional network with stub B class network address 172.16.0.0 and the port 
numbers of a node G(Gateway node) which has a global IP address.  
This mapping is dynamically allocated by
{enumerate}
{DNS call as in {franc}}
{looking for SYN flag in TCP header information}
{enumerate}
and deallocated when the STATUS becomes CLOSED.

Whenever G encounters a packet requiring address translation, this table
is looked up to modify the header information and the modified packet is
relayed.  G monitors all inbound packets and outbound packets to properly
modify them.

The source address of the outbound packet is mapped from $(I.Addr, I.PORT)$ to
$(G.Addr, G.PORT)$ according to the port-address mapping table and relayed.
Also, inbound packets with destination address $(G.Addr, G.PORT)$ is translated
into $(I.Addr, I.PORT)$ and relayed to the inside regional network.

All the outbound packets should be translated before going out of the local
network since the IP addresses are replicated.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%{The efficiency of IP address reuse}

%Æ÷Æ®-ÁÖ¼Ò º¯È¯±â´Â IP ÁÖ¼Ò°ø°£À» È¿À²ÀûÀ¸·Î »ç¿ëÇÒ ¼ö ÀÖ°Ô ÇÑ´Ù.
%
%¿¹¸¦ µé¾î Àü¿ªÀûÀ¸·Î »ç¿ë°¡´ÉÇÑ B Class ¸Á ÁÖ¼Ò¸¦ °¡Áö°í C Class
%Áö¿ª¸Áµé·Î À籸¼ºÇÏ´Â °æ¿ì, ÇÑ Áö¿ª¸Á ³»¿¡¼­ µ¿½Ã¿¡ ¿ä±¸µÇ´Â Àü¿ª ¼ÒÄÏÀÇ
%°¹¼ö°¡ 10,000°³¶ó°í °¡Á¤Çغ¸ÀÚ. (ÀÌ ¼ýÀÚ´Â ÀüÇô ±Ù°Å°¡ ¾ø´Â °ÍÀº
%¾Æ´Ï´Ù. C Class³»¿¡´Â ÃÖ´ë 255°³ÀÇ ³ëµå°¡ Á¸ÀçÇÒ ¼ö ÀÖÀ¸³ª ¿ÜºÎ¿Í
%Á¢¼ÓÀ» °¡Áö´Â ³ëµåÀÇ ¼ö°¡ µ¿½Ã¿¡ 50°³¸¦ ³ÑÁö ¾ÊÀ» °ÍÀÌ¶ó º¸¸é ÇÑ ³ëµå´ç
%ÃÖ´ë 200°³ÀÇ ¿ÜºÎ¿Í Á¢¼ÓµÈ ¼ÒÄÏÀÌ µ¿½Ã¿¡ Á¸ÀçÇÒ ¼ö ÀÖ´Ù.~{½ÇÁ¦·Î
%ÁÖ¼Òº¯È¯±â¸¦ µµÀÔÇÏ·Á¸é Áö¿ª¸Á ³ëµåµéÀÇ È°µ¿Æ¯¼º¿¡ ´ëÇÑ Á¤·®ÀûÀÎ ºÐ¼®ÀÌ
%¹Ýµå½Ã ¼öÇàµÇ¾î¾ß ÇÑ´Ù.})
%ÇÑ ³ëµå¿¡¼­ TCP Port´Â $2^{16}$°³°¡ »ç¿ëµÉ ¼ö ÀÖÀ¸¹Ç·Î
%´Ü ÇϳªÀÇ Àü¿ªÁÖ¼Ò¸¦ °¡Áö°í ¸ðµç Àü¿ª ¼ÒÄÏÀ» ó¸®ÇÒ ¼ö ÀÖ´Ù.
%µû¶ó¼­ {rfc:1597}¿¡¼­ Á¦½ÃµÈ Àç»ç¿ë Àü¿ë ÁÖ¼Ò¸¦
%ÀÏ¹Ý ³ëµå¿¡°Ô ÇÒ´çÇØ ÁÖ°í °¢ C Class Áö¿ª¸ÁÀº ÇϳªÀÇ Àü¿ª ÁÖ¼Ò¸¸À»
%ÇÒ´çÇØ ÁÖ¸é µÈ´Ù.
%
%ÀÌó·³ ÁÖ¼ÒÀÇ Àç»ç¿ëÀº IP ÁÖ¼Ò°ø°£ÀÇ ³¶ºñ¸¦ ÁÙÀÌ°í IP ÁÖ¼Ò ºÎÁ·À» ¾î´À
%Á¤µµ ÇؼÒÇÒ ¼ö ÀÖ´Ù.  À̶§ Æ÷Æ®-ÁÖ¼Ò º¯È¯±â´Â ¸Å¿ì ÀûÀº ºñ¿ëÀ¸·Î ±âÁ¸
%ÀÀ¿ëÀ̳ª ¸Á ±¸Á¶ÀÇ ¼öÁ¤ ¾øÀÌ »ç¿ëÀÚ¿¡°Ô Åõ¸íÇÑ ¼­ºñ½º¸¦ Á¦°øÇϱâ À§ÇØ
%»ç¿ëµÉ ¼ö ÀÖ´Ù.  

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Design and Impliment issues for port-address translator}

We have implemented a prototype on an IBM compatible PC using packet driver.
A lot of skeleton codes are adapted from PC bridge and PC router softwares.
Since the port-address translator has more functionality such as address
translation, more hardware resource is needed.  From the experiment we
have done using the prototype, we found that the performance is comparable
to that of general PC ethernet bridge.  Detailed performance evaluation
is being done and will be reported later.

Some of the issues we have encountered are as follows.

{itemize}
{The checksum of the TCP/IP header should be modified accordingly.}
{It is difficult to decide when to allocate and deallocate mapping table
endty for UDP protocol.}
{A separate mechanism such as static allocation is needed for inbound
request to the server with only regional address.}
{To deal with applications which generate packets with IP address in them
such as FTP, ICMP, the translation should be done on application layer.}
{itemize}

These problems are due to the fact that the port-address translator can only
gather limited information from the packets.  They are similar to the problems
encountered with packet filtering gateway~{bell:fw} which is used to 
enhance security.  However, they are more difficult than the case with
the translation using socket server~{socks} since the information can
be obtained from Rbind() call in socket server whereas the port-address
translator only looks at the header information.

Calculating checksum for TCP/IP header is pretty simple and it can be
efficiently done by a combination of additions and 
subtractions~{rfc:1631}~{franc}.
We have implemented our protytype using the algorithm shown in ~{franc}.

%%%%%%%%%%%
{Timing for allocation and deallocation of port-address mapping table entry}

Two methods have been introduced for the timing of allocation and deallocation
of port-address mapping table entry.

First, we can use DNS to dymically allocate addresses.  It has advantages
that the address allocation time is specified and inbound service can be
supported.  However, it tends to be more complex since the address deallocation
should be done either by monitoring each session or explicitly specifing the
deallocation.  Furthermore, for this method to work, all the nodes should be
registered to the DNS and DNS caching can cause a severe inconsistency problem.

Second, we can monitor the packet header and its contents and modify them
accordingly.  It could be complex since we need to trace the regional sockets 
to follow their TCP STATE change.  However, this information can be obtained
from the TCP header flag(e.g. SYN, FIN).  Figure~{fig:5} shows the state
transition diagram of the TCP STATE and corresponding header flags.  A pseudo
code of the algorithm is attatched as an appendix.

{figure} {figure=tcp-con.eps,width=7cm}
{TCP STATE transition diagram from TCP header flag} {fig:5}
{figure}

%%%%%%%%%%%
{Supporting UDP}

It is more difficult to extend the port-address translator to support UDP
protocol.  Since UDP is a stateless protocol and there is no sequence number,
it is close to impossible to correctly trace a session.  What we can do is
to use an appropriate  timeout value to determine a termination of a session.
This idle time threshold based algorithm is difficult to use since the proper
timeout value is hard to select.

We have implemented the idle time threshold base algorithm with a timeout
value of 2 minutes.  This value is selected since it is relatively large
compared to the other timeout values used in NIS(Network Information System)
or NFS(Network File System).

A special caution is needed to support UDP applications with different 
characteristics.


%%%%%%%%%%%%%%%%%%
{Supporting inbound request}

Besides the dynamic allocation of the port-address mapping through packet
flags, our port-address translator supports static allocations for inbound
connection requests.  It has a limitation that only one inside server can
be specified for each IP address, port pair.  In other words, only one
server can be activated for each well known protocol if there is only
one global IP address.
The static allocation is assigned when the port-address translator is launched
and stay valid all the time.  We can have inside servers for well-known ports
to service inbound requests.

For example, if we have a HTTP server at (www.our.domain, 80),
packets coming to (gateway.our.domain, 80) is translated into (www.our.domain,
80) and relayed to the HTTP server inside.  Of course, our server should be
registered as gateway.our.domain in the DNS.

Recently, information servers tend to be configured using a server pool to
balance the server load.  Our translater can be used for dynamic load balancing
for a server pool.

%%%%%%%%%%%
{Supporting application programs}

There are some network applications which can not be handled by the 
port-address translator we have described.  A special consideration is 
required to support these applications.  Let us first look at the most 
famous applications: FTP.

There are two different types of connections used in FTP.  The control
con for setting up the session and sending commands and
the data con for data transfer.  The control con
is established when the FTP session is first set up while the data
con is separately established and terminated whenever there is
a need for data transfer.  When FTP client needs to get some data from
the server, it sends a PORT command with its IP address and TCP port number 
for data con through the control con and waits 
listening to the port~{rfc:959}.  Upon receiving the PORT command, 
the FTP server establishes data con using the port number received.

When the client has a replicated address which is meaningless outside its
regional network, it still sends a PORT command with its IP address and port
number.  For the client to be able to establish the data con 
correctly, the port-address translator should recognize the packet carrying 
the PORT command and change the IP address and port number with a correct 
one before relaying this packet to the server.

This can be done by looking at the packets belonging to a FTP session and
look for the PORT command with IP address and port number.  Since all data 
are ASCII coded, it is relatively easy to find them.  However, there is a 
slight problem since modifying the address and port number often results in
different string length which causes inconsistent TCP sequence number.
The inconsistency in TCP sequence number can render further communication
impossible.  The sequence number as well as the acknowledgement number of
the ACK packet should be properly adjusted to ensure correct communication.
In our prototype, we solved this problem by keeping track of the difference
between the sequence numbers of the original packet and modified packet and
properly adjust all the sequence numbers and acknowledge numbers for the
forthcoming packets of the same FTP session.

Applications like SNMP often uses encrypted IP address and port number.
It is impossible to handle this kind of application which encrypts the packet
contents at this stage.  However, we believe that SNMP packets usually
are confined inside its regional network and did not consider SNMP.

To be able to implement a transparent port-address translator, it is 
necessary to classify each applications and devise appropriate translation
schemes for each of them.  We are currently working on other applications
we have overlooked using our prototype.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{Conclusion}

The port-address translator we propose can be used to reuse the IP addresses
without modifying existing applications or network structure.
It is also realizable with very little cost.  Compared to the address
translator using DNS which provides one to one mapping between globally unique
address and reused address, our scheme can provide a large number of 
connections using just one globally unique IP address.
Ultimately, it can be used to transform a class C network to a network
with only one globally unique IP address and reused addresses.
We believe that the IP address reuse through port-address translator is 
a very practical solution and it can be a short term solution to the IP 
address shortage.  The advantages of the port-address translator is summarized
as follows:

{itemize}
{The cost of implementing a port-address translator and following network
restructuring is comparable to that of packet filtering gateway.}
{The port-address translator provide users transparent service without
modifying existing applications programs or network topology.}
{It is possible to relay UDP packets by careful considerations.}
{It is possible to relay inbound requests by reserving ports or using
server pool.}
{Most of the applications such as FTP can be relayed by application
specific gateway.}
{It can provide security as a firewall does since it controls all 
outbound connections.}
{itemize}

However, the port-address translator has the following drawbacks.
These problems should be addressed before it can be a global, long term
alternative.

{itemize}
{There are some applications which need special consideration and 
some applications which can not be handled.}
{Various protocols such as ICMP, SNMP, RIP should be considered.}
{The ability to relay packets per unit time for a base hardware 
need to be evaluated.}
{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%% Import bibliography entries
%{rfc:1631}
%{rfc:1519}
%{rfc:1597}
%{socks}
%{bell:fw}
%{rfc:959}
%{franc}
%{rfc:791}
%{rfc:793}

{alpha}
{pat}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%% begin one column appendix

{}{1}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{TCP STATE trace algorithm for Port-Address Translator}{apdx:1}

{verbatim}
main()
{
    do {
        packet = get_next_packet();
        if (packet is from inner network) {
            newpacket = i_to_o(packet);
            send_packet(newpacket, outer network);
        } else {
            newpacket = o_to_i(packet);
            send_packet(newpacket, inner network);
        }
    } while(end);
}

i_to_o(packet)
{
    if (packet.flag == SYN) {
        alloc_port(packet);
    }

    newpacket.src_ip = gateway_ip;
    newpacket.src_port = get_gatewayport(packet.src_ip, packet.src_port);
    
    /* we should carefully design an algorithm to handle 
        graceful shutdown of TCP connection..TBD */
    if ((packet.flag == FIN) || (packet.flag == RST)) {
        prepare_release_port(packet);
    }
    if (packet.flag == ACK) {
        if (the packet is ACK to previous FIN..etc) {
            ......
            release port w.r.t. packet flags;
        }
    }

    return newpacket;
}

o_to_i(packet)
{
    if (port_table[packet.dst_port] == NULL) {
        /* no entry in table, which means there is no TCP client
           in inner network, so send back reset to source */
        newpacket.dst_ip = packet.src_ip;
        newpacket.dst_port = packet.src_port;
        newpacket.src_ip = packet.dst_ip;
        newpacket.src_port = packet.dst_port;
        newpacket.flag |= RST;
        return newpacket;
    }

    newpacket.dst_ip = port_table[packet.dst_port].inner_ip;
    newpacket.dst_port = port_table[packet.dst_port].inner_port;
    
    /* again, we should redesign following algorithm to handle
        graceful close of TCP connection */
    if ((packet.flag == FIN) || (packet.flag == RST)) {
        prepare_release_port(packet);
    }
    
    return newpacket;
}
{verbatim}

{document}