IPv6 transition technologies and constraints for IPv4 migration

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.

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.

The final issue is the conversion of IPv6/IPv4 nodes to IPv6-only nodes and is expected to take a long time before all the current IPv4-only devices are fully upgraded to IPv6-only. However for IPv4-only nodes that are impossible to upgrade, the use of translation gateways will be upheld to make IPv4-only nodes relay traffic to IPv6-only nodes.

Conclusions

The transition from IPv4 to IPv6 has been slow and given the nature of the migration, it will take a long period of time before the transition is successful. The approaches discussed in this document are valuable options that can be used when deploying IPv6 and for organizations planning the transition from IPv4, they should look at the applicability of each approach based on their specific requirements. In addition, the migration encompasses the upgrading of existing applications, hosts, routers, and DNS to support IPv6. Besides, due to the fact that the transition will take a long time, both IPv4 and IPv6 nodes should be able to coexist over IPv4 infrastructures such as the Internet. Therefore, to ensure successful transition to IPv6, compatibility with existing IPv4 structures should be given top priority, a factor that will make the transition easier and cost effective (Chen et al., 2009). Additionally, the mechanisms provided in this paper are meant to be adapted by IPv6 hosts and routers that need to interoperate with IPv4 hosts while using IPv4 networks. It is anticipated that a large portion of existing IPv4 nodes will become compatible with IPv6 nodes and remain so to ensure the complete migration. The transition's main aim is to ensure IPv6 and IPv4 hosts to interoperate and allow for easier deployment of IPv6 hosts and routers with few interdependencies.

Recommendations

From the above paragraphs, the approaches highlighted deal with interoperability as well as compatibility between dual nodes and IPv4 nodes, in situations whereby the dual nodes only have IPv4 addresses. On the contrary, they do not deal with interoperability between IPv6-only nodes and IPv4-only nodes. Given that most operations are becoming dual, the challenge faced by most organizations is whether there are sufficient IPv4 address spaces for assigning each node a specific address able to interoperate with IPv4-only nodes (Amoss & Minoli, 2007). In this regard, there are several recommendations given to ensure the interoperability without the use of additional transition mechanisms. Two applicable methods are given as highlighted below.

The first method is the use of Application Layer Gateways (ALG) which acts as the boundary between IPv6-only nodes and the Internet. Commonly used ALGs include HTTP proxies and mail relays.

The subsequent approach is the use of Network Address Translators (NAT) for IPv4 that assist in translating private IP addresses on the inside and other IP addresses on the outside. Besides, plans are underway to upgrade NAT boxes to support IPv6 to IPv4 address translation.

Nonetheless, both ALG and NAT solutions are likely to result in a weak Internet platform and as a result, the most appropriate tool recommended is the use of stateless header translators which are capable of assigning IPv4 compatible addresses when needed. The other recommendation is allocating IPv4 compatible addresses whenever situation demands as well as using IPv4 in IPv6 tunneling to bridge the IPv6-only routers.

The stateless header translator is essential since it translates between IPv4 and IPv6 header formats given that the IPv6 addresses under scrutiny are able to be represented as IPv4 addresses; IPv4-compatible (Nordmark, 2000). In addition, most IPv6 protocols support such translators thus; the translation remains unaffected even if the system restricts the passage of encrypted packets as well as rarely used features like source routing.