IPv6 Subnet – Common Sizes to Split /29 to /32 Subnets

ip addressipv6subnet

As an LIR, you are getting a /29 to /32 network allocation by the RIPE, but I am a bit overwhelmed by the size of this subnet, and don't find a starting point to split this into common sizes.

What we need to address with this subnet:

office workstations
We currently have two offices in (yet) one country.

office IoT stuff
cameras, phones, tv's, other stuff

local office servers
Just a bunch of VM hosts and routes/switches

data centers
Currently we have servers in one datacenter.
There we are hosting several different services:

  • shared SaaS applications
  • dedicated servers for individual customers
  • shared web hosting
  • internal service
  • a bunch of routes

My problem is that I don't have a idea how big subnets I should assign to:

  • individual host
  • service group (like, workstations, or all hosts of specific product)
  • location
  • county

Best Answer

Some simple guidelines that work most of the time:

Dividing your /29

  • The standard size of your allocation from RIPE NCC is a /32
  • A /32 is a well-accepted prefix size in the global routing table
  • You can get a /29 just by asking for it
  • Conclusion: Get a /29 and start using the a /32, save the other /32s for when you deploy to other countries, continents etc.

Determining per-site prefix size

  • RIPE allows you to assign up to a /48 per site without having to explain anything. When you assign a shorter prefix (/47, /46 etc) you'll have to explain why you need more than a /48.
  • A /32 contains 65,536 /48s.
  • So no need to give a site anything smaller than a /48 (/49, /50 etc) either.
  • Conclusion: /48 per site

Determining LAN prefix size

  • The standards say to use a /64.
  • So in your addressing plan always align on /64s
  • Configuring a /127 on point-to-point links is common and can protect you against cache overflows, use x:y:z::a on one end and x:y:z::b on the other end for readability.
  • Reserve a /64 for router loopback addresses, anycasted services etc. I usually choose the first /64 from the /48 for this so the addresses are nice and short to write with :: notation. Configure /128 addresses from this /64 on loopback interfaces etc.
  • Don't even think about not using a /64 on a LAN or VLAN, things will break. If not today then very probably in the future.
  • Don't change your LAN/VLAN architecture yet, just assign /64s to each existing LAN/VLAN.

The remaining bits

  • There are still choices to be made:
    • How to use the bits on country-level between a /32 and a /48?
    • How to use the bits in a site between a /48 and a /64?
  • In both places you could just use random numbers between 0000 and ffff, but that would create a mess that is hard to understand and remember, so do something useful with those bits!
    • Always split at multiples of 4 bits (nibbles) so your addressing plan structure matches the hexadecimal notation of IPv6 addresses (each character in an IPv6 address represents 4 bits)
    • What to use those bits for depends on your organisation. You might divide the country-level /32 into /36 blocks and use a /36 per province. Or you use a /40 for some structure that is important to your organisational or infrastructure architecture. Or both.
    • The same for the /48:
      • Maybe you want to give a /52 to each building on the site and give a /56 to each floor in each building. That works well with prefix aggregation in your routing protocols.
      • Or maybe you want to assign a /52 or /56 to each security zone in your security architecture. That makes maintaining firewall policies and rules a lot easier!
    • Whatever you choose to do: keep a balance. Don't just start assigning from 0 up to ffff sequentially without giving any thought to how to organise those numbers, but also don't over-engineer it. If you want to put too much information in the prefixes (building + floor + security zone + function of the server + what brand of server it is + etc etc) then your addressing plan becomes impossible to work with.
  • Plug: I wrote a paper on this for SURFnet a couple of years ago. RIPE NCC has translated it to English: https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf