Scholarly article on topic 'ISP Independent Architecture (IIA) for IPv6 Packet Traversing and Inter-connectivity over Hybrid (IPv4/IPv6) Internet'

ISP Independent Architecture (IIA) for IPv6 Packet Traversing and Inter-connectivity over Hybrid (IPv4/IPv6) Internet Academic research paper on "Computer and information sciences"

CC BY-NC-ND
0
0
Share paper
Academic journal
Procedia Computer Science
OECD Field of science
Keywords
{Tunneling / Translation / "Dual Stack" / "Hybrid Network" / IPv4 / IPv6}

Abstract of research paper on Computer and information sciences, author of scientific article — Tariq Saraj, Muhammad Yousaf, Sajjad Akbar, Amir Qayyum, Mudassir Tufail

Abstract Tunneling and translation are the two popular transition mechanisms for hybrid (IPv4/IPv6) network. ISPs configure both mechanisms to provide interconnectivity in hybrid (IPv4/IPv6) environment. This research document provides an ISP independent architecture to provide interconnectivity in hybrid network by deploying tunneling and translation mechanism through a decision entity. For the demonstration, NAT64/DNS64 (translation) and Tunnel broker service (Hurricane electric with 6in4 tunneling) are used. This architecture enables a user to deploy their required tunneling and translation mechanism under the umbrella of a decision entity which identifies the packet requirement.

Academic research paper on topic "ISP Independent Architecture (IIA) for IPv6 Packet Traversing and Inter-connectivity over Hybrid (IPv4/IPv6) Internet"

CrossMark

Available online at www.sciencedirect.com

ScienceDirect

Procedia Computer Science 32 (2014) 973 - 978

The 4th International Symposium on Frontiers in Ambient and Mobile Systems (FAMS-2014)

ISP Independent Architecture (IIA) for IPv6 Packet traversing and Inter-Connectivity over hybrid (IPv4/IPv6) Internet

Tariq Saraja*, Muhammad Yousafb, Sajjad Akbarc, Amir Qayyumd, Mudassir Tufaile

abRiphah Institute of Systems Engineering (RISE), Riphah International University, Islamabad, Pakistan c'dCenter of Research in Networks and Telecom (CoReNeT), Muhammad Ali Jinnah University, Islamabad, Pakistan

e Sr Distinguished Engineer Citigroup, USA

Abstract

Tunneling and translation are the two popular transition mechanisms for hybrid (IPv4/IPv6) network. ISPs configure both mechanisms to provide interconnectivity in hybrid (IPv4/IPv6) environment. This research document provides an ISP independent architecture to provide interconnectivity in hybrid network by deploying tunneling and translation mechanism through a decision entity. For the demonstration, NAT64/DNS64 (translation) and Tunnel broker service (Hurricane electric with 6in4 tunneling) are used. This architecture enables a user to deploy their required tunneling and translation mechanism under the umbrella of a decision entity which identifies the packet requirement.

© 2014 Published by ElsevierB.V.Thisisan open access article under the CC BY-NC-ND license

