IPv6 removes the scarcity that shapes IPv4 hosting, but replaces it with design decisions that are hard to undo: how much to give each customer, how to deliver it and how to keep your own announcements tidy. This article covers prefix sizes, per-customer assignment, registration, reverse DNS delegation and an addressing plan that stays aggregatable as you grow. It describes principles rather than policy text, so check the current RIPE NCC IPv6 policy before you finalise your plan.
Choosing between /48, /56 and /64
The RIPE IPv6 policy leaves the size of an end-site assignment to the LIR, with a /64 as the minimum where only one subnet is expected. Within that, the right choice depends on what the customer runs.
| Assignment | Typical hosting use | Notes |
|---|---|---|
| /64 | A single VPS or a server on one network | Effectively unlimited addresses but one subnet; SLAAC assumes a /64 per link |
| /56 | Dedicated servers, private cloud tenants, customers with containers or several internal networks | 256 /64 subnets for VMs and segmentation |
| /48 | Colocation, enterprise and multi-site customers, or those running their own routing | 65,536 /64 subnets; the usual size for a business site |
Do not assign prefixes longer than /64 to customers; they break SLAAC and surprise customers who expect standard behaviour. If you hesitate between two sizes, choose the larger. A /32 already contains 65,536 /48s, so address space is rarely the constraint, while renumbering a customer later is costly for both sides.
Assigning more than a /48 to a single end site requires documented justification under RIPE policy, so treat those cases as exceptions and check the current procedure first.
Assign per customer, not per shared segment
Give each customer its own prefix rather than handing out individual addresses from a shared /64. Per-customer assignment keeps abuse handling, reverse DNS, filtering and billing clean: a prefix points to exactly one customer, and blocking or null-routing it does not affect anyone else.
How you deliver the prefix matters too:
- On-link /64: simplest for a single VPS, configured directly on the customer’s interface. On shared segments, set neighbour discovery limits and first-hop security so scans of a large on-link prefix cannot exhaust the router’s neighbour cache.
- Routed prefix: for /56 and /48 assignments, route the prefix to the customer’s link address, over a small transfer network or a link-local next hop. The router then holds one route per customer instead of a neighbour entry per address.
- Prefix delegation: DHCPv6 prefix delegation can automate routed assignments on platforms with many customers.
Registering assignments in the RIPE Database
Assignments made from your allocation must be registered in the RIPE Database. The policy lets you register individual inet6num objects with status ASSIGNED, or group many same-sized assignments under one object with status AGGREGATED-BY-LIR and an assignment-size attribute.
For hosting, a practical pattern is one AGGREGATED-BY-LIR object per pool of /64 or /56 customer assignments, with separate ASSIGNED objects for larger customers. Check the current policy for when an assignment must be registered on its own, and keep abuse contacts accurate so complaints reach the team that can act on them.
Delegating reverse DNS
Reverse DNS for IPv6 lives under ip6.arpa, with one label per nibble (four bits). The RIPE NCC delegates the reverse zone for your allocation once you create the relevant domain objects and your name servers pass its checks. From there, delegation to customers is up to you.
The /48, /56 and /64 sizes all fall on nibble boundaries, which keeps delegation simple:
- A /48 is a zone 12 nibbles deep; for 2001:db8:1234::/48 it is 4.3.2.1.8.b.d.0.1.0.0.2.ip6.arpa.
- A /56 is 14 nibbles deep and a /64 is 16.
- Customers running their own name servers get an NS delegation for their zone; others can manage PTR records through your control panel.
Avoid non-nibble sizes such as /50 or /62 unless you have a strong reason, because each would need several reverse zones. Create PTR records for specific hosts or generate them on demand; populating every address in a /64 is neither possible nor useful.
Planning so allocations stay aggregatable
Your allocation should reach the internet as few, stable announcements as possible. That requires a hierarchical plan before the first customer is assigned.
- Split by location first: give each data centre or region a block, such as a /36 or /40, so each site can be announced or summarised on its own if needed.
- Then by service type: within each site, reserve separate pools for /64, /56 and /48 assignments.
- Leave room to grow: keep space next to each pool free, so a growing pool expands into contiguous space rather than a new, disconnected block.
- Keep infrastructure apart: loopbacks, link networks and management addressing get their own block, which simplifies filtering.
- Track everything in IPAM: the plan only works if every assignment is recorded and the RIPE Database matches it.
Announce your aggregate, and add more-specifics only where you need them for traffic engineering. Many networks filter IPv6 announcements longer than /48, so do not expect anything smaller to be routed globally.
Under current policy an LIR can receive an initial allocation from a /32 up to a /29 without supplying additional information, which suits a multi-site plan. Confirm the current thresholds before you build around them.
How TACS can help
As a RIPE NCC member, TACS can help you obtain an IPv6 allocation, design an aggregatable plan and set up database objects and reverse DNS delegation; see our IPv6 page. For customers who need portable space of their own, our LIR services include sponsoring provider-independent assignments.