WISP Design – An overview of adding IPv6 to your WISP

The challenge of adding IPv6 to your WISP

IPv6 is one of those technologies that can feel pretty overwhelming, but it doesn’t have to be. Many of the same ideas and concepts learned in IPv4 networking still apply.

This guide is meant to give you an overview of an example IPv6 addressing plan for an entire WISP as well as the config needed in MikroTik to deploy IPv6 from a core router all the way to a subscriber device.


Benefits of adding IPv6

  • Public addressing for all subscribers – reduced need for NAT
  • Regulatory compliance – public addressing that is persistent makes it much easier to be compliant for things like CALEA
  • Reduced complaints from gamers – Xbox and Playstation both have IPv6 networks and prefer IPv6. This reduces complaints from customers who have gaming consoles that have detected an “improper” NAT configuration.
  • Increased security – IPv6, while not impervious to security threats makes it much harder for attackers to scan IPs due to the sheer size of the IP space. If using privacy extensions with SLAAC, it also makes it much harder to target someone online as the IP address seen on the internet changes randomly.
  • Improved real time communications – one way audio and video issues are often caused by NAT. Using end to end connectivity on public addressing improves the reliability of IP voice and video when used on IPv6
  • Web scale content (Netflix, Facebook, Google, etc) is IPv6 enabled which means a large portion of your traffic will shift to native IPv6 once dual stack is enabled.


IPv6 Addressing

One of the things i’ve learned about IPv6 is that addressing plans seem to spark epic debates about the waste of addresses and what size prefix an end subscriber should get.

Although this lab could have easily been done with a /56 at the tower and /53 at each AP, I decided to use RIPEs recommendations from their guide on IPv6 best operational practices.

This is mainly to keep the focus of the article on actually getting IPv6 deployed and not focusing on the addressing.


Dual Stack

For simplicity, the IPv4 config is not shown, but the recommended design for an operational WISP is to implement IPv4 and IPv6 side by side in a Dual Stack configuration.


Lab Overview

The lab is designed to illustrate most of the operational aspects of IPv6 in a WISP using MikroTik CHR routers in EVE-NG. This includes:

  • DHCPv6 and Prefix Delegation (PD)
  • OSPFv3 single area configuration and origination of a default route
  • Subscriber router example with SLAAC

Core Router



In the lab, the core router is shown directly connected to the tower for simplicity, in your WISP, there may be multiple towers between the core and the end of the network.

The concept, however is the same – use /126 addressing to connect towers for OSPFv3.

Note that OSPFv3 still requires a router-id in dotted decimal format, even though the address you put int doesn’t have to actually exist – for consistency however, use the IPv4 loopback of the router for the router id.

The internet connectivity isn’t shown in this lab, but your ISP will give you a /126 address to connect to your border router and either peer with BGP or the provider can route the /32 prefix to you.



Tower Router



The tower router is handling most of the work as it is responsible for DHCPv6 and Prefix Delegation as well as advertising the /48 AP subnets into OSPF

In this lab , the APs are split into separate VLANs (with dual stack, IPv4 would exist on the same VLAN).

The router is configured to hand out /56 prefixes to the end subscriber using a pool of /48 per AP.

Because Prefix Delegation is being utilized, a dynamic static route is created for each /56 the DHCPv6 server hands out which eliminates the need to use a routing protocol.

Prefix Delegation in action

This example shows the prefixes allocated by the router and the dynamic static routes created


Subscriber Routers


For simplicity, MikroTik is used as the Subscriber or CPE router to provide an example of how the /56 prefix is received from the tower router and handed off to devices inside the subscriber’s home.

In this lab, the “WAN” interface or ether1 has a DHCPv6 client configured to receive the prefix from the tower router.

Ether2 or the “LAN” side, which would include a bridge of the the wireless/wired interfaces in a real router is configured with a dynamic /64 from the /56 pool and is set for SLAAC to give devices on this segment an IPv6 address.


DHCPv6 client and subscriber addresses/routes


Config – Subscriber 1

Config – Subscriber 2


Subscriber Device

EVE-NG has a small Linux image that can be used as a host called VPC or virtual PC. This allows us to put a device on ether2 and test end to end reachability back to the core router.

SLAAC addressing example

Ping test back to the core router



Let IPA help you with your IPv6 transition

The team at IP ArchiTechs has decades of experience in networking and specializes in WISP design, troubleshooting and operation. Click on the graphic below to contact IP ArchiTechs and get help with your networking problems.

MikroTik ISP Design: Building an 802.1q trunk between sites using VPLS and S-tag

Use Case

ISPs that use MikroTik are always looking for new ways to deliver services to customers and expand their offerings. Delivering Layer 2 at scale for customers is a design challenge that comes up frequently.

While it’s easy enough to build a VLAN nested inside of another VLAN  (see below), this requires you to build all of the VLANs a customer wants to use into the PE router or handoff switch.

However, if you have a client that needs a layer 2 service delivered to two or more points and wants to be able to treat it just like an 802.1q trunk and add VLANs in an ad-hoc way, then using the S-Tag feature in RouterOS along with VPLS transport is a great option.

What’s the S-tag do???


Clients will often ask me “what’s the S-Tag check box for?”

So a little background on this, there is a protocol for using outer and inner VLAN tags specified in IEEE 802.1ad that uses Service Tag (or S-Tag) to denote the outer VLAN tag used to transport Customer Tags (or C-Tags).

What makes the S-Tag/C-Tag a little bit different is that it actually changes the ethertype of the Frame.

802.1q (Normal VLAN Tags) 0x8100
802.1ad (S-tag) 0x88a8

Here is an overview of the frame format of each and links to the Metro Ethernet Forum Wiki for more info.






Lab Scenario

Here is a very common example of a deployment for a Layer 2 service to an end customer that rides on top of the ISP MPLS core.

In this lab we are using Cisco switches trunked to each other using VLAN 101 and 201 over a VPLS pseudowire with an S-Tag of 777.

s-tag lab

After configuring the P routers, PE routers and Cisco switches, let’s take a look at the Cisco switch and see if we can ping the SVI on the other switch on both trunked VLANs.

Here are the subnets used on the customer side:

Switch-1 subnets

Now let’s ping the .2 address for each VLAN on Switch-2

VLAN 101


VLAN 201


Notes on MTU

A note on MTU sizing, in order to hand off a 1500 byte packet with VPLS, you normally need an MPLS and L2MTU of 1530 bytes. In order to pass a second VLAN tag you’ll want to make sure your network equipment can go up to 1534 for Layer 2 and MPLS MTUs to pass 1500 byte packet with S-Tag.

Configs for the lab

In the section below, here are all the configs for this deployment

Cisco Switch-1

Cisco Switch-2

MikroTik PE-1

MikroTik PE-2

MikroTik P-CORE-1

MikroTik P-CORE-2