IPv4 Success and Future Limitations

Introduction

The internet connections based on the IP version 4 (IPv4) made a great success for the past 20 years. The central reason for this is that the success was informed by a scarcity of the unallocated IPv4 address, as the protocol would not satisfy the demands of the expanding internet. Some of the reports indicate that the IPv4 addresses that were unallocated would be used in either 5 or 6 years to come. However, the eventuality is informed by the fact that IPv4 experiences a deficiency of the IP as a result of the many devices that are continuously added to the network. Apparently, due to the drawbacks of IPv4, the next generation of the IP addresses was seen to be necessary and relevant to the increasing demands of a larger network. The introduction of IPv6, referred to as Internet Protocol version 6, was seen as a solution to the problems that were encountered before while using IPv4. The incoming of IPv6 has triggered a migration which is likely to introduce new challenges, which can be informed by significant methods of co-existence between IPv6 and IPv4. Therefore, the aim of this report is to establish the challenges of migration and the methods of co-existence between IPv4 and IPv6. Sections of the report will cover the background, work to date and time management as well as the remedial plan needed.

Background

The use of IP addresses has for a long period of time captured the attention of many researches. Most of them would discuss the use of IPv4 and the emerging gap that compelled the Internet Engineering Task Force to introduce the IPv6. The latter was introduced to address the anticipated problem of a shortage of addresses when using IPv4. The implementation of the addressing system would introduce a poll of addresses that can sustain a bigger network. According to the research conducted by Rao and Kanneganti (2015), the added advantage of migrating from IP version 4 to IP version 6 is inevitable and may not happen instantly as a result of the huge sizes of the networks. In addition, more organizations are daily adding their work to the internet. The need for more addresses has to the notion of an established system where IPv6 can be turned on and IPv4 off due to the high chances for coexistence between the two. Based on the findings established by Bi et al. (2007), the migration from IPv4 to IPv6 should be done node by node as well as by means of the auto-configuration procedures. The need for such a transition is informed by ensuring that users enjoy the advantages of IPv6 while retaining the IPv4 peripherals for communication reasons. Therefore, the transition period is likely to be long and addition of the IPv6 networks will be forced to continue communicating with IPv4 networks available. This is the reason why NAT-PT becomes handy for the purposes of giving room for direct communication between the IPv4-only networks and IPv6-only networks (Chandra and Lalitha 2015). As much as most of the researches are informative on the reasons and advantages of IPv6, there is still a research gap in terms of the likely limitations or challenges of migrating from IPv4 to IPv6, and the recommended methods that can ensure the two types of addresses coexist. NAT-PT has briefly been mentioned without illustrating it by use of the packet tracers as it would be required for technical reasons.

Literature Review

