Please also see my earlier article on RIPE Labs where I provided 12 steps to enable IPv6 in an Internet Service Provider (ISP) network.

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 300 million USD.

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 realise that this architecture is widely adopted by many government organisations 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

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 organisation 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.

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.

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 organisation 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 organisation is larger, or includes networks or devices of other organisations 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 organisation 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.

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.