In the first part of this article, I described persistent and non-persistent prefixes. In this concluding part I will look at the choices for the numbering of WAN and customer LANs, and at customer assignment prefix sizes.
Numbering the WAN link
There are several possibilities for numbering the WAN link that interconnects the ISP network and the customer’s equipment (CPE). Let’s describe each one and understand the pros and cons.
- 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.
- 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 separate 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.
- Unnumbered
Instead of using a Global Unicast Address (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.
- 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 part one of this article 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:
a. The standard subnet size is /64.
b. 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).
c. 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:
- 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.
- 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.
- 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 article, 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 the 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:
a. 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.
b. 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.
c. 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, refer to RIPE BCOP WG.
Jordi Palet Martínez has been working with computers, networking and technology since he was eight 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.
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.
Jordi,
I have a few questions I’m hoping you may be able to answer for me. If you want to use a customer assignment scheme of assigning a /127 or /64 subnet to the customer WAN, then giving them a full /48 for them to assign to their routers / network, is there any way to get around having to add a static route pointing the customer /48 to the customer’s IP on the /127 or /64? This seems like a very cumbersome and unsustainable model. Also, with this scheme, how would that affect your ability to use prefix-delegation to hand out /64 subnets carved from the /48 to the inside interface(s) of the customer’s CPE router? For most commercial customers, I would expect them to be able to choose a /64 from their /48 and assign it to their router themselves. But for residential, both their LAN and WAN subnets would need to be assigned automatically.