Donate
‹ Back
IPv6 2 June 2014

Case Study: How Romania’s RCS&RDS Deployed IPv6

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.

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.

rcs-rds-1-450

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.

rcs-rds-2

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.

rcs-rds-3

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.

rcs-rds-4

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):

rcs-rds-5

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.

rcs-rds-6

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

rcs-rds-7
‹ Back

Related articles

State of IPv6 Deployment 2017
IPv625 May 2017

State of IPv6 Deployment 2017

IPv6 deployment is increasing around the world, with over 9 million domain names and 23% of all networks advertising IPv6 connectivity.

State of IPv6 Deployment 2018
IPv66 June 2018

State of IPv6 Deployment 2018

IPv6 deployment continues to increase around the world. In the six years since World IPv6 Launch[*] levels of IPv6 deployment in networks and service providers all over the globe have increased dramatically.

Case Study: Facebook Moving To An IPv6-Only Internal Network
IPv66 June 2014

Case Study: Facebook Moving To An IPv6-Only Internal Network

At the 2014 v6 World Congress in Paris, Facebook's Paul Saab outlined how Facebook is well on the path toward...

Join the conversation with Internet Society members around the world