One of the main issues when an ISP is planning to deliver IPv6 services is to decide how to address the customers. 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 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.

So, 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.

 

1. 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 to make non-authorised usage of the network.

 

2. 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 to 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, which means you don’t need to log those connections for lawful interception, as everything is static — “each custom same prefix”, 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.

3. Numbering the WAN link

There are several possibilities for numbering the link that interconnects the ISP network and the customer CPE (the WAN link). Let’s describe each one and understand the pros and cons.

3.1. A /64 prefix from the IPv6 prefix assigned to the customer
This is being used by a number of ISPs and has been described in an IETF document (Guidelines for Numbering IPv6 Point-to-Point Links and Easing the Addressing Plans). It means that, for example, if you assign a /48 to the customer, the first /64 will be used for the WAN link, and is being used in cellular networks. There are many advantages, as it simplifies routing and management, but works only if the CPE is following RFC6603 (Prefix Exclude Option for DHCPv6-based Prefix Delegation). However, because most of the IPv6 CPEs should follow RFC7084 (Basic Requirements for IPv6 Customer Edge Routers), which already recommends supporting RFC6603, it is expected that modern CPEs will work in this situation.

3.2. A /64 prefix from a dedicated IPv6 pool for WAN prefixes
This is probably the most common choice and indeed closer to what is often done for IPv4. It means having a totally separated pool of IPv6 prefixes for the WAN links, so in this case there is no correlation between the customer prefix and the one used on the WAN link. A dedicated pool has the advantage of being able to apply security policies explicitly for those pools; however, it should be noted that this is only true if all customers have a CPE at their end, as, otherwise, it will harm users without a CPE.

3.3. Unnumbered
Instead of using a GUA, the link uses IPv6 link-local addresses. In this case, the CPE may not work and stay unnumbered because it may be unable to request a prefix using DHCPv6-PD. This will also fail if instead of a CPE, an OS is used, which does not support DHCPv6-PD. It may look easier to implement than the other choices described here, but because the link-local addresses aren’t visible in tools such as traceroute, it makes troubleshooting more complex.

3.4. ULA
Numbering the WAN link with IPv6 ULAs (Unique Local Unicast Addresses) is strongly discouraged, as it may cause a number of problems. For example, if the CPE needs to send ICMPv6 to a host outside the ISP network, the packet will have an ULA source address, and will not traverse the ISP upstream router, therefore breaking PMTUD (Path MTU Discovery), and the IPv6 connection if the MTU is not the same through the whole path. Again, this might make troubleshooting more difficult.

There is one more issue related to the WAN link, which refers to the choice of the WAN link prefix length. Some ISPs just use the default /64, as the default IPv6 subnet size (as the WAN link is one more subnet). RFC6164 suggests using /127, but other ISPs use /126 or /112, among other choices.

However, it must be noted that some hardware has limitations for prefixes longer than /64, and some may not even allow using anything other than /64. Using a /64 is futureproof and has the advantage of allowing a point to point link; to have additional devices such as managed bridges, troubleshooting or monitoring devices; or even high availability by means of VRRPv3, etc.

Last, but not least, if you decide to use /127, you should consider allocating the complete /64, even if you use one /127, so you prevent the Neighbour Discovery exhaustion attack (RFC6583).

Note that the discussion about “persistence” in the first sections of this document is relevant only to the IPv6 prefixes assigned to the customer for using inside its network, and not the prefix used for the WAN link, which may be “non-persistent”. However, typically most of the ISPs will also make it persistent and is automatically handled by the provisioning system.

 

4. Customer assignment prefix size choices

As a starting point, we need to remind ourselves of the three golden rules that need to be considered with IPv6:

1. The standard subnet size is /64.
2. Customers must be able to subnet their networks, which means that they need to be assigned n x /64 (so a single /64 is NEVER a valid choice).
3. To keep addressing plans usable and understandable and to align with DNS reverse zone delegations, the size of the prefix assigned to the customer must be aligned with a nibble boundary (4 bits).

The policies of the RIRs, in all the five regions, allow assigning a /48 to each end-site, and it is clear that globally it is a well-understood and very common practice to assign a /48 to each corporate end-site.

Furthermore, a new IETF work, “Unique IPv6 Prefix Per Host”, shows the need for multiple /64’s in each end-site and probably many more than what we assumed up to now, as it becomes more and more frequent, even in the case of residential usage, to have devices that run several virtual machines. This means that it may be a requirement to isolate those different VMs in different subnets (therefore, different /64s). This similarly happens with new protocols such as Homenet, which uses a /48 from the ISP and then subassigns /56’s to downstream routers.