The study of the coexistence and the challenges that are linked to the transition from IPv4 to IPv6 has attracted several studies that have gone deeper looking into the history. Chandra et al. (2013) focuses on the comparative study of the IPv6 and IPv6. Notably, Internet Protocol, based on the study conducted by Chandra et al. (2013), is one of the significant protocols in the TCP/IP. The protocol would identify the hosts as well as the routes the data that moves over the internet. Goralski (2014) indicates that IPv4 was developed in the year 1978 and determined later in the year 1981. IPv4 makes the fundamental use of the 32 bit addressing known to have a capacity of around 4.3 billion, sometimes denoted as 2^32 unique internet addresses. This version has five classes including A, B, C, D and E where classes A, B and C are known for specifying the length of the host as well as the network. Class D addresses are usually used for the multicasting group while class E is normally kept for future use. Park et al. (2004) further asserted that the next generation of the Internet protocol was IPV6, which was meant to succeed IPv4. The development of version 6 began the year 1991 and later integrated in the year 1997. The Internet Corporation for the Assigned Names and Numbers (ICANN) would add the IPv6 addresses in the DNS server in the year 2004. Unlike IPv4, IPv6 address space is around 128 bits, which means that it can accommodate 2^128 unique addresses. The format for IPv6 addressing is represented by eight 16 bit hexadecimal number fields that can be separated. IPv6 is said to have been developed by the Internet Engineering Task Force, which aimed at handling the anticipated problem of address exhaustion when making use of IPv4. IPv6 has ever been known to be an internet layer protocol meant for end-to-end datagram transmission and packet switched internetworking. IPv6 is thought to be advantageous in term of implementing features that are never offered by IPv4. Notably, the current version offers the simplified aspects of router announcements, address configuration as well as network renumbering. Even before learning about the challenges behind migrating from IPv4 to IPv6, Che and Lewis (2010) indicates that the IPv6 characteristics are explicit and almost designed in a way that can simplify the migration. For instance, most of the IPv6 addresses can essentially be derived from the IPv4 addresses. This implies that IPv6 can easily be built on the IPv4 networks. The IPv6 nodes are meant to follow what is known as the dual stack approach. Aravind and Padmavathi (2015) further indicate that a significant level of compatibility between IPv6 and IPv4 may lead users to think that migrating to the latest version can be useless. However, it should be noted that years from 1997 to 2000 were essentially characterized by the adoption of version 6, which cut across the ISPs as well as the users. Even on or before 1997, most of the users still experienced problems linked to the newness of the product. With such challenges in place, Blanchet (2009) insisted that the migration was imminent citing the interoperation of the IPv6 and IPv4 hosts, the application or utilization of the IPv6 hosts and routers substantiated by distribution over the internet, as well as the need for network administrators to understand the ease of implementing the new version. Gold (2011) further denotes that the ease of transmission can be realized through the IPv6 transition mechanism, which is simply a technology designed to permit the hosts on IPv4 network to communicate with hosts on IPv6 network. The exceptional expansion of the internet users over the recent years denotes the significant use of the IPv4 addresses. The technology informs on a set of mechanisms referred to as the Simple Internet Transition. Che and Lewis (2010) asserted that the SIT approach encompasses the protocols as well as the management rules known to simplify the migration process. The approach bears a number of characteristics including the progressive as well as the non-traumatic transition, less requirements for updating as well as the simplicity of addressing. Several methods can describe the transitional process. To start with, Che and Lewis (2010) start with the dual stack which is applicable when the IPv6 and IPv4 protocols are present on the same network node. The technology normally upgrades the IPv4 node through the partial hosts that equips the two protocol stack. The IPv6 and IPv4 routing information is normally calculated with respect to the protocols and routing tables. The dual stack method applies where the destination address is an IPv4 address, which allows the use of the IPv4 protocol stack. It also applies where the destination address is IPv6 with an embedded IPv4 address. This means that IPv6 can be encapsulated inside IPv4. Raicu and Zeadally (2003) further noted that the Network Address Translation is another significant method used in converting protocols from IP version 4 to IP version 6 and vice versa. The translation can result into transformation of the two protocol headers as well as the payload. The mechanism can be introduced at layers into the protocol stack, which constitutes the network, application and transport layers. The process can essentially be conducted using the network devices or at the end systems. NAT is known for giving consistent internet experience to the significant users by allowing them to access the contents through the internet. Perkins (2015) further insists that internet service providers can easily provide the IPv6 services by simply making use of the translation features. Two types of the translation can be noted which include the NAT64 which is known for providing Network Address Translation between IPv6 and IPv4. The second type is the NAT-PT, which supports Protocol Translation.

