Transitioning From IPv4 to IPv6

Transitioning From IPv4 to IPv6

The proposed migration from IPv4 to IPv6 is on in some organizations though some organizations have not put in place measures to ensure the transition. The transition has been initiated since IPv6 offers increased addressing capacity, quality of service provisioning as well as improved routing efficiency. However, shifting from the current platform, IPv4 is not easy given the incompatibility of these two internet protocols. In addition, network specialists have created several technologies and address types to help in the proposed migration. Therefore, this paper describes the IPv6 transition technologies and constraints likely to impede the migration from IPv4 to IPv6 platforms.

Introduction

The proposed protocol transition from IPv4 to IPv6 is quite challenging just like other former transitions in the Internet domain. Protocol transitions involve the installation and configuration of new protocols on all existing nodes within the network and ascertaining that all the nodes and router operations work efficiently. For small and medium organizations, this transition is possible but for large firms, the challenge of making a rapid protocol transition is difficult. Moreover, due to the Internet's magnitude, rapid transitioning from IPv4 to IPv6 may prove to be a tall order (Cheswick & Bellovin, 1994). Proponents of IPv6 are aware the transition from the current IPv4 is likely to take several years and some organizations will continue using IPv4 indefinitely; thus, while the shift is a long-term goal, consideration should be given to co-existence between IPv4 and IPv6 nodes. The only hope to successful migration lies on the compatibility of IPv4 hosts and routers with their successors. In line with this, specialists have initiated several methods to ensure compatibility of IPv4 host and routers with IPv6 host and routers. These approaches range from Dual Stack, Tunneling and Translation among others. Dual Stack involves provision of both IP versions by a single host while Tunneling provides ways of carrying IPv6 packets over unmodified IPv4 routers. According to network specialists, these approaches are vital for the transition and may be implemented based on an organization's preferences. This paper therefore gives a detailed explanation of these methods, the constraints, as well as various techniques and standards necessary for the migration; however, they are a sample of tools required for transition and interoperability between IPv4 and IPv6.

Methodology

In this section, three approaches necessary for the transition from IPv4 to IPv6 will be discussed. In this part, the selected approaches are critically evaluated and compared as well as constraints likely to hinder compatibility between IPv4 and IPv6(Bi et al., 2007). Tunneling is a mechanism whereby IPv6 hosts without a path between them consisting entirely of IPv6-capable routers may be able to communicate by encapsulating IPv6 datagrams within IPv4. For Dual Stack, routers and hosts are configured with both IPv4 and IPv6 implementations to allow them communicate with both types of hosts. Finally, Translation involves configuration of Dual Stack routers and hosts to accept requests from IPv6 hosts, convert them to IPv4 datagrams, send the datagrams to the IPv4 destination and then process the return datagrams similarly.

Dual Stack Approach

Dual Stack provides several methods of assigning temporary IPv4 addresses to IPv6 nodes by using dynamic tunnels within IPv6 hosts to carry IPv4 traffic. In this approach, each node is given both IPv4 and IPv6 addresses to help in relaying data with other IPv4 and IPv6 hosts and routers (Park et al., 2004). Additionally, the nodes are able to send and receive both IPv4 and IPv6 packets and besides, they directly interoperate with IPv4 nodes using IPv4 packets, and as well with IPv6 nodes using IPv6 packets. However, the implementation of Dual Stack is possible for a short period for testing IPv6 applications and initial network deployment, but does not give a solution to lack of IPv4 addresses once IPv6 begins production operations.

Additionally, this approach assists in assigning IPv4 addresses to IPv6 hosts thus allowing IPv6 hosts to interconnect with IPv4-only hosts; besides, other IPv4-only applications are able to run without altering IPv6 hosts. This sharing out process is augmented by dynamic tunneling IPv4 packets inside IPv6 packets to restrict exposure of IPv4 native packets in some sections of the IPv6 network. This makes easy network management of IPv6 deployment because routers require only IPv6 routing tables to move IPv4 packets across an IPv6 network. Data Stack is essential in ensuring the interoperability of newly deployed IPv6 networks with existing IPv4 networks; thus, seeks to minimize chances of delaying IPv6 usage once it is set up since IPv6 interfaces will not be compatible with IPv4 hosts for a given period of time.

Despite having the ability to support both IPv4 and IPv6 protocols at any particular time, one of the stacks may be disabled for operational reasons. In this regard, the stacks may be operated in three different ways; with the IPv4 enabled and IPv6 disabled; when IPv6 is enabled and IPv4 disabled and with both stacks enabled. Disabling some protocols does not make the stack lose its functionality since nodes with the IPv6 stack disabled operate like IPv4-only nodes while nodes with the IPv4 stacks disabled work as IPv6-only nodes. This is due to the configuration switch provided by then Dual Stack by either disabling the IPv4 or IPv6 stack.

In addition, Dual Stack has DHCPv6 servers integrated with DNS servers that helps in assigning IPv4 addresses to IPv6 interfaces via the use of AIIH servers. By incorporating the services of the DHCPv6, the AIIH server will temporarily assign allocate IPv4 addresses to IPv6 hosts. Moreover, the server is important in maintaining close mapping between the IPv4 address and the host's permanent IPv6 address. Besides, all the IPv6 host are provided with IPv4 interfaces known as dynamic tunneling interface for compress IPv4 packets into IPv6 packets and resolve the address space mechanics between IPv4 and IPv6.

The DNS will be upgraded since the DNS infrastructure is essential for ensuring compatibility of IPv4 and IPv6 due to the use of names as opposed to addresses when referring to network resources. In this regard, records supporting IPv6 name-to-address and address-to-name resolutions will be fed into the DNS servers (Gallaher & Rowe, 2006). After using DNS name query to obtain addresses, the sending node selects addresses to use for communication. The DNS infrastructure for this transition approach contains A records for IPv4 nodes and AAAA for IPv6 nodes. Furthermore, for resolution of addresses to domain names, the DNS will provide; PTR records in the IN-ADDR.ARPA domain for IPv4 nodes and PTR records in the IP6.ARPA domain for IPv6 nodes.

Nonetheless, Dual Stack incorporates two sub-sections, mandatory and optional parts in its functioning. Under the mandatory section, IPv6 nodes are required to fully communicate with IPv4 nodes while the optional part allows IPv4 nodes to transmit data to IPv6 nodes after assigning IPv6 nodes with temporary IPv4 address whenever IPv4 nodes send packets to IPv6 connections.

Tunneling Approach

The integration of IPv6 will be conducted over a period of time and while the platform is being deployed, network administrators argue that the existing IPv4 system is supposed to remain efficient and functional to help in transmitting IPv6 packets. Therefore, it is proposed that tunneling is likely to offer a way of utilizing present IPv4 hosts infrastructure to relay IPv6 traffic. Tunneling also known as IPv6 over IPv4 tunneling is an approach whereby IPv4 tunnel endpoint addresses are pre-determined by configuration data on the encapsulating nodes. Moreover, the tunnels can be either unidirectional or bidirectional; tunnels configured bi-directionally conduct similar roles just like virtual point-to-point links and for all the tunnels; the encapsulating nodes store the tunnels' endpoint addresses.

Whenever an IPv6 packet is under transmission over a particular tunnel, the tunnel's endpoint address undergoes configuration to make the tunnel usable as the destination address for the IPv4 header. As a concern, within the IPv4 header there are two major processes that take place; the IPv4 protocol field is set as 41 an indication of an encapsulated IPv6 packet while the source and destination fields are set to IPv4 addresses of the tunnel endpoints (Bin et al., 2004). Besides, the tunnel's endpoints are either manually configured as part of the tunnel interface or are automatically derived from the next-hop address of the matching route for the destination and the tunneling interface. In line with this, routing information on the encapsulating node usually determines which packets to tunnel which is done via the use of routing tables; the tables are useful in directing packets to their destination address by the use of prefix masks and match techniques.

In the case of IPv6 over IPv4 tunneling approach, the IPv6 path Maximum Transmission Unit (MTU) for the destination is typically 20 less than the IPv4 path MTU for the destination. However, failure to store IPv4's path MTU for each tunnel results to the fragmentation of the IPv4 packet at an intermediate IPv4 router (Choi et al., 2006). As a result of this, the IPv6 over IPv4 tunneled packet is immediately relayed to the Don't Fragment flag within the IPv4 header set at 0. According to RFC articles, there exist three tunneling configurations used in tunneling IPv6 traffic between IPv6/IPv4 nodes over an IPv4 infrastructure. These include Router-to-Router, Host-to-Router or Router-to-Host and Host-to-Host.

In the first configuration; Router-to-Router tunneling configuration, two IPv6/IPv4 routers are interconnected with two IPv6-capable infrastructures through an IPv4 interface. In this setting, the endpoints within the tunnel form a logical link in the path between the source and destination with the tunnel between the two routers acting as a single hop. In addition, there are routes within each IPv4 and IPv6 interface pointing the IPv6/IPv4 router on the edge and there is a tunnel link depicting the IPv6 over IPv4 tunnel and routes that use the tunnel interface. Some examples of this topology include two IPv6-only routing domains tunneling across the IPv4 Internet as well as 6to4 routers transmitting through the IPv4 Internet to reach other 6to4 routers.

