How to Create a Scalable IPv6 Infrastructure for Testing Purposes

Although IPv6 deployment is being rolled out slowly, it is still broadly increasing. This means that demand for testing various services and apps that run over IPv6 networks will keep on increasing as well. The range of real-world scenarios is also getting wider – clients switching from mobile to Wi-Fi networks, from IPv4 to IPv6, to dual-stack, IPv6 only, NAT64, etc., therefore to test these scenarios a proper testing infrastructure is required. And in case you have multiple remote locations, maintaining such infrastructure can be quite a complex task.

This article will walk you through the process of how to plan and set up an IPv6 infrastructure in order to provide your test devices with IPv6 connectivity. The goal of the article is to create an IPv6 infrastructure that is capable of scaling over multiple remote sites with the least resource overhead, though these approaches can also be applied for single-site infrastructure when no scaling is necessary.

Afterwards you will be able to cover the following test scenarios:

• Dual-Stack (IPv4+IPv6) network
• IPv6 only network
• NAT64 network (Accessing IPv4 addresses over IPv6 only network)

Requirements

Things you will need:

• A router running RouterOS (Physical Mikrotik router or CHR). You could achieve this setup with other routers as well, but commands in this article are provided for RouterOS.
• OpenWRT router (only if NAT64 testing is necessary).
• Remote sites must be reachable over site-to-site VPN (tested over L2TP/IPSec tunnel).
• Basic IPv6 knowledge is highly recommended since IPv6 networking will not be explained in depth.

Planning your infrastructure

The first step is to plan out your infrastructure. Our demo infrastructure has one central site (A) which will have IPv6 connectivity via a tunnel broker, and two remote sites (B, C), that are connected together with L2TP/IPSec tunnel (others should work as long as they can pass 6to4 protocol traffic). The following systems will be used:

• OpenWRT – running inside ESXi Virtual Machine on Site A (NAT64 gateway).
• Mikrotik hAP ac – gateways on all sites
• Mikrotik hAP ac lite – wireless routers with various test configurations for test devices

Our final demo infrastructure will look like this:

This approach reduces hardware and configuration overhead since we only need a single NAT64 gateway and a single IPv6 edge router. Then we utilize a site-to-site VPN connection to route IPv6 traffic via 6to4 protocol to and from remote sites. This is very convenient when remote sites don’t have native IPv6 connectivity and on-site hardware. Basically, we will be creating our own Tunnel Broker service to distribute IPv6 networks on our intranet over IPv4 links. Using hAP ac routers on site provide testers with advanced features such as filtering specific traffic, simulating DNS spoofing, limiting bandwidth, capturing traffic from mobile devices, and a lot more.

On the other hand, if you do have native IPv6 connectivity with routed subnet at each remote site and NAT64 isn’t a necessity, then it is completely reasonable to use a decentralized approach and deploy NAT64 gateway only on necessary sites.

Obtaining IPv6 connectivity

There are numerous ways to achieve IPv6 connectivity, but only a few of them are suitable for our purpose. That’s why we will evaluate only two options – native IPv6 and tunnel broker.

For best performance, it’s recommended to use a native IPv6 connection provided by your ISP. If you are not sure whether your ISP provides an IPv6 connection, you need to contact them and ask. Usually by default ISPs provide just a single /64 pool via SLAAC, which isn’t sufficient, since we need one pool for the WAN interface and at least another one for test devices. Depending on your planned infrastructure you will need to request a routed subnet. If you need only one configuration at the time (single router), then one /64 subnet would be sufficient. But in most cases, if you want to have multiple access points and site configurations then a larger subnet will be needed (e.g. /48 or /56). Since IPv6 address space is significantly larger than IPv4, it should not be a problem for ISP to allocate at least /56 subnet. After ISP completes the configuration on their side they will provide network addresses for you to use.

An alternative option is to use the Tunnel Broker service, which routes IPv6 traffic over the IPv4 tunnel through the tunnel broker service provider network (similar to how the proxy works). This is a viable solution for a Lab environment setup or when your ISP cannot provide a routed IPv6 network. The downside of using Tunnel Broker is that all IPv6 traffic is being routed through 3rd party servers. If you consider this option, you should keep in mind that it might affect latency as well as throughput; also you can run into setup issues if your router is behind NAT. In our demo, we will be using this approach.

