Quite a few ISPs in the Asia Pacific region have embraced IPv6. Some even have an IPv6-only backbone! On the other hand, ‘bricks-and-mortar’ enterprises (banks, insurance companies, government agencies, and so forth) have been slow to adopt IPv6. In many cases, they just don’t see the business case for it. One of the largest mobile providers in India, which had already transitioned to an IPv6 backbone, had to purchase IPv4 addresses on the open market simply to support companies that had not implemented IPv6.
Why aren’t enterprises transitioning to IPv6?
When asked why these organizations don’t just migrate to IPv6, even in the Asia Pacific region, the answer is often that the decision to move to IPv6 is made in the head office (generally in the United States (US)). The decision of the head office is to stay with IPv4 — possibly because IPv4 is in more plentiful supply in the US as it was an early economy to adopt IP, so they don’t understand the overseas need.
Another factor may be called ‘First Mover Disadvantage’. The US and Europe were the first to computerize processes in the 1970s using mainframe technology; yet as we have moved to a world of cell phone apps and mobile Internet, the needs of developing economies evolved quite differently.
Ghosts of a pre-IPv6 era
I recently had a conversation with a senior architect at a major US federal government agency regarding the transition to IPv6. The architect said that one of their mission-critical computer applications was written in the 1970s. No one at the agency is familiar with the application nor do they have the funds to hire external resources. So, in the opinion of the senior architect, transitioning to IPv6 is out of the question.
In many cases, the first manual processes to be computerized were the core functions of the business. These old, yet very stable, applications have remained critical for operations. In the early days, programmers had few conventions. Little ‘middleware’ existed to shield the programmer from operating system calls. Not that the programmers of those days wanted to be shielded — some even rewrote TCP to function better. Today, new programmers with that skill set are extremely difficult to find and the original programmers are approaching retirement, if they haven’t already retired.
Understandably, corporations, have upgraded to new technologies and architectures (such as IPv6) when it gains them revenue. Thus, legacy programs and technical debt accumulate.
With 20-20 hindsight, IPv6 could have been designed to be able to migrate more seamlessly. That is, some way might have been found within the protocol to allow for gradual migration. As it is, IPv4 and IP6 are completely incompatible. Yes, there are transition technologies — which brings me to yet another problem! There are many, many IPv6-IPv4 transition technologies. Again, with the benefit of hindsight, we should have chosen one or two transition technologies and made them work.
Industry indifference
You might ask, “Why didn’t these organizations say something when IPv6 was being developed? Surely, it would have been obvious to them that they were going to have a hard time migrating their networks.” One of the persistent issues in Internet standards is the lack of involvement by large bricks-and-mortar industry companies. At IETF meetings, I can count on the fingers of one hand the traditional industries present from any economy.
This is a tricky area as enterprises are not specialists in Internet standards and do not clearly understand how and why they should be involved. That is, it takes a lot of work and their management does not see that it adds to their bottom line (in the short term) to have people be involved. Additionally, the kind of person who can be involved effectively in standards activity is likely to be a very experienced and highly-paid employee. Such employees are likely to be critical components of many other projects within the organization, and possibly not have the time or resources to attend these meetings.
What’s being done to rectify the problem?
We at the non-profit organizations of the Industry Network Technology Council (INTC) and the India Internet Engineering Society (IIESoc) have received a grant to help educate senior enterprise technicians on new protocols as well as how to collaborate to relay requirements to Internet standards bodies. These senior technicians have influence in their organization. This is a long-term effort at changing the technical culture of organizations.
Having said all this, this is not just a problem for enterprises; one of the persistent problems in Internet protocol design is that of legacy equipment. Having to always be cognizant of legacy equipment keeps us from being able to migrate to newer, more secure, and more efficient Internet protocols. IPv6 is a clear example of this.
ISIF Asia has generously provided a grant for this project to IIESoc to work collaboratively with the INTC to address the issue of IPv6 adoption at large bricks-and-mortar enterprises in the Asia Pacific region.
We have done a survey of large enterprises and have found that security, application conversion, and training are three of the biggest barriers to IPv6 adoption reported by enterprises. We plan to help in each of these and are already engaged in some of these activities in different regions around the world. Currently in the Asia Pacific region, we are looking at issues related to training.
Training is one piece of the puzzle
Management can, understandably, be reluctant to spend money training many people on the several concepts needed for IPv6 — especially when there does not appear to be a business benefit. The thinking might go: “I am paying hundreds of thousands of dollars out of my training budget, taking on a multi-year project that will take the time of many of my best people, just to end up with what I have today? Why would I do that?”
It’s a tough sell.
So we have developed a training program to tackle many of these issues related to IPv6, targeted at those who are already familiar with IPv4. Using language that enterprises understand and examples of work that are familiar to them, we present these classes with the knowledge of the constraints faced by enterprises.
The sessions until August are sponsored by the grant from ISIF Asia. Most sessions will have a hands-on lab portion the week following the conceptual webinars. You do not need any equipment to participate and the sessions are free of charge. We will send full instructions so that, if you wish, you may do the same commands and exercises on your own system but this is entirely optional.
Register here. You only need to register once to attend any or all classes.
The first IPv6 webinar, ‘Introduction to IPv6’ will be held on 4 February 2021. This webinar will help participants understand the IPv6 methodology, which is, in many ways, a fundamental change from the IPv4 paradigm. It will cover issues ranging from prefixes through to a variety of issues on unicast, multicast and anycast addresses as well as address allocation methods.
Below is the full schedule for all the IPv6 webinars:
– Introduction to IPv6: 4 February 2021
– Lab: IPv6 basics: 11 February 2021
– Neighbour discovery: 4 March 2021
– Lab: Neighbour discovery: 18 March 2021
– IPv6 address planning: 15 April 2021
– IPv6 transition mechanisms: 6 May 2021
– Lab: IPv6 transition mechanisms: 13 May 2021
– DHCPv6: 3 June 2021
– Lab: DHCPv6: 10 June 2021
– IPv6 and cloud: 17 June 2021
– Lab: IPv6 and cloud: 24 June 2021
– Introduction to IPv6 security: 8 July 2021
The following sessions are sponsored by a grant from ARIN:
– Trace Reading: 12 August 2021
– Troubleshooting: 19 August 2021
Dhruv Dhody contributed to this post.
Nalini Elkins is President of the INTC and CEO and Founder of Inside Products. Dhruv Dhody is Co-Chair of the Path Computation Element (PCE) working group at the IETF, and Chief Standards Architect at Huawei Technologies India.
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.