[attachment=1436]

---

The Use of Translators as a co-existence strategy for IPv4 - IPv6 transition for 3G evolution

ABSTRACT :
In the coming decade, we are said to confront the final frontiers of the mobile revolution. The 3G or the Third Generation mobile technology is expected to fulfil the idea of location and data independent communication. It is almost now clear that the packet switched (PS) technology will dominate the technological developments in the mobile sector. The packet switched technology would not only integrate the mobile infrastructure with the already existing Internet backbone, but also provide the facility of always on connection. These two features are seen to be two great leaps forward in the direction of 3G. The Packet switched technology would not only enhance the existing data messaging services, but also provide alternate voice services through VOIP. The mobile vendors have planned long term strategies for 3G evolution. The most popular path is through GSM-GPRS -EDGE. This has allowed gradual transition, giving enough time for development, deployment and testing of better technologies. This evolution is as much a challenge to the mobile sector as it is to the networking sector. The advent of 3G technologies would rather blur the line of distinction between the two. While the mobile sector moves towards 3G, the Internet infrastructure would be moving from IPv4 to IPv6. Each of these transitions are essential for the other, they rather form a symbiotic combination. The 3G technologies would need an IP address each, for all of its mobile terminates. The huge requirement of IP addresses can only be provided by the 128 bit IPv6. So the implementation of 3G technologies would speed up the IPv4 to IPv6 transition and vice versa. The mobility management too is essentially done through the Mobile IP (MIP), stressing the need further for IP integration into 3G.
There will be no sudden changeover from IPv4 to IPv6. Hence methods of coexistence between the two, forms an essential feature of the evolution. This paper discusses the coexistence strategies for IPv4 and IPv6 in general, and its specific applications in the mobile technologies. Further it discusses the implementation of two translation methods used for coexistence between IPv4 and IPv6 .

CONTENTS :
1. IP COEXISTENCE STARTEGIES 4
2. NAPT “ PT 4
3. TCP UDP RELAY TRANSLATOR 6
4. COMPARISON BETWEEN NAT-PT AND TRT 7
5. SPECIFIC APPLICATION OF TRANSLATORS IN THE MOBILE TECHNOLOGY. 8
6. CONCLUSIONS 9
7. REFERENCES 9

IP COEXISTENCE STARTEGIES :
The different methods for coexistence are
1) Dual IPv4/IPv6 Stack : Dual Stack provides the facility of both the protocols in terminals & routers, thus facilitating tunneling.
2) Tunneling : Here, encapsulation and decapsulation are used at terminal nodes.
3) Translation : This method is based on the header conversions, mostly the translation of source and destination IP addresses that are carried by the packets.
The two translation methods of coexistence discussed in this paper are
I. The Network Address Port Translation “ Protocol Translation
(NAPT PT)
II. Transport Relay Translator (TRT)
Both of the above are the Ëœmiddle boxâ„¢ based methods. The essential difference between the two is the layer at which they work. While the former works at the data page link layer the latter works at the transport layer.
NAPT-PT :
NAPT-PT [4] provides a combination of port multiplexing, address translation and IPv6/IPv4 protocol translation. It resides within an IP router, situated at the boundary between an IPv4 network (say the Internet backbone) and an IPv6 network (say the mobile network). By installing NAPT-PT between an IPv6 network and the Internet, all Internet users are given access to the IPv6 network without host modification. Equally, all hosts on the IPv6 network (the 3G mobile) are given access to the Internet with a pool of IPv4 addresses.

Suppose that some applications carry network addresses in payloads. Because NAPT-PT does not snoop the payload, it can be application unaware. So, NAPT-PT requires some Application Level Gateway (ALG) which are application specific programs that allow an IPv6 node to communicate with an IPv4 node and vice versa on a particular application level program. That is, ALG could work in conjunction with NAPT-PT to provide support for many such applications.

Implementation :
The implementation of this model requires no change in either host or the router configurations[3]. The system that works as NAPT has two interfaces as in the figure 1. It uses multi- homing. One Ethernet interface is connected to the IPv6 network while the other to the router that routes the packet to the (IPv4) internet. The implementation is discussed below : -
1. Two simultaneous processes on the NAPT-PT system continuously sniff for packets on the two respective interfaces. When a packet arrives, it passes the same for processing. This is done by Packet capturing utilities. Note that, as we need to extract the addresses and the port numbers from the packets, the packet needs to be captured at the Data-link layer itself. Since only those packets destined to reach this system are to be accessed, promiscuous mode is not used.
2. The NAPT maintains a record table that has the entries for all the connections through it. The extracted addresses and port numbers from the arrived packets are matched with the records of the NAPT-PT table and manipulated accordingly.
3. If the protocols that carry the address or address related information, are to be made available, then it needs an ALG. We have restricted our implementation to only HTTP.
4. The two processes work in totally different memory segments. Hence the variables in the two processes would not correspond to the same location. Since both the processes need to access the table, the inter-process communication technique comes handy. This is done by storing the table in the Shared Memory area so that it can be accessed by both the processes. The following blocks show the implementation of the two processes mentioned above.
Process 1 :
When a packet is destined to reach a terminal outside the LAN (the IPv6 network) , the following manipulations are made before routing the packet.
a. search is made in the records to find if the connection already exists.
b. If yes, the source IP address is replaced by that of the NAPT- PT and the source port number is replaced by the port number already assigned to this Ëœconnectionâ„¢.
c. If no, a new entry is made into the table and an unused port number is assigned to it.
d. The packet IP header is now manipulated, i.e the IPv4 addresses are now changed with the IPv6 address(es) assigned to the NAPT-PT system and the port numbers are replaced with the already assigned port numbers.
Process 2 :
For the packets that arrive from outside the LAN i.e from the global IPv4 network, the following manipulations are necessary before they are passed on to the LAN system.
1. Search is made in the records to find if the connection already exists.
2. If exists, the destination IP address which is that of the NAPT-PT is replaced by that of the local host, based on the assigned port number. It is effectively the port de-multiplexing that is taking place here.
3. If not, the packet is discarded.
TRANSPORT RELAY TRANSLATOR :
The TCP UDP Relay Translator (TRT) [5] is a transport layer system that performs IPv4 “ IPv6 translation and vice versa. It is similar to NAPT-PT in its application. But here, rather than capturing individual packets at the data page link layer, the data is transferred by establishing connections at the transport layer. Figure 4 illustrates the concept better.

