IPv6 Deployment in Estonia

The plan

This specific deployment of IPv6 was something we’d been actively planning for several years. As part of that, I’d been working hard on building a business case for IPv6 deployment, but everywhere I looked I just found costs, rather than capital.

However, as we were approaching the replacement of our broadband network gateway (BNG) platform, we decided to combine this work with the transition to IPv6 and do the job properly. We wanted to provide native IPv6 (without tunnelling) from day zero to avoid incurring additional costs to a process that could drag on for too long.

In order to minimise the disruption to our service that the transition might cause, we prepared to make the whole move in one big push. Our plan was to roll out IPv6 connectivity to all of our end users with last-generation customer premises equipment (CPE) in a quick, smooth transition – without them even noticing.

Network topology

Our access network has a tree topology. The private service vlan (virtual local area network) from the ETH/DSL/GPON access network is connected to the MPLS to create one virtual private LAN service (VPLS). We use MPLS pseudowires to connect the service VLAN to our BNG boxes. IPv6 traffic shares the VLAN with IPv4. We use a dual-box system to protect against BNG failure. All the IP routing happens at the BNG.

Figure 1:  An overview of our network architecture

We can’t control the customer home network, and it’s important that we don’t break anything for the customer at home, so we rely on  Happy Eyeballs to make IPv4 and IPv6 connections to the web server, which creates an IPv4 fallback mechanism to cover the case that the IPv6 connection malfunctions.

We’ve found that using private VLAN is very difficult, and you must make sure that you have configured your deployment correctly. However, it is possible, and is a viable alternative to using a separate VLAN per customer, which in our case is simply not scalable.

Address assignments

Each subscriber is allocated up to four mixed IPv4 and IPv6 hosts. For IPv4, we use the usual DHCP , while for IPv6 we use DHCPv6 with Identity Association for Prefix Delegation (IA_PD) only - no non-temporary address (IA_NA) is provided. Unfortunately, DHCPv6 provides no way to signal the IPv6 default route, so we must fall back to router advertisements (RA) for the default route. RA does not include any on-link prefixes or DNS information.

The RAs we use are Layer-2 unicasted to CPE MAC, so no other CPE in the service VLAN picks up those RAs. To ensure rapid switchover between BNG routers, we signal the virtual link-local address as the default route.

We use Alcatel Lucent internal DHCP/DHCPv6 servers to allocate leases, but we also signal IP information from radius servers (in such cases, we configure the BNG to "fake" a DHCP server) for our static-IP customers. The IPv6 prefix is always a /56 and we keep the old lease for 24 hours, even if the CPE is turned off.

Unfortunately, IPv6 Lightweight DHCPv6 Relay Agent ( LDRA ) is not available on most of our access platforms, so we have to rely on IPv4 session information for authentication. This linking is done in the radius server during subscriber authentication, and the same MAC address is allowed to run the IPv6 session on exactly the same virtual BNG port.

The IPv4 and IPv6 sessions are both tied to the same subscriber and share shapers, QOS, etc. We were able to enable IPv6 only on our last-generation Inteno CPEs. They run modified OpenWrt .

In the CPE, a /56 is divided into /64s. The first one is currently reserved, but we will configure it on a loopback interface and use it for CPE management. The second /64 is configured on LAN and the third is configured on public WiFi SSID (if customers choose to enable this option).

In the LAN, the IPv6 configuration is provided by RAs. We also support recursive DNS server ( RDNSS ) and stateless DHCPv6 for DNS. There is also an ingress IPv6 firewall in the CPE and its configuration is modifiable by the user.

Summary

A lot of people ask about how we achieved the deployment in four weeks. In fact, this isn’t strictly true: we actually cheated a little to stay inside the four-week window. To make the deployment as smooth as possible, we rolled out IPv6-capable CPE software first. Then, during the BNG platform refresh, we deployed Layer-2 access control lists (L2 ACLs) that dropped all IPv6 traffic based on 0x86DD EtherType. We then deployed the IPv6 configuration to all our BNGs and could verify everything before the single IPv6 lease was handed out to our subscribers. Then, interface by interface, we replaced the L2 ACL with one that only allowed 0x86DD for certain, supported, Layer-2 Organisationally Unique Identifier (OUIs).

Figure 2 shows the increase in IPv6 deployment in a short series of steps, which marks the points at which we removed filters that were disallowing IPv6 for certain MACs. We didn’t do any real configuration changes at those points, thanks to the groundwork we’d laid beforehand.

Figure 2: IPv6 deployment in Estonia end of 2014 (source Akamai Internet Report)

Numbers and future work

We’re now investigating ways to support third-party CPEs. Our main problem is the unreliable IPv6 configuration in CPEs. Many don't enable DHCPv6 (or enable non-temporary address (IA_NA)  but no prefix delegation (IA_PD)), but still pick up default route from RA and happily signal it to the LAN. Others hammer our BNGs with NA requests every 0.1 seconds...

That said, over the last six months we’ve had zero problems affecting customers. Happy Eyeballs probably contributes a great deal to this stability.

As for the statistics, we have a total of 250,000 subscribers in our network. We have 38,000+ active IPv6 subscribers (almost 15% of our customer base). Eighty-one percent of these have at least one IPv6-enabled device in the LAN and 70% have more than one.

Most of the IPv6 traffic we handle is generated by the following:

• Google, YouTube, Google Analytics
• Facebook
• The big content delivery networks (Akamai, etc.)
• Some Russian social media and search engines
• Torrents and gaming networks

Not bad for a country with 1.3 million people, right?

In the future we intend to apply our IPv6 efforts to our mobile network. If you have any tips on how we might do this, or any questions on how we got this far, you’re more than welcome to get in touch or leave a comment below.

T hanks to Tarko Tikan for sharing his experience and insights with us. This piece is a summary of Tarko’s presentation at this year’s Troopers conference, and you can watch the video of that presentation here .