Another “hybrid” approach would be to set up the required network infrastructure on a cloud provider that supports IPv6 connectivity and then tunnel that traffic to your network via an IPv4 tunnel.

Setting up a tunnel broker account

You can safely skip this section if you do have native IPv6 from your ISP.

We will be using Hurricane Electric Tunnel broker, which is free of charge. Hurricane Electric provides a single routed /64 subnet by default, and an additional /48 subnet if needed. First, you will need to register a free account at tunnelbroker.net. There is a limitation that you can set up only one tunnel per IPv4 endpoint and 5 total tunnels per account. After registering an account go to “Create Regular Tunnel”, enter your public IP address shown and choose the closest server to your location. After creating a tunnel you can set Description to something meaningful. Then you can go to the “Example Configurations” tab and choose “Mikrotik” from the dropdown where you will find a working configuration to establish IPv6 networking with tunnel broker. You can paste this configuration directly into the router’s CLI. In case your router is behind NAT, make sure to unset the “local-address” parameter, otherwise, the connection will not establish.

Planning the address layout

After configuration on ISP or tunnel broker’s side is done, you will be provided with IPv6 configuration details, for example:

• 2001:470:1:24::1 – ISP endpoint
• 2001:470:1:24::2 – Your endpoint
• 2600:70ff:b068::/48 – Routed subnet

The next step is to divide the provided routed subnet into smaller chunks. Subnetting /48 is quite easy without any additional tools. If you need to divide smaller subnets like /56 or you are not very familiar with IPv6 subnetting, I would suggest using tools like IPv6 subnet calculator to verify or calculate subnets for you. In the following example, the main idea with /48 subnet is that the next block after the prefix must be unique for each endpoint pair and each subnet, so we use the site/device index as a unique identifier. For endpoint addresses, we just prepend “1” before the identifier.

Sample subnet layout for our demo infrastructure:

For the sake of simplicity, we are using only /64 networks both for endpoint addresses and subnets. Your layout will highly depend on the type of your infrastructure and routed subnet size. This specific layout is intended for multiple devices within multiple sites’ infrastructure. I recommend keeping such a table in your documentation so it’s way easier to maintain your network. This approach makes it easier to visually understand which site the address belongs to. But for dynamic environments, a more appropriate solution might be just to use incremental numbers as a unique ID, without involving site ID.

Configuring the main router

Before moving forward we assume that the router is already preconfigured with a working Internet connection, basic IPv4 firewall, etc. Also, make sure the IPv6 package is enabled.

To setup IPv6 connection on Mikrotik router, simply assign your IPv6 address to WAN interface and add default route via ISP endpoint address:

/ipv6 address add address=2001:470:1:24::2/64 advertise=no interface=ether1-wlan
/ipv6 route add distance=1 gateway=2001:470:1:24::1

In the case of tunnel brokers just use the provided example configuration which will have an additional 6to4 interface configuration. Also, verify in your IPv4 firewall that traffic from a remote tunnel endpoint is being accepted on the input chain and add accept rule if necessary:

/ip firewall filter add action=accept chain=input log-prefix="HE 6to4 Tunnel" src-address=xx.xx.xx.xx

To verify that the IPv6 connection works, you should now be able to ping the Google DNS server:

/ping 2001:4860:4860::8888

If you get no response from the server, double-check your configuration. You need to fix this issue first before proceeding further.

Configuring remote sites

The principle of the 6to4 tunnel in Mikrotik is quite simple. First, you create 6to4 tunnel interfaces on both sides with appropriate local and remote IPv4 addresses. Then assign IPv6 addresses within the same subnet on both interfaces. Now both sides should be able to ping each other over the IPv6 network. The remaining part is to configure routes and add IP addresses within the client’s subnet to the client’s bridge interface with the “advertise” option enabled so that the test devices receive IPv6 configuration through SLAAC.

Example configuration for device router_b1:

On main router:

/interface 6to4 add !keepalive local-address=10.1.0.1 name=ipv6-b1 remote-address=10.2.0.10
/ipv6 address add address=2600:70ff:b068:1b1::1 interface=ipv6-b1
/ipv6 route add distance=1 dst-address=2600:70ff:b068:b1::/64 gateway=2600:70ff:b068:1b1::2

On router_b1:

