Deploy IPv6

Deploying IPv6 can be a challenge but many organizations around the world have made the transition successfully. Here’s some of the elements you’ll need to consider for your organization’s deployment of IPv6.


  1. Plan
    1. Have a project plan in place
      Who are your stakeholders? Define your goals.
    2. Assess your network
      • Audit your existing infrastructure; critical servers, and services
        • Identify a workable business model to enable CPE, for example, home gateway routers
      • Check your hardware and software is IPv6 capable
        • Transitioning requires that your equipment is dual stacked
      • If you get your Internet services through an ISP
        • Check if they have an IPv6 deployment plan
    3. Assess the skills in your organization
    4. Communicate the plan
    5. Get management sign off
  2. Prepare
    1. Learn about deploying IPv6
    2. Develop an addressing plan
    3. Build a test environment and experiment
      • Experiment with IPv6 anycast, mobile IP, transition technologies etc.
  3. Deploy
    1. Get IPv6
    2. Configure and monitor your networks
Because IPv4 and IPv6 cannot communicate directly with each other, it is necessary to use transition mechanisms during the deployment to ensure your network can handle both IPv4 and IPv6 traffic. Dual Stack is the simplest option from an operational standpoint; however, it might take multiple iterations to reach the final goal. To save on cost and reduce operational complexity, it is obviously important to minimize the number of iterations towards native IPv6 deployment.
 
Commonly used transition mechanisms use address translation. Translation refers to tools used by an IPv6 device to communicate with an IPv4 device.
 
Carrier Grade NAT (CGN) and Large Scale NAT (LSN) are often presented as “IPv6 Transition Technologies” but in reality are NOT transition mechanisms to IPv6 – they are technologies to prolong IPv4 address availability.
 
While the field of IPv6 transition technology is still evolving, operators need to carefully consider which mechanism is most suitable to their networks. Native IPv6 is preferred, but many operators will need to deploy in steps, by using one or more transition mechanisms, to align with long-term network planning.
 
Transition technology summary courtesy of networking expert, Dr Philip Smith.
 
  • Prolongs IPv4
  • Allows business growth
  • Requires IPv6 deployment
  • Coexists with IPv6 deployment
  • Complexity of operation
  • Complexity of troubleshooting
  • Breaks end-to-end IPv4
  • NAT scalability issues to IPv4 services
  • NAT scalability issues to IPv6 services
  • DNSSEC issues
  • Lawful intercept issues

Dual Stack with IPv4 NAT

  • Prolongs IPv4 Yes
  • Allows business growth Yes (traffic to IPv4-only servers)
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting High
  • Breaks end-to-end IPv4 Yes
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues Yes for IPv4 / No for IPv6
  • Lawful intercept issues Yes for IPv4

6RD with IPv4 NAT

  • Prolongs IPv4 Yes
  • Allows business growth Yes
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting High
  • Breaks end-to-end IPv4 Yes
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues No to IPv4 / Yes to IPv6
  • Lawful intercept issues Yes for IPv4

Dual Stack Lite

  • Prolongs IPv4 Yes
  • Allows business growth Yes
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting High
  • Breaks end-to-end IPv4 Yes
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues Yes for IPv4 / No for IPv6
  • Lawful intercept issues Yes for IPv4

464XLAT

  • Prolongs IPv4 Yes
  • Allows business growth Yes
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting High
  • Breaks end-to-end IPv4 Yes
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues Yes for IPv4 / No for IPv6
  • Lawful intercept issues Yes for IPv4

Stateful AFT (NAT64)

  • Prolongs IPv4 Yes
  • Allows business growth Yes
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting Moderate
  • Breaks end-to-end IPv4 N/A
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues Yes for IPv4 / No for IPv6
  • Lawful intercept issues Yes for IPv4

