IPv6 Address Planning in GavleNet

GavleNet (AS16117) has served its enterprise customers with native IPv6 for almost ten years, and deployed IPv6 to all remaining customers with 6RD (using DHCP option 212) for four years now.

One key difference between IPv6 and IPv4 is of course the vast amount of address space available. You don't have to fight against address exhaustion! Just take a little care on your address planning up-front. Here's how we did it.

Planning GavleNet's FTTH Address Space

GavleNet was allocated 2001:b48::/29 by RIPE NCC way back in early 2003. This allocation gives them up to 2³⁵ -- that's over 34 billion -- /64 networks to assign. They divide their space as described in this table:

As you can see, we use the first /32 for enterprise customers with static configurations, and we use half of the space for 6RD customers. For FTTH customers, we decided to use 2001:b49::/32, the first available /32 in our space.

We subdivide this /32 first into /44s for use by each switch, subdivided into /48s for each VLAN, subdivided further into a /56 for each customer. Let’s talk more about these decisions.

/32

GavleNet has a shared VLAN per IPv4 subnet and we wanted to use the same VLAN for IPv6. On the IPv4 side we have subnets sized from a /24 to a /27. In IPv6, we have enough space to be more consistent, and decided to allocate a /48 alongside each existing IPv4 subnet. Consistency like this is a huge win when it comes to managing, configuring, and debugging networks.

We didn't design this space to map between IPv4 and IPv6 -- there's no subset of bits that let you determine one from the other -- because we decided we didn't need it.

/44s and /48s

2001:b49::/32 provides 4,096 /44s in total. That's a lot. GavleNet's FTTH network is built almost exclusively with Cisco 4500 switches. We choose to assign a /44 to each Cisco 4500 as shown in this table:

We avoid using the zeroth address in a subnet, i.e. 2001:b49:0000::/44, because it can easily lead to misunderstandings: IPv6 text representations mean that the ":0000:" hextet might be compacted to "::", which may be confusing to network operators. Removing this one subnet leaves us with 4,095 subnets (0010 through fff0) available to allocate to Cisco 4500 switches.

Having allocated a /44 to each switch, we are then free to subdivide those subnets into /48s to be assigned to each VLAN. Let's take 2001:b49:0010::/44. In this case, we're comfortable using the zeroth subnet, so each /44 provides 16 /48s that can be used by our Cisco 4500s: 2001:b49:0010::/48 through 2001:b49:001f::/48.

/56

We decided to provide each customer a "static" /56, provisioned via DHCPv6-PD (Prefix Delegation) with option 37 (relay agent remote ID). Using a subnet of this size aligns with the best current operational practice recently published by RIPE NCC. Using a /56 for each customer means we have space for 256 customers per VLAN.

With a /56, each customer gets 256 /64 subnets, which is a big boost compared to one shared IPv4 address per customer. Note of course that a /64 is the standard subnet size IPv6: it is mandatory for stateless address autoconfiguration to work, and is also expected by all common implementations of privacy addressing and stable privacy addressing.

The assignment of the /56 to the customer is made by the KEA DHCP server, managed by GavleNet's provisioning system Netadmin and discussed in a follow-up article. 

Discussion

Voila! We have an addressing plan! Assigned this way, we have:

• A /29, from which we use a /32 for FTTH
• ... from which we have up to 4,095 /44s to assign to switches
• ... from each /44 we have sixteen /48s to assign to VLANs
• ... from each /48 we have 256 /56s to assign to customers
• ... from each /56, the customer has 256 networks to assign as they see fit!

There are many discussions on address planning for your organisation; in fact, people have written whole books on the topic. This article describes how we did it, but it's not the only way. As you can see, there's a lot of space to play with!

In the next RIPE Labs article, I will explain how we implemented the "static" DHCPv6 prefix delegation per subscriber port.