There’s a tried and tested process to deploying IPv6 that many organizations have adopted: get a team together with the right skills and knowledge, design an address plan that will suit the organization’s needs, tests, tests, and more tests, and then implement.
This process worked successfully for Nepal’s Worldlink Communication Ltd (Worldlink), Nepal’s largest Internet Service Provider (ISP), that recognized that they needed to deploy IPv6 with the depletion of IPv4.
Worldlink operates one of the largest fibre backbone and access networks across the economy, serving 73 districts and providing high-speed Internet of up to 100Mbps along with HD IPTV services.
Speaking at APRICOT 2020, Rabindra Maharjan from Worldlink gave an in-depth presentation on their IPv6 deployment, the challenges they’ve faced and the best practices they’ve adopted for a successful implementation.
Worldlink now provides IPv6 services to around 100K customers and has a traffic mix of around 51% on IPv6 and 44% on IPv4. They are trying to improve this IPv6 percentage.
Figure 1 — There’s been a sharp increase in Nepal’s IPv6 capability from February 2020, with Worldlink serving close to 14% of Nepal’s IPv6 customers.
“Prior to IPv6, we used the PPPoE protocol to connect our retail broadband customers, which runs only IPv4,” said Rabindra. “We deployed IPv6 along with IPv4 on the IPoE protocol and started connecting new customers to it, which is currently around 100k.
“We are planning to migrate our other customers to this network in due course and expect to see much more traffic on IPv6 as our customers access content from a number of popular CDNs like Google, Facebook, Akamai, Netflix, and Cloudflare that we host in our data centres, all of which are capable of serving IPv6.”
Getting to 100K IPv6 customers
After getting a team together, Worldlink had to decide on what transition technology to use and create an address plan. They had a few options to consider but like many ISPs, they selected dual-stack as their go-to solution.
“There are many transition options to choose from, for example, header translation and encapsulation — for these we knew there was extra overhead to carry. Instead, we decided to carry both IPv4 and IPv6 passengers on our journey and the best way to do that for us is via dual-stack,” said Rabindra.
The addressing plan included a /32 assignment from APNIC, a /127 for point to point, a /128 for loopback, and because they provide broadband to their customers, one /64 for their Customer Premises Equipment Wide Area Network (CPE WAN). And finally, a /64 for their CPE Prefix Delegation.
Worldlink first enabled dual-stack IPv6 for its upstream provider Interaptus, then enabled it within its core network, including their IPv6 DNS and internal servers. They then established IPv6 peering with all the CDNs, enabled it on Broadband Network Gateways (BNGs), enterprise gateways, MPLS networks, aggregation/distribution layers, and then finally, to customers. Below is an example of their IGP and BGP interface configuration, using Juniper routers:
Deployment challenges
Rabindra highlighted several challenges Worldlink faced during deployment.
The first was controlling bandwidth as they are running dual-stack and need to control IPv4 and IPv6 pipes independently. “We consulted with our vendors and found a solution — during user connection initiation, an assigned bandwidth value will be pulled from the radius and create a dynamic policer to specify the traffic flow rate on the BGN. Then it creates an IPv4 in/out filter and IPv6 in/out filter. After that, both filters will call the same dynamic policer,” explained Rabindra.
The second issue was their IPv6 traffic was blocked somewhere on switching. “Before we implemented IPv6, we deployed filters as one of the security measures to block all multicast traffic to avoid unnecessary flooding,” added Rabindra.
“However, it was clear that multicast traffic has to pass for IPv6 so we turned off these related filters. We also needed to enable multicast on Nokia Optical Line Terminals (OLTs), whereas on Huawei OLTs, it was enabled by default.”
Rabindra also noted they have no filtering mechanism for IPv6 on CPEs, but they are working with their vendors to have these features enabled in the future.
“There is also no visibility of IPv6 distribution on CPEs to end devices like mobiles, tablets, and PCs. This has made it difficult figuring out which end device was getting which IPv6 address,” added Rabindra. “We also found it difficult to troubleshoot issues from CPEs, for example, there are no diagnostic troubleshooting tools on CPEs for IPv6 like v6 ping and v6 traceroute — we are working with vendors to develop these features.”
Best common practices
Like any adoption of a new protocol, best common practices are tried and tested methods for a successful deployment. Rabindra shared the following best common practices Worldlink used for its deployment:
- Bogon filtering and applying this on its upstream routing policy.
- Control plane protection of its infrastructure by allowing access to only an IPv6 prefix used within its infrastructure.
- Blocking exploitable ports and enabling an RPF check on its gateway routers.
- Actively monitoring and measuring its IPv6 ICMP traffic.
The last mile
Worldlink is already seeing several benefits of deploying IPv6.
“We are seeing a slightly better latency over IPv6, probably because there aren’t as many layers of processing that you find with Network Address Translation (NAT),” said Rabindra. “Other reasons could be because IPv4 and IPv6 take different routes on a backbone; and IPv4 is more heavily loaded with routing policies than IPv6.
“Either way because the majority of our traffic is being delivered on IPv6 it is offloading Carrier Grade NAT resources and investment.”
Their future plan includes migrating their internal infrastructure to IPv6 and they have already created an AAAA record for their company website.
View Rabindra’s presentation from the APRICOT 2020 IPv6 Operations session.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Providing a single /64 to the customer is a very bad practice, it is even worse than not deploying IPv6.
How do you expect customers to create multiple SSIDs, subnets, VLANs, whatever, if they are not bridged? For example, guest SSIDs ?
Please amend that immediately!
Read RIPE690.
https://www.ripe.net/publications/docs/ripe-690
You have also this article at the APNIC blog:
https://blog.apnic.net/2017/07/07/isps-simplifying-customer-ipv6-addressing-part-1/
https://blog.apnic.net/2017/07/10/isps-simplifying-customer-ipv6-addressing-part-2/
it’s been 4 years and Wlink still hasn’t fixed this. They are still doing /64 prefix to the customer CPE. Because of this power users have to use NDP proxying and stuffs to get around. Doing prefix delegation is not possible.
I hope they fix this.
Jordi,
I agree that ISPs should be deploying /48s and /56s to customers but deploying /64s is not worse than not deploying IPv6 at all, especially for residential use.
I would hazard a guess and say that most residential networks are one LAN, no VLANs, and one SSID.
I see otherwise.
More and more people has *at least* one guest SSID.
You don’t want guest or kids at home to access your private multimedia contents, or work items, etc., for example.
Hit send to early …
And that means that if you need more subnets and can’t do it with IPv6, you will need to disable IPv6, as you “regular user” prefer to give priority to have several SSIDs.