You are here: Home > Publications > RIPE Labs > Jordi Palet Martinez > Simplifying IPv6 Addressing for Customers - Part 2

Simplifying IPv6 Addressing for Customers - Part 2

Jordi Palet Martinez — 11 Jul 2017
One of the main issues when an ISP is planning to deliver IPv6 services is to decide how to address the customers. In this second part we describe choices for numbering the WAN and customer LANs.

This is a continuation of the study on IPv6 Addressing for Customers. Please also see Part 1 in which I describe the value of the IPv6 customer prefix "persistence". 

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.

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 RFC 6603 (Prefix Exclude Option for DHCPv6-based Prefix Delegation). However, because most of the IPv6 CPEs should follow RFC 7084 (Basic Requirements for IPv6 Customer Edge Routers), which already recommends supporting RFC 6603, it is expected that modern CPEs will work in this situation.

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

4. Unique Local Unicast Addresses (ULA)

Numbering the WAN link with IPv6 ULAs 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 a 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). RFC 6164 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 (RFC 6583).

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.

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:

  • The standard subnet size is /64.
  • 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).
  • 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:

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.

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.

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.

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:

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

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

7 Comments

Leo Vegoda says:
12 Jul, 2017 11:47 PM
This pair of articles is interesting and informative. It would be interesting to know what proportion of ISPs have chosen to assign subscribers a prefix longer than /48.

Is it practical to analyze the amount of space cut into /56s versus /48s (or other prefix lengths) using an analysis of "assignment-size:" attributes in inet6num objects in the RIPE Database?
Jordi Palet Martinez says:
13 Jul, 2017 11:24 AM
If you look at the figures of my survey (I will update it with more data I've got in the last months), 22% use /48, 35% /56, 33% /64 and 10% something else. Most of the /64 deployments are in LACNIC region and hopefully will move to /48.

If you look at my presentation at the Madrid RIPE meeting, you will find how it correlates to countries/regions.

Actual figures from the new survey responders in the latest months, show a higher trend towards /48, fortunately!

https://labs.ripe.net/[…]/results-of-the-ipv6-deployment-survey
Leo Vegoda says:
14 Jul, 2017 05:26 PM
I knew about the survey. The reason I asked about using the RIPE Database data is that the RIPE NCC now has over 10,000 members with IPv6 (https://labs.ripe.net/[…]/10-000-lirs-with-ipv6-resources). This is a very large number and the 368 survey responses from the RIPE NCC service region might not be representative.

I don't know what proportion of LIRs use the "assignment-size:" attribute. If it is widely used, it might be possible to get an even more representative measurement than the survey.
Jordi Palet Martinez says:
15 Jul, 2017 11:59 AM
Now I understood what you mean and indeed I agree, that will be very interesting. The question is that it will be necessary also to discriminate among those LIRs, which of them actually are doing IPv6 services, and other issues such as if they are really "ISPs" in the sense of provide connectivity to customer end-sites (instead for example big corporations being a LIR for their own infrastructure, or data centers, etc.).
Ross Chandler says:
15 Jul, 2017 07:13 PM
Another option for the customer delegated prefix assignment size policy is to accept requests for PDs between /64 and /48 inclusive and have a default PD size for when it isn't specified in the DHCPv6 client request.
Jordi Palet Martinez says:
15 Jul, 2017 07:47 PM
Agree, but this is not making easy for the ISPs to make the addressing plan ... unless they reserve by default, for example /48 to each customer.
Ross Chandler says:
20 Jul, 2017 09:40 PM
It might not be as hard for ISP as at first evaluation. I've gone through this. For example in the case of an ISP where most or all of their CPE routers are managed. The ISP knows what size delegated prefix the managed CPE will request. By default, if the CPE doesn't specify the assignment size requested the server will send the default size. The vast majority of CPE will be non-managed and request a non-default assignment. Only a small percentage of CPE request a larger prefix. As the CPE base does not change rapidly there is time to expand pools if required. I've got a /29. If I gave a /48 by default with the same simple pool design to all subs I'd need a /22. So there's complexity on the other side of this too as I'd have to change the pool design.
Add comment

You can add a comment by filling out the form below. Comments are moderated so they won't appear immediately. If you have a RIPE NCC Access account, we would like you to log in.