You are here: Home > Publications > RIPE Labs > Torbjorn Eklov > IPv6 Address Planning in GavleNet

IPv6 Address Planning in GavleNet

Torbjorn Eklov — 02 Nov 2017
About a year ago I started to discuss with GavleNet in Sweden about how they can best deploy native IPv6 for their fibre-to-the-home (FTTH) customers. GavleNet is a city network that operates in the municipalities of Gävle and Ockelbo. In this article, I discuss how we designed GavleNet's FTTH IPv6 address space.

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 235 -- that's over 34 billion -- /64 networks to assign. They divide their space as described in this table:

 2001:b48::/32   Enterprise with static addresses
 2001:b49::/32  DHCPv6 PD for FTTH
 2001:b4a::/32  Free
 2001:b4b::/32  Free
 2001:b4c::/32  Part of 2001:b4c::/30 for 6RD
 2001:b4d::/32  Part of 2001:b4c::/30 for 6RD
 2001:b4e::/32  Part of 2001:b4c::/30 for 6RD
 2001:b4f::/32  Part of 2001:b4c::/30 for 6RD


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.


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:

 The 1st Cisco 4500   2001:b49:0010::/44
 The 2nd Cisco 4500  2001:b49:0020::/44
 The 3rd Cisco 4500  2001:b49:0030::/44
 The 4th Cisco 4500  2001:b49:0040::/44


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.


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. 



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.


Thomas Schäfer says:
05 Nov, 2017 03:53 PM
Do you mean 6rd seriously?

We live in year 2017 and you are using a technique for lazy people.
Stephen Strowes says:
06 Nov, 2017 11:58 AM
Hi Thomas; we tend to take the view that reachability via an ISP-provisioned and managed transition mechanism is better than no reachability. Anything that brings more IPv6 to the internet is good.
Torbjorn Eklov says:
07 Nov, 2017 02:19 PM
Yes, and we deployed it for four years because we couldn't solve the first hop security for IPv6 then.
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.