The next design is Host-to-Router and Router-to-Host which are almost identical with slight differences between them. For Host-to-Router tunneling configuration, existing IPv6/IPv4 nodes within IPv4 system are used in creating IPv6 over IPv4 tunnel for reaching IPv6/IPv4 routers. In this setup, the endpoints in the tunnel are the first segment of the path between the source and destination nodes while the tunnel between IPv6/IPv4 nodes and IPv6/IPv4 routers acting as single hops. In addition, for the IPv6/IPv4 node, a tunnel depicting the IPv6 over IPv4 tunnel is initiated while a route is also created using the tunnel interface. Therefore, the IPv6 traffic is tunneled by IPv6/IPv4 nodes based on the matching route, the tunnel interface, and the destination address of the IPv6/IPv4 node (Chen et al., 2004). On the other hand, for Router-to-Host tunneling, IPv6/IPv4 routers establish IPv6 over IPv4 tunnels through IPv4 network to help in relaying traffic to IPv6/IPv4 nodes. Moreover, in this setting, the endpoint of the tunnel spans the last segment of the path between the source and destination. In this setup, a tunnel representing the IPv6 over IPv4 tunnel is formed while a subnet route is created by the use of the tunnel interface. The IPv6/IPv4 router tunnels the IPv6 packet based on the matching subnet route, the tunnel interface, and the destination address of the IPv6/IPv4 node. Common examples of the above tunneling techniques include IPv6/IPv4 hosts tunneling through a firm's IPv4 system to relay traffic to the IPv6 nodes as well as ISATAP routers tunneling across IPv4 network to connect with ISATAP hosts.

The last approach is Host-to-Host tunneling whereby IPv6/IPv4 nodes within IPv4 infrastructures establish IPv6 over IPv4 tunnels to assist in relaying data to other IPv6/IPv4 nodes situated within the same IPv4 infrastructure. As a requirement, for this tunneling, the endpoints traverse the entire path between the source and destination nodes acting as a single hop. In this process, two or more IPv6/IPv4 nodes are able to relay IPv6 packets between themselves without passing via intermediary IPv6 routers. Some illustrations of this model include IPv6/IPv4 hosts using ISATAP addresses to tunnel through an IPv4 infrastructure. The other example is IPv6/IPv4 hosts using IPv4-compatible addresses to transmit via IPv4 platforms.

However, according to RFC 4213, there are two types of tunneling techniques configured and automatic. For configured tunnel, there is need to manually configure the tunnels' endpoints. In this technique, IPv4 addresses at the tunnel endpoints are not established from encoded addresses in the next-hop address whenever traffic is under transmission (Nordmark & Gilligan, 2005). Moreover, configured tunneling can be used for the above configurations but, it is commonly used in Router-to-Router channels based on the need to explicitly configure the tunneling endpoints. As a concern, Router-to-Router tunneling is easily configured manually which requires that IPv4 addresses in the tunnel endpoints be manually specified end-to-end with static routes used by tunnel interfaces. On the other hand, for automatic tunnel there is no need for manually configuring the system.in this process, tunnel endpoints are determined by using routes, next-hop addresses based on destination IPv6 addresses, and logical tunnel interfaces. Nonetheless, prior to using configured tunnels, there is need for the creation of a relationship between the two IPv6 platforms.

Translation

As opposed to the aforementioned approaches, translation aims at converting IPv6 to IPv4 traffic and vice versa but, it does not allow for data encapsulation (Zhongcheng et al., 2004). Just like tunneling, translation incorporates two procedures Network Address Translation-Protocol Translation (NAT-PT) and NAT64. NAT-PT enables users to easily configure translations of IPv4 network addresses into IPv6 network addresses and vice versa. Besides, NAT-PT has traits of Application Layer Gateways which help in converting DNS mappings between protocols. On the contrary, NAT64 assists in keeping track of bindings and enables 1-to-N functionality as well.

Discussion

Prior to the proposed transition, there are several issues that should be met to ensure smooth transition and interoperability of IPv4 and IPv6 and besides, there are possible constraints faced during the transition process.

The first initiative taken is upgrading the applications to be independent of IPv6 or IPv4. Due to the imminent transition, all the existing applications should be changed to use new Windows Sockets application programming interfaces so that name resolution, socket creation, and other functions are independent of whether IPv4 or IPv6 is being used (Jayanthi & Rabara, 2010). In line with this, the DNS structure is updated to support IPv6 address and PTR records. This will ensure the DNS infrastructure is capable of supporting the new AAAA and PTR records in the IP6.ARPA reverse domain. In addition, the DNS server should ensure that the IPv6 hosts automatically register their names and IPv6 addresses.

The next initiative to ensure operability of the two systems is upgrading the hosts to IPv6/IPv4 nodes. Due to the unveiling of the new platform, the hosts are supposed to be upgraded to use either dual IP layer or dual IP stack. Furthermore, DNS resolver support is also established to help in processing DNS query results containing both IPv4 and IPv6 addresses. As a concern, ISATAP will be deployed to ensure IPv6/IPv4 hosts communicate with each other over the IPv4-only infrastructure. And besides, the routers will undergo updating to make them able to support native IPv6 routing and IPv6 routing protocols.