Often I find people are hesitant to implement IPv6 because they are intimidated by the subnet planning process and therefore find it hard to get started. In this post, I will attempt to identify some different approaches to address planning, and when it’s best to use them, as well as some best practices for allocating networks.
First off, “… to reduce the likelihood of conflict and confusion when relating documented examples to deployed systems, an IPv6 unicast address prefix is reserved for use in examples in RFCs, books, documentation, and the like. Since site-local and link-local unicast addresses have special meaning in IPv6, these addresses cannot be used in many example situations.” See RFC 3849 for further details. Following this RFC, we will be utilizing space within the 2001:DB8::/32 for this example.
Most small sites will be able to easily obtain a /48 IPv6 network from their regional registry or a tunnel broker such as Hurricane Electric. In this example we’ll be using 2001:DB8:1::/48 as our base supernet. When subnetting IPv6 address blocks, it’s best to do on the 4-bit (nibble) boundaries as it makes it easier for a human to identify, plus many router’s ASICs are optimized to forward traffic this way. Generally speaking, each VLAN should be assigned a /64 allocation. This allows for StateLess Auto-Address Configuration (SLAAC) to automatically assign addresses and to advertise available routers on the network without the use of DHCPv6. As your network grows, your VLAN will never run out of addresses again, ever. Traditionally IPv4 point-to-point links would utilize a /30 or /31 IPv4 subnet to make more efficient use of the space. In IPv6 land, conservation is not needed. Point-to-points should have an entire /64 allocated, but be configured with a /126 or /127 mask for good measure. This prevents SLAAC from accidentally occurring. There are many debates and opinions on this matter but within the IPv6 community, the above is generally agreed upon as best practice.
Depending on the site’s size and requirements, there are two main ways to develop an addressing plan:
- Routing table optimized: Utilizes routing summarization to decrease the size of the routing table
- Access list optimized: Allocates blocks to individual groups/departments regardless of their logical location on the network
Let’s cover both of these methods with practical examples. Suppose we have a campus with approximately 50-100 buildings that is broken up into several distinct areas separated by layer 3 boundaries. Each area has 50-100 individual VLANs that may or may not span between buildings within that region. Each area shares the same 3-digit VLAN IDs, even though they are separated by Layer 3, which allows for easier policy enforcement for network access. This example assumes a mobile or disperse working environment, where a department may be staffed from various locations/buildings around the campus.
Routing Optimized
First we’ll look at the routing table optimized plan. Our allocated block of 2001:db8:1::/48 can be subnetted into 16 x /52 subnets, each of which can have 4,096 x /64 networks. This design allows for plenty of growth with up to 16 regions, while also making the addresses easier to identify by embedding the region number along with the VLAN ID into the address. If you are using 4-digit VLANs, you’ll likely have a much larger network, in which case, a /48 may not be enough. If this is a requirement, get a /32 and then use 16 bits of the address to embed your 4-digit base-10 VLAN ID. Below is a sample plan for our 4-region network:
| Region | VLAN | IPv6 |
| North Area | 2001:DB8:1:1000::/52 | |
| loopbacks | 2001:DB8:1:1000::/64 | |
| 101 | 2001:DB8:1:1101::/64 | |
| 102 | 2001:DB8:1:102::/64 | |
| 103 | 2001:DB8:1:1103::/64 | |
| … | … | |
| 999 | 2001:DB8:1:1999::/64 | |
| South Area | 2001:DB8:1:2000::/52 | |
| loopbacks | 2001:DB8:1:2000::/64 | |
| 101 | 2001:DB8:1:2101::/64 | |
| 102 | 2001:DB8:1:2102::/64 | |
| 103 | 2001:DB8:1:2103::/64 | |
| … | ||
| 999 | 2001:DB8:1:2999::/64 | |
| East Area | 2001:DB8:1:3000::/52 | |
| loopbacks | 2001:DB8:1:3000::/64 | |
| 101 | 2001:DB8:1:3101::/64 | |
| 102 | 2001:DB8:1:3102::/64 | |
| 103 | 2001:DB8:1:3103::/64 | |
| … | ||
| 999 | 2001:DB8:1:3999::/64 | |
| West Area | 2001:DB8:1:4000::/52 | |
| loopbacks | 2001:DB8:1:4000::/64 | |
| 101 | 2001:DB8:1:4101::/64 | |
| 102 | 2001:DB8:1:4102::/64 | |
| 103 | 2001:DB8:1:4103::/64 | |
| … | ||
| 999 | 2001:DB8:1:4999::/64 |
ACL Optimized
Using the same campus scenario, we can build a plan that optimizes address allocation for Access Control Lists (ACLs) simplification. This has the drawback of dramatically increasing the size of the routing table; however, we can greatly reduce the potential number of firewall policies by assigning blocks to an individual department. Our allocated block of 2001:db8:1::/48 can be subnetted into 4,096 x /60 subnets, each of which can have 16 x /64 networks. This allows each group or department to have a /60 dedicated to them, so firewall policies can be more easily built permitting/denying interdepartmental traffic. Again, we are also making the addresses easier to identify by embedding the region number along with the VLAN ID into the address, only in a different order. Up to 16 different regions/areas could be allocated for each group/department, allowing this method to scale well passed our 4-region environment.
| Department | VLAN | Region | IPv6 |
| 1 | 2001:db8:1:1010::/60 | ||
| 101 | North | 2001:db8:1:1011::/64 | |
| 101 | South | 2001:db8:1:1012::/64 | |
| 101 | East | 2001:db8:1:1013::/64 | |
| 101 | West | 2001:db8:1:1014::/64 | |
| 2 | 2001:db8:1:1020::/60 | ||
| 102 | North | 2001:db8:1:1021::/64 | |
| 102 | South | 2001:db8:1:1022::/64 | |
| 102 | East | 2001:db8:1:1023::/64 | |
| 102 | West | 2001:db8:1:1024::/64 | |
| 3 | 2001:db8:1:1030::/60 | ||
| 103 | North | 2001:db8:1:1031::/64 | |
| 103 | South | 2001:db8:1:1032::/64 | |
| 103 | East | 2001:db8:1:1033::/64 | |
| 103 | West | 2001:db8:1:1034::/64 | |
| … | |||
| 199 | 2001:db8:1:1990::/60 | ||
| 199 | North | 2001:db8:1:1991::/64 | |
| 199 | South | 2001:db8:1:1992::/64 | |
| 199 | East | 2001:db8:1:1993::/64 | |
| 199 | West | 2001:db8:1:1994::/64 |
Infrastructure
Let’s not forget, all of your network infrastructure will also require allocations for loopbacks, point-to-points, and management. I like to block off the first and last bunch of networks in each major allocation for this purpose. You may have noticed, with our 2001:db8:1::/48, that we didn’t start using the first available addresses.
Documentation
You know, that thing everyone wants but nobody does? I still see people using spreadsheets to keep track of address allocations. Even something is better than nothing in this case; however, the open source software phpIPAM is an excellent address management tool and is very customizable to your environment. It take a lot of the guess work out of subnetting and gives you a clearer picture on how your allocations are structured.
Summary
While every network has its own individual business requirements, either method of designing an IPv6 addressing plan can be leveraged to get you started. Hopefully you’ll be able to find this information useful in planning your IPv6 deployment!
Eric's Blog 