My interest in IPv6 dates back to 1997. At that time I was writing my first technical book, “Troubleshooting TCP/IP.” As I reached the last chapter, I felt the urge to go out and see what the future could be like. That's how I found Christian Huitema's first 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, one that will eventually help solve the IPv4 addressing problem". I think it was the only book available on IPv6 at the time. I can't explain why, but for some reason this topic fascinated me.
So, when O'Reilly called me three years later and asked if I could write a book on IPv6 for them, I didn't hesitate to say yes. I knew from experience writing the first book on TCP/IP that there is no better way to learn something than by writing a book on the subject. And I was convinced that IPv6 would be the future Internet Protocol, so it was well worth delving into it. In those early years, not many had heard of IPv6, so it was mainly developers who supported me in my writing process. And so I learned from the source.
Challenges along the way.
The design of IPv6 began in the early 1990s. Published in 1995, RFC 1752 was the first RFC on IPv6. At that time it was called IPng (next generation). Already in those early days of the Internet, developers anticipated that the IPv4 address space would be exhausted at some point. They estimated it would happen between 2012 and 2015 (in retrospect, that was a very good prediction!), so they decided they had enough time to not only expand the address space but also try to make the protocol more scalable for large Internet structures.
As for the challenges to the development and deployment of IPv6, I suppose it was that NAT (Network Address Translation) became increasingly popular to solve the problems arising from address limitation before IPv6 was mature enough to its implementation. IPv6 was published in 1998 with RFC 2460, a draft RFC, and it took some time for vendors to make their first implementations. So, by the time IPv6 was ready to use, many had already implemented NAT to “solve” the pressing problems with address throttling and saw no reason to deploy IPv6.
From a short-term perspective, this is understandable. However, it does not support a long-term perspective from a network architecture point of view and also from a business case perspective. Thinking long term, NAT should be replaced by the solution created to solve the addressing problem, i.e. IPv6.
If we look at this through the lens of the Internet, companies should understand that we are all participants and co-creators of the Internet. Whether or not they offer their Internet services, for example websites and online stores, over IPv6 has a big impact on other ISPs and end users. For all services offered over the Internet, the recommendation is to offer them in dual-stack form , which means that they are accessible through both IPv4 and IPv6. This way, each end user can access the site through the protocol with which they obtain the best performance.
For an ISP, operating costs are substantially lower if it has an IPv6 route. It is much easier to maintain and offload traffic from your IPv4 route (which is typically a complex NAT structure that incurs a high maintenance cost). Therefore, every public website that offers its services over IPv6 downloads traffic from the IPv4 route and transports it over the most efficient IPv6 route to all ISPs on the route. Depending on how you are connected to the Internet, for the end user this can be a big advantage in terms of performance: if your ISP has a complex and perhaps overloaded NAT structure for IPv4, over IPv6 you can access any dual -Internet service. stack .
Swisscom, a Swiss ISP that has been offering dual-stack Internet to its DSL users since 2012, evaluated its operating costs after five years. The results were interesting.
Cost for an effective transfer rate of 1 Gb/s:
6th: CHF 1'650.00
IPv4 CG-NAT: CHF 8'000.00 (no registration fee)
This means that for Swisscom, delivering data over IPv4 is more than four times more expensive than delivering data over IPv6. More than 35% of its backbone traffic is IPv6 (2017 figures). The IPv6 route reduced the load of the IPv4 route by 9 Gb/s.
Therefore, it would be a major improvement for public websites to offer their services in a dual-stack manner (which is actually a no-brainer from a technical point of view) and for companies to give their users dual-stack access to the Internet. This would substantially increase IPv6 traffic on the Internet and reduce IPv4 traffic.
IPv6: difficulties in organizations.
The main problem I see today is that it is very common—especially in large organizations— to make decisions with a short-term perspective. If something does not generate profits in a few months, it is often eliminated from the budget. And money is usually a good excuse to not have to do things that people don't want to deal with. In many discussions with customers I find that they believe IPv6 is too complex and they will not be able to master it. It may seem overwhelming, I agree, but only if we don't take the time to look at it more closely. If we look closer, we will see many examples of companies that have led by example and found that it is easier and less expensive than they expected. On the other hand, it is difficult to manage an IPv6 project without support at the management level, since it is necessary to have shared priorities and objectives between different departments.
Another reason that is slowing down IPv6 implementation is that IPv6 is seen as a standalone project. Thus, each year it is analyzed as part of an annual budget and it is decided that there is no time and that the money is needed for other projects that seem more important. The fact is that IPv6 is not a stand-alone project, but should be seen as an integral part of any other project. Because all IT projects run on the same network of which IPv6 is an integral part, as is security. No one would say “we don't have time or money for security.” Now we have to deploy our new data center. We will deal with security later.” This doesn't make sense, right? The same thing happens with IPv6!
And when we consider that IPv6 is an integral part of any project that uses the network, it is no longer something huge, super complex and mind-blowing, but can be approached step by step, by project. Obviously, there are some aspects that need to be addressed in all projects, such as the overall architecture, direction plan, and security concept. This should be done at the beginning and then serve as a framework for each individual project.
Organizations are not aware of hidden costs of running their IPv4 networks.
A large organization I worked with recently looked at this issue more carefully. One of their costs was that they had to buy IPv4 addresses. The market price of an IPv4 address has increased significantly in recent years. In 2013, when Microsoft bought Nortel's IPv4 addresses, it paid about $12 for each address. Today, the cost of an IPv4 address has increased to between $50 and $60 (https://www.ipxo.com/blog/ipv4-price-history). This customer paid around a million dollars for a /16 IPv4 address. If they had included IPv6 in their planning early enough, they could have saved these costs or been able to invest this money in IPv6 deployment.
This customer also discovered that a large portion of their downtime and troubleshooting costs were generated by complex NAT structures and devices. Therefore, when evaluating the cost of implementing IPv6, these costs should be considered as savings.
Another case in which unnecessary costs and problems were generated by not implementing IPv6 was that of the Swiss railway company SBB. In 2014 they had started working on the issue by creating an address plan. Instead of beginning a step-by-step implementation, the direction plan went into a drawer and remained forgotten. A few years later, the business team decided to launch a new service. The release date would be in a year. They wanted to create a smartphone app so their customers on trains could get information about their seats, storage space, and other information related to their trip. The business team contacted the team responsible for the network and asked for 1,000 addresses per train for 1,200 trains. This unexpected demand was impossible to satisfy with IPv4.
So the devices on the train had to be assigned only IPv6. And since their backend infrastructure was still IPv4 only, they had to do a translation to write the data to their backend . If they had started migrating the backbone step by step after 2014, the backend would most likely be accessible via IPv6. Furthermore, since the Swiss Mobile provider only had an IPv4 mobile connection, the data had to be channeled through it. We are talking about the year 2018. If all Internet participants did their homework, these scenarios could be much simpler.
Because IPv4 results in much higher operation, maintenance, and troubleshooting costs, providers and ISPs are gradually starting 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 per 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 was specified in RFC 8200, which dates back to July 2017. It is the current Internet protocol and is constantly being optimized and developed.
IPv4 was specified in RFC 791, which dates back to 1981 and is no longer in development. It reached the end of its useful life in 2011, when the IANA handed over the last five blocks of IPv4 addresses.
Those responsible for developing and maintaining an IPv4 network must take this into account. It is an important aspect of investment protection. IPv4 generates many unnecessary costs and at some point it will be necessary to migrate to IPv6. This means that anything we install over or for IPv4 will have to be modified. Everything we can implement over IPv6 is a lasting investment. Isn't it common sense to invest in the current Internet protocol instead of troubleshooting, fixing, extending and creating alternative solutions for an outdated protocol?
The goal should be to create an IPv6-only network as soon as possible, as this is the simplest and most secure way to operate a network. Beginning June 29, 2021, the U.S. Department of Defense began its mandatory transition to IPv6, requiring all networked systems to move to the most up-to-date version of the Internet Protocol (IP), Internet Protocol version 6. (IPv6), before the end of fiscal year 2025.
On the other side of the world, China has similar strategies. Its goal is for all levels of industry and government to deploy single-stack IPv6 networks by 2030.(https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/)