/interface 6to4 add !keepalive local-address=10.2.0.10 name=ipv6-b1 remote-address=10.0.2.2
/ipv6 address add address=2600:70ff:b068:1b1::2 interface=ipv6-b1
/ipv6 address add address=2600:70ff:b068:b1::1/64 advertise=yes interface=bridge
/ipv6 route add distance=1 dst-address=::/0 gateway=2600:70ff:b068:b1::1

Repeat the same procedure for the remaining devices.

Setting up NAT64 gateway

In order to simulate a NAT64 environment, we need to set up a NAT64 gateway. The easiest way to achieve that is to install a tayga package on OpenWRT OS. We are running OpenWRT inside the ESXi virtual machine but it can also be run on Proxmox VE, Raspberry Pi, real router, etc. You could also try to install Tayga software on any other Linux-based OS if necessary.

For OpenWRT Install tayga package, add nat64 interface to LAN zone and reboot router:

dpkg install tayga;
uci set firewall.@zone[0].network='lan nat64';
uci commit firewall;
Reboot;

After reboot, you should be able to see a tayga-nat64 interface when issuing the “ifconfig“ command.

Add nat64 route on your main router:

/ipv6 route add comment="nat64 route" distance=1 dst-address=64:ff9b::/96 gateway=2600:70ff:b068::64:64

Verify NAT64 connectivity from client:

ping6 64:ff9b::8.8.8.8 -c1

Receiving PING doesn’t guarantee that the connection works. It is possible that there is a firewall in between that is allowing ICMP packets but dropping everything else. To verify network connectivity use WGET or a similar tool to fetch HTTP response code.

/tool fetch url=http://64:ff9b::1.1.1.1/

You should get a response <403 Forbidden> if it’s working correctly. Otherwise you might see <connection error>, which likely means that the Firewall is dropping traffic. Add firewall rules before drop everything else coming from WAN rule:

/ipv6 firewall filter add action=accept chain=forward comment="Allow NAT64 forwarding" dst-address=64:ff9b::/96 src-address=2a02:16d8:105:100::/56 
/ipv6 firewall filter add action=accept chain=forward comment="Allow NAT64 traffic from owned subnet" src-address=2a02:16d8:105:100::/56

Now in order to use NAT64, you need to change the DNS server address that is provided to the clients. We are using Google Public DNS64 so there is no need to set up our own DNS64 server.

Changing configuration

After you have finished all the previous setup procedures you can now switch these configurations around.

• Dual stack: Default configuration when you enable add IPv6 connectivity on top of IPv4.
• IPv6 Only: Same as Dual stack, except IPv4 is disabled either by disabling DHCPv4 server (recommended) or blocking clients IPv4 traffic with Firewall.
• NAT64: Same as IPv6 Only, except DNS server is set to DNS64 and additional NAT64 route is enabled that forwards NAT64 traffic through NAT64 gateway.

Changing configuration on the fly (while clients are connected) is not recommended, as this normally doesn’t occur in the real world. A better solution is to reconnect clients after switching configuration or having multiple routers with different configurations, therefore simulating handover from one network to another. It’s also possible to set up multiple VLANs and SSIDs for each configuration on a single Mikrotik router so you can provide it as a plug-and-play appliance tool for your testers without needing to teach them how to change configurations, but it requires a more sophisticated setup.

Verifying IPv6 connectivity

Last but not least is to verify that your configuration actually is working as expected. This can be done by:

1. Manually checking assigned addresses on the device and doing ping/curl requests
2. Using online tools like ipv6-test.com or test-ipv6.com
3. Using an up to date IPv6 Fragmentation checker to verify that there are no major issues with MTU

Known issues

• On rare occasions, some 6to4 tunnels might go down. The solution is simply to disable and enable the interface on one or both sides. It’s recommended to set up external monitoring for your IPv6 endpoints (we use cloud-hosted Zabbix) to react faster. RouterOS also has a Netwatch tool, that can monitor connectivity and execute scripts to restart interfaces when necessary.
• If you are using multiple VPN links between sites for redundancy, in case of primary link failover your IPv6 tunnels might stop working, since the 6to4 interface local-address is fixed to a specific link. One solution is to set a remote-address to a bridge interface address not VPN link endpoints, but this might not work on other tunnel types than L2TP.
• If a Windows device is not getting IPv6 configuration while other platforms work as expected, try to disable and enable the network adapter, it usually fixes the issue.

Summary

Hopefully, this article explained the main principles well enough to implement them on your own or gave some new ideas on how to improve your testing environment for IPv6 networking.