IPv6 for Governments and Enterprises: Impact and Implementation in 12 Steps (Part 2) [Archived]

By Jordi Palet Martínez

In the first part of this article, we analyzed the impact of deploying IPv6 on corporate networks, which include governments, companies and organizations. Now I will explain the 12 necessary steps to implement your IPv6 deployment project.

1. Get training

An IPv6 deployment project in any network is a big step towards the future, and therefore training is imperative. IPv6 is not the same as IPv4. It is inconceivable to properly plan the project, and its subsequent execution, without having the proper training. The cost of training is a small investment that will result in savings and quality of deployment.

2. Create a deployment strategy

Once your team has had sufficient training, you can begin work on the IPv6 deployment project. Every project should start with an audit of current and future planned changes in infrastructure including client devices, operating systems, applications, network services, servers, security equipment and, of course, all the equipment which supports the network itself (switches, routers, wireless, etc.).

The project team must carefully study all the organization’s systems that the project will have to support.  This will help the team: identify potential bottlenecks and solutions, ensure they test to confirm that it works as expected and that it has not adversely affected the rest of the network nor its internal or external users, and understand whether they connect with IPv4-only, IPv6-only or dual-stack. It is essential to test from various Internet points to confirm that your network is not only accessible from its immediate environment, country or region. We often see cases of networks that have not made these checks and have incorrect global visibility.

Generally, this project will force a rethink of many aspects of the current design of the network. It will not be necessary to make changes in all the cases– this will depend on each network. But we must look at deploying IPv6 as an opportunity to ensure that the network and its applications and services comply with future developments, such as Internet of Things (IoT).

The following steps in this guide should be an integral part of the IPv6 deployment project. We list them as additional steps, to highlight the importance that each of them has in the project.

Network pictured before the IPv6 deployment

3. Get control of the DNS

One of the most important aspects for an adequate deployment of IPv6 is the control of authoritative DNS zones. The transition to IPv6 is based on the fact that the operating system and/or applications are able to choose properly if they must use IPv4 or IPv6. This implies an intensive use of DNS for the entire network,  which we are not always used to when using IPv4.

If we don’t have control of the DNS, or depend on third parties to make changes, the deployment and testing may become very complex, which can generate large and unnecessary delays and difficulties throughout the project.

4. Consider using BGP

Many current corporate networks with IPv4 don’t use BGP with their Internet providers. Instead, they depend closely on Network Address Translation (NAT) or other mechanisms which are not recommended, as they have negative implications which are hidden by IPv4.

However, IPv6 does not require NAT or private addresses, therefore, the use of BGP is not only a good practice, but essential if you want to have provider independent addressing to avoid renumbering your network when changing providers.

Imagine a Ministry with 5,000 officials, each with their own computer, in addition to the entire network infrastructure, and another 5,000 VoIP phones. Imagine having to renumber all that infrastructure every four years. Imagine the economic cost, the impact on human resources, and the “disconnection” time with citizens needed to make this change. Do not underestimate the impact even when we talk about only 500 or 1,000 user devices.

Network pictured after the IPv6 deployment

5. Develop an addressing plan

In many cases, existing IPv4 addressing plans may be a reference for IPv6. However, the recommendation is to start from scratch because undoubtedly IPv4 “patches” will have been made over the years, and it will most likely be based on private addresses that may be duplicated in different parts of the network. IPv6, again, is an opportunity to to “fix” problems seen in IPv4 addressing plans.

We can say that IPv6 has almost unlimited address space, but you have to be meticulous and not waste addresses where it is possible. In many guides it is recommended to use “bits” to facilitate identification of networks/VLANs, services, geography or several of these aspects. However, we must be very careful with these recommendations–  each network case is very different and often this leads to a waste of addresses because of the “consumption” of bits in an unnecessary way.

6. Obtain Internet number resources (ASN, IPv4 and IPv6 Addresses)

If you want to avoid the renumbering that I mentioned before, and be able to have your own addresses with BGP, you have to obtain an Autonomous System number (ASN), in addition to IPv4 and IPv6 addressing space, from an RIR.

In the case of IPv4, if the need is adequately justified, it is possible to obtain up to /22, that is 1.024 addresses. This will only be possible while IPv4 addresses remain in the corresponding RIR and if it is the first time they are requested. Alternatively, an IP broker could provide them.

In the case of IPv6, if your organization only uses the address for its own network and not for third parties, it can qualify for a minimum of one /48 for each “site” of the network, such as end-user (PI, or Provider Independent.) This allows addressing up to 65.536 sub-networks (/64) within each site.