NAT 64 is regarded as a technique for the IPV4-IPv6 transition as well as IPv4-IPv6 coexistence. Govil et al. (2008) further points at tunnelling as another method that comes to the effect of migrating from IPv4 to IPv6 with minimized transitions. In the first place, the IPv6 packets are put inside the IPv4 packets which are subsequently routed via the IPv4 routers. One of the key objectives of integrating IPv6 into IPv4 networks revolves around the ability to transfer or transport the IPv6 packets over the IPv4 only-networks. While using the tunnelling method, the IPv6 packets would be encapsulated via an overlay tunnel in the IPv4 packets meant for delivery via the IPv4 infrastructure. The key disadvantage of tunnelling revolves around the fact that the method does not give room for communication across the users of either the old protocols or the new ones without putting in place the dual stack hosts. While transition from IPv4 to IPv6 is made possible through a variety of mechanism, same attention is extended to methods that can enable the two types of addresses to co-exist. Across the mechanisms and methods introduced, security remains one of the challenges that remain unsolved by most of the designers. However, studies around Univers6 Architecture might one of the future works researchers can focus on. Univers6 Architecture does not only involve a single method, but procedures and guides that ensures protection of the network even when using a combination of the two. Various studies narrow down to understanding the challenges linked to the migration from IPv4 to IPv6. Caicedo et al. (2009) conducted a study of the problems and challenges associated with the attempts of migrating from IPv4 to IPv6. Caicedo et al. (2009) further notes that designing the Internet Protocol are such a daunting task that no one would dare to attempt. People would end up collaborating with the intention of producing mere documents seen sufficient for peer review. Since the premier IPv6 protocol RFC, other RFC’s as well as drafts are said to have appeared with the central purpose of correcting certain vulnerabilities while fostering operation or performance of the system. While actions aid formalization of the improvement of the protocol, such endeavours have never gone without having major problems as regards the updates and protocol implementation. When developing the IPv6 protocol RFC, the architecture was believed to compliant of the Security for the Internet Protocol. However, the architecture could not support the multicast and gave a leap way for definition of documents. Bi et al. (2007) denotes the fact that IPv6 protocol depends on the multicast communication especially for the local link operations while stating the IPSEC as mandatory. However, authors cited a few issues with regards to the migration from IPv4 to IPv6. The most preliminary issue includes the internet access problem for IPv6. It is a basic requirement that very network environment needs to have access to IPv6 internet. However, there is still limited telecommunication operators believed to provide the IPv6 network access. With even popular tunnelling methods like 6RD, 6to4 and 6in4, appropriate software and hardware as well as knowledge are needed in the course of picking on the proper configuration of the tunnels. On the other hand, Durdağı and Buldu (2010) further indicated that in some cases, the infrastructure can encounter the incomplete IPv6 support identified in the operating systems. Notably, implementation of the IPv6 stack never facilitates the required support for IPv6. For instance, the IPv6 support across the popular MS Windows of NT5 family would always be limited as a result of connecting to the latest version as well as the correct data exchange. Common system services like remote management, resource sharing and storage of IPv6 addresses are likely not to work in the systems. This limits the operations to NT6 systems, which include Windows Server 2008, Vista, Windows 8 and Windows 7, which are believed to have the new IP subsystem embedded in the Dual Stack Technology. Durdağı and Buldu (2010) also pointed out the reconfiguration problems and the security policies. The IPv6 is known for attracting the whole idea of individual and global IP addresses. Devices attached to the IPv6 network is expected to have an address that is universally routable. The pervasive routing associated to IPv6 has raised issues regarding the security of the network. Perhaps, security policies and mechanisms are needed for the purposes of facilitating IPv6 firewall configuration believed to take into account the universal availability of every device across the IPv6 network (Kalwar et al. 2015). Popular network devices said to offer the basic IPv6 support would only ensure availability of proper IPv4 traffic protection. However, such devices are normally incapable of providing the predefined IPv6 firewall. This is due to the fact that the IPv6 router is significantly transparent for IPv6 traffic while exposing the equipment to direct network attacks. Davies et al. (2007) asserts that due to security conversations, it emerges tat migration of the version 4 firewall security policies in support of IPv6 is one significant issue that requires attention. Notably, the new protocol for ND (Neighbour Discovery) is known for replacing the ARP protocol, which calls for special treatment of ICMPv6. It is important to note that the security policy for ICMP may not give room for mere translation of IPv4 rules. The missing correlation of IPv6 and IPv4 addresses for same hosts leads to the need of the careful analysis of the significant blockade rules while passing the traffic from particular networks as well as addresses. Choudhary (2009) asserts that deployment of the IPv6 has constantly attracted such issues like security as well as quality of service. Most of the IPv6 networks are said to be increasingly exposed to different attacks. Some of the threats include the Extension Header Threats where an attacker makes use of a chain of the extension headers that enables one to pass through the firewalls as well as the intrusion detection systems. In this case, Choudhary (2009) noted that an attacker is likely to cause a DoS attack with the intermediary device failing to process the chained EHs. On the other hand, covert channel security attack creates leap way for the attackers to transfer information using processes which are never allowed to community based on what is asserted by the computer security policy. This also introduces an extra avenue for attackers where routers with slower software and inefficient hardware are more vulnerable to the DoS attacks that are flooded by the router alerts (Wu et al. 2013). Apart from the EHTs, IPv4-IPv6 transition or migration is more vulnerable to the First Hop Security Concerns. The FHS encounters a number of local link security threats. In this case, link operations are constantly constrained by the link boundaries. Some of the link operations include neighbour reachability tracking, default gateway discovery and local network configuration among others. New patterns noted with IPv6 link operations would tend to be different compared to the ones of IPv4 (Deering and Hinden 2017). Such cases would allow the end nodes on the available link which would end up increasing neighbour cache size and create a defaulter router. Other attacks are caused by the Router Discovery Threats, Neighbour Discovery Threats and the Neighbour Cache Attack.

Research

