The following IPv6 case study was contributed by Liviu Pislaru from RCS & RDS.
RCS & RDS is one of the most important telecom operators in the region, providing telecommunication services in different european countries. In Romania, it is the market leader for broadband and TV services and the only quad-play provider.
When it comes to IP/MPLS backbone and services, we have a “do it yourself” business model and that helped us a lot with IPv6 deployment from different perspectives:
- we have an open minded management responsive to new ideeas
- we have very experienced engineers with a complete knowledge of the network setup
- we react quickly to network design and software changes
Meet The IPv6 Protocol
In July 2003, we got our first IPv6 allocation from RIPE, a ::/32. Three years later, we set up our first IPv6 peerings in AMSIX, without even having IPv6 enabled in backbone. We did that 2 years later following some basic rules:
- we kept the IPv6 routing standard simple and similar to IPv4. we used the v6 version of the configured protocols.
- we took good care of “IPv6 next-header/routing header” issues. source-routing in IPv6 is a bad ideea
- we tried not to mix Dual Stack with 6PE, especially on BGP RRs (route reflectors) as there are so many issues/bugs with IPv6 next-hop even on major vendors core routers
In 2009, we extended our peering sessions to DECIX, LINX, VIX, we set up peering sessions with Google and we got IPv6 global routing table from upstream providers. We built our first allocation plan in 2010, following “nibble boundary rule”, meening a network mask which aligns on a 4-bit boundary (/n, where n is evenly divisible by 4) and returned to RIPE the ::/32 for a ::/28. When “World IPv6 Day” started, on June 8, 2011, we had already activated IPv6 in backbone, we had already configured hundreds of IPv6 peering sessions in different IEXes but we didn’t have any IPv6 customers. We decided is time to stop talking and start acting.
IPv6 Trial for Residential Customers
The trigger for IPv6 deployment wasn’t IPv4 depletion. We still have plenty of IPv4 addresses and this is gold nowadays.
We wanted our engineers to gain experience with IPv6 when the size of the IPv6 internet was less the 1% and chances to affect customer services was minimised. RCS & RDS is an organization with a well managed IPv4 network with modern hardware and we faced relatively few costs in deploying IPv6, mostly centered around manpower. We’ve studied all transition mechanisms and decided to take advantage of our linux based BNGs with PPPoE and implement an IPv4/IPv6 dual-stack. We hoped and still hope we’ll be able to offer dual-stack to all our customers until the size of the IPv6 internet will be big enough so the carrier-grade NAT (“CGN” – NAT44 for example) that unfortunately we’ll be forced to introduce someday, will translate a very small amount of traffic. We built up “v6team”, with a few highly skilled engineers from different cities in Romania, whose first goal was to give IPv6 to every residential customer. The PPP encapsulation allowed us to avoid all layer 2 related issues and the distributed linux based BNG system gave us a lot of flexibility.
The main challenge was the lack of IPv6 support on customer-premise equipment (CPE). We needed IPv6 via PPPoE (IPv6CP) and DHCPv6 with prefix delegation (PD) and decided to modify and existing open-WRT/ Tomato image to support what we needed and then ask CPE vendors to do the same with their firmware. At that time, our residential customers were buying their own CPEs from the shelf and it was very important giving them a list of CPEs that support IPv6 via PPPoe and DHCPv6 PD. We also gave them the open-WRT/ Tomato modified images but unofficialy because we didn’t want to offer software support for a CPE not provided by RCS & RDS.
On October 10, 2011, we announced in a press release an “IPv6 Pilot Project” start-up and in six months more the 12.000 customers had enrolled. A third of them actually succeeded connecting with both IPv4/IPv6.
The idea was simple and was based on ServiceName field in PPPoE client. For those that entered the string ‘ipv6test’ as a servicename the server responded with both IPv4 and IPv6 Link Local that was created based on IPv4 address (fe80::<32 bits in hex from ipv4>). IPv6 Link Local address forced on customer’s CPEs / PCs gave us the possibility to allocate to all the customers from the same BNG the ::/128 IPv6 global from one single ::/64 and another ::/64 for each customer via DHCPv6 PD. We decided to do that because we relied on IPv4 logging/tracking system at that time and that saved us a lot of time. Now we have a different logging/tracking system for IPv6 as well and we give each residential customer a ::/64 + a ::/56 via DHCPv6 PD.
One month before World IPv6 Launch we successfully ended the pilot project and started offering IPv6 to every single residential customer without them even knowing it, simply by ignoring ServiceName field and providing both IPv4/IPv6 to everyone that supported it (negotiate IPCP/IPv6CP) . To get an idea about our IPv6 traffic, in Romania we offer high speed broadband access (50Mbps, 100Mbps, 500Mbps and 1Gbps) for more than 1.5 million residential customers.
On June 6th 2012, World IPv6 Launch, RCS & RDS had the highest IPv6 adoption rate among ISPs worldwide, placing Romania also in the first place according to APNIC & Google public measurements.
IPv6 adoption rate in RCS & RDS network right before World IPv6 Launch:
- March 2012: 0.2%
- April 2012: 0.98%
- May 2012: 9.55%
- June 2012: 18.6%
The source for these numbers is http://labs.apnic.net/ipv6-measurement/AS/8/7/0/8 and the image below is a printscreen from this website on June 6th, 2012.
Our own measurements show a bit smaller numbers because we are counting the numbers of clients and APNIC and Google are looking at IP addresses. One dual-stack customer usually has and use more then one device and that means only one public IPv4 address but more public IPv6 addresses.
The IPv6 traffic was also big that time mainly because most of it was Google and we had our DNS servers in Google’s whitelisting program. As it can be seen the graphs below, 75% of our IPv6 traffic was CDN and 95% of the CDN was Google.
The rest of the traffic was from peering sessions and I would include here Akamai as well because they weren’t prepared to deliver IPv6 traffic from their servers (Akamai CDN) from our data center at that moment.
So basically, we had to pay some extra peering traffic that moved from IPv4 Akamai CDN to IPv6 peerings.
With a broadband internet market share of almost 45%, RCS & RDS put Romania first place on IPv6 adoption rate top world wide, as shown in this chart from http://www.vyncke.org/ipv6status/ (based on Google’s IPv6 measurements):
After June 6th, 2012, we moved on to offering IPv6 to business to business customers. After analysing security implications of all kind of sceneries that matched our network topology, we decided to have the same IPv6 link local (fe80::1) on every interface that represents customer’s default gateway and gave them a ::/48 routed via their IPv6 link local. We also have enabled IPv6 for MPLS customers, our streaming servers and some equipment’s management interface.
Nowadays our IPv6 traffic goes to 30-35G in peak time, mainly because there’s more IPv6 content on the Internet. Our measurements show that 25% of a dual stack residential customer traffic is IPv6 traffic.
Unfortunately, the IPv6 adoption rate in our network has not increased much over time mainly because the lack of IPv6 support on CPEs and the high percentage of Windows XP users whose PPPoE native client doesn’t support IPv6.
For more detailed information regarding IPv6 adoption rate in RCS & RDS residential network we’ve created a webpage with live statistics: http://labs.rcs-rds.ro/?action=ipv6-adoption
About the author: Liviu Pislaru is Chief Architect for IPv6 at RCS&RDS in Romania.
Please visit our IPv6 Case Studies page for more examples of IPv6 deployment. If you would like to get started with IPv6, please visit our IPv6 resources or begin with our “Start Here” page to help find resources most appropriate for your type of organization. If you have an IPv6 case study you think we should consider for inclusion on our site, please contact us – we are always looking for more!
Editor’s Note: We have added the image below to show the latest IPv6 statistics at the time of publication (June 2, 2014) of this case study. The bottom of the image shows Liviu’s point that IPv6 adoption has been flat over time. The latest statistics can be found at http://labs.rcs-rds.ro/?action=ipv6-adoption
