In a previous post, I provided 12 steps to enable IPv6 in an Internet Service Provider (ISP) network. This time, I will look at corporate networks which include government and enterprise networks in general.
I’ve drawn inspiration for this post from a recent IPv6 deployment project I worked on in the LACNIC region, which required connecting 1,800 municipalities to the single government network, and in the process saving the government client around USD 300 million.
This aside, what I wish to concentrate on is the peculiar architecture of the (IPv4) network I had to deal with and how it made deploying IPv6 more of a challenge. I’ve come to realize that this architecture is widely adopted by many government organizations in the region, and other regions of the world, thus the need to share this information.
Auditing network unearths NAT challenges
The peculiarity itself consists of an exaggerated dependence on Network Address Translation (NAT) and load balancing to provide failover with two access links to the same ISP, in place of using BGP.
This, of course, is good if you have a single ISP, but doesn’t work among multiple ISPs; the customer is kept captive by their ISP (which typically provides all the required equipment as part of the service) and will only have partial redundancy, because even if the links of the ISP are using different paths, at some point they will converge.
Figure 1 — Before and after schematics of a client’s network. Drag the slider left to right to see the difference. Right click to view the larger-sized image.
Many current corporate IPv4 networks do not deploy BGP with their ISPs. Instead, they depend closely on NAT or other translation mechanisms, the problems of which are well documented.
In this case, the authoritative DNS records were located in the ministry’s ISP and had extremely low Time To Live (TTL) expiration dates. This allowed the load balancers to detect when a link was down, so they could replace the CNAMEs, among other resource records.
The immediate negative ‘technical’ consequence of this configuration is that the global caching of DNS information becomes ‘invisible’ for this network. This results in an increase in DNS queries, slower access to resources, and more unnecessary and expensive traffic for not only this organization but every Internet user connecting to the network.
Developing a plan to simplify and future proof network
The challenge of this IPv6 deployment was having to first correct this existing (IPv4) architecture to ensure that it would align with the IPv6 deployment and, more importantly, allow for future ISP changes.
Typically, the use of NAT and private addresses in IPv4 is considered advantageous when changing providers, as it avoids the need to renumber all users in the network.
Read: IPv6 renumbering: a pain in the …
In the case of IPv6, there is no need for NAT, therefore, the use of BGP is not only good practice, but essential if you want to employ Provider Independent (PI) addressing to avoid renumbering when changing ISPs. It also allows you to connect to several ISPs (multihoming), which provides complete failover.
Provider-Independent (PI) address space is a block of IP addresses assigned by a Regional Internet Registry (RIR) directly to an end-user organization. The user must contract with an ISP to obtain routing of the address block within the Internet.
PI addresses offer end-users the opportunity to change ISPs without renumbering of their networks and to use multiple access providers in a multihomed configuration.
Imagine a ministry with 5,000 officials, each with their own computer, in addition to the entire network infrastructure, firewall rules, server configurations, and another 5,000 VoIP phones. Imagine the economic cost and the impact on human resources and the ‘disconnection’ time with citizens, to make this change every four years when negotiating for a better deal with another ISP.
With PI, the client could still use IPv4 private addresses, together with global IPv6 ones, but can retain most of the network infrastructure with stable addressing for both IPv4 and IPv6 and avoid any kind of disconnections.
I’ve considered alternative solutions to BGP for enterprise multihoming in the past, such as the one described in RFC 8475 (Using Conditional Router Advertisements for Enterprise Multihoming) as well as NPT (which is only an experimental protocol not to be used in production environments) and Unique Local Address (ULAs). However, these have yet to capture the attention of vendors and are designed for very simple networks, typically with only clients. In the case of the latter two, they also don’t exist as standards, so they aren’t something to recommend in a production network.
Address planning for IPv6
When it comes to address planning for IPv6, the logical thing for an organization to do is request as many /48 as they have sites — if they have a single site, a /48 will suffice, but if they have 13 sites, in locations with different access links, then a /44 (16 x /48s) would be best.
If an organization is larger, or includes networks or devices of other organizations in its infrastructure, — for example, the ministry I was assisting manages a network that connects 1,800 municipalities, and is considering connecting other ministries, police headquarters, schools, and health centres — instead of using the end-user policy, it must request LIR/ISP addressing space. This is because it behaves in a similar fashion as an ISP for the other networks within its own.
Under such a plan, the organization will only be able to receive, at most, a single /22 of IPv4 addresses but can be allocated a minimum /32 (containing 65.536 x /48’s) of IPv6 addresses — several European governments have /24s to /26 allocations for reference.
Although RIR policies did not specifically address the needs of government networks when they were first conceived (since such networks were not common when IPv4 was the only protocol of choice), the community has since adapted policies to cover this need.
See APNIC’s IPv6 address allocation and assignment policy
Project results and future
Although the client could have continued to use NAT for the foreseeable future, they understood the complexities and ongoing costs associated with maintaining such a network and how this compared to deploying IPv6.
Yes, it was a less than straight forward deployment, however it provided the client with an opportunity to audit their network and ensure that it and its applications and services comply with future developments, such as the Internet of Things.
Stay tuned for my next post in which I will outline the 12 steps for deploying IPv6 for governments and enterprises.
Jordi Palet is CEO/CTO of The IPv6 Company.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Great article..Thank you for sharing this blog..
Thanks for sharing. We need more posts like this.
What happens when you use IPv6 with Provider-Independent addressing, and you actually change ISP ? As you said in your article, you need a contract with your ISP to establish BGP neighborhood. If you change ISP, you then need to change your BGP neighbor configuration. How long is this change going to take to propagate to the Internet as a whole, and packets to start flowing to the right Autonomous Systems ?
This sounds like it’s just adding more hurdles along the way – but then again I have never configured this so I’m unsure as to what would happen.
If you are using BGP and you change provider, this just works!
You even can actually keep both the old provider and the new one, while the setup is being done.