Two key areas that attracted the research part of this report include methods for co-existence between IPv6 and IPv4, and the possible challenges that may hamper or impede the process of migration from IPv4 to IPv6. Findings on the side of challenges that can impede the migration noted the following. Security is an issue especially at either the application or the user level. Security challenges largely emanate from the fact that security networking appliances do not communicate as well as understand IPV6. In addition, security issues can be mechanism-specified where the encryption schemes of DNS SEC can be broken easily by use of the DNS-ALG (Rao and Kanneganti 2015). DoS attacks can also be witnessed as a result of the small data fragments that are sent without establishing the end signal. The second security issue is the one that is IPv4/IPv6 co-existence related where the attacker can traverse the filter of IPv4 by use of the IPv6-in-IPV4 tunnel. Another challenge revolves around allocation of a unique global address to each user in the address space. This leads to increased attention that is needed while designing the Address Architecture IPV6 and the IPv6 network (Quynh Anh et al. 2012). Lastly, cost issue is also another challenge that needs attention. More research conducted in the area of security and challenges paid more attention towards the design flaws, which are commonly identified in IPv6. Sometimes, designing an IP is such a daunting task. Since the IPv6 protocol RFC, added drafts and RFCs seemingly appeared to rectify certain vulnerabilities. For every protocol updates to work, the software producer, vendor and even the operating system developer should take care of the information and changes. Research indicates that IPv6 bears the State Address Auto-configuration is one of the key features that moves the address to the core of the network protocols. Security concerns regarding the automatic assignment of the addresses need to be balanced against the automatic configuration and network availability (Chandra and Lalitha 2015). Another concern that would lead to security concerns is the DNS configuration with details not provided through the SLAAC’s first draft. The use of IPv6 instead of the DNS records is never allowed for most users. At some point, setups for DNS records in the respective domains rarely work unless the network nodes get the support from the DNS servers. With such observations in place, one would easily note that privacy is a big issue for the SLACC and network operations, assertions that support the earlier stated challenges. The second area of the findings includes methods that can be used to make IPv6 and IPv4 coexist. The first method is the NAT-PT, a technique used in modifying the network address details within the Internet Protocol datagram packet headers in the course of transit across the available traffic routing device for the fundamental reason of remapping an IP address space into another space (Chowdhury et al. 2015). Sometimes, the NAT44 would be used to showcase mapping within or between two IPv4 addresses. NAT44 is applied in a typical case where the majority part of the traffic is IPv4-based. On the other hand, NAT64 would be used in mapping an IPv4 to an IPv6 address. However, the process can happen either way depending on the nature of the network (Sharma and Singla 2016). However, more versions of NAT are being established to meet different needs. The NAT-PT method is regarded as an interoperable solution that may not require modifications as well as additional software such as dual stacks. Different versions of NAT-PT would majorly depend on the interoperability functions noted within the core network, and build the interoperability across the nodes. Key benefits of NAT-PT include no need of changes on the existing hosts due to the fact that all NAT-PT configurations are essentially performed at the router. This means that customers having stable IPv4 network can easily and conveniently introduce IPv6 network while using NAT-PT for the purposes of allowing communication without interfering with the existing network. Another mechanism used to facilitate coexistence between IPv4 and IPv6 include the 6RD (Sharma and Singla 2016). The model is applied when IPv6 is deployed over IPv4 infrastructure hence facilitating a transition as well as coexistence of the two addresses. The model gives room for IPv6 services, which can still be provided along the IPv4 services while working on minimal upgrades on the IPv4 infrastructure. It is also of note that 6RD can be decommissioned upon completion of the network migration to a given dual stack model. The latter has two key parts that enable the transition. First is the customer equipment, which encapsulates the IPv6 traffic while the 6RD is realized from the internet via the BR router. The second part is the border relay, which offers the connection between the CE routers and IPv6 network. 6RD calls for the use of 6RD aware CPE and the aware-border relay routers. The CPE device would encapsulate the IPv6 packets that would be taken over the supplier’s IPv4 network to the immediate relay routers. The latter would thereafter encapsulate the packet before sending it to the IPv6 network (Paul and Bakon 2016).

Development and implementation

I did packet tracing for the purposes of simulating configurations of the switches and routers. The following diagrams show the course. In the course of striking the development of the IPv4-IPv6 coexistence, Dual stack technology became significant, simple, and relevant to use. I investigated the dual stack implementation by taking note of the IPv6 as well as IPv4 configuration for the required end devices. I also tested the connectivity of both the addresses with the help of ping before tracing the path for IPv4 and IPv6. However, other technologies such as tunnelling and translation can still be applied with each method bearing complexities. The primary focus on Dual stack came in the light of the simplicity of the structure as shown below.

