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

By Jordi Palet Martínez

In a previous article, I discussed the 12 steps to deploying IPv6 in an Internet Service Provider network. Now, I want to concentrate on corporate networks, which include cases for governments, enterprises and organizations in general.

While working for a new customer in the LACNIC region, I learned about a peculiar IPv4 deployment solution, which created a number of added difficulties for IPv6 deployment. I learned that this is a solution widely used in almost every government organization worldwide. It consists of an exaggerated dependency on NAT and load balancing, replacing what should be a correct usage of BGP. Because of that, the authoritative DNSs are located in the service provider with extremely low TTLs, which allows the load balancers to detect when a link is down so they can replace the CNAMEs, among other resource records.

The immediate negative “technical” consequence is that the global caching of DNS information becomes “invisible” for this network, which means that DNS queries are increased and unnecessary, and expensive traffic for every Internet agent (not only for this organization) is generated, which slows access to this organization’s resources.

This solution, which must be considered a “very bad practice”, is only an example. There are several other “technical” variations that can be used to resolve a non-existent problem: Avoid using BGP. It’s probable that many vendors and network operators worldwide are selling these solutions for organizations and enterprises of all sizes as a “good practice.” This has another negative implication, in this case a “non-technical” one. The dependency of a unique operator, even if it can offer multiple links using different paths which may divert only partially to that network, can increase cost for customers and negatively impact quality of service and response times towards network changes (such as authoritative DNS changes).

The use of NAT and private addresses in IPv4 in this type of solution can be considered an advantage because it allows you to avoid renumbering all the users in the network when changing providers.  In any case, it will be required to change the rules on firewalls, reverse-proxies and similar devices, which are needed to allow the incoming traffic to access internal resources that are published in Internet applications, web sites, etc.

However, those solutions based on NAT aren’t valid in IPv6 and would be a serious mistake if used. What is the point of transitioning to IPv6 if we reproduce some of the issues that NAT is creating? NAT is a solution to resolve the scarcity of IPv4 addresses and is not a security solution, as some people believe. IPv6 doesn’t have the scarcity of addresses problem and, consequently, doesn’t require NAT. The IETF hasn’t standardized NAT or private IPv4 addresses.

Some consider Unique Local Address (ULAs) and Network Prefix Translation (NPT) as equivalents to NAT and private IPv4 addresses, but that’s incorrect. NPT is an experimental protocol and must be used only in lab environments. Additionally, since it isn’t standardized, it’s not possible to guarantee the interoperability of NPT so there may be adverse effects when used. Sometimes NAT is confused with a security mechanism, and that by having global IPv6 unicast addresses (equivalent to the public IPv4 ones), is not a weakness. However, a firewall is required in every node on any network because 80% of security attacks come from inside the same network. It should also have perimeter firewall which must be configured to protect the network against unexpected IPv4 and IPv6 traffic.

There have been several attempts to search for alternative solutions to BGP for enterprise multihoming, such as the one described in RFC8475 (Using Conditional Router Advertisements for Enterprise Multihoming). This has not yet captured the attention of vendors and has not been implemented since it needs to be supported in each of the infrastructure devices and services on the network in order to work correctly, and will impact the TTLs of DNS, equivalent to the previously described situation. Moreover, the document states that is only useful for simple networks (possibly small ones which have only clients, not servers) and will not preserve existing connections.

It will be unwise, as professionals, to recommend solutions such as NPT, NAT66 (which doesn’t exist as a standard, it can be implemented in Linux but not in other platforms) or even multihoming solutions that haven’t been implemented by vendors, and will only apply to small networks with large contraindications.

Then how should we solve the “non-problem”? How can we avoid when a network changes the provider and has to be renumbered? Simple: By Following Best Current Practices, based on the usage of BGP, and own addressing space, which commonly is named “end-user addressing” or “Provider Independent” (PI).

All the RIRs have policies that allow an organization to obtain an Autonomous System Number (ASN) and the required IPv4 and IPv6 addressing space.

