IPv6: Telecom’s experience

03/02/2011

Introduction

When we were invited to share with the community how Telecom Argentina is experiencing the transition from IPv4 to IPv6, memories came back of how we had to explain to the “greater Company” that IPv4 – that precious resource – would be soon exhausted.

Managing the early stages of IPv6 has shown us that IP communications do not only involve technical issues. IPv6 is a change that we cannot choose to avoid and from which there is no turning back. It involves not only network administrators but also the company as a whole.

In the beginning, every time the subject of IPv6 came up we heard comments such as the following:

– There’s still a lot of time… let’s talk about this later.

– What do you mean IP addresses will run out?

– Are you sure? When?

Now that day has come and, thanks to all the work that has been done and the plans that have been implemented, Telecom Argentina is prepared to begin the transition to IPv6.

Telecom Argentina

Telecom Argentina S.A. is a company that provides communications services in Argentina and Paraguay. As at September 9, 2010, its consolidated results showed 17,843,000 mobile clients; 1,330,000 broadband accesses; 4,087,000 landlines; and a growth of 18% in net sales of voice, data, Internet and mobile telephone services within the past year.

Based on current growth estimates for (mobile and fixed) data and Internet services, in 2011 the company will need to assign 1,000,000 new IP addresses to satisfy its clients’ needs.

Transition to IPv6

Background at Telecom:

Because the company has always been involved in technological innovation activities, we began preparing projections on the exhaustion of the stock of IPv4 addresses back in 2005. At that time, a goal requiring that all future purchases of new equipment relating to Internet access services, from the backbone to corporate CPE, should comply with the various standards that make up IPv6 was adopted. This decision allowed us to begin acquiring the formal tools required for the new protocol’s future deployment.

The process of developing the necessary network engineering began in late 2007, focusing on the backbone. This phase included a detailed analysis of the IPv6 support status of existing infrastructure and identifying which hardware and software would have to be replaced due to their obsolescence. Consequently, a replacement plan was prepared that would be executed along with the annual process of expanding required infrastructure during the upcoming periods. Thus, the required investment was gradually absorbed within the normal growth process.

During 2008 and 2009, capacity plans were executed that provided the network with the hardware and software needed to support IPv6, among other drivers. In parallel, during 2008 and 2009, laboratory testing was conducted and the configuration parameters that would be applied to the network through ad-hoc engineering processes were prepared. During this stage the company worked jointly with the provider, as many of the required functionalities were part of their internal development roadmap but had not yet been released for use.

During the last quarter of 2009, we began to implement the previously approved logical configurations in the production network, beginning with RFC 4798, 6PE (IPv6 packets transported from PE to PE inside MPLS network) .

During the second quarter of 2010, the levels of field deployment and reliability that had been achieved were enough to consider backbone IPv6 to be of production quality. For this, the joint work carried out with one of our clients, RIU (Redes de Interconexión Universitaria) and our upstream provider, TIS was essential (Seabone is the international backbone of Telecom Italy, property of and operated by Telecom Italia Sparkle).

Towards the end of 2010, laboratory testing for compliance with RFC 4659, 6VPE (IPv6 packets transported from PE to PE inside VPN-MPLS network), was concluded. Field testing and production network deployment are planned for the first quarter of 2011.

IPv4 Address Management

Although Telecom Argentina has always kept its assignment processes in line with LACNIC policies, during 2008 and 2009 the company worked on reorganizing the assignment of all products requiring IPv4 in order to prepare for IPv4 address stock exhaustion. In addition, in order to increase the efficiency in the use of IPv4 address space, an adaptation plan was defined:

• Reviewing assignments for all products that use public IPv4 addresses
• IP address recovery plan
• Creating awareness on IPv4 exhaustion and a plan for introducing IPv6
• Analysis of the impact on the company’s systems

Reviewing assignments for all products that use public IPv4 addresses

Executing the first item of the plan required modifying the assignment of all company products requiring IPv4. For this, we worked together with the Marketing and Product Development departments for the various customer segments, redefining the number of IPv4 addresses that would be assigned to each service and aligning them with the latest policy approved by LACNIC. Section 2.3.2.8. of the current policy, Webhosting, which affects datacenter clients was the one that had the greatest impact.

These modifications were coordinated by the Corporate Process department, which documented and published the agreed processes on our internal portal.

IP address recovery plan