(http://creativecommons.Org/licenses/by-nc-nd/3.0/).

Selection and Peer-review under responsibility of the Program Chairs.

Keywords: Tunneling, Translation, Dual Stack, Hybrid Network, IPv4, IPv6

1. Introduction

The Internet service providers (ISPs), organizations and home users are now gradually shifting from IPv4 to IPv6. The core reason for this shift is the IPv4 address space exhaustion. The use of NAT temporarily solved this issue but now its again a serious concern. The transition phase from IPv4 to IPv6 will not occur over nights, it will take long

* Corresponding author. Tel.: +0-000-000-0000 ; fax: +0-000-000-0000 . E-mail address:tariqsaraj@gmaiLcom

1877-0509 © 2014 Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license

(http://creativecommons.Org/licenses/by-nc-nd/3.0/).

Selection and Peer-review under responsibility of the Program Chairs.

doi: 10.1016/j.procs.2014.05.520

time and during this both the protocols IPv4 and IPv6 will co-exist in the Internet that refers as a hybrid IPv4/IPv6 Internet.

TransitionTools - Deployment

The two serious issues of hybrid networks are inter-connectivity and Packet traversing. The two working groups of IETF, "Behave[1]" and "Softwire[2] " are working on the development and standardization of inter-connectivity and packet traversing solutions respectively. These issues can be solved by administratively deploying transition techniques i.e. Dual Stack, Tunneling and Translation. In the late 1990's, the IPv6 protocol stack support in many operating systems provided on experimental basis[3]. Now these days almost every operating system has support for IPv6 protocol stack. Figure.1 [4] shows Transition tools deployment timeline. The Figure. 1 indicates different transition mechanisms over time. It is observed that most of the tunneling techniques use 6to4 encapsulation mechanism; moreover, the translation mechanisms use the approach of address mapping. NAT64/DNS64 is the most usable mechanism used for translation. Hybrid network requires a combination of tunneling and translation mechanism for the interconnectivity. ISPs use the combination of transition technique for the deployment. Our architecture IIA aims to make an ISP independent deployment on the user end. It is useful where a user desires to use a specific combination of transition mechanism to achieve required features. For the demonstration, NAT64/DNS64 (translation) and Tunnel broker service (6in4 tunneling) are used. Here, the challenge is to correctly identify requirement of the packet i.e. either tunneling or translation. We have proposed a decision entity that will decide either the packet need tunneling or translation.

In the section 2, the discussion is done for the transition techniques. Section 3 elaborates the problem identification with example. Section 4 explains the proposed solution with the flow chart and the pseudo code of the proposed algorithm. Section 5 concludes the research contribution.

2. Transitioning Techniques

The IPv6 transition mechanisms provides the facility to overcome the incompatibility issues by successfully making interoperability between IPv4 and IPv6 networks and hosts.

2.1 Dual Stack

Dual Stack is a technique for providing complete support for both Internet protocol stacks i.e. IPv4 and IPv6 in a node[5]. Two types of devices are operating in the current Internet. One with IPv4 only protocol support and the other one with both IPv4 and IPv6 protocols support called dual stack devices. The IPv4 nodes can only communicate with IPv4 only nodes or with a dual stack node if the IPv4 protocol stack is enabled on it. If all the devices in the current Internet upgraded to dual stack, instead of solving the inter-connectivity problem the dual stack mechanism will result two parallel networks in the Internet.

2.2 Tunneling

Tunneling is used for successful packet traversing from source Network(s)/Host(s) to destination Network(s)/Host(s). Currently tunnels are used to connect two IPv6 network that are not directly connected to each

other but there is an IPv4 network between them which acts as an intermediate network to transport IPv6 packet from one network to the other. Figure.2 depicts a generic hybrid-network.

■ The core process in tunneling technique(s) is to: Encapsulate an IPvX packet into an IPvY packet delivered from IPvX host(s)/Network(s)

■ Traverse the encapsulated packet over IPvY network

■ Decapsulate the IPvY packet and extract IPvX packet before forwarding it to IPvX host(s)/network(s) This process may be performed once or repeatedly until the packet reaches to its destination host(s)/network(s).

Fig. 2. Tunnelling mechanism

2.3 Translation

Translation mechanisms support transition process by translating an IPv6 header to IPv4 header. Hence, an IPv6 only node can communicate with IPv4 only node. Although, some information of IPv6 header can be lost but interconnectivity is achieved.

3. Problem identification with literature survey

Under the IETF working group "Softwire", a number of tunneling protocols such as 6to4[6], 6rd[7], 6over4[8], ISATAP[9] , Teredo [10] are standardized that can be used to achieve packet traversing over hybrid network. In Table. 1 a generic hybrid network scenario is shown that is further elaborated to specific network scenarios.

Table 1. Generic and Specific Network Scenarios

Generic Network Scenario Specific Network Scenario

IPvX-IPvY-IPvX a. IPv6 LAN -> IPv4 Internet b. IPv6 LAN -> IPv4 Internet -> IPv6 Server -> IPv4 Server

The aim of a tunneling technique is to provide packet traversing of an IPv6 packet from one isolated IPv6 network to another isolated IPv6 network over an IPv4 Internet.

Consider a tunneling technique 6to4 and the generic network scenario in Table.1. By mapping the generic network scenario to the specific network scenario (scenario a), through the 6to4 tunneling protocol communication between the two end hosts in isolated IPv6 networks will successfully be made. The network scenario (scenario b) is also a hybrid network but tunneling will failed to provide communication between the two end hosts. The reason is now along with the "Packet Traversing" the "Inter-connectivity" is also required. This can be achieve through an administratively deployed Translation technique.

Under the IETF working group "behave" a number of translation techniques such as NAT64[11], DNS64[12], Bump-in-the-Stack[13], Bump-in-the-API[14], Bump-in-the-Host[15] are standardized. Translation is the conversion of one type of protocol IPvX to another type of protocol IPvY before leaving or entering to an incompatible network. In other words translation is a one-to-one mapping of fields between the two protocols headers. Dual stack techniques do not, by themselves, solve the IPv4 and IPv6 inter-connectivity problem, due to the incompatibility between the two protocols. Translation is required to make the IPv6 header compatible with the IPv4. Consider a Translation technique NAT64 along with DNS64 and the generic network scenario in Table. 1. By mapping the generic network scenario to the specific network scenario (scenario b). The Inter-connectivity between the two end hosts can be achieved when translation is deployed, but if we want to achieve Inter-connectivity for specific network scenario (scenario a) the translation will failed to provide that.

This shows that in one single network to overcome these issues both the techniques (i-e Translation and Tunneling) are need to be deployed. Further, we get these services from ISP's. Our ISP's routers decide about the

packet need that either it require a tunneling mechanism or the translation mechanism. Although, these solutions work well but they are ISP dependent. For an isolated user on IPv6, where ISP is not providing required tunneling and translation mechanisms, IPv6 user could not communicate on the IPv4 link as well as with the IPv4 only node. For this problem, we have proposed an ISP independent solution, which will use the available tunneling and translation mechanisms. Moreover, to make this solution fully automated, a decision entity is added in the network which will decide either packet need the tunneling or the translation. We have discussed issues and proposed solution in the section 4.

4. Proposed Architecture

Considering a typical host configuration on a windows OS within an IPv6 or IPv4 LAN as shown in Table.2. To provide Internet access to a host, the host must be configured with a default gateway. Table 2. Host Configurations

Internet Protocol Version 4 (TCP/I PV4) Properties b Internet Protocol Version 6 (TCP/I PV6) Properties

IP address; 10.0.1.2 IPv6 address: 2000:dead:0:l::2

Subnet mask: 255.0.0.0 Subnet prefix length: 64

Default gateway: 10.0.1.1 Default gateway: 2000:dead:0:l::l

| Use the following DNS server addresses: Use thefollowing DNS server addresses:

Preferred DNS server: 10.0.1.1 Preferred DNS server: 2000:dead:0:l::l

Alternate DNS server: Alternate DNS server:

A host can be configured with only one default gateway on a single interface say Ethernet interface. There is no secondary option for that. Due to this restriction, Figure.3 shows that even by deploying both the Transition

Fig. 3. LAN with both Translation and tunnelling deployment The IPv6_Host_A can communicate with IPv4_Server in the Internet, but it cannot communicate with the IPv6_Server in the Internet because the default-gateway for IPv6_Host_A is the NAT64 machine IPv6 Interface address. Similarly the IPv6_Host_B can communicate with the IPv6_Server in the Internet, but it cannot communicate with the IPv4_Server in the Internet because the default-gateway for IPv6_Host_B is the Router LAN side IPv6 interface address. By changing statically the default-gateway address of IPv6_Host_A similar to the IPv6_Host_B now it can communicate with the IPv6_Server in the Internet.

Table 3 IPv6 Hosts configuration summary

IPv6 Host IPv6 Address Default Gateway Global destination

A 2000:dead:01 ::3/64 2000:dead:01::2/64 IPv4 Server

B 2000:dead:01 : :4/64 2000:dead:01::1/64 IPv6 Server

The question is that for how long a user or administrator will doing all these configurations for this purpose even if there are only two Web servers in the Internet. This is quite annoying for a user/administrator. Table.3 shows a summary of configuration of both the IPv6_Hosts.

In Figure. 4 we have shown our proposed architecture by introducing a "Decision Entity" in LAN that will decide that which network path the traffic will follow for a session. The configuration summary for the IPv6 End-Hosts is

as in Table.4, with just one default-gateway configuration. Any host within the LAN can communicate with either of the two servers (i-e, IPv4 server or IPv6 server). The "Decision Entity" has multiple interfaces installed on it. A connection request for an IPv6 server will follow the interface connected directly (DIRECT_IF) to the Router, while a connection request for an IPv4 server will follow the interface connected indirectly (IDIRECT_IF) to the Router via Translation server (i.e. NAT64 & DNS64 Server).

Fig 4. Proposed Architecture (IIA) The Pseudo code for the proposed architecture is in two parts. The first one is how the DNS request is handled and the second part shows the normal traffic shaping as shown in Table.5 the pseudo code for the decision entity is presented in two parts.

Table 4. IPv6 Hosts configuration summary

IPv6 Host

IPv6 Address

Default Gateway

Global destination

2000:dead:01::7/64 2000:dead:01::5/64 IPv6 Server

IPv4 Server

2000:dead:01::6/64 2000:dead:01::5/64 IPv6 Server

IPv4 Server

The Figure. 5 represents a flow chart for the proposed solution. The flow chart depicts the complete flow of the proposed solution. The first part of the Pseudo code explains how the DNS query will be processed when a IPv6_Host_x initiates a session with a server on Internet. The IPv6_Host_x will first request for an "AAAA" record. When the DE (Decision Entity) receives the request packet on its LAN interface, it will forward it on its both WAN interfaces. The reason for forwarding this request on both interfaces is quite obvious. If there is no "AAAA" record exists for a server located in Internet it will then need to contact with the DNS64 for a translated "AAAA" record. This will lead to lots of implementation complexities in DE so for simplicity and an early connection establishment, the DE will forward the DNS "AAAA" record query on both of its WAN interfaces. In response the DE will receive possibly "AAAA" but it MUST receive an "Translated AAAA" record in any case which it will forward to the source IPv6_Host_x.

Table 5.Psuedo code of proposed Architecture

Part-01: DNS query

IPv6Hostx ^ reqAAAArec DErecv ^ DNSreq pkt DEforward DNS DE recv ^ (AAAA, AAAAtranslated )

Part-02: Traffic Shaping

DE recvIPv6pkt ^ LANinterface ifdestaddr ^ has Translatorprefix

forward ^req ^ on (DIRECTJF, IDIRECTJF)

forward

IDIRECT IF

else forwardpkt ^ DIRECTJF

Connects dest

Server

The Host will then establish a connection with the server either on using "AAAA" or "Translated AAAA" record depends upon the protocol stack implementation in the OS. The second part of Pseudo code is about the traffic shaping. Upon arrival of an IPv6 packet on the LAN side interface of the DE, it will simply check for the destination address in the packet header. If the destination address contains a well know translator prefix "i-e 64:FF9b::/96" the

packet will be forwarded on the IDIRECT_IF connected to the translation machine, otherwise the packet will be forwarded on DIRECTIF connected to the ROUTER configured a Tunnel on it.

Fig. 5: Flow chart of proposed solution

5. Conclusion

In this research paper, a new ISP Independent Architecture (IIA) for interconnectivity in hybrid network is presented. This ISP independent solution provides flexibility to the users to deploy their required transition solution. Our implementation uses 6in4/6to4 mechanism for tunneling with support of online tunnel broker by Hurricane Electronics[16] and NAT64/DNS64 translation mechanism by Ecdysis[17]. A decision entity is deployed in the network to provide intelligence regarding the packet traversing. For the implementation the pseudo code is also presented along with the real time testbed setup.

This architecture is suitable in the environment where a network administrator wants to take benefits from the features of new and upcoming tunneling and transitions mechanisms. The dependency of ISP's configured transition mechanism is eliminated. Further, a network administrator can create multiple combinations of transition mechanisms for different destinations to manage security and load balancing. In future, we will expand the algorithm of the decision entity so that it can provide multiple translation and tunneling mechanisms. The algorithm will adopt the network conditions as well. Acknowledgement

This work is done during ICT-Related Development and Research Grant funded Project "Design and Development of Hybrid IPv4 & IPv6 Network for QoS Enabled Video streaming Multicast Application". References

1. IETF. Behave WG charter [Online]. Available: http://datatracker.ietf.org/wg/behave/charter/

2. X. LiSoftwire. Problem Statement. IETF RFC4925, July, 2007.

3. S.-J. Yoon. Performance Comparison of 6to4, 6RD, and ISATAP Tunnelling Methods on Real Testbeds. International Journal, vol. 2.

4. F. Bovy. Transition Technologies [Online]. Available: http://fredbovy.com/WordPress3/about/

5. E. Nordmark and R. Gilligan. Basic transition mechanisms for IPv6 hosts and routers. RFC 4213, 0ctober2005.

6. B. Carpenter and K. Moore. RFC 3056: Connection of IPv6 domains via IPv4 clouds. Chapter 12 The Domain Name System, 2001.

7. W. Townsley and O. Troan. IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)--Protocol Specification. RFC 5969, August2010.

8. B. Carpenter and C. Jung. Transmission of IPv6 over IPv4 domains without explicit tunnels. ed: RFC 2529, March, 1999.

9. F. Templin. Intra-site automatic tunnel addressing protocol (ISATAP). 2008.

10. C. Huitema. Teredo: Tunneling IPv6 over UDP through network address translations (NATs). 2006.

11. M. Bagnulo. RFC 6146: Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers. IETF, Apr, 2011.

12. M. Bagnulo. DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers. Internet Engineering Task Force (IETF) RFC, vol. 6147, 2011.

13. K. Tsuchiya. Dual stack hosts using the" bump-in-the-stack. technique (BIS)," 2000.

14. S. Lee. Dual Stack Hosts Using 'Bump in the API'(BIA). IETF RFC3338. October, 2002.

15. B. Huang. Dual Stack Hosts Using" Bump-In-the-Host"(BIH). RFC 6535, Internet Engineering Task Force2012.

16. Hurricane Electronics Internet Services http://www.he.net.

17. Ecdysis: Available online http://ecdysis.viagenie.ca/download.html.