It’s true that in the case of IPv4 we will continue to depend on NAT for the sole reason that there are not enough addresses. However, if an organization requires a certain number of public IPv4 addresses, it may request a maximum of 1.024 (/22) as long as there are enough addresses in said RIR.

In the case of IPv6, the logical thing is to request as many /48 as there are “sites” in that organization. Thus, if an organization has a single site, a /48 will suffice, but if it has 13 sites in locations with different access links, it must request its RIR a /44, which is the prefix immediately above the need for this network (contains 16 x /48’s).

If the organization is larger, or includes networks or devices of other organizations, it must request LIR/ISP addressing space from its corresponding RIR since it behaves as an “ISP” for other organizations. Although in the case of IPv4, it will receive at most a single /22, in the case of IPv6 it can receive a /32 (containing 65.536 x /48’s) or justify the need for a much larger space.

Although initially the policies of the RIRs did not address networks of end-user organizations, like governments, they were adapted a few years ago to cover this need with the consensus of the community.

Going back to the customer mentioned at the beginning of this post, the appropriate use of these policies allows the creation of a government network, in which entities (usually small and medium-sized ones) are interconnected with addresses provided by the government organization that manages said network, and larger entities (or the most advanced ones in terms of IPv6 deployment), with “end-user” addressing. This government network allows the saving, at first sight, of about 300 million dollars (USD), only by connecting 1,800 municipalities. This project also offers, among many other advantages, two data centers (main and backup), configured with high availability for centralized services such as network security, transition, virtualized servers, and help-desks to address all the incidents of said municipalities. When that network also connects to health centers and hospitals, schools, military bases, police stations, and courts, just to mention a few examples, the savings are multiplied.

Obviously, what has been said so far is only a small part, given that the IPv6 deployment project in a network must be accompanied by a detailed study of it, for which it is necessary to analyze the IPv6 capabilities of both the devices of the network infrastructure itself, as well as the clients that connect to it and especially the applications, which is usually the biggest problem. Don’t forget the services that exist in the network, such as databases, web servers, email/messaging services, voice/multimedia services, etc.

IPv6 is much simpler than IPv4, however, it is essential to perform a network audit before “unlearning IPv4” or we will make many mistakes, since the deployment of IPv6 may require major changes in our infrastructure. That is why it is essential to be trained by professionals, before we even start thinking about an IPv6 deployment project.

It is also necessary, once the network is known and understood, to make a detailed addressing plan to be able to request the Internet resources appropriate to our case from the corresponding RIR. The resources available in IPv6 are astronomical amounts of addresses and can no longer be managed with a spreadsheet or text document, so we will require an IP Address Management (IPAM).

Finally, the study of the network and the applications, as well as the addressing plan, will define the possible alternatives to initiate the transition of our network to IPv6, and show us which parts of the network, services, and applications might need the support of transition mechanisms.

Impact of IPv6 Deployment in Corporate Networks

In summary, we can conclude that the impact of the deployment of IPv6, in all types of corporate networks (including governments, organizations and companies of different sizes, among other possible cases), affects the following aspects:

1. Training

2. IPv6 deployment and testing project

3. DNS

4. BGP

5. Addressing Plan

6. Internet Resources (ASN, IPv4 and IPv6 addresses)

7. Address Management (IPAM)

8. Assignment and audit or addresses

9. Network infrastructure devices and clients

10. Impact on applications and services

11. Transition mechanisms

12. Contracts with operators and connections with other organizations

Often, we fall into the error of thinking that IPv6 only affects the connection of the network to the Internet. In other cases, it is thought that it only affects internal users. The global nature of networks, services and applications implies that the deployment of IPv6 affects both aspects of the network, except in very specific cases, so it is necessary to study the deployment of IPv6 as a whole.

In the second part of this article, I reveal the 12 steps to take when approaching your IPv6 deployment project.

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.