If it is a larger network, which may need to sub-assign addresses to third parties, even to other institutions in the case of a government network, then it will qualify for a minimum of one /32 (allowing 65.536 sites, each with its own /48). Large networks of governments will often require shorter prefixes, for example, /25 or /26.

7. Use IP address management (IPAM)

It has been common with IPv4 for organizations to use a text document, spreadsheet, or even a notebook when creating their addressing plan. The IPv6 address space, and the possibilities of network growth, make it difficult to use these mechanisms. This encourages us to adopt IP Address Management (IPAM) tools, which can be OpenSource, commercial solutions, or even devices (“appliances”.)

Often these solutions allow coordination with the DNS, DHCPv4, and DHCPv6.

8. Assign and audit addresses

One of the most important aspects when deploying IPv6, is to understand the differences between the different mechanisms of address assignment, such as autoconfiguration with SLAAC, DHCPv6, or the combination of both and even the use of multiple addresses in each interface. It is also necessary to understand what devices or operating systems can use one or the other and in what circumstances.

In networks which require you to regularly “audit” which devices and users are accessing certain applications or services on the network – which is usual in government networks or financial entities, among many others – these aspects have a special relevance and represent very significant changes with respect to IPv4, which can have an impact on applications, databases and network security mechanisms.

9. Verify IPv6 support

When auditing the equipment that constitutes the network itself such as the servers, client equipment, operating systems, etc., be aware that some manufacturers think it’s enough to indicate “supports IPv6”.

This is a serious error since there is no clear definition of “IPv6 support”. This depends exclusively on the context where said device or operating system will be used. That is, what RFCs it must comply with according to its location and functions in each specific point of the network.

Don’t assume your equipment supports IPv6 just because it says so. Be sure to verify this information with your vendor before proceeding.

10. Test the impact on applications and services

This is undoubtedly the most complicated aspect of deploying IPv6. We can find applications that use literal addresses, applications that use old libraries without IPv6 support, applications that store 32-bit fields in databases, and an endless list of other problems.

All these applications could continue working when we deploy IPv6 coexisting with IPv4 (dual-stack), but will not work when IPv4 is removed from the network– which will happen sooner rather than later. While maintaining dual-stack in the network, applications that depend on IPv4 for security or audit purposes will not work correctly when users access them with IPv6. Likewise, many applications could be impacted when external users only have access to IPv6.

In short, this forces us to study and classify these applications and adopt appropriate solutions to each group.

11. Create a long-term network with transition mechanisms

The deployment of IPv6 should not be considered exclusively dependent on the coexistence with IPv4. While generally, the logical step is that both protocols coexist, but in the very near future networks will be IPv6-only.

This implies that the entire deployment project must contemplate both situations and solve the problems that arise in both cases, with the aforementioned special affection of the applications, since some of them can’t be modified (the manufacturer no longer exists, no access to the source code, the change is very expensive, etc.), and in some cases, adopt transition mechanisms that allow coexistence initially, and finally an “IPv6-only” network.

12. Check contracts with operators and connections with other organizations

Often, and especially in large networks, we have several Internet providers that generally don’t collaborate with each other. It also happens with other providers for voice, or other services. As we have indicated before, this was solved with NAT in the case of IPv4.

With the deployment of IPv6, we will have to renegotiate those contracts, both data, voice and other services, so that they not only have IPv6 support (initially in dual-stack mode, in the future they could be IPv6-only), with BGP. Only in cases of a single common provider for all services is it possible to avoid the use of BGP. Although it is still convenient and good practice to have multiple paths with different providers and to announce your own addressing space in your autonomous system.

Once we have taken all 12 steps into account, and only then, can you begin your IPv6 deployment. Depending on the size of the network, it may take several months, even years, for the most complicated aspects, such as the analysis and adaptation of all applications.

It is important to keep in mind that there are many other aspects besides those indicated in this guide. For example, it will be necessary to prepare a purchasing guide, so that future acquisitions and contracts fulfill the appropriate requirements in each case regarding IPv6 support, think about trainings for software developers (internal or external collaborators), and prepare a roadmap to maximize the usage of the IPv6 deployment, etc. It’s logical to assume that the network will have IoT services in the future– in the case of government networks think: SmartCities.

All these aspects, and many others, will undoubtedly give you a vision and dimensioning very different from your current IPv4 network, hence the importance of training and consulting with professionals with previous experience in government and corporate networks with IPv6, since this guide is only a starting point.

Any views, positions, statements or opinions of a guest blog post are those of the author alone and do not represent those of ARIN. ARIN does not guarantee the accuracy, completeness or validity of any claims or statements, nor shall ARIN be liable for any representations, omissions or errors contained in a guest blog post.