My interest in IPv6 goes back to the year 1997. At that time, I was writing my first technical book with the title “Troubleshooting TCP/IP.” In the last chapter I felt the impulse to go out and check what the future might look like. And I found Christian Huitema’s early book “IPv6: The New Internet Protocol.” It was a small book, about 100 pages, and in the last chapter of my book I summarized it in two or three paragraphs, saying “there is a new protocol on the horizon, which will eventually help solve the address issue with IPv4.” I think at that time it was the only book available on IPv6. I cannot explain why, but somehow this topic fascinated me.
So, when three years later O’Reilly called and asked if I would write a book on IPv6 for them, I did not hesitate to say yes. I knew from my experience with writing the first book on TCP/IP that there is no better way to learn something than to write about it. And I believed that IPv6 would be the future Internet Protocol, so it was well worth diving into the depth of it. In those early years, not many people had heard about it, so it was mainly the developers that supported me in my writing process. This meant that I was learning from the source.
As for the challenges for IPv6 development and deployment, I guess it was that NAT (Network Address Translation) became more and more popular to solve address limitation issues before IPv6 was mature enough to implement. IPv6 was published with RFC 2460 in 1998 as a draft standard and it took some time until the vendors had made their first implementations. So, by the time IPv6 was ready to use, many had their NATs “solving” their pressing address limitation issues and did not see a reason to implement IPv6.
In a short-term perspective, that is understandable. However, this does not support a long-term perspective from a network architecture point of view nor from a business case perspective. Seen with a long-term view, NAT should be replaced with the solution that has been built to solve the address issue, and that is IPv6.
If you look at this through the lens of the Internet, businesses should understand that each of us is a participant and co-creator of the Internet. Whether they offer their Internet services like websites and shops over IPv6 or not has a large impact on other ISPs and on end users. For all services offered over the Internet the recommendation is to offer them dual stack, which means they can be accessed over both IPv4 and IPv6. In this way, each end user can access the site over the protocol with which they get the best performance.
For an ISP, operational costs are substantially lower if it has an IPv6 path. It is much simpler to maintain and unloads traffic from its IPv4 path (which often is a complex NAT structure that creates high maintenance costs). In consequence, each public website offering their services over IPv6 unloads traffic from the IPv4 path and transports it over the leaner IPv6 path for all ISPs on the route. For the end user, depending on how they are attached to the Internet, it can be a great performance advantage because if their ISP has a complex and perhaps overloaded NAT structure for IPv4 they can access any dual-stack Internet service over IPv6.
Swisscom, a Swiss ISP who delivers dual-stack Internet to their DSL users since 2012, assessed their operational cost after five years. The results were interesting.
Cost for 1 Gb/s throughput:
6rd: CHF 1’650.00
CG-NAT IPv4: CHF 8’000.00 (without cost for logging)
So for Swisscom, delivering data over IPv4 is more than four times more expensive than over IPv6. More than 35% of their backbone traffic is IPv6 (figures from 2017). The IPv6 path offloaded 9 Gb/s from the IPv4 path.
So a major improvement would be if public websites offer their services dual-stack (which is actually a no-brainer from a technical viewpoint) and if companies give their users dual-stack access to the Internet. This would substantially increase IPv6 traffic on the Internet and offload it from IPv4.
IPv6: Difficulties within the organizations. The main issues I see here is that it is very common these days, especially in large organizations, to make decisions with a short-term perspective. If something does not create a return within a few months, it is often canceled from the budget. And money is often used as a good excuse to not have to do things that people don’t want to deal with. In many discussions with customers, I also find that there is a belief that IPv6 is way too complex and that they could not master it. This can look overwhelming, I agree, but only if you don’t take the time to have a closer look at it. If you do have a closer look, you will find many examples of companies that have walked the talk and found out that it is easier and less costly than they had expected. Also, without management support an IPv6 project is difficult to manage, as you need to have cross-departmental priorities and goals.
Another reason which is slowing down IPv6 deployment in organizations is that IPv6 is seen as a separate project. Every year it is assessed as part of an annual budget. And then it is decided that currently there is no time and that money is needed for other projects that seem more important. Fact is, IPv6 is not a separate project but should be seen as an integral part of any other project. Because all IT projects run over the same network and IPv6 is an integral part, just like security is. You don’t say “oh, we have no time and money for security. Right now, we need to roll out our new datacenter. We will take care of security later.” This doesn’t make sense, does it? Same for IPv6!
And when you consider that IPv6 is an integral part of any project that uses the network, it is no longer this huge overcomplex mind-blowing thing. It can be addressed step by step, per project. Obviously, some aspects have to be addressed across projects, such as overall architecture, address plan and security concept. This should be done in the beginning and then serve as the framework for each individual project.
Organizations are not aware of how many costs are hidden in the operation of their IPv4 networks. One large organization I was working with recently assessed this more carefully. One thing was that they had to buy IPv4 addresses. The market price for an IPv4 address has risen quite a bit in the last few years. Back in 2013, when Microsoft bought the Nortel IPv4 addresses, they paid something in the range of USD 12 per address. Today the cost for an IPv4 address has risen to USD 50 to 60 per address (https://www.ipxo.com/blog/ipv4-price-history). This customer of mine had paid approximately one million US dollars for a /16 of IPv4 addresses. If they had accommodated IPv6 in their planning early enough, they might have saved these costs or been able to invest this money in the deployment of IPv6.
This customer also found out that a large part of their downtime and troubleshooting costs were caused by their complex NAT structures and devices. So these costs should be considered as savings when evaluating the cost of implementing IPv6.
Another case where unnecessary costs and troubles were created due to ignoring IPv6 deployment was the Swiss train company, SBB. They had done some of their homework back in 2014 by creating an address plan. Instead of starting a step-by-step deployment, the address plan was stored in a drawer and forgotten. Some years later, the business team decided to launch a new service. The launch date would be in one year. They wanted to create a smartphone app for their customers to get information in the trains about their seats, storage, and other information for their travel. The business team contacted the network team and asked for 1000 addresses per train for 1200 trains. There was no way to cover this unexpected demand with IPv4.
So they had to assign IPv6-only to the devices in the train. And because their backend infrastructure was still on IPv4-only, they had to go through translation to write the data into their backend. Had they started migrating the backbone step by step after 2014, chances are that the backend would have been reachable over IPv6. On top of this, because the Swiss Mobile provider had only a mobile IPv4 connection, the data had to be tunneled over this. We are talking about the year 2018. If all participants of the Internet would do their homework such scenarios could be much simpler.
Because IPv4 generates significantly higher costs in operation, maintenance, and troubleshooting, providers and ISPs are gradually moving to charge more for IPv4 services than for IPv6 services.
Azure, for example, has announced that it will start charging more for IPv4 addresses and prefixes in July 2022. A static IPv4 address now costs Microsoft $31.50/year, while static IPv6 addresses are free. (https://azure.microsoft.com/en-us/updates/azure-public-ipv6-offerings-are-free-as-of-july-31/)
The message after 20 years. IPv6 is specified in RFC 8200, dated July 2017. It is the current Internet protocol and is continuously optimized and developed.
IPv4 is specified in RFC 791, dated 1981 and it is not further developed. It is end-of-life since 2011, when IANA gave out the last five blocks of IPv4 addresses.
If you are responsible for the development and maintenance of an IPv4 network, you should be aware of this. It is an important aspect of investment protection. IPv4 creates a lot of unnecessary costs and will have to be migrated at some point. So whatever you install over or for IPv4 you will have to touch it again. Whatever you can deploy over IPv6 is a lasting investment. Isn’t it just common sense to invest in the current Internet protocol instead of troubleshooting, fixing, extending, and creating workarounds for an outdated protocol?
The goal should be to create an IPv6-only network as soon as possible as this is the leanest and most secure way to operate a network. Effective 29 June 2021, the US Department of Defense began its mandatory transition to IPv6, calling for all networked systems to switch to the most up to date version of the Internet Protocol (IP), Internet Protocol Version 6 (IPv6), by the end of the fiscal year 2025.
On the other end of the world, China has similar strategies. They set the goal for all levels of industries and government to run single-stack IPv6 networks by 2030.
(https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/)
This is good advice! Everybody being part of the Internet should aim to jump on this train.
*Including all editions and German translations, the author has published nine books on IPv6.
