|
 |
| ARTICLE |
|
|
|
| Year : 2012 | Volume
: 29
| Issue : 2 | Page : 114-132 |
|
|
Assuring Interoperability Between Heterogeneous (IPv4/IPv6) Networks Without using Protocol Translation
Ala Hamarsheh1, Marnix Goossens1, Ahmad Al-Qerem2
1 Department of Electronics and Informatics ETRO, Faculty of Engineering, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Elsene Brussels, Belgium
2 Department of Internet Technology, Faculty of Science and Information, Technology, Zarqa University, B.O. Box 150863-Code, No. 13116, Zaqra, Jordan
| Date of Web Publication | 25-Apr-2012 |
Correspondence Address:
Ala Hamarsheh
Department of Electronics and Informatics ETRO, Faculty of Engineering, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Elsene Brussels
Belgium
 DOI: 10.4103/0256-4602.95384
 Abstract | | |
This paper introduces a new mechanism called AIN-PT, which stands for Assuring Interoperability between heterogeneous (IPv4/IPv6) Networks without ("minus") using Protocol Translation. The mechanism intends to make communication between two heterogeneous networks (operating on two different IP protocols) possible by tunneling IPv4 packets in IPv6 packets, instead of translating complete headers between IPv4 and IPv6. With the AIN-PT mechanism, the translation is limited to mapping addresses between IPv4 and IPv6. This mechanism can be deployed by Internet Service Providers (ISPs) or any other service providers in different stages of the transition to IPv6. The performance of AIN-PT was measured on different interoperation network scenarios, and the overall performance analysis showed that AIN-PT has better performance, in comparison with current protocol translation-based techniques. Keywords: IPv4/IPv6 networks, Protocol translation, Protocol tunneling, Internet service provider, IPv6 transition
How to cite this article:
Hamarsheh A, Goossens M, Al-Qerem A. Assuring Interoperability Between Heterogeneous (IPv4/IPv6) Networks Without using Protocol Translation. IETE Tech Rev 2012;29:114-32 |
How to cite this URL:
Hamarsheh A, Goossens M, Al-Qerem A. Assuring Interoperability Between Heterogeneous (IPv4/IPv6) Networks Without using Protocol Translation. IETE Tech Rev [serial online] 2012 [cited 2013 May 20];29:114-32. Available from: http://tr.ietejournals.org/text.asp?2012/29/2/114/95384 |
| 1. Introduction | |  |
IPv6 was introduced to overcome all the limitations associated with IPv4, of which the most important was scarcity in the IPv4 address space, but also routing issues, security (IPSec), etc. The IPv6 address comes with a 128-bit (16-bytes) address scheme, whereas IPv4 has a 32-bit (4-bytes) address scheme. This means that IPv6 can accommodate more than 3.4×10 38 possible unique addresses [1] .
When the new Internet protocol (IPv6) will be fully deployed, all features and improvements of IPv6 will be provided to all network-connected devices. The transition to IPv6 will require all the network elements and hosts to be upgraded to support IPv6 however. Furthermore, less obvious at first, the applications will need to be upgraded to be IPv6 capable as well [2] . Due to the size of the Internet, there will be no "flag day" for the transition to IPv6. The new protocol will slowly and gradually spread into networks and across the whole Internet. The coexistence of both Internet protocols will remain for a considerable amount of time. The Internet Engineering Task Force (IETF) has proposed several transition mechanisms to assure a smooth and successful transition to IPv6. A transition mechanism is a way to facilitate the connection between hosts/networks using the same or different IP protocols. Generally, IPv6 transition mechanisms can be classified into three approaches: dual-stack, tunneling, and translation [3] .
Dual stack: The idea behind dual stack approach is to implement both IPv4 and IPv6 protocol stacks and also provide connectivity to both types of networks at devices that require access to both protocols. These devices use the IPv6 stack and connection when communicating with IPv6 nodes, and they use the IPv4 stack and connection when communicating with IPv4 nodes.
Tunneling approach is commonly used for hosts/networks to communicate with each other using the same IP version (IPv4 or IPv6) but communicating over a different IP protocol infrastructure. For example, tunnels can be used to connect IPv6 nodes/networks separated by IPv4 network(s). In this case, IPv6 packets will be encapsulated into IPv4 packets, and then transmitted over the IPv4 network infrastructure, and decapsulated on arrival. Similarly, tunnels can be used to connect IPv4 nodes/networks separated by IPv6 network(s). The IETF proposed tunnels cannot be used to interconnect between systems/networks using different IP versions however.
The translation approach is used when communication is required between systems/networks operating in a different IP version. In this case, translation of the full IP headers from IPv4 to IPv6 and vice versa is required for every IP packet [4] . [Figure 1] shows the functionality of a translator located between heterogeneous networks. | Figure 1: The functionality of a translator located between heterogeneous networks.
Click here to view |
For interconnecting machines in heterogeneous IPv4/IPv6 environments (IPv4-only connectivity to IPv6-only connectivity), translation is the only option.
As far as interconnecting IPv4 and IPv6 network communication, several protocol translation mechanisms have been proposed, but they have many common limitations [5],[6],[7]:
- Some IPv4 header fields have changed meaning in the IPv6 header. This will not make translation between them straightforward.
- Translation inhibits end-to-end network security. The IP header is protected by cryptographic functions, and hence the translator has no access to the encrypted values.
- Translation of both DNSSEC [8] and end-to-end IPSec is not possible.
- Limited translator capacity (the number of simultaneous connections are limited). This may be used by denial-of-service attacks throughout exhausting the memory and address/port pool resources on the translator.
- Protocols that embed IP addresses into payloads do not get translated properly. Such protocols include DNS, FTP, SIP, RTP, and ICMP. Therefore, implementing an Application Level Gateway (ALG) is required for each of these protocols.
- As translation requires translating every IP header, processing overhead in the translating device is quite high.
- Most proposed mechanisms are based upon stateful operation, which is ill matched to the stateless IP operation.
This paper proposes a mechanism where tunneling is used in a slightly different way from what is proposed by IETF to interconnect IPv6 with IPv4 communications, and where translation is limited to a "one-time" address translation only (i.e., not for every packet but only at the start of the communication session between hosts) for communication between two nodes connected to different IPv4/IPv6 version networks. The AIN-PT mechanism assures bi-directional interoperability between two heterogeneous networks (i.e., requests initiated from an IPv4 zone to an IPv6 zone, and request initiated from IPv6 zone to IPv4 zone). [Table 1] lists all interoperation scenarios between two heterogeneous networks [9] in which AIN-PT can be used.
The AIN-PT can be used in different stages of the transition to IPv6, for example, when an Internet Service Provider (ISP) is operating in IPv6 only, and there are IPv6-only hosts wanting to communicate with IPv4-only hosts; or when an ISP is not yet supporting IPv6 to its clients, and there are some IPv4-only hosts are wanting to communicate with IPv6-only hosts.
The rest of the paper is organized as follows. Section 2 illustrates the related work. In section 3, we defined some terms used in this paper. In section 4, we discussed the AIN-PT mechanism and its components. Section 5 illustrates the AIN-PT address handling. Section 6 illustrates AIN-PT detailed network scenarios and behaviors. Section 7 analyzes and compares the performance of the proposed mechanism with protocol translation-based mechanisms, and section 8 concludes the paper.
| 2. Related Work | | |
In this section, we briefly present some of the research literature related to translation between heterogeneous environments and the proposed mechanism in this paper.
Host-based mechanisms:
- Bump-in-the-API (BIA) [10] is customized for dual-stack hosts. BIA is a mechanism that is inserted between the Application Programming Interface (API) module and the Transmission Control Protocol/Internet Protocol (TCP/IP) module. The main purpose of this mechanism is to make IPv4 only applications communicate with applications that can only communicate using IPv6 (IPv6-only connectivity and/or IPv6-only application) without any modification of those applications. This would be achieved by translating the IPv4 API functions into IPv6 API functions and vice versa
- Bump-In-the-Stack (BIS) [11] is also customized for dual-stack hosts. It allows hosts to communicate with other IPv6 hosts using existing IPv4 only applications. The technique uses host-based Stateless IP/ICMP Translation (SIIT) (see related work) translation for the IPv4 traffic into IPv6 traffic and vice versa. The translator is inserted between the TCP/IP module and the network card driver
- BIH [12] is a successor and combination of the two protocols BIA and BIS. It aims to allow IPv4-only applications to communicate with IPv6-only hosts by synthesizing IPv4-addresses from 'AAAA' records. BIH includes two implementation options: a protocol translator extended from BIS and an API translator extended from BIA. Unlike BIA and BIS protocols, BIH supports IPv6-only network connections
- Decoupling Application IPv4/IPv6 Operation from the Underlying IPv4/IPv6 Communication (DAC) [2] (by the authors of this paper) is a generalization of BIA. It allows any mixture of IPv4/IPv6 capable applications to communicate over any IPv4/IPv6 connections with any IP version capable remote applications. DAC effectively decouples application IPv4/IPv6 capability from IPv4/IPv6 connectivity, and allows IPv4/IPv6 incompatibility between two communicating applications. Unlike BIA, BIS, and BIH, DAC can be used in situations where IPv6-only applications need to communicate over IPv4-only connections.
The common key aspect behind all these protocols (i.e., BIA, BIS, BIH, and DAC) is to support the incompatibility between the running application and the host's connectivity only. These protocols all fail to support the situation where a client and a server are connected to two different IP versions. Till now, a protocol translation-based technique must be used to support this situation, which means translation is needed for the IP headers from IPv4 to IPv6 and vice versa [13] . The detailed process of how IP headers are translated can be found here [14] .
Most recent translation mechanisms use the SIIT algorithm to translate the IP headers between IPv4 and IPv6 networks, for example NAT64 [15] and Bi-directional Mapping System as a New IPv4/IPv6 Translation Mechanism (BDMS) [16] mechanisms; it is also used in BIS translation.
- SIIT Algorithm [4] is a common protocol translation-based algorithm to translate between IPv4 and IPv6 packet headers. When it is configured at an IPv6 node (i.e., host/router), it will translate the transmitted IPv6 packet headers into IPv4 headers, and the received IPv4 packet headers into IPv6 headers
- NAT64 is a stateful IPv6 transition mechanism to allow IPv6-only clients to initiate communications with IPv4-only servers. The NAT64 server is installed at the ISP border network to connect between IPv6 and IPv4 networks. The NAT64 server implements the SIIT algorithm to translate the IP headers of IPv4 and IPv6 protocols. Additionally, it maintains a NAT-mapping between IPv4 and IPv6 addresses. The mechanism must be deployed in conjunction with a special DNS server to synthesize 'AAAA' record(s) from 'A' record(s). Since NAT64 implements the SIIT algorithm to translate packets between IPv4 and IPv6 protocols, it has the same common limitations associated with any protocol translation-based technique (see section 1). Additionally, NAT64 cannot be used in situations where an IPv4-only client wants to initiate communication with an IPv6-only host, except through statically configured binding
- BDMS is a stateful IPv6 transition mechanism to allow the communication between two IPv4/IPv6 networks (for connections initiated from IPv4 to IPv6, and for connections initiated from IPv6 to IPv4). It translates the addresses and the IP headers in each communication session. The BDMS domain consists of the following servers: DNS4, DNS6, DNS v4-v6 server, and v4-v6-enabled gateway. Moreover, the domain consists of IPv4-only and IPv6-only hosts. The mechanism mainly translates the IPv6 addresses into public IPv4 addresses from the assigned IPv4 public address pool. In order to allow communication between two IPv4 and IPv6 zones, it uses the SIIT algorithm to translate the IP headers between the two protocols. For example, when an IPv6-only host wants to initiate communication with an IPv4-only host, BDMS will translate the private IPv4 into public address, then map this public address with the corresponding IPv6 address, and send the resolved IPv6 address back to the requesting IPv6 host. Later on, when the client transmits an IPv6 packet to an IPv4-only host, this packet will be delivered at the v4-v6-enabled gateway. The v4-v6 gateway will change the destination address into IPv4 address, translate the IPv6 header into the equivalent IPv4 header, and finally forward the IPv4 packet to its destination.
In addition to the limitations associated with SIIT-based mechanisms, BDMS has the following drawbacks: (1) both IPv4 and IPv6 networks must have both v4-v6-enabled gateway and DNS46 modules installed; (2) it assigns public IPv4 addresses from the public IPv4 address pool, but this is nearing its exhaustion now; (3) since BDMS servers are distributed all over the Internet, the response time may be high, due to the propagation requests through different types of DNS servers. - DNS64 [17] provides great transparency in resolving domain names. It allows the IPv6 initiator host to perform a traditional 'AAAA' resource record DNS lookup to learn the destination host address including those with only IPv4 'A' records. If only 'A' records are available, it synthesizes 'AAAA' records from the 'A' records which contain the real IPv4 addresses of the destination servers (IPv4-embedded IPv6 address). One of the required configuration parameters of DNS64 is the IPv6 prefix (Pref64).
The AIN-PT mechanism does not rely on SIIT or any other protocol translation-based algorithm to translate the IP headers between IPv4 and IPv6 networks. Instead, it uses a tunneling approach to traverse the IPv6-only networks without any modifications to these IPv4 packets.
It is important to note that the mechanisms 6rd [18] , DSLite [19] , and CHANC [20] cannot be used in the places where an IPv6-only client wants to communicate with an IPv4-only server or an IPv4-only client wants to communicate with an IPv6-only server. They can only be used to provide dual connectivity across IPv4 access networks infrastructure when both end-users' hosts are IPv6 capable. Thus, these mechanisms are out of scope of this paper.
| 3. Terminology | | |
This section provides a definitive reference for all the terms used in this paper.
- IPv4-only host: A host that implements only an IPv4 stack. An IPv4-only host cannot recognize IPv6 packets
- IPv6-only host: A host that implements only an IPv6 stack. An IPv6-only host cannot recognize IPv4 packets
- IPv4/IPv6 host: A host that implements both IPv4 and IPv6 stacks and has both IPv4 and IPv6 connectivity. An IPv4/IPv6 host can recognize both IPv4 and IPv6 packets
- IPv6 host: A host that implements both IPv4 and IPv6 stacks, but with IPv6-only network connectivity
- IPv4 host: A host that implements both IPv4 and IPv6 stacks, but with IPv4-only network connectivity
- IPv4-only application: It has only IPv4 addressing capability
- IPv6-only application: It has only IPv6 addressing capability
- IPv4/IPv6 application: It has both IPv4 and IPv6 addressing capability.
| 4. The AIN-PT Mechanism | | |
As indicated previously, AIN-PT allows heterogeneous (IPv4/IPv6) communication between two or more networks without using protocol translation. AIN-PT should be installed at either the IPv4 or IPv6 ISP network, and on each IPv6 hosts that wants to use this. No modification to any of the huge, older installed base of IPv4 only or IPv4 hosts is required with AIN-PT; the rationale behind this is that having something extra installed in the small, new installed base of IPv6 machines is much more likely achievable than having to install something in the old and huge IPv4 base of machines.
[Figure 2] shows the AIN-PT installed at the IPv6-only network. This allows IPv6 hosts to initiate communication to IPv4-only hosts. In this configuration, AIN-PT modules have to be installed in the IPv6 network (DNS64) and the IPv6 host (DAC and Tunneler). When an IPv6 application is trying to resolve a host's IP address located in IPv4-only zone, the DNS64 at the IPv4/IPv6 border of the IPv6 network will synthesize the IPv4-embedded IPv6 address from the resolved server's IPv4 address and send it back to the AIN-PT host. Although the received address is an IPv6 address, the AIN-PT host will translate the application's IPv6 API functions into equivalent IPv4 API functions, arranging the application communication with the host that communicates in IPv4 only using IPv4 protocols. After that, the AIN-PT host will tunnel the IPv4 packets into IPv6 packets and transmit them over IPv6 network infrastructure to the AIN-PT gateway router. The AIN-PT gateway router at the IPv4/IPv6 border of the IPv6 network will decapsulate the received IPv4-in-IPv6 [21] packets, carry out the appropriate addressing (see further), and finally forward the IPv4 packets to the IPv4 network.
[Figure 3] shows the AIN-PT mechanism installed at the IPv4-only network. This allows IPv4 hosts to initiate communication to IPv6 hosts. When an IPv4 application is trying to resolve a host's IP address located in IPv6 zone, the customized DNS (Address Pool IPv4 → IPv6 (AP46)) at the IPv4/IPv6 border of the IPv4 network will map the resolved server's IPv6 address into a mapped IPv4 address of a private network space* that corresponds with the IPv6 network destination and send it back to the IPv4 host. The IPv4 host will transmit IPv4 packets over IPv4 network to the AIN-PT gateway router that has been configured to have "routing" to that private network range. The AIN-PT gateway router at the IPv4/IPv6 border of the IPv4 network will encapsulate the received IPv4 packets into IPv4-in-IPv6 packets, carry out the appropriate addressing (see further), and finally forward the IPv4-in-IPv6 packets to the IPv6 network. The destination IPv6 host will decapsulate the IPv4-in-IPv6 packets and pass them on to the application trough the IPv4 stack.
Summarized, we can say that the AIN-PT mechanism when installed at the IPv6 network allows IPv6 (or IPv6- only) applications that are running on IPv6-only or IPv6 hosts to initiate communications with IPv4-only or IPv4 hosts. Similarly, when the AIN-PT mechanism is installed at the IPv4-only network, it allows IPv4-only applications that are running on IPv4-only or IPv4 hosts to initiate communications with IPv6-only or IPv6 hosts without translating the full IP headers between different networks. In both cases, only address conversion is required (see further). When the ability to initiate communication is needed from both IPv4 and IPv6 sides, AIN-PT needs to be installed at both IPv4 and IPv6 edges.
The ISP network should have the AIN-PT Tunnel Gateway (ATG) and either DNS64 (IPv6 network) or Address Pool IPv4 → IPv6 (AP46) (IPv4 network) installed. The IPv6 peer host should have the DAC and the Tunneler modules installed in the same way as above.
The following subsections detail the AIN-PT components at both end-user IPv6 host and network side.
4.1 AIN-PT Host Architecture
AIN-PT-based IPv6 hosts should have two modules installed: DAC and Tunneler. [Figure 4] illustrates the AIN-PT host-based architecture.
4.1.1 DAC
DAC [2] was originally designed to deal with incompatibility between the running application and the current host connectivity type. It translates the API functions from one protocol stack (IPv4 or IPv6) into the other, and does the appropriate internal addressing conversions when necessary. It consists of two sub-modules, the API "redirector" and an ENR (Extended Name Resolver), which is a modified version of the standard DNS name resolver and handles address conversions. The trigger that makes DAC to translate between IPv4 and IPv6 API functions is the incompatibility of IP versions between the running application and the current host connectivity. However, in this AIN-PT mechanism, we will add a new trigger to DAC to translate between IPv6 and IPv4 API functions: Despite the fact that the running application using IPv6 is compatible with the current host connectivity IPv6, DAC will translate the IPv6 API functions into equivalent IPv4 API functions if the received IPv6 address contains a certain IPv6 prefix (see further). These received IPv6 addresses are created either by the DNS64 when the AIN-PT is installed at an IPv6-only zone, or by the ATG when the AIN-PT is installed at an IPv4-only zone (see further). Also, the ENR in DAC is configured with specific IPv6 prefixes that will be used in synthesizing IPv6 addresses from IPv4 addresses.
Strictly speaking, with applications that are both IPv4 and IPv6 capable redirection of IPv6 to IPv4 would not be needed, as the application would communicate using the IPv4 API functions, and only the ENR needs to be used in AIN-PT. Redirection from IPv6 to IPv4 was added in the AIN-PT mechanism to make it more general, as to be able to translate the IPv4 traffic toward the IPv6 API functions in the particular situation that the application is IPv6-only.
4.1.2 Tunneler
This module is responsible for receiving the incoming tunneling IPv6 packets (passed from the IPv6 standard layer with next header field set to 41, the code for IPv6 tunneling). It will do the required address manipulation in the IPv4 address fields, and then forward the extracted IPv4 packet to the IPv4 stack. Similarly, the Tunneler will take the outgoing IPv4 packets, do the required address manipulations inside the IPv4 header, and pass them to the IPv6 layer for tunneling (see further). The interaction with the IPv6 stack is standard, the interaction between Tunneler and the lower side of the IPv4 stack is implementation dependent (e.g., a pseudo network driver).
4.2 AIN-PT Network Infrastructure
AIN-PT can be installed at the IPv4/IPv6 border both of IPv4 and IPv6 networks, at the IPv6 side to allow IPv6 hosts to initiate a communication to IPv4 hosts and at the IPv4 side to allow IPv4 hosts to initiate communication to IPv6 hosts. Thus, there will be two different types of configuration to set up AIN-PT at the ISP side. Based on the network interoperation scenario, the network administrator should deploy either DNS64 or AP46. DNS64 is used to synthesize 'AAAA' records from 'A' record. AP46, which extends the functionality of DNS46 [22] , is used to synthesize 'A' records from 'AAAA' records. The ATG router is installed at the ISP as default router to connect between the two heterogeneous networks. The ATG is a router that has at least one IPv4 interface and one IPv6 interface. When it is installed at the IPv4/IPv6 border of the IPv6 network, it will allow AIN-PT hosts to initiate communications with IPv4-only hosts. Similarly, when it is installed at the IPv4/IPv6 border of the IPv4 network, this will allow IPv4-only hosts to initiate communications with IPv6-only hosts. The ATG is mainly responsible for decapsulating the IPv4-in-IPv6 packets and forwarding them to the IPv4 zones, as well as encapsulating the received IPv4 packets into IPv6 and forwarding them into AIN-PT IPv6 zones. Furthermore, it does all the required address manipulation when packets are traversing between the heterogeneous networks.
The following subsections detail the configuration and behavior of each AIN-PT network component when requests are initiated from IPv6-only zones to IPv4-only hosts and from IPv4-only zones to IPv6-only hosts.
4.2.1 DNS64
The DNS64 is installed at the IPv6-only zone. It will use Pref64 and the destination IPv4 address to synthesize 'AAAA' records. To allow the outgoing IPv6 packets that have an IPv4 host as destination to traverse the ATG router, both devices (DNS64 and ATG) must use the same Pref64 and the same synthesizing algorithm. As they are using the same Pref64, the outgoing IPv6 packets will be routed to the ATG device. They will also both create the same IPv6 address from resolved IPv4 address.
4.2.2 AP46
The AP46 is installed at the IPv4-only zone. Functionally, it synthesizes 'A' records from 'AAAA' records, and creates IPv4 addresses for IPv6 hosts. The original DNS46 works in stateless operation [section 1.3 of [4] ] and uses IPv4-translatable addresses [23] in synthesizing 'A' records from 'AAAA' records in the scenarios 2 and 6 in the table at the introduction (i.e., IPv4 Internet → IPv6 Network and IPv4 Network → IPv6 Network). In this mechanism, the functionality of the original DNS46 is extended into the AP46 module in order to handle the following interoperation scenarios: IPv4 Internet → IPv6 Network, IPv4 Network → IPv6 Internet, IPv4 Network → IPv6 Network, and IPv4 Internet → IPv6 Internet, which actually means all scenarios. The AP46 works in stateful operation; this means it maintains a table to map the IPv6 addresses with the corresponding IPv4 addresses in order to create 'A' records for the destination IPv6 hosts and remembers these mappings.
The AP46 appears as a traditional DNS server to the IPv4 source host. First, it attempts to resolve 'A' records. If there is no 'A' record available for the destination host (this is the normal situation when the destination host is an IPv6-only host), then it performs an alternative query to resolve 'AAAA' records. For each 'AAAA' record resolved, AP46 will check if the resolved 'AAAA' record is a translatable record or not. A translatable address means that the IPv6 address contains the embedded IPv4 address of the machine, and the AP46 can extract the IPv4 address from the 'AAAA' record; translatable addresses are recognizable by specific IPv6 address prefixes. If not translatable, a mapping entry is created by mapping the resolved host's IPv6 address into a mapped IPv4 address of a private network space* that corresponds with the IPv6 network destination. Finally, it will send the resolved IPv4 address back to the host.
To make the IPv4 packets that are transmitted to an IPv6 host routed at the ATG router first, the AP46 assigns IPv4 addresses with the same Classless Inter-Domain Routing (CIDR) [24] of the ATG router. Thus, all the outgoing (IPv4 → IPv6) traffic will be routed to the ATG router.
4.2.3 ATG
The ATG router is mainly responsible for encapsulating and decapsulating the traffic exchanged between two heterogeneous IP zones. It decapsulates the IPv4-in-IPv6 packets received from the IPv6 zone and forwards them to the IPv4 zone. Similarly, it encapsulates the received IPv4 packets into IPv6 packets and forwards them to their destinations inside the AIN-PT IPv6 zone. The ATG does all the address manipulation in this heterogeneous environment (see next section). It is installed at the IPv4/IPv6 border of the IPv6 ISPs with DNS64 or at the IPv4/IPv6 border of the IPv4 ISPs with AP46.
The ATG maintains a dynamic data structure (mapping tables, similar to NAT64 mapping tables) to record addressing information for each communication session (IPv6 → IPv4, and IPv4 → IPv6). The ATG dynamic data structure is physically a mapping table dynamically allocated to record addressing information for the active connections initiated from AIN-PT IPv6 zones and needing to be transmitted to IPv4-only zones, or for connections initiated from IPv4-only zones and needing to be transmitted to AIN-PT IPv6-only zones. The mapped records are potentially reused for certain subsequent connections between the same machines. These tables are ATG_AP64 and ATG_AP46, and the ATG router is responsible for managing these tables (deleting or adding records, see further). [Figure 5] and [Figure 6] show the structure of ATG_AP64 and ATG_AP46 tables, respectively. These mapping tables should be supported with a round-robin scheme to drop mappings longest unused.
| 5. Address Handling | | |
When an IPv6 application which is running on an AIN-PT host wants to communicate with an IPv4-only host, it asks to resolve the IP address of that host. If the ISP has AIN-PT installed at the IPv6 side, then the application will receive a synthesized IPv6 address for the IPv4-only host. This address contains a Network-Specific IPv6 prefix [23] which will subsequently be called Pref64 and is used by all the AIN-PT components (DAC, Tunneler, ATG, and DNS64). DAC at the IPv6 host will recognize this address by parsing Pref64, and then the name resolver of DAC will create an 'AAAA' record and pass this record to the IPv6 application. When the IPv6 application calls the IPv6 API functions to connect to that address, DAC will extract the IPv4 address from the IPv4-embedded IPv6 address, then translate these function calls into equivalent IPv4 API functions. As a result, the IPv4 stack will be used in the current communication. After that, the Tunneler will tunnel the IPv4 packet into an IPv6 packet and transmit it over the IPv6 network to the ATG at the IPv6 side; the ATG is in the same network as the AIN-PT host, and therefore the prefix used in the IPv6-embedded destination will make the ATG that is the router for that address. Since there is no IPv4 address assigned for the sending IPv6 host, the IPv4 stack is configured with an IPv4 address, which will be of no further consequence, and the extracted IPv4 address of the destination host as the destination address in the IPv4 packet. As for the IPv6 header, the Tunneler assigns the IPv6 address of the AIN-PT host as the source address, and the IPv4-embedded IPv6 {Pref64+IPv4} address as the destination address. This tunneled packet is sent to the ATG in the IPv6 part. The ATG will decapsulate the IPv4 packets and set up the required 'NAT64-style' mapping between the source IPv6 address and destination IPv4 address and the port numbers (see the ATG_AP64 table in [Figure 5]), and replace the Tunneler-assigned IPv4 private source address by its own IPv4 address (see next section). [Figure 7] shows the structure of an IPv4-in-IPv6 packet transmitted to an IPv4 network over an IPv6 network.
The possible reply from the IPv4-only host is send to the ATG. It looks it up in the mapping table (ATG_AP64) trying to find addresses related to the current session. After that, the ATG will encapsulate the received IPv4 packet into an IPv4-in-IPv6 packet and configure the source address and the destination address of both IPv4 and IPv6 headers. As for IPv4 header, the ATG assigns the IPv4 address of the IPv4-only host as the source address, and IPv4 private address of the AIN-PT host retrieved from the mapping table as the destination address. As for the IPv6 header, the ATG assigns the IPv6 address of the AIN-PT host as the destination address, and the IPv4-embedded IPv6 {Pref64+IPv4 address of the IPv4-only host} address of the IPv4-only host as the source address. The tunneled packets will be forwarded to the AIN-PT host over the IPv6 network. The AIN-PT IPv6 host receives the tunneled traffic and the Tunneler inside will decapsulate the IPv4 packets. These packets will be passed on to the IPv4 stack. These arrive in the DAC API module, which will synthesize (embedded) IPv6 addresses for the source private IPv4 address that was assigned by the Tunneler and the IPv4 destination address. The IPv4 call will be rerouted by DAC to the IPv6 application API, and passed on the application.
When an IPv4 application, which is running on an IPv4-only host, wants to communicate with an AIN-PT IPv6 host, it asks to resolve the IP address of that host. If the ISP has AIN-PT installed at the IPv4 side, then the IPv4 application will receive a synthesized (mapped) IPv4 private address space address for the AIN-PT IPv6 host by AP46. The IPv4 packet will be sent to ATG (both the synthesized IPv4 address and the ATG IPv4 address will have the same CIDR, and the ATG will be seen as router to that destination). The ATG will query the AP46 about the IPv6 address of the destination IPv6 host in terms of the synthesized private IPv4 address, and then encapsulate the IPv4 packets into IPv6 packets and set up the required mapping between the source IPv4 address and destination IPv6 address (that was retrieved from AP46) and the port numbers (see the ATG_AP46 table in [Figure 6]). The ATG will encapsulate the received IPv4 packet into an IPv4-in-IPv6 packet and configure the source address and the destination address of both IPv4 and IPv6 headers. As for IPv4 header, no change is required on the source address and the destination address. As for IPv6 header, it will synthesize the source IPv6 address using Pref64 and its own IPv4 address (IPv4-embedded IPv6 address). After that, it will assign the IPv6 address of the IPv6 destination host as the destination address, and forward the tunneled packets over IPv6 network (see next section) to that host. [Figure 8] shows the pseudo code of the ATG device. The AIN-PT IPv6 host receives the tunneled traffic and the Tunneler inside will decapsulate the IPv4 packets. The Tunneler on the reception needs to replace the destination IPv4 address of the IPv4 header with the IPv4 address that the IPv4 stack is configured with. These will be passed on to the IPv4 stack. These arrive in the DAC API module, which will synthesize (embedded) IPv6 addresses for the source IPv4 address and the destination IPv4 address. The IPv4 call will be rerouted by DAC to the IPv6 application API, and passed on the application.
When the application replies, this will be received by DAC, and rerouted again toward the IPv4 stack, DAC knowing from the IPv6 prefix of the embedded addresses that this was IPv4 traffic. The Tunneler will receive the IPv4 packets for encapsulation into IPv6 packets. The Tunneler has to configure the source and destination IPv6 addresses of the IPv6 header. It will assign the IPv6 address of the AIN-PT host as the source address. As for the destination address, there is a problem. The Tunneler will get for destination address the IPv4-embedded IPv6 address IPv4-only host represented as {prefix + IPv4 address}. However, since the ATG is not necessarily connected to the same IPv6 network, the IPv6 prefix is in this case not enough to make this destination address route to the ATG.
To solve this problem, the Tunneler module at AIN-PT IPv6 host has to remember the ATG IPv6 address that was present when receiving the tunneling IPv6 packet for which this outgoing packet is a reply in this particular situation. For the Tunneler to distinguish if the ATG is located at the IPv6 side-for which there is no problem-or at the IPv4 side, where the address of the ATG for this IPv4 destination needs to be remembered, a special "type" bit will be used in the synthesized address. [Figure 9] shows the structure of the synthesized IPv6 address. The ATG located at the IPv4 side will set this bit in the synthesized address when sending tunneled traffic to the AN-PT hos, and this bit being set will trigger the Tunneler to cache mapping between the IPv4 address of the IPv4-only host and the ATG IPv6 address. For the reply, the Tunneler has to verify the destination IPv4 address, and if in the cache, get out the ATG's IPv6 address where the tunneled traffic needs to be sent to. Otherwise, if the "type" field was equal to "0," this means the ATG gateway router is installed at the IPv6 network, and the destination IPv6 address can be synthesized by concatenating the Pref64 with the destination IPv4 address and there is no need to cache any addressing information. [Figure 10] shows the pseudo code of how the Tunneler module works.
| 6. AIN-PT Detailed Network Scenarios | | |
The following subsections discuss the behavior of AIN-PT components when they are installed at an IPv6-only network, and at an IPv4-only network.
6.1 Initiating a Connection from AIN-PT IPv6 Host to IPv4 or IPv4-only Host
This scenario depicts an AIN-PT host connected to an IPv6-only network which is trying to communicate with a host located in an IPv4-only network. First, the DNS64 will synthesize an 'AAAA' record for the destination IPv4 host, by concatenating the Pref64 with the destination host IPv4 address, and send it to the AIN-PT host. Thereafter, the Tunneler will encapsulate the IPv4 packet into an IPv4-in-IPv6 packet and send it over an IPv6 network. Then, the IPv4-in-IPv6 packet will be routed to the ATG router. When the IPv4-in-IPv6 packet is received at the ATG router, it copies the source IPv6 address, strips off the IPv6 header, and looks up in the ATG_AP64 mapping table to check if there is a previously mapped entry associated with this communication. If no entries are found, then it will create a new entry by concatenating the source host IPv6 address, destination IPv4 address, source port number, mapped source port number, and destination port number with each other, and record them in the mapping table. Finally, the ATG will replace the Tunneler-assigned private IPv4 source address by its own IPv4 and forward the IPv4 packet over the IPv4 network.
Similarly, when the ATG receives a reply from an IPv4 host and transmitted to an AIN-PT host, it looks it up in the mapping table trying to find addresses related to the current session. After that, the ATG will encapsulate the received IPv4 packet into an IPv4-in-IPv6 packet and forward it over an IPv6 network. The ATG router configures the IPv4-in-IPv6 packets' headers as follows:
- IPv4 header: Source (SRC): IPv4 address for IPv4 host, Destination (DST): Private IPv4 address.
- IPv6 header: SRC: Pref64+IPv4 address for IPv4 host (leave the type field value unchanged "by default = 0"), DST: IPv6 address for the AIN-PT host.
[Figure 11] illustrates the behavior of AIN-PT at the IPv6 network.
6.2. Initiating a Connection from IPv4-only Host to AIN-PT IPv6 Host
This scenario depicts an IPv4-only host which is connected to an IPv4-only network and trying to communicate with a host located in an IPv6 AIN-PT network. In this scenario, the AP46 will synthesize the 'A' records of the destination AIN-PT host by mapping the resolved host's IPv6 address into a mapped IPv4 address of a private network space that corresponds with the IPv6 network destination. When the IPv4-only host receives the resolved IPv4 address, it sends a traditional IPv4 packet to that address. As described earlier, the transmitted IPv4 packet will be delivered at the ATG router (because they use the same CIDR). After that, the ATG router will look up in the mapping table trying to find addresses related to the current session. If no related addresses are found, then it will retrieve the IPv6 address of the destination host by querying AP46 for the destination IPv6 address in terms of a private IPv4 address. The ATG router will record this addressing information (i.e., the IP addresses and the port numbers of the current connection session) in the ATG_AP46 table to be used for subsequent connections. The ATG_AP46 table will be referenced each time a packet is received at the ATG side, but querying the AP46 for the destination IPv6 address is limited to a 'one-time' address resolution only.
After querying the AP46 and receiving the destination IPv6 address, the ATG router will configure both IPv4 and IPv6 headers of the IPv4-in-IPv6 packet as follows:
- IPv6 header: SRC: Pref64+IPv4 address for ATG host (set the type field with value 1), DST: IPv6 address for the AIN-PT host
- IPv4 header: SRC: IPv4 address of the IPv4 host, DST: Private IPv4 address.
Similarly, when the ATG receives a reply from an AIN-PT host transmitted to an IPv4-only host, it firstly looks up in the mapping table (i.e., ATG_AP46) trying to find addresses related to the current session. Then, it retrieves the mapped IPv4 address that relates to the AIN-PT host. Thereafter, the ATG will decapsulate the IPv4-in-IPv6 packet and manipulate the source and destination addresses of the IPv4 header by adding the mapped IPv4 address as the source address and the host IPv4 address (retrieved from ATG_AP46 table) as destination address. Finally, it forwards the IPv4 packet over an IPv4 network. [Figure 12] illustrates the behavior of AIN-PT at IPv4 network.
| 7. Performance Analysis | | |
This section analyzes and compares some of most important performance metrics of the AIN-PT mechanism with other protocol translation-based mechanisms (e.g., BDMS and SIIT). These metrics are end-to-end delay (EED) and Throughput [25],[26] . OMNET++ [27] and INET framework [28] were used as a simulation environment. OMNET++ is a discrete event-driven simulator. INET framework is a package for OMNET++ used to simulate communication networks. It contains models for network protocols (wired and wireless) (e.g., UDP, TCP, IPv4, IPv6, and many others).
The simulation was mainly used to prove the validity and study the performance of the AIN-PT mechanism. The AIN-PT performance was compared with the performance of other protocol translation-based mechanisms (i.e., BDMS and SIIT) in large-scale settings. The SIIT includes the basic protocol translation algorithm that is used by most protocol translation-based mechanisms. In this simulation, we used SIIT mechanism to denote these mechanisms. It is important to note that the simulator was developed to simulate the NAT64 extends SIIT algorithm to translate the IP headers between heterogeneous networks. For simplicity, in this paper, we will call the process of "NAT64 extends SIIT" as SIIT.
As AIN-PT is installed either at IPv4-only networks or IPv6-only networks, the simulator was developed to simulate two different network scenarios. The first is when the AIN-PT mechanism is installed at IPv6-only network and the second is when the AIN-PT mechanism is installed at IPv4-only network.
Synthetic traffic was generated for these scenarios using the ReaSE [29] tool. The ReaSE traffic generator tool has the ability to generate TCP traffic between clients and servers. It also has the ability to configure traffic parameters for a certain traffic flow. For example, it configures packet size, destination server's address, and traffic generation (ON/OFF) in seconds.
In each simulation scenario, the AIN-PT performance was compared with the performance of both BDMS and SIIT mechanisms. To study the influence of these mechanisms on the native communication (IPv4 network communi cates with IPv4 network and IPv6 network com municates with IPv6 network), the performance of the two mechanisms was compared with both native IPv4 and IPv6-based networks, taking into account that the same traffic parameters were used in all the conducted tests. In all tests, the performance of the network was measured as a function of the number of nodes (clients) in the network (100, 300, 500, 1000 nodes) with varying packet sizes (i.e., 64, 256, 512, 1024 bytes). Hence, we can figure out the amount of overhead that was generated while using these translation mechanisms in comparison with native IP networks. Thus, it would be possible to evaluate them based on the generated overhead in the border gateway router. The network infrastructure consists of varying number of nodes (clients) connected through router at the ISP side.
The following subsections analyze the performance of each network scenario.
7.1 End-to-end Delay
The EED was measured and analyzed for all network types (i.e., AIN-PT, SIIT, BDMS, IPv4, and IPv6-based networks) with varying number of nodes and packet sizes. [Figure 13] illustrates the EED values for all network types. It shows four different cases. In each case, the EED was measured at a specified packet size. The horizontal axis indicates the number of nodes (clients) in the network. The vertical axis indicates the packet EED in terms of seconds. The EED NETWORK represents the EED value of all nodes under the specific case. The simulator finds out the EED NODE for each node separately, and then calculates the EED NETWORK as the average of all EED NODE values. The EED NETWORK was calculated as given in Eq. (1) and Eq. (2).
Where,
EED NODE: EED value for a single node
EED NETWORK: EED value for the whole network at a specified packet size
N Rec: Total number of packets received at destination host
T start: Time of packet at source node
T end: Time of packet at destination node
k: Total number of nodes in the local access network.
The processing time factor should be taken into consideration when computing EED [30] . Processing time is the overhead that is generated by the sender and/or receiver at the time of submission and/or reception (including accessing the DNS64 or AP46 tables) adding the overhead that is generated by the ATG or by the translator devices at the border network. In our simulator, we have calculated the processing time by using the "time" command. We have run the simulator in "Cmdenv" mode, which shows the CPU consumed time when the simulator run finished.
7.1.1 Scenario I: Initiating a Connection from an IPv6-only Host to an IPv4-only Host
This scenario evaluates and compares the AIN-PT performance with SIIT, BDMS, IPv4, and IPv6-based networks when an IPv6-only host initiates communication with an IPv4-only host.
Referring to [Figure 13], it is observed that the EED NETWORK values are increased significantly with the increase of packet sizes. Usually, a larger packet size means consuming more time in delivering packets to their destinations, and this will increase the queuing delay of the transmitted packets. The experimental results showed that this factor is considered marginal in comparison with the overhead generated by protocol translation-based or tunneling-based techniques. There are other two factors that affect EED NETWORK values. The first is the number of nodes in the network. Increasing the number of nodes in the network leads to an increase in the probability of collision and contention, which increases the EED NETWORK. The second factor is whether the border router is a protocol-based translator or a protocol-based Tunneler.
[Figure 13] compares the values of the BDMS mechanism with other mechanisms while increasing the transmitted packet sizes from 64 to 1 024 bytes. The BDMS mecha nism has the maximum values of all translation mechanisms. We can clarify this by the overhead generated by the BDMS translator when accessing either DNS4 or DNS6 at every received packet, and when translating the IP headers (i.e., from IPv4 to IPv6 and vice versa). These combined factors mean that the BDMS consumes the maximum time of all mechanisms. The SIIT overhead was generated by translating the IP headers accessing the mapping table. However, the AIN-PT overhead was generated by encapsulating and decapsulating packets. [Figure 13] shows that the AIN-PT achieves the lowest EED NETWORK among all translation mechanisms, especially when larger packet sizes are used (above 64 bytes). [Figure 13] also illustrates that increasing packet sizes in AIN-PT, SIIT, and BDMS mechanisms leads to decreased EED NETWORK values, which results in better overall performance. It is important to highlight here that increasing the packet sizes will result in a decrease in the number of transmitted packets required to transfer the same traffic on the network. Thus, this leads to the decrease of the overhead generated by encapsulation/decapsulation/translation and/or accessing mapping tables. This clarifies why the gap between BDMS and other mechanisms was reduced from 3.85 (ms) in [Figure 13]a to 1.76 (ms) in [Figure 13]d when assuming the number of nodes in the network = 1000.
7.1.2 Scenario II: Initiating a Connection from an IPv4-Only Host to an IPv6-only Host
This scenario evaluates and compares the AIN-PT performance with the BDMS performance when an IPv4-only host initiates a communication with an IPv6-only host. It is important to highlight that the "NAT64 extends SIIT" was excluded here because NAT64 cannot be used when connections are initiated from IPv4-hosts to IPv6-only hosts [15] . The BDMS was built on both protocol and address translation. On the other hand, AIN-PT was built on address translation and IPv4-in-IPv6 tunneling. [Figure 14] depicts the performance of both techniques with varying number of nodes and packet sizes. In both mechanisms, using larger packet sizes results in extra overhead, and hence longer delay. However, the EED values for AIN-PT were always lower than BDMS EED values. The variance between them was small when the number of nodes in the network was under 300, but it was increased significantly when the number of nodes in the network was above 300. The reasons behind this significant increase in variance are as follows:
- Based on the conducted tests, we conclude that the amount of overhead generated in encapsulation/decapsulation is smaller than the amount of overhead generated in translation of the IP headers
- In AIN-PT, the ATG maintains local connection state tables (e.g., ATG_AP64 and ATG_AP46) (local access). However, in BDMS, the translator and the DNS46 are located in the Internet. Therefore, the response time in AIN-PT is smaller than the response time in BDMS.
In computing the percentage difference of the EED values between [Figure 14]a and [Figure 12]d for both mechanisms when number of nodes = 1000, the percentage difference of EED values in AIN-PT: (13.8501-13.1784)/13.1784100% = 5.1%, whereas the percentage difference of EED values in BDMS: (15.63214-14.37124)/14.37124100% = 8.77%. We notice here that AIN-PT has a lower percentage increase in EED values in comparison with BDMS for the same reasons listed above. [Table 2] lists EED values of the BDMS with the mean of AIN-PT EED. The mean of AIN-PT EED was calculated as (AIN-PT EED IPv6→IPv4 + AIN-PT EED IPv4→IPv6)/2.
7.2 Throughput
Throughput is the amount of actual data that are transmitted over a communication path per unit of time.
In this simulation, the Throughput was measured for all kinds of AIN-PT, SIIT IPv6 to IPv4 , and BDMS-based networks. Moreover, the Throughput was measured when AIN-PT was installed at both IPv6-only and IPv4-only networks. In each simulation case, the simulator was configured by the number of transmitting nodes in the network (i.e., 100, 300, 500, 1000 nodes), and packet size (64, 256, 512, 1 024 bytes). The time used to simulate each case was 100 seconds. For the sake of accuracy and reliability, the Throughput was calculated 30 times for each node individually. The reported value of Throughput for each node (THROUGHPUT NODE ) is the average of the reported values at a certain packet size. The average network throughput (THROUGHPUT NETWORK ) was measured as the average of all THROUGHPUT NODE values. It was calculated as in Eq. (3) and Eq. (4).
Where,
THROUGHPUT NODE: Throughput value for a specific node
THROUGHPUT NETWORK: Throughput value for the whole network at a specified packet size.
N Rev: Number of packets received at destination point.
P size: Packet size in bytes
T end: Time at destination host (seconds)
T start : Time at source host (seconds)
k: Total number of nodes in the local access network
The simulator tested the behavior of average Throughput for TCP stream traffic generated between clients and servers. The Throughput values were studied and evaluated with various packet sizes and various numbers of transmitting nodes. In [Figure 15], the AIN-PT IPv6 to IPv4 denotes that the AIN-PT is installed at the IPv6-only network, and the TCP traffic stream was initiated from IPv6 to IPv4 zones. Similarly, the AIN-PT IPv4 to IPv6 denotes that the AIN-PT is installed at the IPv4-only network, and the TCP traffic stream was initiated from IPv4 to IPv6 zone. [Figure 15] shows the average Throughput as a function of number of transmitting nodes in the network. Both AIN-PT IPv6 to IPv4 and SIIT IPv6 to IPv4 achieved better average Throughput in comparison with other mechanisms, and their Throughput values were nearly equal at all packet sizes. The BDMS, on the other hand, showed the lowest average Throughput of all mechanisms. Traditionally, when the number of transmitting nodes in the network increased, the average Throughput decreased (inverse proportion). Increasing the number of transmitting nodes in the network leads to an increase in the probability of contention, collision, and delay. In most tunneling and translation-based mechanisms, the border routers perform more work than other traditional routers by translating, encapsulating, or decapsulating the received packets.
With respect to the BDMS mechanism, the border router consumed additional overhead in accessing the mapping tables. For example, the average Throughput was reduced by 67.75% for AIN-PT IPv6 to IPv4 and was reduced by 86.34% for SIIT IPv6 to IPv4 when the number of nodes was increased from 100 to 1000 with packet size = 64 bytes [Figure 15]a. Besides, it was reduced by 22.72% for AIN-PT IPv6 to IPv4 and 23.26% when the number of nodes was increased from 100 to 1000 with packet size = 1024 bytes [Figure 15]d. In both AIN-PT IPv4 to IPv6 and BDMS mechanisms, the average throughput was reduced by 86.43% for AIN-PT IPv4 to IPv6 and was reduced by 95.53% for BDMS when the number of nodes was increased from 100 to 1000 with packet size = 64 bytes [Figure 15]a. It was reduced by 23.86% for AIN-PT IPv4 to IPv6 and was reduced by 30.81% for BDMS when the number of nodes was increased from 100 to 1000 with packet size = 1 024 bytes [Figure 15]d. We explain this significant variance in Throughput values between BDMS, AIN-PT, and SIIT IPv6 to IPv4 mechanisms by the overhead generated by increasing the number of transmitting nodes with small packet sizes. The AIN-PT IPv4 to IPv6 mapping table is larger than the AIN-PT IPv6 to IPv4 mapping table and the ATG has to request the AP46 for the destination IPv6 address. Additionally, the Tunneler in AIN-PT host has to cache the addressing information in AIN-PT IPv4 to IPv6 scenario. All these things make AIN-PT IPv4 to IPv6 consumed a slightly higher overhead than AIN-PT IPv6 to IPv4 .
Whatever the packet size, the border router in the BDMS mechanism has to access the mapping tables at every received packet. Furthermore, it has to translate every received packet. Thus, larger packet sizes allow transmission of the same payload with a fewer number of packets, which leads to the minimizing of the overhead and finally improves the overall Throughput in these mechanisms.
| 8. Conclusions | | |
The paper introduced a new mechanism to allow communication between heterogeneous networks without translating the full IP headers of the transmitted packets. It uses IPv4-in-IPv6 tunneling technique to carry IPv4 traffic (data and control information) over an IPv6 infrastructure. The mechanism can be used in the early stages of transition to IPv6 by installing it at IPv6-only networks, to allow IPv6 hosts to initiate communication with the large installed base of IPv4-only hosts. Moreover, it can be used in the later stages of the transition to IPv6 by installing it at the IPv4-only networks to allow IPv4-only hosts to initiate communication with the growing number of IPv6 hosts.
The performance analysis of the proposed mechanism showed that the performance parameters of AIN-PT are nearly equal to other protocol translation-based mechanisms (e.g., SIIT) when considering the communication initiated from IPv6 to IPv4 zones. Furthermore, the performance parameters of AIN-PT are better than other stateful protocol translation-based mechanisms (i.e., BDMS) when considering the communication initiated from IPv4 to IPv6 zones. Unlike IP-based networks, the simulation results showed that increasing the packet sizes in protocol translation or tunneling-based techniques leads to a decrease in the processing overhead, and hence, improves the Throughout and decreases the amount of EED values in these networks. Referring to the simulation results, we can conclude that tunneling-based techniques produce a lower processing overhead than other protocol translation-based techniques.
| 9. Acknowledgement | | |
This work was funded by European Union, Erasmus Mundus External Cooperation Window (EMECW) programme under project number 141085-EM-1-2008-BE-ERAMUNDUS-ECW-L02, Belgium.
The authors would like to thank the anonymous reviewers and the editors for their time and valuable comments and suggestions to improve the quality of this paper.
NOTE: *Actually, it would be better to use an address that can never be used in any public or private network. The authors proposed to reserve one of the last remaining IPv4 address ranges for sole use in mapping between IPv4 and IPv6 addresses, but this was declined by IETF/IANA.
| References | | |
| 1. | J.F. Kurose, and K.W. Ross, "Computer Networking a Top-Down Approach", 5 th ed, Boston: Addison-Wesley, 2010. 
|
| 2. | A. Hamarsheh, M. Goossens, and R. Alasem, "Decoupling Application IPv4/IPv6 Operation from the Underlying IPv4/IPv6 Communication (DAC)", American Journal of Scientific Research, London, England: Eurojournals Press, pp. 101-21, Issue 14, 2011.
|
| 3. | N. Oliver, and V. Oliver; "Computer Networks Principle, Technologies and Protocols for Network Design", Hoboken, New Jersey; John Wiley and Sons; 2006.
|
| 4. | X. Li, C. Bao, and F. Baker, "IP/ICMP Translation Algorithm", Internet Engineering Task Force RFC 6145, 2011.
|
| 5. | G. Tsirtsis, and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", Internet Engineering Task Force RFC 2766, 2000.
|
| 6. | M. Raste, and D.B. Kulkarni, "Design and implementation scheme for deploying IPv4 over IPv6 tunnel", Journal of Network and Computer Applications, Vol. 31, Issue 1, pp. 66-72, 2008.
|
| 7. | S. Subramanian, "IPv6 Transition strategies", White Paper, 2003. Available from: http://www.usipv6.com/6sense/2004/oct/ipv6_transition_strategies.pdf [Last cited on 2011 Sep 1].
|
| 8. | D. Karrenberg, "DNSSEC: Securing the global infrastructure of the Internet", Network Security, Vol. 2010, Issue 6, pp. 4-6, 2010.
|
| 9. | F. Baker, X. Li, C. Bao, and K. Yin, "Framework for IPv4/IPv6 Translation", Internet Engineering Task Force RFC 6144, 2011.
|
| 10. | S. Lee, M.K. Shin, Y.J Kim, E. Nordmark, and A. Durand, "Dual stack Hosts Using "Bump-in-the-API" (BIA)", Internet Engineering Task Force RFC 3338, Oct. 2002.
|
| 11. | K. Tsuchiya, H. Higuchi, and Y. Atarashi, "Dual Stack Hosts using the "Bump-In-the-Stack" Technique (BIS)", Internet Engineering Task Force RFC 2767, Feb. 2000.
|
| 12. | B. Huang, H. Deng, and T. Savolainen, "Dual Stack Hosts Using "Bump-in-the-Host" (BIH)", Internet Engineering Task Force Draft (work in progress), 2011.
|
| 13. | J. Bi, J. Wu, and X. Leng, "IPv4/IPv6 Transition Technologies and Univer6 Architecture", IJCSNS International Journal of Computer Science and Network Security, Vol. 7, No.1, pp. 232-43, 2007.
|
| 14. | M.E. Fiuczynski, V.K. Lam, and B.N. Bershad, "The design and implementation of an IPv6/IPv4 network address and protocol translator", Proceedings of the annual conference on USENIX Annual Technical Conference, USENIX Association Berkeley, CA-USA, 1998.
|
| 15. | M. Bagnulo, P. Matthews, and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Internet Engineering Task Force RFC 6146, 2011.
|
| 16. | R. AlJa'afreh, J. Mellor, M. Kamala, and B. Kasasbeh, "Bi-Directional Mapping System as a New IPv4/IPv6 Translation Mechanism", Tenth International Conference on Computer Modeling and Simulation, 2008.
|
| 17. | M. Bagnulo, A. Sullivan, P. Matthews, and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", Internet Engineering Task Force RFC 6147, 2011.
|
| 18. | W. Townsley, and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6 rd ) - Protocol Specification", Internet Engineering Task Force RFC 5969, 2010.
|
| 19. | M. Boucadair, C. Jacquenet, JL. Grimault, M. Kassi-Lahlou, P. Levis, D. Cheng, et al., "Deploying Dual-Stack Lite in IPv6 Network", Internet Engineering Task Force Draft (work in progress), 2010.
|
| 20. | A. Hamarsheh, M. Goossens, and R. Alasem, "Configuring Hosts to Auto-detect (IPv6, IPv6-in-IPv4, or IPv4) Network Connectivity", KSII Transactions on Internet and Information Systems, Vol. 5, no. 7, pp. 1230-51, 2011.
|
| 21. | A. Conta, and S. Deering, "Generic Packet Tunneling in IPv6 Specification", Internet Engineering Task Force RFC 2473, 1998.
|
| 22. | X. Li, and C. Bao, "DNS46 for the IPv4/IPv6 Stateless Translator", Internet Engineering Task Force Draft (work in progress)), 2010.
|
| 23. | C. Bao, C. Huitema, M. Bagnulo M., M. Boucadair, and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", Internet Engineering Task Force RFC 6052, 2010.
|
| 24. | V. Fuller, and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", Internet Engineering Task Force RFC 4632, 2006.
|
| 25. | R.K. Dehury, "An analysis of QoS Traffic Engineer using CR-LDP Protocol over MPLS Networks", A Research study RSPR No. TC-01-5, Telecommunication Program, School of Advanced Technologies, Asian Institute of Technology, 2001.
|
| 26. | I. Raicu, and S. Zeadally, "Evaluating IPv4 to IPv6 transition mechanisms", IEEE International Conference on telecommunications, 2003.
|
| 27. | "OMNeT++ Network Simulation Framework". Available from: http://www.omnetpp.org. [Last cited on 2011 Sep 01].
|
| 28. | "INET Framework". Available from: http://inet.omnetpp.org/. [Last cited on 2011 Sep 01].
|
| 29. | T. Gamer, and M. Scharf, "Realistic simulation environments for IP-based networks", Proc. of the 1 st International Conference on Simulation Tools and Techniques for Communications, Networks and Systems and Workshops, SIMUTools 2008, pp. 83-9, 2008.
|
| 30. | E. Gamess, and R. Suro´s, "An upper bound model for TCP and UDP throughput in IPv4 and IPv6", Journal of Network and Computer Applications, Issue 31, pp. 585-602, 2008.
|
| Authors | | |
Ala Hamarsheh is a PhD candidate at the faculty of Engineering, Vrije Universiteit Brussel - Belgium. He has been awarded a full scholarship from Erasmus Mundus ECW II project. Prior this, Hamarsheh was working as a full-time lecturer at the Arab American University - Jenin, Palestine. He obtained a BSc of Computer Science at the faculty of Science, Birzeit University - Palestine in 2000. He obtained an MSc in Computer Science at the Kind Abdullah II School for IT, The University of Jordan in 2003 - Jordan. He has published numerous papers in international refereed journals and conferences. His PhD research focuses on proposing mechanisms to break the deadlocks for transitions to IPv6.
Marnix Goossens graduated in electrical and mechanical engineering (Masters) in 1978, and obtained a PhD in engineering in 1985, both at the Vrije Universiteit Brussel, Belgium. He became full-time Professor - teaching and research - at the same University afterwards, and heads since a research group working on digital telecommunications, especially "protocol engineering." The research team has much collaboration with industry, and has a tradition in research on practical-oriented communication problems.
Ahmad Al-Qerem graduated in applied mathematics and MSc in Computer Science at the Jordan University of Science and Technology in 1997 and 2002, respectively. After that, he was appointed as full-time lecturer at the Zarqa University and also a part-time lecturer at the Arab Open University. He has also held a post in the Ministry of Labor. He obtained a PhD from Loughborough University, UK. His research interests are in performance and analytical modeling, mobile computing environments, protocol engineering, communication networks, transition to IPv6, and transaction processing. He has published several papers in various areas of computer science. Currently, he has a full academic post as associate professor and the head of the Department of Internet Technology at Zarqa University - Jordan.
[Figure 1], [Figure 2], [Figure 3], [Figure 4], [Figure 5], [Figure 6], [Figure 7], [Figure 8], [Figure 9], [Figure 10], [Figure 11], [Figure 12], [Figure 13], [Figure 14], [Figure 15]
[Table 1], [Table 2]
|
|
|
|
[PR EV] |
|
|