Through a number of studies, Dual stack is regarded as a transition technology where IPv4 and IPv6 are believed to work in tandem through dedicated or shared links. Notably, in any dual stack network, both IPv4 as well as IPv6 are absolutely used or engaged across the infrastructure. Therefore, the configurations as well as routing protocols are given room to handle IPv6 and IPv4 addressing and adjacencies. For dual stack to offer an ideal solution, two requirements need to be observed. First, the current network infrastructure needs to be capable of making use of IPv6. In some cases, the existing network is likely to miss on the required software as well as hardware upgrades. Secondly, IPv6 should be activated on every network element. For this requirement to be met, the prevailing network should be redesigned. While doing packet tracing, three things were observed. First, there was the fundamental requirement of completing the addressing table documentation. Secondly, there as need to test connectivity while using ping and lastly, there was need to discover the path via racing the route. The following typology was worked on.

First, completing the addressing table documentation called for verification of the IPv4 addressing. This was possible by clicking on PC1 before clicking on the Desktop tab. This should pop up the command prompt before entering the ipconfig command for the purposes of collecting the IPv4 information. Such details allows one to complete the addressing table using the IPv4 address, default gateway and subnet mask. Secondly, by clicking on PC2 as well as the Desktop tab, one can enter ipconfig command before collecting the details for IPv4 information. This allows one to fill the addressing table with subnet mask, the address, as well as the default gateway. While using the IPv6 config in verifying IPv6 addressing, one would be allows to enter ipv6config command for PC1 to get all the IPv6 information. The same happened to PC2 before filling the subnet prefix, default gateway as well as the IPv6 address. The table appears as shown below.

After filling the Addressing Table, ping was used in verifying the IPv4 connectivity. The results came out successfully when IPv4 address was ping for PC2 from PC1. The same results could be realized when IPv4 address was ping for PC1 from PC2. In verifying IPv6 connectivity, IPv6 address was ping for PC2 from PC1 and vice versa. Finally, it was good enough to discover the path via tracing the route by first making use of the tracert in discovering IPv4 path. The route from PC1 could be traced to PC2 by using the tracert 10.10.1.20. Addresses 10.10.1.5, 10.10.1.97, 10.10.1.10 as well as 10.10.1.20 could be encountered. The addresses could be linked to such interfaces like S0/0/01 on R3, G0/0 of R1, NIC of PC2 and S0/0/0 on R2. When tracing from PC2 to PC1, the addresses that can be encountered include 10.10.1.100, 10.10.1.17, 10.10.1.6 and 10.10.1.9. These could be linked to such interfaces such as NIC of PC1, S0/0/1 of R1, G0/0 of R3 and S0/0/1 of R2. When using the tracert for the IPv6 path, the route for IPv6 address could be traced from PC1 to PC2 by using the tracert 2001:DB8:1:4::A where addresses 2001:DB8:1:3::2, 2001:DB8:1:1::1, 2001:DB8:1:4::A and 2001:db8:1:2::1 could be encountered. Interfaces associated to the addresses include NIC of PC2, G0/0 of R1, and S0/0/0 of R2 and S0/0/1 of R3. If the tracert for IPv6 address starts from PC2 to PC1, the addresses that can be encountered along the path include 2001:DB8:1:2::2, 2001:DB8:1:4::1, 2001:DB8:1:1::A and 2001:DB8:1:3::1. The interfaces that interact with the addresses include NIC of PC1, G0/0 of R3, S0/0/1 of R1 and S0/0/1 of R2.

Analysis of Progress

