Dual Stack Network Design

Stephen Robinson
|
18 June 2022

Having decided I wanted to understand IPv6 in the ‘real world’ the design of my lab network seemed like a good place to begin. As most of my lab will be at home and I plan on using the lab (home) network to hold all my IoT devices amongst other hardware it seems sensible to go with a dual stack network design where IPv4 and IPv6 run in tandem. This will be especially useful when adding in consumer grade devices, some of which don’t handle IPv6 well.

Hardware

To start with it’s time to check the hardware in the homelab will support this dual stack network design, this mainly comes down the following components:

Routers & Firewalls
Switches
Network Interfaces

The last one on the list, Network Interfaces, is the easiest as any network card in the last 10-15 years has support for IPv6 the level the main differences between them being how much of this is offloaded to specific hardware on the network card and how much is handled by the host system. For my lab environment this shouldn’t be a problem as many of my networking cards are not that old and support some level of hardware offload for both IPv4 and IPv6.

Switches

As I am wanting to used managed switches across both L2 and L3 in my network the choice becomes a a little more difficult, especially at the price point I’m looking at. I’ve previously invested into both the Mikrotik and TP-Link Omada eco-systems and was ideally looking to stay within them, however, the price point of new hardware for both of these compared to used hardware on eBay from different eco-systems has meant I now have a combination of different providers. Thankfully all of these support both IPv4 and IPv6 at L2 and L3 allowing me to learn a lot about network segmentation and configuration.

In the lab I currently have the following switches and am waiting on delivery of a couple others to enable me to plug everything in.

TP-Link TL-SG3428X - 24x 1Gbe + 4x 10Gb
TP-Link TL-SG3428XMP - 24x 1Gbe PoE + 4x 10Gb
Mellanox SX-1016 - 64x 10Gb (Noctua fan replacement)
Mikrotik CSS-326-24G-2S+RM - 24x 1Gbe + 2x 10Gb
Brocade ICX6450-48P - 48x 1Gbe + 4x 10Gb (Awaiting delivery from eBay)

Routers & Firewalls

Prior to getting back in to the homelab I’ve been using a TP-Link ER-7206 as my primary router with some TP-Link EAPs for the wireless access points. Having stepped back in to the homelab a lot more this will now be replaced with something more configurable and having looking at the market I decided to go with the custom built router. Initially this was going to be a PF-Sense build but after looking at the configuration as code options for this I quickly realised that whilst it provided all the IPv4 and IPv6 features I needed the config as code features were very lacking. Given this I’ve ended up going with VyOS on the custom router which allows full config as code management via Ansible as well as APIs.

The router is a custom build with the following specs:

Chassis - Asus Rack Server RS200-E9-PS2
CPU - Intel E3-1240v5
Memory - 2x 8GB DDR4
Storage - 2x 500GB NVMe SSD
Networking
- 4x 1Gbe on-board - Intel X350
- 2x 10Gb SFP+ - Intel X520-DA2 PCIe card

Knowing that the hardware will support a dual stack network design the next decision on the list is which IP ranges to use for IPv4 and IPv6 so I can get started configuring the network.

Prefix Allocation

As the world running out of IPv4 addresses the only sensible choice for the home lab environment is to choose a range from RFC1918, address allocation for private internets and NAT gateways to access the internet. RFC 1918 defines the following 3 blocks for private internets / networks leaving the choice up to the network administrator of which is most appropriate.

 10.0.0.0        -   10.255.255.255  (10/8 prefix)
 172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
 192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

In my current network I have been using the ‘172.20/16’ prefix and whilst this has worked well it overlaps with an IP range the company I work for uses for one of our AWS VPCs. This causes me a few problems when I connect to the work VPNs and then trying to access local services. Whilst the easy solution is to choose another prefix/range to use this becomes a slight challenge when the company I work for has services in all 3 blocks due to a mix of legacy networks, EC2 Classic networking and new VPC network design.

With all this in mind I decided to base my network in the 10/8 prefix as this is used by our services in EC2 Classic which has been deprecated and is end-of-life in August 2022 so after this date will not be in use by our VPC networks in AWS.

On the other hand IPv6 does not really have the concept of private address ranges as all IPv6 addresses are designed to publicly routable. With this in mind I wanted to get hold of a fixed IPv6 range I could use for my home/lab network that wouldn’t change if I switched internet providers. Thankfully when I requested my own ASN, hopefully I’ll write about this soon, a prerequisite was that I had an IPv6 or IPv4 resource, to fulfil this my sponsoring LIR provided a /44 PA (provider assigned) range from their own block. At this time I also learned about route48 who offer free tunnel broker services for IPv6 as well as IPv6 address allocation.

So as to keep my networks separate and easy to manage I decided to signup for the Route48 service and request a couple of /44 IPv6 blocks to use for my physical lab and cloud lab alongside my homelab tutorials, see my follow up post on Route48 Address Allocation to request your own range.

Basic Address Plan

Having decided on the private range for IPv4 and the public IPv6 range I’d be using, it’s time to give some thought to how these will be broken down and the addresses used for different purposes. As I was going to be using VLANs to segment my network into different zones it makes sense for these to be represented somehow in the address plan. Depending on the use case for your network and the hardware linking it, the way you break down your overall IP blocks and separate them out can change. Primarily this is whether you are doing purely routing with the address ranges or will be doing firewall based rules as well.

As these ranges will be used within the HomeLab and Cloud Lab environments there will be some elements of both pure routing and firewall based rules, to keep the firewall rule aggregation simple this is reflected in how the blocks are broken down.

To keep this post short I won’t go into too much detail on how I ended up with the blocks I mention below for the IPv4 and IPv6 networks but don’t worry I have two upcoming posts on how to break down the root block into manageable chunks that I you allocate to both local and cloud networks.

IPv4 - 10.0.0.0/8

Following my own network address plan I ended up with the 10.128.0.0/14 block allocated to my ‘Home’ environment this includes my standard home network alongside the lab and any other uses I have.

IPv6 - 2a06:a005:c90::/44

Note: Throughout my posts on IPv6 you’ll see my reference this subnet range whilst this is not the reserved range for documentation (2001:db8::/32) it will allow examples to be configured and demonstrated in the real world.

Note: This is not the range I actually use in my ‘production’ lab environment and I requested the allocation purely for the purposes of homelab.gdn and learning IPv6.

Breaking down the /44 subnet into manageable network chunks was done, in part, by following the Preparing an IPv6 Address Plan by SURFNet which is a really useful and practical guide of how to organise your IPv6 network and some useful tips to follow. Following the IPv6 network address planning I ended up with the 2a06:a005:c92::/48 block for my homelab environment.

Having put all this hardware together and given thought to the address planning I should be looking at a good start with the dual-stack network design being able to support IPv4 and IPv6 at the same time with the same hardware and features available to me. Look out for more content as I progress further with my IPv4 and IPv6 homelab setup.