In this first of two articles, we looked into one of the issues related to IPv6 addressing for customers: the value of “persistence”. The follow-up article will describe choices for the numbering of WAN and customer LANs.

In a generic way, we could say that the first thing to do for any IPv6 deployment is the complete network addressing plan, even before obtaining your addressing space from your Regional Internet Registry (RIR), so you get it right from the very beginning.

In the case of corporate customers, generally nobody doubts that they should receive a /48 IPv6 GUA (Global Unicast Address) at every end site, and of course, those prefixes should be persistent (often called static) to each customer.

In the case of residential customers, small office/home office (SOHO) customers or even SME customers, in IPv4, we are used to a single non-persistent (often called dynamic) public address. Moreover, because of IPv4 address exhaustion, we are moving towards private addresses in the customer WAN by means of Carrier Grade Network Address Translation (CGN).

So, what is the right thing to do in the case of IPv6 for residential and SOHO customers? This is the question we are trying to address in this article.

Looking for quick and easy ways to do your addressing plan might be tempting, but this might cause unexpected consequences that may require a new plan, renumbering your customers, adapting your provisioning systems, and ultimately make everything much more expensive than if you had done it right from the start. Don’t underestimate the value of investing some extra time and effort in learning more about IPv6 and understanding how it is different from IPv4.

What does persistent versus non-persistent mean?

In IPv4, at least for residential or SOHO customers, because we typically run Network Address Translation (NAT) in the CPE, there is a perception that using non-persistent prefixes is the easier approach. However, doing that with IPv6 is a very different thing and could have negative consequences.

Let’s clarify first what we mean by persistent and non-persistent, as it might be confusing with other terminology such as “(non-)stable”, “dynamic”, “static”, etc. Here we don’t refer to technology used for actually assigning the addresses or prefixes, but instead technology that will “stay” with the same customer.

In general, residential and SOHO customers are provisioned using DHCP (or DHCPv6 for IPv6). In many cases, a very simple way to use DHCP is to have an address pool at every PoP and allow the PoP to assign addresses dynamically (or prefixes in IPv6 by means of DHCPv6-PD - Prefix Delegation).

This very simple mechanism, if not tied to customers, means that arbitrary addresses or prefixes are provided to each customer when the CPE connects to the network, for a given lease time. This is what we call a non-persistent assignment, because if the customer turns off the CPE, after the lease time, they will get a different address (for IPv4) and/or prefix (for IPv6) next time.

However, if we make the lease time very long, maybe weeks or months, instead of just a few minutes or days, the customer will get the same address or prefix. This will be a “persistent” assignment.

If the DHCP/DHCPv6 is tied to some more sophisticated provisioning system, which actually can be as simple as a database correlating specific customers to specific addresses/prefixes, then we have also “persistent” assignments. This can be done, for example, by using an AAA (Authentication, Authorization and Accounting) system such as Radius or Diameter, which is very commonly available at any ISP, for security reasons and to disallow both customers and non-customers from making non-authorised usage of the network.

Persistent versus non-persistent prefixes

From the description above, it might seem that non-persistent assignments is the easier choice, but in fact, in IPv6 you really need to manage the addresses by means of an IPAM (IP Address Management) system. Trying to use simple tools like we often do in IPv4, such as a spreadsheet or word processor, will not work due to the sheer size of the IPv6 addressing space.

The advantage is that those IPAM systems often come with functionalities such as DHCP/DHCPv6/DHCPv6-PD and DNS. Therefore, they can take over the prefix assignment to customers for each PoP so that, in the end, it becomes even simpler than having a pool for each PoP and allowing arbitrary addresses to be assigned to each customer as they connect. With that you win more control over the parameters across your network.

There is one additional advantage of using persistent prefixes, both from the user and the ISP side. Having the same addresses means the ISP can offer new services to the customers, and they don’t need to have complex systems to correlate those services to “changing” addresses inside the customer network. Also, the users can create their own services without any constraints.

So, for example, the ISP can offer advanced DNS service for user devices, such as camera1.username.ispname.com, or main-door.username.ispname.com, etc. Or they can deploy VPN services inside the network. In addition to that, persistent prefixes can be an incentive for customers to remain with their ISP. All those aspects may bring additional revenues.

There is one final consideration: Are you going to do something different, in terms of persistency, for corporate versus other types of customers? Do you have differentiated networks or provisioning systems? I don’t think it make much sense to have non-persistent prefixes for residential/SOHO/SMEs and persistent ones for corporate customers.

In any case, I strongly suggest to offer persistent IPv6 prefixes.

If you’re not convinced yet, let’s take a look at the problems caused by non-persistent prefixes, for instance when it comes to network failures, power outages, or similar situations.

Let’s suppose a customer provisioned in the first stage with the prefix 2001:db8:1111::/48. Their devices are using, for our example, the first free /64 (2001:db8:1111:1::/64). Everything is fine until there is a power outage. The CPE boots up again when power is recovered, and because the ISP is using a non-persistent prefix, a new prefix is assigned (2001:db8:2222::/48), so now the CPE is announcing 2001:db8:2222:1::/64.

However, the devices that have battery (laptops, tablets, smartphones) still have the previous prefix, so now they have two different prefixes (2001:db8:1111:1::/64 and 2001:db8:2222:1::/64). These devices will try to keep using the older one, and they will not work, as the ISP is no longer routing the first prefix to that customer. Just think: if another network failure or power outage were to happen now. Devices could then have three or even more prefixes. And the user will end up calling the ISP help-desk for troubleshooting because the network is not working.

In addition to that, big content providers are measuring “IPv6 brokenness”. The situation described above will increase the failure rate of your network, so they will stop serving AAAA records to that network and your traffic will go back to IPv4. If you are using CGN, it means extra CGN usage, resulting in extra costs, extra delays, and so on.

Furthermore, if you use persistent prefixes, there is another advantage: because it means each customer always has the same prefix, you don’t need to log those connections for lawful interception, as everything is static - “each customer same prefix”, therefore lowering your costs and even simplifying troubleshooting in case of any failures.

Of course, when we suggest assigning persistent prefixes, we aren’t considering “portability”. If a home/SOHO user moves from one location to another, they will need to switch off their network and move it to the new house, ask for a new Internet connectivity setup, etc. So, they must not expect (unless it’s the same building or neighbourhood), that they will get the same prefix – unless you want to offer this as an extra service.

There may be a special case for customers with privacy concerns: if they consider the prefix (not the address) as personal data, the customer might have the right to get it changed from time to time. In IPv6 this should not be a significant issue, because OSes use privacy addresses to avoid tracking users, and furthermore, modern technologies for tracking rely on many other parameters obtained from the browser, apps, etc. However, this can be solved by allowing the users to choose a non-persistent prefix in their Internet connection management interface.

The second article will describe choices for the numbering of WAN and customer LANs. We will then also draw conclusions for all those aspects.