Finally, it is clear that in many countries, corporate customers (at least SMEs and SOHO) get the same links, because broadband capacities are increasing quickly for all kind of customers. The only possible differentiation are SLAs and may be a number of public IPv4 addresses. So, we need to consider that older service/marketing/sales differentiations by the number of addresses, are not meaningful anymore with IPv6.

Considering the above, here are the choices for assignment sizes to customers:

4.1. A /48 for all the customers

This is my recommendation as it allows a very simple and straightforward addressing plan and thereby reduces the risk of making mistakes. It also has the advantage that if the customers need to use ULAs, or they have used previously transitioned mechanisms, the prefix sizes match and they don’t need to have different internal addressing plans, as they directly map into each different prefix.

4.2. A /48 for corporate and a /56 for residential

It is possible to consider the previous recommendation just for high-end corporate customers and then use a /56 for the rest, but as explained before, this kind of marketing/service differentiation doesn’t make much sense anymore in IPv6. In the near future, it will mean that you are forced to redo your addressing plan and renumber your customers, which comes with a cost. If you don’t have enough address space to assign a /48 to all of your customers, you can go back to your RIR and ask for more, justifying it with the complete addressing plan. As an alternative, you can reserve a /48 to each customer but actually assign them just a /56, so instead of renumbering in the future, you will just increase the prefix size.

4.3. Prefixes longer than /56

This is definitely the worst thing you can do, so I must strongly advise against. There is no valid reason to assign longer prefixes than a /56 to any customer.

There is a special case, outside the scope of this document, for a single /64, the only possible exception to the rules above described, which is cellular networks. In those networks, each PDP context of a smartphone or similar device gets assigned a single /64. Nevertheless, they can also use DHCPv6-PD to request shorter prefixes, as happens in the case of 3G/LTE modems/routers, which often are used to deliver broadband in areas where no other technology offers coverage.

5. Conclusions

Making wrong choices when designing your IPv6 network will sooner or later have negative implications on your deployment and require further efforts such as renumbering when the network is already in operation. The temptation to take “easy” approaches for quicker deployment should therefore be resisted.
As a generic set of recommendations, you should consider the following:

5.1 IPv6 is not the same as IPv4. In IPv6, you assign a short prefix to each end-site, so they are able to have as many subnets (/64s) as they need. You should not be concerned with exhausting the IPv6 addressing space, and you should think big when planning future requirements. If you need more space, you can go back to your RIR and, providing your addressing plan justifies the need, you can obtain more IPv6 addresses.

5.2 It is strongly discouraged to assign prefixes longer than a /56, so your choices are:

1. My recommendation and if you want a simple addressing plan, assign a /48 to each customer. This will work very well for customers coming from other ISPs, those that have their own ULA, or have been using transition mechanisms. This will also be easier when you have a mix of customers using the same infrastructure, whether they are residential customers, SMEs or even large corporates.
2. Differentiate among types of customers, even if this will increase the complexity of your network and those of your customers. Offer a /48 to business customers and a /56 for residential customers. As explained, this is not future proof and some new protocols will not work, so consider it carefully as it may mean that sooner or later you need to redo the plan and renumber.
3. A compromise could be to reserve a /48 for residential customers, but actually just assigning them the first /56.

5.3 There is a specific case for cellular phones, to be assigned a single /64 for each PDP context, but this is outside the scope of this document.

5.4 In order to facilitate troubleshooting and have a future-proof network, you should consider numbering the WAN links using GUAs (Global Unicast Addresses), using either the first /64 prefix out of the customer pool or a /64 from a dedicated pool of IPv6 prefixes. If you decide to use a /127 for each point-to-point link, it is advisable to allocate a /64 for each link and just use one /127 out of it.

5.5 Non-persistent prefixes are considered harmful in IPv6 as you can’t avoid issues that may be caused by simple customer power outages, so assigning persistent prefixes is a safer and simpler approach. Furthermore, this avoids the need for expensive logging, increases your chances to offer new business to customers, and decreases your customer churn.

This article is partially based on the work done at the RIPE BCOP WG (Best Current Operational Practice for operators: IPv6 prefix assignment for end-customers — persistent vs non-persistent, and what size to choose). For the complete document look at RIPE BCOP WG.

Jordi Palet Martínez has been working with computers, networking and technology since he was 8 years old. For the last 18 years, he has been CEO/CTO at “The IPv6 Company”, where he has devoted most of his time to IPv6 R&D, standardization, training and consultancy.