Future Of Internet Communication

Published Date: 02 Nov 2017

IPv4 vs. IPv6

Jackie Syddall

Ozarks Technical Community College

Author Note

This paper was prepared for Advanced Topics 260, Section 101 taught by Mike Vest

Abstract

[The abstract should be one paragraph of between 150 and 250 words. It is not indented. Section titles, such as the word Abstract above, are not considered headings so they don’t use bold heading format. Instead, use the Section Title style. This style automatically starts your section on a new page, so you don’t have to add page breaks. Note that all of the styles for this template are available on the Home tab of the ribbon, in the Styles gallery.]

Keywords: [Click here to add keywords.]

IPv6: The Future of Internet Communication

IPv4 vs. IPv6

The Internet provides unlimited connectivity, but in order to provide this connectivity necessitates that the computers and other devices are able to establish a connection using a common addressing scheme. IPv4, adopted by ARPANET [1] to use only TCP/IP [2] and IPv4 address on January 1, 1983. (Hauben, 1998) With the depletion of addresses recognized in the 1990’s a new addressing scheme was developed called IPv6. IPv6 is being put into place to accommodate with the growth of the Internet. These questions need to be asked:

Why IPv6 is needed?

What are the 5 main concerns in implementing IPv6?

When will it be imperative to implement IPv6

What are ‘best practices’ to implement IPv6?

How to subnet IPv6?

Why is IPv6 needed?