Whenever a host from the IPv6 network tries to initialize a connection
with a remote host in the internet, the connection is accepted by a listening socket at the TRT system. Once the connection is accepted, the TRT in turn sends a request to establish a connection with the remote server. Hence an indirect connection is established between the hosts through the TRT.
Implementation :
The implementation of the TRT is similar to that of the NAPT-PT, but there are glaring differences too. 1. The TRT also has more than one simultaneous processes running as in a server. The parent process has a listening socket that waits for a connection. When a connection is requested, a child process is forked off which manages the setup of the Ëœindirect connectionâ„¢. When the connection is closed the child process too is killed.
2. The TRT has to have a mechanism which distinguishes the various application level protocols like HTTP, FTP etc. This is needed for the extraction of the information of the remote host, as the IP address may not be directly available.
3. Further the TRT needs to extract and sometimes also resolve the destination IP address. Our implementation is for the HTTP. It can similarly be extended to the other protocols too.

COMPARISON BETWEEN TRT AND NAPT- PT :
Structure : The basic difference between the too translators is the layer at which they work. As discussed earlier the TRT works at the transport layer while the NAPT-PT works at the Data page link layer. This makes the two to differ in many aspects.
Speed : The overhead in NAPT- PT is theoretically less than the TRT, but the speed is highly implementation dependent.
Security : Both the systems compromise on security, while TRT completely disallows security measures like IPsec, the addresses in the packets cannot be encrypted if the NAPT “ PT is used.
Probability of errors : NAPT “PT increases the probability of mis- addressing , while this is avoided in the TRT as a reliable connection itself exists.

SPECIFIC APPLICATION OF THE TRANSLATORS IN THE MOBILE SECTOR :
Consider the GPRS network shown in the figure. The figure shows how a translator is connected between the IPv6 mobile network and the Internet ( IPv4 network). It also shows how mobility management is done using mobile IP. The SGSN ( Serving GPRS Support Node) essentially looks after the issues concerning mobility management. The GGSN (Gateway GPRS Support Node) connects the network to the external networks including the Internet. From outside ( i.e from the IP networks point of view) the GPRS network is another IP sub-network and the GGSN looks like a IP router. One of the main advantage of integrating the mobile network into the IP network is mobility management. The mobility management using MIPv6 provides always on connection.

Although Mobile IPv4 can be used for mobility management, but the Address Depletion Problem makes the use of IPv6 inevitable. So it is seen that the mobile networks would move towards IPv6 faster than the Internet backbone. The translators provide a coexistence strategy for the two versions of the protocols till the IPv6 becomes prevalent in the Internet backbone.

Another aspect that needs to be dealt while using the translators mostly the NAPT-PT in the mobile networks is that the (Session Initiation Protocol ) SIP [6] to inter-work with the Mobile IP[1]. This requires a specific ALG that can interpret the SIP signaling.
CONCLUSIONS:
1) IPv6 is a strategic issue making its own scope in the global network system. It is experiencing its needs and at the same time the research community is working on its perfection.
2) IPv6 is perfectly hailed as ˜evolutionary not revolutionary™. The IPv4 “ IPv6 transition is expected to be eventual rather than sudden in the Internet backbone. But the 3G technologies would inevitably need IPv6. Hence there will be a time period wherein both the versions of the IP need to coexist.
3) The translators provide a coexistence strategy for IPv4 - IPv6 transition.
4) Although they provide a temporary solution, they need to be eliminated in the long run, due to the overhead that the translators add in terms of speed and also due to the security constraints that they impose.

REFERENCES :
1. IEEE communications Magazine, January 2004, page 113 to 120, IP Multimedia Services : Analysis of Mobile IP and SIP interactions in 3G networks by Stefano M. Faccin, Nokia Research Center, Poornima Lalwaney, Nokia Mobile Phones, Basavaraj Patil, Nokia Networks.
2. IEEE communications Magazine, January 2004, page 88 to 96, IPv6 integration and coexistence strategies for Next- Generation Networks by Mallik Tatipamula and Patrick Grossetete, Cisco Systems Hiroshi Esaki, University of Tokyo.
3. RFC 1631, 4. RFC 2766, Network Address Translation - Protocol Translation (NAT-PT), G. Tsirtsis BT, P. Srisuresh, Campio Communications, February 2000. 5. RFC 3142 , An IPv6-to-IPv4 Transport Relay Translator, J. Hagino and K. Yamamoto, IIJ Research Laboratory, June 2001. 6. RFC 3261, Session Initiation Protocol, J. Rosenberg t, H. Schulzrinne, G camarillo, A Johnston, J Peterson, R sparks, M. Handlsy, E Schooler, June 2002

---