IVI (Stateless NAT64

  • Prolongs IPv4 Yes
  • Allows business growth Yes
  • Requires IPv6 deployment Yes
  • Coexists with IPv6 deployment Yes
  • Complexity of operation Moderate
  • Complexity of troubleshooting High
  • Breaks end-to-end IPv4 Yes
  • NAT scalability issues to IPv4 services Yes
  • NAT scalability issues to IPv6 services No
  • DNSSEC issues Yes for IPv4 / No for IPv6
  • Lawful intercept issues Yes for IPv4
In this scenario, the service provider (SP) core network and customer network have to use IPv4 NAT due to IPv4 depletion.
Advantages
  • ISPs can reclaim global IPv4 addresses from their customers, replacing these with non-routable private addresses and NAT
  • Allows continued IPv4 subscriber growth
  • SP can offer IPv6 connectivity as well
  • It does not postpone IPv6 deployment
  • Can off-load service provider NAT (compared with an IPv4-only network)
Disadvantages
  • SP needs a large NAT device in the aggregation or core layers
  • Has every well-known technical drawback of NAT, including prevention of service deployment by customers
  • Tracking the association of port/address and subscriber, and lawful intercept issues, are still under study
  • SP incurs additional investment and operational expenditure by deploying IPv6 infrastructure

Plain text transition technology summary

Dual Stack with IPv4

  • Prolongs IPv4 – Yes
  • Allows business growth (Yes – traffic to IPv4-only servers)
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – High
  • Breaks end-to-end IPv4 – Yes
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – Yes for IPv4 / No for IPv6
  • Lawful intercept issues – Yes for IPv4

6RD with IPv4 NAT

  • Prolongs IPv4 – Yes
  • Allows business growth – Yes
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – High
  • Breaks end-to-end IPv4 – Yes
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – No for IPv4 / Yes for IPv6
  • Lawful intercept issues – Yes for IPv4

Dual Stack Lite

  • Prolongs IPv4 – Yes
  • Allows business growth – Yes
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – High
  • Breaks end-to-end IPv4 – Yes
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – Yes for IPv4 / No for IPv6
  • Lawful intercept issues – Yes for IPv4

464XLAT

  • Prolongs IPv4 – Yes
  • Allows business growth – Yes
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – High
  • Breaks end-to-end IPv4 – Yes
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – Yes for IPv4 / No for IPv6
  • Lawful intercept issues – Yes for IPv4

Stateful AFT (NAT64)

  • Prolongs IPv4 – Yes
  • Allows business growth – Yes
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – Moderate
  • Breaks end-to-end IPv4 – N/A
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – Yes for IPv4 / No for IPv6
  • Lawful intercept issues – Yes for IPv4

IVI (Stateless NAT64)

  • Prolongs IPv4 – Yes
  • Allows business growth – Yes
  • Requires IPv6 deployment – Yes
  • Coexists with IPv6 deployment – Yes
  • Complexity of operation – Moderate
  • Complexity of troubleshooting – High
  • Breaks end-to-end IPv4 – Yes
  • NAT scalability issues to IPv4 services – Yes
  • NAT scalability issues to IPv6 services – No
  • DNSSEC issues – Yes for IPv4 / No for IPv6
  • Lawful intercept issues – Yes for IPv4
6RD is a tunnelling technique in which the IPv4 and IPv6 addresses come from the Internet Service Provider (ISP). Some ISPs offering DSL or cable services are implementing 6RD to connect their customers over IPv6.
Advantages
  • The service provider has a relatively quick way of providing IPv6 to their customer without deploying IPv6 across their infrastructure
  • Subscribers can readily get access to IPv6
  • It is completely stateless, does not have the operational drawbacks of 6to4, and does not postpone IPv6 deployment
Disadvantages
  • It is not a long-term solution for transitioning to IPv6 – one further transition step to remove the tunnels
  • CPE needs to be upgraded to support 6RD
  • ISPs have to deploy one or several 6RD termination devices
  • If customers or SP uses NAT for IPv4, all NAT disadvantages are inherited
Due to its disadvantages, notably that it is not a long-term solution, this mechanism is less commonly deployed compared to the 464XLAT and IVI.
Dual Stack Lite (DS Lite) uses IPv6-only links between the provider and the customer. IPv4 is tunnelled through the IPv6 core to the Internet via an SP NAT device.
Advantages
  • The SP is using IPv6 across their entire infrastructure, avoiding the IPv4 address pool depletion issue totally
  • The SP can scale their infrastructure without any IPv4 dependencies
  • Consumers can transition from IPv4 to IPv6 without being aware of any differences in the protocols
  • IPv6 packets are routed natively
  • SP NAT off-load (compared with an IPv4-only network)
Disadvantages
  • SP requires a NAT device in the core supporting DS Lite
  • Subscriber routers need to be IPv6 capable
  • Model has all the drawbacks of SP NAT model for IPv4 traffic
464XLAT builds on previous technologies such as NAT64 andDNS64 and allows clients on IPv6-only networks to access IPv4-only Internet services such as Skype. IPv4 is transported through the IPv6 core to the Internet via SIIT on the customer router and NAT64 on the SP NAT device.
Advantages
  • The SP is using IPv6 across their entire infrastructure, avoiding the IPv4 address pool depletion issue totally
  • The SP can scale their infrastructure without any IPv4 dependencies
  • Consumers can transition from IPv4 to IPv6 without being aware of any differences in the protocols
  • Devices not supporting IPv6 can access IPv6-only networks
  • IPv6 packets are routed natively
  • SP NAT off-load (compared with IPv4-ony network)
Disadvantages
  • SP requires NAT device in core (PLAT – NAT64)
  • Subscriber router needs to be IPv6 capable and support IPv4/IPv6 header translation (CLAT – SIIT)
  • Model has drawbacks of SP NAT model for IPv4 traffic
This mechanism has been widely deployed by a number of telecommunication providers including SK Telecom (Korea), Orange (Poland), T-Mobile (USA), and Telstra (Australia).
This transition technology allows an IPv6-only client to communicate with an IPv4-only server by translating IPv6 headers to IPv4 (and vice versa for the return traffic to the server). In order for this to work in a large network, it requires DNS64 to support domain name resolution.
Advantages
  • Allows IPv6-only consumers access to IPv4 based content without giving them IPv4 address resources
  • IPv6 services and application offered natively to consumers
  • SP network runs IPv6 only, avoiding IPv4 dependencies
Disadvantages
  • SP requires NAT device in core
  • SP’s DNS infrastructure needs to be modified to support NAT 64
  • Subscriber router needs to be IPv6 capable
  • Subscriber devices need to be IPv6 capable (no legacy support)
  • Model has all drawbacks of SP NAT model for IPv4 traffic
IVI Translation allows hosts in different address families to communicate with each other. Subsets of the ISP’s IPv4 addresses are embedded in the ISP’s IPv6 addresses. Hosts using these IPv6 addresses can communicate with the global IPv6 Internet directly and can communicate with the global IPv4 Internet via stateless translators. The communications can either be IPv6 initiated or IPv4 initiated.
Advantages
  • All the advantages of NAT64
  • Unlike NAT64, IVI is a stateless translator, therefore scales better than NAT64.
Disadvantages
  • Addressing and troubleshooting needs care
  • One IP address consumed per mapping (doesn’t solve IPv4 run out problem, just helps with transition)
  • SP requires NAT device in core – model has all drawbacks of SP NAT model for IPv4 traffic
  • SP’s DNS infrastructure needs to be modified to support IVI
  • Subscriber router needs to be IPv6 capable
IVI is widely deployed in China.

SLTMobitel Mobile (Sri Lanka)

More than half of SLTMobitel Mobile’s customers now connect via IPv6.

NTT DOCOMO (Japan)

Japan’s NTT DOCOMO has begun rolling out IPv6 single-stack support for selected DOCOMO devices.

PLDT (Philippines)

As part of their three-year ‘digital pivot’ towards becoming a multimedia communications company, PLDT knew that they had to deploy IPv6. Now, half of their subscribers are getting IPv6.

Mytel (Myanmar)

As of June 2020, Myanmar was almost 14% IPv6 capable thanks to Mytel (Telecom International Myanmar Co. Ltd).

Worldlink (Nepal)

Worldlink is serving 51% of its customers in Nepal over IPv6.

3BB Broadband (Thailand)

IPv6 capability in Thailand has increased from around 2% to 30% with the help of 3BB.

China Telecom (China)

China Telecom’s IPv6 deployment growth in Metro Area Networks has begun taken off.

Tonga Communications Corporation (Tonga)

TCC is deploying IPv6 on its broadband network in 2019 before its future rollout to mobile services.

SK Telecom (South Korea)

SKT are now using IPv6 for all 23 million LTE subscribers, and approximately 60% of the traffic on their network is IPv6.

China Cache (China)

ChinaCache, a major CDN and data centre provider in China, started deploying IPv6 in 2013; currently more than 70% of its network is updated and capable.

Dialog Axiata (Sri Lanka)

Management support, testing, and building staff skills were key to Dialog Axiata becoming Sri Lanka’s first commercial operator to provide IPv6 services.

Vodafone (New Zealand)

Vodafone New Zealand has deployed IPv6 to 80% of its residential home Internet users.

Chunghwa Telecom

Chunghwa Telecom is the first commercial telco to launch IPv6 in Taiwan on its mobile, broadband and WiFi services.

VNPT (Viet Nam)

VNPT has deployed IPv6 to 1.37m fixed line customers and IPv6 peering with VNIX and other local operators.

Telekom Malaysia (Malaysia)

IPv6 services have been offered since 2010 and now cover both corporate and retail customers (for leased line and broadband services).

Reliance Jio (India)

Launched in September 2016 as the first LTE, all-IP mobile network in India, Reliance Jio has deployed IPv6 services to 90% of its 50+ million mobile subscribers.

AIS (Thailand)

AIS (Advanced Info Service) now provides all its Fibre subscribers with IPv6 and the company had a target of 6.5 million ‘homepasses’ by end of 2016.

CTM (Macau)

Macau’s leading telecom service provider, CTM, first started moving towards IPv6 over 10 years ago, and enabled dual-stack IPv6 connectivity to all fibre broadband users at the end of 2016.
SINET (Cambodia)

SINET (Cambodia)

Covering one of the fastest-growing economies in Asia, SINET has deployed IPv6 to prepare its network for Cambodia’s growth into the future.
The story of IPv6 at FPT Telecom

FPT Telecom (Viet Nam)

FPT Telecom, the largest private telecommunications and Internet Service Provider in Viet Nam, provides valuable insights on their IPv6 transition experiences and lessons learned.

Telstra (Australia)

Australia’s largest telecommunication service provider has made IPv6 available to the general public on its mobile services.

NTT Communications (Global)

NTT Communications developed the world’s first commercial IPv6 service in 2001 and began providing IPv6 services globally in 2004.

IBM (Global)

IBM’s IPv6 deployment stretches across more than 100 sites globally with 100,000+ IBM staff actively using the new protocol.

LinkedIn (Global)

LinkedIn has been accessible via IPv6 since 2014 and has made significant IPv6 deployments across its infrastructure.

Sprint (USA/Global)

With 55 million subscribers, IPv4 was not sustainable long term for the Sprint wireless network.

Sky (UK)

In 2016, Sky became the first major ISP in the UK to enable IPv6 for customers, with around 90% of its fixed-line broadband customers using IPv6.

Cisco (USA / Global)

Cisco is deploying IPv6 across its global network supporting more than 5 million IP endpoints.

Facebook (USA/Global)

Facebook has successfully deployed IPv6 across its network infrastructure.

BMW (Germany)

BMW Group is transitioning to IPv6 to support the growing number of online services provided by BMW vehicles.
Event Mobi

Event Mobi (Canada)

App developer, EventMobi, successfully enabled and tested IPv6 on their systems.

Telus (Canada)

One of Canada’s largest ISPs, TELUS, has deployed IPv6.

T-Mobile (USA)

Deployed 464XLAT for mobile subscribers in the USA.

Comcast (USA)

Comcast deployed IPv6 throughout its entire network in 2014.
University of Colorado

University of Colorado (USA)

Deployed IPv6 across two campuses to approximately 30,000 users.
Louisiana State University

Louisiana State University (USA)

Planning, research and testing was a recipe for IPv6 deployment success at LSU.

Rabobank (Netherlands / Global)

Rabobank has made its external websites available over IPv6 and plans to roll out IPv6 internally in 2017.

Forthnet (Greece)

ISP Forthnet started deploying IPv6 in their network in 2013, using Port Control Protocol (PCP) and DS-Lite to aid in the transition.

European Organization for Nuclear Research (CERN)

CERN rolled out IPv6 in 2014, using dual-stack on all of their internal machines and DHCPv6 for address assignments.

Chubu Telecommunications (Japan)

Japanese ISP, Chubu Telecommunications, has successfully transitioned its Internet services for hundreds of thousands of customers to IPv6.

OTE Group (Greece)

Greece’s largest service provider, OTE Group, has started deploying IPv6 to its network using Lightweight 4over6 (lw4o6).

University of Iowa (USA)

The University of Iowa’s data centres and online faculty, staff and student spaces are available over IPv6.

C&W Communications (Caribbean)

Telecommunications and entertainment provider C&W Communications are providing Internet access services to their B2B customers and downstream ISPs over IPv6 in several markets in the Caribbean.

Microsoft (USA)

After experimenting with dual-stack for several years, Microsoft is now experimenting with real IPv6 deployment, piloting deployment in their corporate wireless network in 12 locations across North America and Europe.

Akamai (Global)

Akamai is encouraging its customers – such as Abema TV (Japan) – to adopt IPv6, with positive results.

This page provides some useful resources from technical stakeholders to support IPv6 deployment in networks.

IPv6 Deployment planning, Dr Phillip Smith, 2014

High level planning considerations which any network operator needs to be aware of prior to deploying IPv6.

IPv6 addressing planning, Dr Phillip Smith, 2016

This presentation covers IPv6 address planning for infrastructure and customer links, gives an example of a deployable address plan, and some useful addressing tools.

Preparing an IPv6 Addressing Plan, SurfNet (translated by the RIPE NCC), 2016

Implementing an efficient and logical IPv6 addressing plan in your subnets provides several advantages for operators. This presentation describes how to achieve efficient IPv6 addressing.

IETF RFC 6177: IPv6 Address Assignment to End Sites

RFC3177 argued that end sites should be assigned /48 IPv6 address blocks in most cases. This document obsoletes RFC3177 and clarifies that a one-size-fits-all recommendation of /48 is not appropriate for all end sites and is no longer recommended as a single default.

IGF2015 Best Practice Forum (BFP) on Creating an Enabling Environment for IPv6 Adoption

This document is a result of the BPF, exploring different “best practices” that have been used in relation to increasing IPv6 adoption on a global, open, participatory, and multistakeholder basis. It is relevant for wired and mobile access Internet Service Providers (ISPs), content providers, CDN operators, web hosting providers, residential gateway makers, VPN service providers, and corporate Information Technology (IT) networks, for example, whether operating in the private sector or public administration.

IPv6 architecture and subnetting guide for network engineers and operators

A practical guide to implementing an IPv6 architecture and subnetting system.

IPv6 Transition Strategies, Dr Philip Smith, October 2016

Upgrading the entire Internet to support IPv6 requires a substantial effort, and requires a migration strategy and transition period so that both protocols can co-exist without breaking the Internet. This presentation focuses on the different transition technologies and strategies when migrating from IPv4 to IPv6.

IPv4 and IPv6 co-existence, Dr Philip Smith, August 2014

How can Service Providers face IPv4 address exhaustion? Deploying CGN/LSN only prolongs IPv4 availability by using private IPv4 address space. All Service Provider networks need to deploy IPv6. This presentation gives an overview and comparison of several transition technologies.

464XLAT in mobile networks (Apr 2015)

Easy to read introduction from Alcatel Lucent on 464XLAT. This transition technology has been implemented at T-Mobile USA, Telstra (Australia) and other mobile operators around the world.

IPv6 implementation in mobile network Orange Poland (Mar 2014)

This presentation by Tomasz Kossut and Michał Czerwonka from Orange Poland analyses various IPv6 transition technologies from the point of view of mobile operators.

464XLAT – A Solution for Providing IPv4 Services Over an IPv6-only Network

Cameron Byrne from T-Mobile USA provides a detailed explanation for network engineers who are interested in testing and deploying 464XLAT.

RFC6877 464XLAT: Combination of Stateful and Stateless Translation (Apr 2013)

This RFC informational document describes the architecture of 464XLAT as one of the techniques for IPv4 service extension that can also encourage IPv6 deployment.

IPv6 mobile network migration strategies (Apr 2015)

A brief introduction from Nokia on IPv6 migration strategies for mobile network operators.

The Cost of Carrier-Grade NAT

Presentation by Lee Howard, Time Warner Cable from APNIC 36. How to quantify the total cost of CGN and what are the implications of that cost?

RFC6883: IPv6 Guidelines for Internet Content and Application Services Providers

This document provides guidance and suggestions for Internet Content Providers and Application Service Providers who wish to offer their services to both IPv6 and IPv4 customers. Many of the points will also apply to hosting providers, or to any enterprise network preparing for IPv6 users.

RFC7381: Enterprise IPv6 Deployment Guidelines

Enterprise network administrators face different challenges and priorities than operators of Internet access providers, or content providers. The overall transition for enterprise networks will be most likely from IPv4-only to a Dual Stack network environment, and potentially an IPv6-only operating mode. This document provides a framework for IPv6 transition for enterprise.

The Business Case for IPv6 Services in Mobile Networks (Mar 2013)

This IDC white paper examines the economics of an IPv4 to IPv6 network for mobile operators providing mobile broadband service.

IPv6 Single Stack Now or Later? – The Ultimate Carrier Conundrum (Feb 2015)

Does dual-stack assist in the transition to IPv6 and help keep your business running smoothly? Are existing standards really sufficient for supporting the difficult transition period, and even if your core network supports Dual-Stack, is it really ready for Single Stack IPv6? With a focus on Wireless Networks, this presentation by Sunny Yeung from Telstra Australia looks at the technological differences between Dual-Stack and Single Stack.

Deployment with Dual Stack Lite and lessons learned about CPEs for IPv6 network (Feb 2015)

Case study focusing on transix, an IPv6 roaming service provided by JPNET, looking at why they chose dual-stack Lite and their investigation into the need to investigate and prepare local CPE’s for DS-Lite.

IPv6 in Mobile Networks: Lessons learned and strategies forward (Feb 2013)

Cameron Byrne from T-Mobile explains the business and technology strategy for IPv6-only networks at T-Mobile USA. T-Mobile USA started their IPv6 transition in 2010 with DNS64/NAT64 as a test network. They discovered issues on DNS64 with IPv4 literals. Cameron co-authored a new standard, 464XLAT, to solve this issue and successfully deployed it in T-Mobile USA’s commercial mobile network. Once they turned on IPv6 in their network, it started showing immediate impact to the level of IPv6-ready end users.

Can You Make IPv6 Work Commercially?

Article by Marco Hogewoning, External Relations Officer – Technical Advisor with the RIPE NCC. Does IPv6 really come with a positive business case?

IPv6 mobile network migration strategies (Apr 2015)

A brief introduction from Nokia on IPv6 migration strategies for mobile network operators.

IPv6 Performance by Geoff Huston (February 2016)

This presentation looks into the relative performance of IPv6 and IPv4, using active measurements to examine the relative RTT and connection success rates to gain some insights into the relative performance of IPv4 and IPv6.

IPv6 Capability from APNIC measurements by George Michaelson (February 2016)

APNIC’s George Michaelson discusses APNIC Lab’s measurement methods – measuring end user capability – and summary of their findings showing economies and organizations with highest IPv6 capabilities in Asia Pacific.

IPv6 Deployment Survey

A comparison of how ISPs are deploying IPv6 to residential customers in different countries/ RIR regions, as well as some observations about possible deployment mistakes or misunderstandings about IPv6. These results were presented at the RIPE 73 meeting.

World IPv6 Launch Measurements

The measurement activities track different aspects of IPv6 deployment on the global Internet. The different measurements show various dimensions of the answer to the question of how broadly IPv6 is being used on the global Internet. The tables, charts, and links provide answers to questions such as: which websites have enabled IPv6, how many visitors to a specific website are using IPv6, how many networks have significant IPv6 deployment, and how much traffic at an Internet exchange is using IPv6?

There are many of useful websites and tools providing up-to-date information on IPv6. Below is a list of just some of these, which you might find useful. Note: APNIC is not responsible, nor do we necessarily endorse the content expressed within them.

Google IPv6 Statistics

This site shows the availability of IPv6 connectivity among Google users in the percentage of users that can access Google over IPv6.

RIPE NCC IPv6 enabled networks

Percentage of networks (ASNs) that announce IPv6 prefixes for a specified list of economies or groups.

IPv6 Deployment Status, by Eric Vyncke

This site captures historical and current data on IPv6 prefixes and their announcements, and IPv6 readiness on the web and mail, and DNS readiness by economy and number of organizations.

mrp.net IPv6 Survey, by Mark Prior

This site shows IPv6 readiness for web servers, mail servers, DNS name servers, NTP services, Jabber services, and email client access via IMAP or POP3.

Cisco IPv6 Lab

This site shows consolidated metrics for IPv6 deployment sourced from various measurement sites at a global, regional, and economy level.

AAAA and IPv6 connectivity

This site shows AAAA and IPv6 connectivity statistics from top websites (Alexa) from June 2009 to the present. The test was performed by banjo.employees.org (2001:1868:205::19, 198.137.202.19), which has native IPv6 connectivity.

Global IPv6 Deployment Progress Report

This site shows various IPv6 readiness metrics, including Top Level Domains, registered domains with AAAA records, the top 100 Usenet Servers, networks running IPv6, rDNS name servers running IPv6, and so forth.

World IPv6 Launch

This site tracks different aspects of IPv6 deployment on the global Internet to answer questions such as: which websites have enabled IPv6, how many visitors to a specific website are using IPv6, how many networks have significant IPv6 deployment, and how much traffic at an Internet exchange is using IPv6?

Next Generation Network Architectures (Feb 2016)

Service Providers all over the world are beginning to embrace IPv6 in their current network architectures. But integrating IPv6 only will not necessarily solve the problems that are being faced in the very near future. With the advent of SDN and NFV, new challenges with the Internet of Things, and upcoming technologies demanding even more bandwidth and speed from the network, what sort of architectures are being considered by carriers to ensure a low-latency, high-quality experience for customers?

IPv6 Progress and Challenges, Chunghwa Telecom, Taiwan (Feb 2016)

IPv6 in Mobile Networks, Telstra, Australia (Sep 2015)

Applying IPv6 to LTE Networks, SK Telekom, South Korea (Sep 2015)

IPv6 Progress in Mobile, China (Sep 2015)

Applying IPv6 to LTE Networks, SK Telekom, South Korea (Sep 2015)

This document is a result of the BPF, exploring different “best practices” that have been used in relation to increasing IPv6 adoption on a global, open, participatory, and multistakeholder basis. It is relevant for wired and mobile access Internet Service Providers (ISPs), content providers, CDN operators, web hosting providers, residential gateway makers, VPN service providers, and corporate Information Technology (IT) networks, for example, whether operating in the private sector or public administration.

IGF 2016 Best Practice Forum on IPv6

This document is a result of the BPF, exploring different “best practices” focused on the economic incentives and commercial drivers behind the decision to adopt IPv6. The document was developed through online discussions and contributions from volunteers from the RIR community via a dedicated mailing list, as well as regular calls and meetings conducted by the BPF prior to and during the 2016 IGF meeting.

Cisco IPv6 White Papers

A collection of Cisco White papers on various IPv6 topics, including DHCPv6 Based IPv6 Access Services, IPv6 Rapid Deployment: Provide IPv6 Access to Customers over an IPv4-Only Network, Detecting IPv6 Tunnels in an Enterprise Network and IPv6 Security Brief.

DREN IPv6 Knowledge Base

Useful links on IPv6 and how to start deploying it.

APNIC provides a number on online and face-to-face courses to help you deploy IPv6 in your network. They range from hour-long webinars to face-to-face tutorials and workshops that provide comprehensive hands-on training from two to five days. Topics include:
  • IPv6 protocol architecture (eLearning)
  • IPv6 addressing and subnetting (eLearning)
  • IPv6 planning, deployment and migrations (Tutorial)
  • IPv6 essentials (Tutorial)
  • IPv6 Workshop (Workshop)
Register for training
See the events calendar to register for an IPv6 course. See our extensive selection of training videos for more information on IPv6 deployment.

Technical Assistance

APNIC can also facilitate one-on-one technical assistance to Members on IPv6 deployment on a cost-recovery basis.