Internet Protocol (IP) addressing is the IPv4 is the most commonly used version of addressing. IPv4 addresses are 32-bit numbers often expressed as 4 octets in "dotted decimal" notation. (IANA, 2013) By the end of the 1980’s it became increasingly obvious that the 4,294,967,296 ( addresses that were available were not going to sufficient to supply the explosive growth in the Internet’s acceptance. The number of devices that would need to link to the Internet using an address far exceeds the available addresses. The Internet Engineering Task Force (IETF) develops and promotes Internet standards, cooperating closely with the W3C and ISO/IEC standards bodies and dealing in particular with standards of the Internet protocol suite (TCP/IP). (Russell & Cohn, 2012)

When the depletion of the IPv4 address was obvious in the 1990’s the IETF was tasked with devising a new addressing scheme. In 1996 IETF developed Internet Protocol version 6 (IPv6) to expand the number of IP addresses available. IPv6 addresses are 128-bit addresses, expressed in hexadecimal notation (for example, 2001:DB8:8::260:97ff:fe40:efab). ( RIPE Network Coordination Centre, 2010)

While IETF was working on the new IP version several workarounds were put into place to slow the depletion of the IPv4 address. The following stop gaps insured that the address space would last till a viable solution could be put into place.

Establishment of Private Network Addresses (RFC 1918)

Establishing gateways

Network Address Translation (NAT)

These protocols provided companies and network administrator’s time before they would have to implement the IPv6. This time was to allow for a smooth transition and not be a permanent solution to the address depletion. Without adding these protocols to the IPv4 addressing scheme the address space would have been used up prior to IPv6 being ready for deployment. RFC 1918 defined has reserved the following three blocks of the IP address space for private internets:

10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

Private network addressing allowed an administrator to assign internal IP addresses to computers running on their internal network by using these address blocks. (Rekhter, Moskowitz, Karrenberg, Groot, & Lear, 1996) Then a gateway would be defined and with NAT running on the edge of a network would change the IP address to the company’s external address or from a group of addresses that are assigned to the company with a port translated to the connecting computer. These measures preserved address space being assigned by IANA delaying the complete depletion of address space available within the IPv4 address space. IANA is the entity that coordinates global IP address allocation, root management of the Domain Name System (DNS) and other Internet Protocol-related symbols and numbers. (IANA , 2013)

IANA assigns the available blocks of IP addresses to the five regional internet registries that in turn divide the addresses into smaller blocks and delegate them to Internet Service Providers and other organizations. "On Monday, January 31 2011, IANA allocated two blocks of IPv4 address space to APNIC, the Regional Internet Registry (RIR) for the Asia Pacific region, which triggered a global policy to allocate the remaining IANA pool equally between the five RIRs. Today IANA allocated those blocks. This means that there are no longer any IPv4 addresses available for allocation from the IANA to the five RIRs." (NRO: The Number Resource Organization, 2011).

Another reason for the need for a new protocol is that technology is always moving forward. To keep up or advance the technology changes needed to be made to the current addressing and flow of data throughout the internet. As with anything that is new there are many concerns by individuals and companies as in how to migrate to the new IPv6 addressing format.

Concerns in implementing IPv6

With the ultimate depletion of IPv4 address from the pool soon companies will have no other choice but to convert their systems to IPv6 just maintain internet connectivity. The only addressing they will be able to get is an IPv6 address from their ISP. It is only a matter of time, the clock is ticking. The migration to IPv6 will be a complicated one for all organizations. There are scans of existing equipment to do, information to gather, and plans that need to be made through the organization to accommodate these concerns. Most of the concerns will be answered by the network administrators and the IT teams that companies have in place. 6connect.com published an article on February 8, 2012 outlining the following top five concerns of that network administrator have about making the switch to IPv6:

Selling the migration internally to the company

The cost of migrating

Complexity of migrating

Dealing with legacy system issues

Removing current IPv4 devices

Selling the Migration Internally to within an organization, the organization will rely upon the IT professional. Corporate decision makers must know exactly what is at stake in the migration and what it means for the organization. Results must be conveyed along with the consequences that are surly going to be part of the process of migrating to IPv6. Once the communication of why the migration is to be done the decision makers can then look at the costs that will be involved with such a task.

The cost to a corporation is not only the amount of money will spent on the project but, also, the time and personnel that will be involved. An exorbitant amount of planning is going to be required to complete the migration as quickly as possible, and having connectivity with hardware/software working as an end result. Trained personnel that can be efficient at their tasks, communicate well, and have different experience and points of view will help reduce the overall cost. By far the costliest will be the equipment needed to perform the specific IPv6 functions, or for new equipment to replace non IPv6 compatible. In an article published by Greg Ferro on March 7, 2011 he states, "Implementing IPv6 will require significant resources, extensive planning and commitment to implementing change." Ferro continues, "The migration to IPv6 means upgrades to data center equipment, but also significant changes to desktops, security and compliance software, network management systems, WANs, telecommunication strategies, IP telephony and more." (Ferro, 2011) With these changes needing to be made the complexity issues with a migration to IPv6 seems to be very formidable road block to complete the process.

With migrating to IPv6 complexity, all departments of an organization will be effected from the president, management personnel to the end users, and all equipment used on the corporate network. The best way to approach the complexity issues is to have a plan that has been and communicated throughout the organization. The plan should be broken up into manageable

For right now, let’s deal with just the complexity issue rather than technical details. There are several different ways to work through a complex issue, and it always involves planning. In order to ensure nothing is missed, a plan must be created that will detail information such as timelines, groups of devices to be migrated, priorities, etc. In doing so, you can break the complex situation into more manageable pieces that are easier to work on and communicate to the rest of the organization. Again, IPAM can assist with this task by creating reports that can be interpreted and used in the planning process.

This is only a brief look at the potential complexity. It can be taken even further by different makes and models of equipment that coexist on the network. But to deal with the concern, the best bet is to reduce the complexity. You can do this by planning out your migration by groups, devices, time, or whatever works best for you. The important part is that everyone agrees on it, and it is something the organization can live with in terms of effectiveness for the business process. It should also be sure to have every single component on the network, and be followed, checked, and updated as needed throughout the migration project.

Concern 4 – Dealing with Legacy System Issues

Legacy systems can be defined basically as older systems. They likely are missing some common functionality from current technology, but still exist because they perform a key or important function for the organization just fine, thus there is no reason to replace it. With IPv6 migration, there may be a reason now.

When an organization migrates to IPv6, the devices on the network need to be able to have an IPv6 address, along with their existing IPv4 address (a technique known as dual-stacking). If the device cannot utilize a v6 address, it will eventually cause conflicts and problems in not being able to be found or communicate properly. It is possible to temporarily force it to use v4 only, but once the network continues to evolve and migrate further towards IPv6, it will progressively lose more and more communication with the network until it is gone.

The best way to deal with legacy systems is simply analyzing them for compatibility. Knowing that this can take up significant resources given volume of equipment, IPAM can help. By scanning and detailing the network, it can help determine compatibility for devices connected to the network, and provide a report. This is highly recommended not only for this function, but to assist in keeping addressing correct during migration.

This may sound like a simple solution, and to a point it is. However, it is inevitable that an important piece of equipment will not be compatible. At that time, the migration plan to IPv6 expands to include all of these devices, which must be planned for migration themselves and implemented on a complimentary schedule to the entire migration. The sooner the compatibility of all devices can be determined the better, as it will allow for a timeline to be determined, and a better view of the scope for the entire IPv6 migration.

Concern 5 – Cleaning Current IPv4 Inventory

The final concern is getting rid of IPv4 inventory. For many network administrators, this will involve getting new equipment, implementing it, hanging onto the old equipment temporarily for backup purposes, then getting rid of it. But it is more than just equipment. Inventory in this case should also include services such as DNS and DHCP, both of which change or are removed with IPv6. This is also the final step of IPv6 migration where IPv4 is removed from the network, so while it should still be a concern, there is a decent amount of time before this happens.

To counter this concern, planning is still the key. However, at this point it is less about the plan itself, and more about executing it. By this stage, dual-stacking should be fully implemented and all non-compatible devices either replaced or their purpose moved to a compatible device. Then DHCP can be turned off for IPv4 and all devices with static addresses having their IPv4 addresses removed. This is where the concern comes in. If one device is missed at this point, it will immediately lose all communication with the network if it has not already. Add in the sheer volume of devices this may have to be done for, and suddenly the scope grows even more.

Aside from proper planning and execution, there are other ways to counter this concern. First, the objective is turning off IPv4, which can be accomplished through network management tools like Group Policy or configuration distribution programs. IPAM can also help by showing if there are any devices still not compatible with IPv6, and which devices are not yet utilizing v6. Of course, with any major network change, backups are also very important so if the system does completely crash, it can be recovered with minimal loss. Testing environments for these methods is encouraged, and always check with manufacturers to ensure that reboots or other strange actions will not result from suddenly removing that communication method from items like servers and firewalls. Naturally, schedule downtime is an absolute must, no way this should ever be done under any circumstance during business hours, especially the service shutdown.

However, at a certain point, you can only prepare for so long before there is no more to do, and the only step left is to remove IPv4 inventory from your network. At that time, double check backups and all the reports to ensure it is correct, then press the button so to speak. Once IPv4 is removed from the network, there is no time limit on actually removing the physical inventory. Without the capability to communicate with v4, the devices will simply not function and do not pose a threat to the network connectivity or as a security risk.

Reflection

These are only what are considered to be the top 5 concerns with IPv6 migration, specific only to network administrators. There are many other challenges and concerns within this project as well. But with each of those, and the 5 seen here, there are some basic strategies that can minimize the impact of them.

Communication is always important, especially within the organization. This migration is everyone’s concern, so why not involve them. Of course not everyone will be involved at every stage, but it helps to build a team environment. With that communication comes planning and understanding so everyone will be together on the project. Use the resources available within the organization as well as the ones outside such as the IPAM.

Regardless of the approach, the entire migration will take time, resources, and planning. There will be meeting after meeting, and a huge amount of information gathered and utilized. By working together in your organization, you can make these top 5 concerns, and all the others not mentioned here have less impact on the project, and have a higher chance of a successful migration.

https://6connect.com/resources/top-5-Concerns-of-network-admins-about-migrating-to-ipv6