Just a guy in Vermont trying to connect all the dots...
Author's posts
Jun 03
Case Study: Mexico’s AXTEL Outlines Phases of IPv6 Deployment and Recommendations
AXTEL is the second-largest telecommunications operator in Mexico, running its own network in 39 major cities in Mexico and having connectivity to 200 more cities across the country. They have implemented IPv6 for their business and VPN customers and are currently analyzing how best to roll out IPv6 to their residential customers. In this 2014 case study (PDF) they walk through the multiple phases of their IPv6 implementation, including:
- Project kickoff
- Initial analysis
- Network deployment
- Service deployment
In each phase outlining what they did and providing a good checklist for any other service provider to consider. Their slides are available for viewing:
In particular, their “In Retrospective” section states that if they could return to the beginning of their IPv6 project, they wish they could have had:
- More insight regarding how each of our different equipment providers were doing towards their evolution to IPv6.
- The possibility to talk to another provider that had already implemented IPv6 in their network and learn from their experiences.
- Support from our providers with people/team that had hands-on experience in an IPv6 evolution project.
- To have had IPv6 support, even years before the beginning of the project; as a required functionality in all or our network and IT equipment requirements.
They go on to provide their recommendations for other companies seeking to move to IPv6:
- Communicate to all company levels the urgency and importance of IPv6 evolution.
- IPv6 is a primarily a business continuity case.
- Test in a lab environment all your IPv6 deployment scenarios
- Begin IPv6 training in all the different technical, sales and marketing teams ASAP.
- Evaluate the necessity of running a network audit or assessment to know where your network stands regarding IPv6.
- Assist to technology forums and ask other people about their experience in the IPv6 evolution. There are a lot of us in the same situation.
- Work closely with your equipment providers.
- Implement double stack wherever possible.
- Avoid NAT techniques wherever possible.
- Don’t be afraid of the IPv6 transition; as with many things the beginning is the toughest part.
All of which are solid recommendations!
This case study was provided by Cesar Joel Ramirez Garcia, IP Architect Engineer and IPv6 Leader with AXTEL in Mexico.
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.
Jun 02
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. 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
May 31
Telegeography’s Submarine Cable Map Now Lets You Link to Specific Cables or Landing Points (Featured Blog)
May 31
TDYR #155 – Djibouti – First Impressions And Thoughts
May 29
TDYR #154 – On The Way To Djibouti By Tiny Planes And Huge Planes
May 26
FIR #757 – 5/26/14 – For Immediate Release
May 25
TDYR #153 – I Never Thought I Would Be A Chicken Farmer
May 22
Goodbye, IPv4! IANA Starts Allocating Final Address Blocks
IPv4 address exhaustion just got more real! In an announcement on Tuesday, the Internet Corporation for Assigned Names and Numbers (ICANN) indicated that they are starting the process of allocating the final available blocks of IPv4 addresses out to the Regional Internet Registries (RIRs) from the IANA recovered address pool. (ICANN is the operator of IANA.) As the announcement states:
ICANN announced today that it has begun the process of allocating the remaining blocks of Internet Protocol version 4 (IPv4) addresses to the five Regional Internet Registries (RIR). The activation of this procedure was triggered when Latin America and Caribbean Network Information Centre’s (LACNIC) supply of addresses dropped to below 8 million.
This move signals that the global supply of IPv4 addresses is reaching a critical level. As more and more devices come online, the demand for IP addresses rises, and IPv4 is incapable of supplying enough addresses to facilitate this expansion. ICANN encourages network operators around the globe to adopt IPv6, which allows for the rapid growth of the Internet.
This is it, folks.
We’ve been talking for many years about IPv4 addresses running out. Now it’s happening.
[NOTE: Back in February 2011, IANA allocated their final IPv4 address blocks from the "free pool" of IPv4 addresses. IANA then worked with the five RIRs to recover unused IPv4 address blocks and establish the "recovered address pool". The agreement was that allocations would start from this pool when the first RIR hit its last /9 block of IPv4 addresses, which LACNIC recently did. After this recovered pool has been allocated to RIRs, there simply aren't any more IPv4 addresses for IANA to give out.]
Yes, there are enough IPv4 addresses in the overall system right now that we’re not running out of addresses TODAY … but we are basically OUT at the top-level. The final allocations will occur over the next few months as part of the Global Policy for Post Exhaustion IPv4 Allocation Mechanisms by the IANA.
It will be increasingly hard for network operators to get more IPv4 addresses for new customers and new networks.
If you are not yet planning for a transition to IPv6, you really need to get going now! If you want to grow your network, the simplest and easiest path will be to make the move to IPv6. Check out our “Start Here” pages to learn how you can get going!
DO YOU HAVE A GREAT EXAMPLE OF MOVING A NETWORK OR APPLICATION TO IPv6? We are seeking IPv6 case studies for our upcoming celebration of the 2nd anniversary of World IPv6 Launch. If you have a great IPv6 story, we’d love to help share that story for others to learn from it. Please let us know.
UPDATE #1 - If you are interested in learning more about how IPv6 adoption is going, check out our list of IPv6 statistics sites. In particular, look at the World IPv6 Launch measurements, where this month Verizon Wireless crossed over 50% IPv6 for the first time!
UPDATE #2 - There is an excellent discussion thread currently underway on Hacker News about this article.
UPDATE #3 – The Number Resource Organization (NRO) has a statement up on their website.
May 22
Webinar TODAY (May 22) – IPv6 and Telecom: IPv4 Is Finally Running Out. Now What?
In about two hours, the free webinar we mentioned last week about IPv6 and telecommunications will be taking place hosted by US Telecom. I’ll be addressing questions such as:
- What is the impact of IPv6 on telecommunications and Voice-over-IP (VoIP)?
- What telecom systems support IPv6?
- What efforts are underway within organizations like the IETF and the SIP Forum to ensure that telecommunications can work over IPv6?
The webinar is happening TODAY, Thursday, May 22, 2014 at 1:00pm US Eastern time. (17:00 UTC).
Registration is free and open to all interested. The presentation will be recorded if you are unable to view it live.
And if you are interested in the overall topic of IPv6 and telecommunications, please do check out our specific page on IPv6 and VoIP/telecom.