The development to date offers the practical side of the IPv4-IPv6 Coexistence network enabled through the dual stack technology. By using the tracert, one can encounter different interfaces and addresses as noted in the network. This means that IPv6 addresses can ride over the IPv4 network without generating more problems. In this context, the analytical part will look at what problems are encountered with the IPv4 addresses, the stability of IPv4-IPv6 coexistence through the dual stack, problems that are likely to be encountered in the dual stack network and possible remedies that can help to solve the issues. The transition and coexistence of the two networks using dual stack technology were prompted by two major problems realized with IPv4. First, it should be noted that over 7.3 billion persons around the world with over half of them said to own a computer while 6 billion are said to have an access to mobile phones. With presumptions that every person should have an IPv4 address, then it means that there would be a shortage of around 3 billion IP addresses. This means that the modern internet requires more addresses and even more in the near future. Another problem associated to IPv4 address is the network address translation. Notably, a single IP having several private IPs behind it would end up breaking a few of the applications while facilitating no additional security against the internet threats. Such cases may lead to increased costs. In addition, security cannot be ignored as it is the case with the initial design. From the problems stated above, there was a gap in terms of the IP addresses that prompted the coexistence of the IPv4 and IPv6 addresses. The need for the coexistence revolves around the fact that the prevailing infrastructure is IPv4-based. Based on this, both the transition mechanism as well as a coexistence technique was required to effect the performance of the two addresses. Among other mechanisms, the common ones include dual stack, tunnelling and translation. In this context, the dual stack was regarded as the simplest transition mechanism that can easily be designed and deployed at the same time. The mechanism requires all the network peripherals including the servers, computers and routers, to support both the IPv6 and IPv4 protocols that work in parallel but side by side. Notably, the applications are allowed to communicate with both IPv6 and IPv4, which means that it is possible to generate the IPv4/IPv6 network. In this network, communications are essentially transmitted using the IP layers said to correspond to the used addresses without encountering the conversion problem. Making a choice of the IP version would be based on the Domain Name System query or even the application preference. Commonly, the dual stack device bears a complete support for either IPv6 or IPv4. This can be a router, server, host or even a printer which can be configured for the purpose of supporting the protocols. For the IPv4 framework, it is possible to encounter the Address Resolution Protocol, the IPv4 addresses as well as the internet control message protocol. Most of IPv4 routers would support the IPv4 static routes as well as IPv4 routing protocols which are not limited to the Open Shortest Path First Version 2 and the Enhanced Interior Gateway Routing Protocol (EIGRP). Within the IPv6 realm, support would imply network headers having longer addresses. This would include the link local addresses, the IPv6 global unicast and the ICMPv6 that constitute the Duplicate Address Detection and the Stateless Address Auto Configuration. From the network, it is expected that IPv6 router should route the IPv6 packets by making use of the static routes as well as the IPv6 routing protocols including the OSPFv3 and the EIGRP for IPv6. The router would send out ICMPv6 Router Advertisement messages while performing either the translation or the tunnelling services. When communicating with the IPv4 device, IPv6 would end up behaving like the IPv4 only device. On the other hand, when it communicates with the IPv6 device, it would end up acting like IPv6 only device. Dual stack host would send DNS query for the quad-A record. Eventually, the DNS server would return the DNS query response that constitutes the A records and the quad-A. The first host would use quad-A to initiate communication with the server. The communication for the designed network follows the tracert, which identified the interfaces and the addresses. The DSTM architecture constitutes the client, which is the operating system on either PC1 or PC2, the server, which can a local host, and the DSTM gateway, which is sometimes referred to as the tunnel end-point router. The client carries with it the code, which is introduced to the IPv6 only dual stack node for the purposes of allowing connections to IPv4 world. It should be noted that the server machine, sometimes considered as remote, also has a code that would relay between the IPv4 world and the clients while running on a code associated with the IPv6 and IPv4 providers. Besides, the gateway or TEP is equally a machine, which facilitates encapsulation as well as de-encapsulation of the IPv4 over the IPv6 packets. The Gateway demands for the permanent IPv4 address as well as the IPv4 connectivity. Both the gateway and the server are usually implemented on a physical machine. The TEP is commonly integrated with the server code applied in the case as it is for the 6Wind router and the DSTM code. When PC1 within the IPv6 domain wants to communicate in IPv4, the preliminary step constitutes querying the DSTM server for a significant but temporal IPv4 addresses. PC2 would reserve an IPv4 address for PC1 from a pool of addresses and would only send it on the replay. Notably, the replay message constitutes details regarding the TEP or the DSTM gateway. However, various commands introduced to the command prompt would help either PC1 or PC2 to get the IPv6 information depending on the flow of packets within the network. Are there no problems with the dual stack network? Can one progress with dual stack technology when coexisting the IPv4 and IPv6 network? Making use of dual stack technology in this case does not imply that other mechanisms such as tunnelling and translation are imperfect. Perhaps, it could even be noticed that dual stack might be having more problems when compared to cases where tunnelling and even translation is applied. What problems should this progress be prepared for and what would be the possible solutions? A number of scenarios were evaluated and analysed against the operational conditions associated to the project. The simplicity of dual stack mechanism may not necessarily imply anything good. First, it should be noted that problems can be identified around the dual-stack ping. By either running ping or ping 6, the ICMT RTT measurements are known to have limitations. This is because most of the firewalls have a tendency of filtering the ICMP packets with even routers ending up processing the ICMP packets in a slow forwarding path. However, ping would only facilitate an estimation that only offers a significant comparative difference between IPv4 and IPv6. Sometimes, the dual stack nodes are unreachable which leads to speculations that some of them maybe offline or there is a likelihood of the network problem, which may again be not specific to IPv6. Another problem revolves around the dual stack traceroute as well as visualization. At some point, it is difficult to take note of the path problems through running a traditional tracert program. Even with the comparative analysis of the multiple paths, path anomalies may rarely be avoided thereby putting the traceroute tool in question. With scampers and skitters, the large scale topology measurement may be a problem due to slight errors in the packet-per-second rate. Besides, running a dual stack network also means riding on the risk of the VPN leaks. Notably, the subtle interaction of the IPv4 and IPv6 protocols across the dual stack networks emanates from the inadvertent or deliberate attacks leading to security issues linked to VPN leak. This means that the traffic, which is to be transferred via the VPN connection, can be exposed to leakages in the presence of the local network. Despite the fact that IPv6 is never backward compatible with the IP version 4, the duo area always glued together by Domain Name System, commonly denoted as DNS. The dual-stacked systems commonly depend on the name resolution services, it is always impossible to establish a secure communication between the two networks. Most of the VPN implementations would rarely support IPv6 protocol and in worst cases, such implementations would absolutely ignore IPv6. The VPN software would end up inserting IPv4 default route, which prompts the IPv4 traffic to be ferried and over VPN connection. Packets designed for IPv6 address are only possible through the local IPv6 router and therefore no support offered. In such as a case, the VPN leak becomes a side effect of deploying the IPv6 unaware software across the dual stack network. Through pretence of the local IPv6 router, local attackers would take advantage of the vulnerability of the system and trigger IPv6 connectivity across the victim host. This is possible by sending forged or fake ICMPv6 Router Advertisement Messages. The packets can be sent with the help of standard software like rtadvd or packet crafting tools with the likes of IPv6 toolkit prompting VPN traffic leaks.

