To mark APNIC’s 30-year anniversary, the APNIC Blog is running a series sharing stories, anecdotes, milestones and insights that capture some of the essence of the last three decades.
We’d love to hear your stories and memories of the APNIC community. Post them on social media using the tag #APNIC30th!
From roots in the early 1990s, competing protocol proposals to replace IPv4 converged on a design in 1994 and this was confirmed in 1995. So, within the first two years of ‘the APNIC experiment’, there was a definition of IPv6 as a protocol. But that was just the start of the work required by the community to realize the future of addressing.
This post reflects on the three pillars of the IPv6 ‘story’:
- The roots, as the logical successor to IPv4.
- The sense of coordination and processes to kick-start uptake.
- The lived experiences of the APNIC Members who invested their time and efforts to realize IPv6.
Background: IPv6 prehistory
The IETF realized early on that IPv4 had a limited horizon of growth against world expectations. This was brought into sharp focus by the Address Lifetime Expectations (ALE) Working Group, which in 1994, projected IPv4 would run out between 2005 and 2011. This turned out to be remarkably perceptive, with the final /8 process in the Regional Internet Registry (RIR) community being enacted in 2011.
As defined, IPv6 could not be directly interoperable with IPv4 as a network layer, although carriage of TCP and UDP transport layer protocols ‘above’ the IP level made the interconnection of IPv4 and IPv6 (as well as adoption by applications that mostly code to TCP or UDP behaviours) much simpler.
As discussed by John Scudder in his APNIC Blog article:
In some ways, IPv6 was designed as a more processor-friendly protocol than IPv4; in particular, the IPv4 header is variable-length and the IPv6 header is fixed-length. That’s very helpful. It also organizes its options such that a transit router need not even attempt to parse options of relevance only to the destination node.
In other ways, IPv6 presents greater challenges than IPv4: because of its greater extensibility, IPv6 has more options. An IPv6 header chain can potentially grow rather large, conceivably large enough to trigger some of the problems described above when the headers exceed the capacity of fast memory to store them for the forwarding engine.
For some older devices that didn’t include IPv6 as a first-class citizen in their silicon design, extension headers of any sort are problematic, moving the packet off the fast path or otherwise reducing the packet rate through the forwarder.
Newer devices (made in the last few years) have the potential to remedy this issue but even though the silicon is capable, the microcode that runs on it may lag; for this reason, throughput for IPv6 packets with extension headers continues to be chancy.
John Scudder, Juniper.
This Internet Protocol next generation (IPng) design was ratified in January 1995. IPv6 was born!
First footsteps: Structured addresses and small delegations
The initial response of the community to IPv6 was cautious. Finally, in 2003, a cohesive and simple model of addressing arrived in RFC 3513, which has been updated and substantively represents the forms of IPv6 addressing used today.
With the launch of IPv6 address delegation in the RIRs, the decision was made to ‘start slow’ and a joint proposal called ‘Provisional IPv6 Assignment and Allocation Policy’ was agreed by the RIPE NCC, ARIN, and APNIC in 1999 (the only three RIRs in existence at this point). This defined the ‘bootstrap phase’ of allocations. The address allocation policy reinforced cautious delegation, with address conservation in mind:
2.2.3. Efficient Address Usage
Although IPv6 address resources are abundant, the global Internet community
must be careful to avoid repeating the problems that arose in relation to
IPv4 addresses. Specifically, even though "conservation" of IPv6 addresses
is not a significant concern, registries must implement policies and
guidelines that prevent organizations from stockpiling addresses.By 2001, the model had enabled a total of 90 IPv6 allocations worldwide. At the time, those involved in routing and address policy were still worried that in real terms ‘bootstrapping’ was proving harder than anticipated. Due to end when 100 delegations had been made, the decision was made to extend both the delegation amount and the bootstrap period.
During this time, IANA was delegating to each RIR a /23 worth of IPv6 space to ensure there was no wastage during the bootstrap period. But it imposed a requirement to re-call on IANA for more space in a short cycle. This was awkward to manage in reverse DNS as both the holder and the RIR had to make multiple records to delegate one prefix under ip6.arpa, which didn’t align with the 4-bit hex values. A single event was, therefore, multiple records to manage.
What size to delegate?
What’s the right size to delegate? A /32! What’s the right size for an RIR? Not a /23!
Across 2001 and 2002 the operations community came to realize the initial ‘slow start’ of handing out /48s and /35s was not really useful. It didn’t leave enough address space before the fixed /64 boundary (where EUI-64 defined unique host identifiers lie, derived from Ethernet card addresses) to allocate a block of addresses to enough customers.
Therefore, a decision was made to realign delegation to Internet Service Providers (ISPs) on a /32, which was ratified by the end of 2002.
This policy change also required the ‘reservation’ of a /29 be made, addressing a concern over the number of prefixes announced in BGP. If this reservation permitted an ISP to come back and extend their address holding as the need arose, there would still only be one prefix after they increased their holdings. But a consequence of this decision was that a /23 from IANA was no longer a good fit. There could only be 64 or so /29s in a /23, and as the pace of ISP delegation had picked up, bigger spaces to work in were needed.
This led to a global address policy decision among the RIRs and IANA, to delegate each RIR a /12 of space. This would be sufficient for at least 131,000 /29 sub-delegations. And to ensure maximum aggregation potential for the future, the sparse allocation model was adopted. This is a ‘binary-chop’ method of selecting the next largest space to sub-allocate from, slightly modified by APNIC to divide the initial /12 extent into a ‘big’ and ‘small’ half, reflecting how address delegates inform us of their future growth potential.
Only a very small number of ISPs need amounts of IPv6 that approach a /16 boundary (the size of reservation in the upper half of this space). This modification has maximized ISP growth potential and preserves free space behind each delegation for future growth efficiently.
A mechanistic model of address consumption was recognized thanks to Christian Huitema’s work in defining ‘HD-Ratio’. The HD-Ratio is a logarithmic model that scales address requirements based on customer count while considering the efficiency of address allocations inside the ISP. This allows RIRs to understand what IPv6 resources an existing IPv4 holder would need and could justify.
But how to encourage IPv6 adoption?
Efforts inside the APNIC Secretariat to coordinate IPv6 deployment were led by Miwa Fuji, who moved from a training role in 2008 to spearhead this initiative.
“I started at APNIC as a Technical Trainer, delivering training on IP addresses and ASNs to various technical communities, and then in 2008 my role shifted to APNIC IPv6 Program Specialist,” Miwa says.
“Reflecting on that eight-year experience, the image that comes to my mind is that of a surfer trying to figure out how to choose the best wave to ride so that it might bring us back to the shore as close and as fast as possible. And then repeat it. It was intense, hard work but a very exciting time.”
Outreach had to go beyond the direct ISP membership to encourage small to medium enterprises, corporate sectors, and government agencies to take IPv6 seriously and invest.
“It was very obvious that APNIC had to expand its reach beyond its main stakeholder — the Internet technical community. The key was approaching Internet multistakeholders such as businesses and industries, governmental and non-governmental organizations, civil society, and international governmental organizations. Initially, I created a list of non-technical organizations that APNIC should approach. The Asia Pacific Economic Cooperation (APEC), an intergovernmental regional association, was at the top of that list,” says Miwa.
“Highlights of this effort were the APEC 2010 and 2012 Ministerial Declarations endorsing IPv6 deployment, and the development of the APEC TEL IPv6 implementation guideline by collaborating with Member economies. Drafting a sentence for a Ministerial Declaration and gaining consensus on a technical guideline in an intergovernmental organization is no simple matter.”
Miwa recalls the pace of deployment had urgency, with the prediction of runout of IPv4 pointing to 2011 as the ‘crunch point’.
“In 2008, IANA’s [freepool of] IPv4 address space was predicted to be exhausted within three years. Although the Internet technical community was aware of the rapidly approaching final days of [the freepool of] IPv4 addresses, back then, implementing the IPv6 protocol into the Internet infrastructure was so slow. As the APNIC IPv6 Program Specialist, I had to think ‘outside the box’ to increase velocity and scalability of information dissemination on the importance of IPv6 adoption.”
‘You can’t improve what you don’t measure’
Once APNIC was exposed to the risk of the final /8 IPv4 address policy, tracking the worldwide deployment of IPv6 became important. There was a need to understand the actual rate of deployment, which differs from delegation and cannot be directly measured within the registry.
As discussed in a recent PING episode with Geoff Huston, a mechanism was designed that used web advertising, deployed randomly worldwide continuously since 2010, which has allowed a better understanding of global IPv6 deployment by economy and origin-AS. This information has been provided freely to policy and strategic planners worldwide and has helped inform the deployment of IPv6 in many economies by providing an external penetration rate reference, discernible through end-user measurements.
The rubber hits the road
APNIC Members are now responsible for 63% of the world’s IPv6 capability, in part due to the example of notable IPv6 deployments in the region. Below, engineers from Chunghwa Telecom (CHT) in Taiwan, Telstra Mobile in Australia, VNPT in Viet Nam, KDDI in Japan, SK Telecom in Korea, FPT Telecom (also in Viet Nam), Reliance/Jio in India and AIS Fibre in Thailand, reflect on their experience leading the charge from 2004 to the present day.
An example of an incumbent telco taking the lead in an Asia Pacific IPv6 deployment is Taiwan’s CHT, which began in 2008. Lin Kuo-Feng, SEVP and CTO at Chunghwa, believed native IPv6 would benefit CHT’s business expansion and reduce the investment risk associated with maintaining older technologies.
“In our planning, we weighed up the cost versus benefit of using NATs to sustain our original network with the IPv4 addresses we already have or investing in upgrading our network equipment to be able to accommodate IPv6,” Lin Kuo-Feng says.
“For us, the benefit of the initial investment, time, and cost to upgrade our network to be IPv6 compatible was greater and more economical in the long run than the risks and costs associated with continual updates that come with using NATs.”
Sunny Leung from Telstra Internet in Australia reflected on why Telstra made the commitment to deploying IPv6 in the new 4G mobile system back in 2012.
“The mobile IPv6 project was created as part of an established program to introduce IPv6 across Telstra’s Internet services — both as a response to the forecast global exhaustion of public IPv4 addresses, but also because of our commitment to Internet technology evolution,” Sunny says.
“We could see the benefits that the massive IPv6 address space would bring to simplifying future network designs, with its greater capability to support the expected explosion of IoT devices.”
“It also made far more sense for us to aim directly for that end IPv6 goal than to attempt to build complex and costly solutions to temporarily extend IPv4 use when a transition to IPv6 would still be needed a few years later anyway,” he adds.
“IPv6 is inevitable,” says Nhan Vu, who was responsible for VNPT’s IPv6 deployment plan from 2013.
“The sooner we prepare for deployment the better, especially as we are entering the IoT era. Deploying IPv6 will make us more competitive.”
Hiroki Kawabata who is responsible for JPNIC’s IP address and Autonomous System Number (ASN) management reflects on the pace of technology change and its effects on the deployment status of IPv6 in Japan from 2009 onward.
“Many Japanese smartphone users replace their devices every two years to take advantage of new technology and discounted plans. All smartphones that the three largest providers currently sell as part of their mobile plans have been set up to use IPv6 in advance. As such, IPv6 deployment on the user side has progressed quite quickly — although we are still waiting for official statistics.”
For many ISPs with an existing customer base on IPv4 and a looming shortage, the opportunity of a shift in technology such as the deployment of 4G from a 3G base, or from copper to fibre-based networks was a strong driver to deploy IPv6.
Consider Reliance Jio’s experience from 2016 in the Indian mobile data market.
“Entering the market as a new 4G operator, we knew we needed to define ourselves differently from established operators if we were to succeed. We knew we could take advantage of the most up-to-date technology, allowing us to accommodate a huge number of users as well as the burgeoning Internet of Things (IoT) market,” says Molay Ghosh.
“We started planning for IPv6 in 2011 when we received our first IPv6 assignment from APNIC and had established a functional network by 2015.”
Piphat Trakoolwatana learned from his experience at AIS Fibre in Thailand that IPv6 must be the goal for every ISP.
“The choice for us was clear. The amount of available IPv4 is decreasing and we wanted to reduce CGN NAT use. And from a content point of view many Internet applications — IoT, YouTube, and Google — already support v6,” argues Piphat.
The journey isn’t finished
From the initial stages of bootstrap, IPv6 deployment has reached a point where over half of the world’s IPv6 users reside in the Asia Pacific region. Two major Asia Pacific economies, India and China, have emerged as powerhouses of global Internet usage and both are now well down the road to an IPv6 ‘first’ Internet.
In Internet technology terms, IPv6 has now become the norm. Chinese network regulations now specify that all infrastructure deployed in the national network must now come IPv6-enabled from the supplier (not just capable as an optional extra but actually configured to expect IPv6) and the density of IPv6 prefixes in the global BGP routing table now exceeds the ASN count (200,000 prefixes for around 80,000 origin-AS, compared to IPv4’s 800,000 prefixes).
IPv6 deployment worldwide has reached 35% and continues to grow. At the current pace, it may be some years before it predominates, which makes the continued availability of IPv4 even more important for new entrants. Those newer deployments will be IPv6 mostly, with Carrier-Grade NAT (CGN) extending the limited remaining IPv4 resources.
Part and parcel of the rise of IPv6 in the Asia Pacific has been the rise of local Internet Exchange Points (IXPs) which keep traffic local and encourage interconnection amongst BGP speakers.
Alongside this has been the growth of local community organizations for mutual support, the Network Operations Groups (NOGs), and the security activity of the Computer Emergency Response Teams (CERTS), which help manage the risks of global connectivity to the community at large. These will be explored in the following post on NOGs, IXPs and CERTS.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
And yet deployment of services on the IPv6 infrastructure is still very poor. For example, if you use Microsoft for your email service then it is very likely that you aren’t reachable via IPv6.
Tried turning off IPv4 off and using IPv6 only about a year back – result was a disaster with my machine basically being crippled with most websites not reachable and a lot of my background apps stop working.