The Company set up a task force to implement a plan for recovering underutilized IPv4 addresses, which resulted in the recovery of a large amount of IPv4 address space.

Creating awareness on IPv4 exhaustion and a plan for introducing IPv6

Meetings with various Company departments to communicate “the news”, answering questions, clearing doubts and dispelling existing myths:

• The Internet will not come to a halt.
• There will be IPv4 addresses in production networks for many years to come (in various ways).
• IPv6 does not replace IPv4.
• IPv6 is the evolution of IPv4.
• It’s not about disabling IPv4 in order to enable IPv6. THIS IS NOT A MIGRATION.

Implementing IPv6 involves the coexistence of IPv4 and IPv6; applications are responsible for deciding which protocol they will use.

Analysis of the impact on the company’s systems

In order to prepare an adaptation plan, an analysis was conducted to determine which systems would be affected and when.

Our Experience in Enabling IPv6 Services

A field testing period was required to stabilize the service.

The dual-stack solution involves higher costs (building and maintaining two networks, including security).

DNS Resolution for IPv6 Addresses

Dual-stack DNS resolver software must be available – a software that supports all the elements required both for IPv4 and IPv6 address resolution (A records, AAAA records, PTR records, etc.) and that is within the IPv6 domain (0.d.3.1.1.0.0.2.ip6.arpa). Reverse resolution of the assigned /32 prefix is also required, as are the reverse and direct resolution of each IPv6 host. Authoritative resolution also requires dual-stack software.

As part of our experience in enabling IPv6 services, in October 2010 we conducted field tests to verify the support status of dual-stack resolution in some content servers using our dual-stack DNS resolver.

The operation was verified on some websites which can be reached using both IPv4 and IPv6: www.isoc.org, www.ietf.org, www.iana.org, www.arin.net and www.lacnic.net.

However, it is still not possible to reach websites such as www.yahoo.com.ar, www.ebay.com, www.flickr.com, www.linkedin.com and www.facebook.com using IPv6 as they are not providing DNS resolution for IPv6 but only for IPv4.

In the case of www.youtube.com and www.google.com, an AAAA DNS Whitelisting IPv6 policy is used (to qualify, Google requires separate DNS servers for IPv6 users, not servers shared with IPv4-only users).

Interconnection Challenges

Assumption:

“When a certain number of clients are able to access IPv6, part of their communications will fail…”

There are several factors that determine the quality of Internet interconnections. In particular, due to the fact that IPv6 deployment is in its early stages, it is important to consider the existence of low-latency paths, symmetry in IPv4 and IPv6 paths for the same website, operational status reliability (industrial process support), and DNS connectivity.

Based on this assumption, as part of the experience we verified route and path quality at certain points, comparing both IPv4 and IPv6 performance.

As a general conclusion, we observed that IPv6 paths have a latency of the same order of magnitude as IPv4 paths. In addition, path asymmetries were observed for the same site for IPv4 and IPv6. This is an aspect that should be improved for improving future reliability.

Final Considerations

To conclude, we would like to highlight some relevant points that should be taken into consideration for transitioning to IPv6 (recommendations taken from IETF RFC 6036, October 2010 – Emerging Service Provider Scenarios for IPv6 Deployment, informational survey of a number of ISPs carried out in early 2010).

“Without customers wanting IPv6, getting business backing is very hard, and IPv6 security and scale was not a focus for vendors until very recently. Operators lack real experience with customer usage of IPv6, and the resulting lack of confidence causes delay. …”.

“Customer support needs to be aware that IPv6 is being started in your network, or servers. We experienced many IPv6 blocking applications, applications that do not fall back to IPv4, etc…”.

“Evangelization remains a must, as it seems that many ISP and IT managers are still unaware of the need for an IPv6 plan, and are inclined to dismiss IPv4 depletion as a false alarm, and also seem unaware that NATs create expensive support requirements”.

Finally:

• Why bother moving to IPv6?
• Ready or not, here is IPv6
• Don’t panic! The web isn’t full to capacity – yet

Acknowledgements:

To our managers and directors who provide their unconditional support to this project, and to the working team that makes it possible.

Gabriel Castro
Transportation Engineering Department – Engineering Department – Technology Division – Network Division – TELECOM ARGENTINA

Marta Astaco
Network and Services Assurance Department – Network and Services Provision and Assurance Department – Network Division – TELECOM ARGENTINA