Can there be solutions for problems that can attack the Dual stack network? The developed system is expected to work and offer stable network for IPv4 and IPv6 at the same time. While this coexistence is possible, developers are still eyeing at solutions that could prolong the durability and functionality of the system. In the case of the traceroute and visualization of the dual stack network, it is advisable for developers to take advantage of the PMTU discovery in identifying the IPv6-in-IPv4. Notably, a drop in the MTU on the intermediate router would always portray possible entry point of the tunnel. It is always important to take note of the tunnels especially when the network seems to ignore the existing IPv4 topology. On the other hand, visualization scripts would read the results of the scamper while trying to create graphs that draw comparison between the IPv6 and IPv4 path pairs. The graph would then juxtapose the path pairs for the bordering destinations as well as plot the intermediate hops. Concerning the VPN leaks, the report notes that most of the systems would fear the DoS attacks but ignore the possibilities of packet leakages. The simplest solution revolves around disabling the IPv6 support across the network interface the moment VPN connection is deployed. Again, the implementation of the first-hop security models like Router Advertisement Guard as well as the DHCPv6 Shield can be more appropriate. Apart from the solvable security issues, dual stack technology remains the ideal framework that brings sense amid the coexistence between IPv4 and IPv6 addresses. The simplicity of dual stack technology over tunnelling and translation has made it easy to adopt and implement at the same time. The traceroute and visualization of the network is made possible by use of this technology. The identified addresses and interfaces running from PC1 to PC2 and back presents the practical side of this project that showcase the possibility of IPv6 network riding over IPv4 infrastructure.

Changes and Challenges

While the project looks successful, there were changes and challenges that were considered and experienced when developing the final project. First, the proposed network below looks different from the final network. A few changes were made such as working on the addressing table and new IP addresses for version 6. The network also needed an active server instead of a remote one for the practicality of the project. This made it possible to do engage the tracert that detected the addresses and the interfaces. Other changes included adding an extra router to detect the interaction among them via Router Addressing Messages.

The main challenge that went overboard is the security issue. This is because one may fail to describe the form or type of an attack. While some are mechanism-specified, others might be IPv6/IPv4 coexistence related. The most convenient way of addressing the security issue is to adopt the Unvers6 Architecture, which addresses a number of prospective attached to the applications, protocols, and network infrastructure (Akilandeswari et al. 2017). However, this one area can be placed under research for the purposes of realizing a better approach.

Conclusion

The report aimed at establishing the challenges encountered while migrating from IPv4 to IPv6, as well as taking note of the methods that would give room for the coexistence. The report notes that the migration is necessary due to the scarcity of the IPv4 addresses, which could not meet the demand by the users. Based on background study, the migration of IPv4 to IPv6 as well as forging their coexistence is in tandem with the need to expand on the IP addresses, as well as the requirement of using the available infrastructure, which has dominant IPv4 characteristics. From the literature review, it can deduce that a number of methods can be used to co-exist IPv4 and IPv6 networks with security emerging as the key challenge. Such mechanisms are not limited to dual stack technology, tunnelling, and Network Address Translation among others. The research to date still point at the fact that design flaws, DNS configurations and VPN leakages can reduce the efficiency of the mechanisms used to integrate Pv4 and IPv6. Despite the challenges, the report noted developing coexistence of IPv4 and IPv6 can be possible by making use of the dual stack technology. The project tested the packets in the network with the help of the tracert. Developing the Addressing Table could be regarded as a milestone as far as verification of the IPv4 and IPv6 connectivity is put into consideration. The purpose, reason, and workability of the dual stack technology could be showcased in the analysis section where the mechanism is considered as the simplest among the three mechanisms. However, it still faces the challenge of insecurity. A number of mechanisms have been thought to contain the issue of insecurity including the use of PMTU discovery among other methods.

Further Work

From the report, it can be established that migration and coexistence of IPv4 and IPv6 is possible through such mechanisms like dual stack technology, tunnelling, and translation. However, the main issues in the course of migration are the insecurity challenge, which is rarely handled through absolute mechanisms. However, robust mechanisms such as Unvers6 Architecture are still under the development process. Unvers6 Architecture has the capacity of addressing issues linked to applications, network infrastructure, as well as protocols. Further work should foster modification of Unvers6 Architecture in an effort to address the security challenge encountered by the coexisting network of IPv4 and IPv6. This means that the architecture should be developed in a way that can detect flaws in a network and prompt the right mechanism that can solve the problem.

References

Bi, J., Wu, J. and Leng, X., 2007. IPv4/IPv6 transition technologies and univer6 architecture. International Journal of Computer Science and Network Security, 7(1), pp.232-243.

Rao, K.M. and Kanneganti, S., 2015. Implementation of “Traslator Strategy” For Migration of Ipv4 to Ipv6. International Journal of Engineering Research and Applications, 5(11), pp.70-75.

Quynh Anh, N., Nguyen, M. and Phu, N., 2012. Transition from IPv4 to IPv6: Best transition method for large enterprise networks.

Sharma, P. and Singla, R., 2016. A Detail Comparative Review on IPv4/IPv6 Dual Stack Co existence Techniques. International Journal of Innovative Research in Computer and Communication Engineering, 4(4), pp. 6923-6932.

Paul, H.C. and Bakon, K.A., 2016. A Study On Ipv4 And Ipv6: The Importance Of Their Co-Existence. International Journal of Information Systems and Engineering, 4(2), pp.97-106.

Udeagha, C., Martin, R., Peck, D., Youton, A., Marshall, A. and Clarke, J., 2018, April. Migrating from IPV4 to IPV6 in Jamaica. In SoutheastCon 2018 (pp. 1-8). IEEE.

Bi, J., Wu, J. and Leng, X., 2007. IPv4/IPv6 transition technologies and univer6 architecture. International Journal of Computer Science and Network Security, 7(1), pp.232-243.

Choudhary, A.R., 2009, November. In-depth analysis of IPv6 security posture. In 2009 5th International Conference on Collaborative Computing: Networking, Applications and Worksharing (pp. 1-7). IEEE.

Prakash, B.A.B.U., Kaplan, J., Skowronek, C.J., Senthilnathan, J. and Seshadri, A., Cisco Technology Inc, 2015. Port chunk allocation in network address translation. U.S. Patent 9,083,587.

Takeda, Y., Sony Interactive Entertainment Inc, 2012. Peer-to-peer communication traversing symmetric network address translators. U.S. Patent 8,224,985.

Chu, T.P., Jin, T., Magee, F.R., Richman, S.H. and Tang, B.Y., Nokia of America Corp, 2009. Method for optimal path selection in traversal of packets through network address translators. U.S. Patent 7,620,033.

Wu, P., Cui, Y., Wu, J., Liu, J. and Metz, C., 2012. Transition from IPv4 to IPv6: A state-of-the-art survey. IEEE Communications Surveys & Tutorials, 15(3), pp.1407-1424.

Park, E.Y., Lee, J.H. and Choe, B.G., 2004, June. An IPv4-to-IPv6 dual stack transition mechanism supporting transparent connections between IPv6 hosts and IPv4 hosts in integrated IPv6/IPv4 network. In 2004 IEEE International Conference on Communications (IEEE Cat. No. 04CH37577) (Vol. 2, pp. 1024-1027). IEEE.

Chandra, D.G., Kathing, M. and Kumar, D.P., 2013, April. A comparative study on IPv4 and IPv6. In 2013 International Conference on Communication Systems and Network Technologies (pp. 286-289). IEEE.