David Holder — 07 Jun 2018
On a recent flight from the UK to the USA I sat next to the IT director for a global corporation. He asked me why I was travelling, to which I answered that I was giving the keynote presentation at an IPv6 conference held by the US Federal government. Without hesitation, his response was “IPv6 is not even on my radar.”
For many enterprises, IPv6 is a long way from being on their to-do lists. Many cite several blockers to adopting it. Here are the three biggest blockers that I’ve seen over 20 years of providing IPv6 services:
Blocker 1: Why should we fix something that is not broken?
Enterprises perceive IPv6 as a technology that gives them exactly what they have today; the Internet, but at increased cost and risk. They ask, “Why should we fix something that is not broken?” Enterprises see no difference between an Internet based on IPv4 and an Internet based on IPv6.
Even some leaders in the IPv6 community appear to agree with them. At the North American IPv6 Task Force in 2017, the President and CEO of the American Registry for Internet Numbers (ARIN) said, in his keynote presentation, that there is no real difference between the IPv4 and IPv6 Internets. His answer was to make IPv6 more attractive than IPv4 by making it more secure. I believe that this is wrong.
Blocker 2: We have no budget for IPv6
I hear this repeatedly. At another recent conference, the speakers were bemoaning their organisation’s lack of an IPv6 budget. Even though they wanted to deploy IPv6, they could not proceed due to a lack of funding. Many organisations see the initial cost of deploying IPv6 and the ongoing costs of managing it alongside IPv4 as prohibitive and, as a result, have not allocated any budget for the process.
Blocker 3: We lose the benefits of NAT44
Enterprises often use NAT44 at the edge of their networks, not for security, but for load-balancing and resilience. This is especially true of small and medium-sized enterprises that connect to multiple Internet providers and do not run BGP or have their own provider independent (PI) address space. Even large enterprises sometimes use NAT44 to ease the use of multiple providers.
For small and medium-sized enterprises that do not wish to obtain PI space and run BGP, IPv6 presents a big problem. There is currently no standardized IPv6 solution for these types of multi-homing scenarios.
Overcoming Blockers
Sometimes overcoming the blockers to IPv6 deployment is easy. Today there are many scenarios where organisations are driven to IPv6 to solve specific real-world problems. It is worth reiterating some of these drivers for IPv6 adoption here:
- Organisations that have exhausted their RFC1918 address space
- Organisations that have exhausted their allocated public IPv4 space
- Application providers developing apps for the Apple App Store
- Organisations with specific peer-to-peer requirements
- Cyber security organisations that must consider dual-stacks
- Those deploying the Internet of Things (IoT)
- New ISPs and service providers with an insufficient stock of IPv4 addresses
- Operators faced with the problems of deploying Carrier Grade NAT (CGN)
In recent months, I have spoken with clients who have deployed IPv6 for each of the reasons above.
Overcoming Blockers: Why should we fix something that is not broken?
This is a valid question, if and only if, we accept the underlying premise; that the IPv6 Internet is identical to the IPv4 Internet. Personally, I do not agree with this. More importantly, I see the differences between the two Internets as being some of the most powerful reasons for enterprises to adopt IPv6.
Most people understand that IPv6 has an unimaginably huge address space and that, in contrast, the IPv4 address space is tiny and completely exhausted. The IPv4 address exhaustion only directly affects a subset of enterprises. However, the indirect impact of exhaustion, affects all organisations. The scale of this impact depends upon how organisations use the internet and how important it is to their business.
There are several areas that are critical to enterprises that are worse in IPv4 than IPv6. These include:
-
Performance . In our experience, network latency is often less on IPv6 networks. This influences not only user experience but also influences factors such as search engine rankings. Studies into IPv6 performance generally do not measure a large sample of clients against a large sample of content providers at the same time. Therefore, it is difficult to give definitive measures. However, factors such as the size of the IPv4 routing tables and the latency due to CGN may go some way to explain our observations.
-
Reliability . Some applications fail intermittently over IPv4 networks. CGN between your site or your application and your customers or end-users can cause some applications to fail. You may have no control over which customers or end-users, are behind CGN. We found many examples of this whilst carrying our research on CGN for Ofcom, the UK’s telecommunications regulator. We knew that even applications designed to work through NAT44 can fail through CGN. In mobile networks, we suspected that intermittent failures are often being attributed to the mobile network when in fact they are caused by CGN. We looked at the support forums for UK mobile operators and searched for a well-known message application and intermittent faults. We found that there were many reports of intermittent failures using this application with the same phone, network and at the same location. We surmised, but could not prove, that this was due to CGN. The difficulties of logging in CGN make it impossible for the operators and application providers to prove this too. Interestingly there was a special thread on the application’s support forum discussing the same symptoms.
-
Analytics . Web analytics is very important to organisations of all sizes. Again, CGN in the path from your end-users can make tracking users by address impossible. You have no control over this as you cannot control how your end-users, partners or potential clients connect to the internet.
-
Governance, security, forensics and legal intercept . The relationship between IP address and end-user in the IPv4 internet is becoming more dynamic and unreliable. This is due to the CGN being in the path. Again, you have no control over when CGN will be in the path. Therefore, forensics and legal intercept becomes more difficult. This led the Belgium government to mandate a limit on the CGN compression ratio of 16:1. This is widely seen as one of the key drivers in the adoption of IPv6 in Belgium. More recently Europol advocated the banning of CGN. Without CGN it will be impossible to continue to keep the IPv4 functioning. For more information see https://tools.ietf.org/html/draft-daveor-cgn-logging-04, https://www.europol.europa.eu/activities-services/main-reports/internet-organised-crime-threat-assessment-iocta-2016, https://www.europol.europa.eu/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online and my CGN presentation and report referenced later in this article.
-
Failure of important functionality . For example, the widescale sharing of IPv4 addresses in the IPv4 internet means that the usefulness of geolocation has deteriorated to the point that in some cases it is no longer meaningful. This impacts web-sites, analytics, forensics and applications that use geolocation. Again, the enterprise has no control or knowledge of whether geolocation is being degraded.
Whilst enterprise managers have no interest in the technical details of IPv4 imperfections like CGN, they are very interested in the business implications.
It is important to reiterate that enterprises have no control over whether their customers are behind CGN. Worse, they will usually not be able to even detect that they are behind CGN.
The intermittent nature of these and other problems means that it is hard for enterprises to be aware that these problems exist. Even if they do detect them, the lack of visibility means that is often impossible for them to attribute them to deterioration in the IPv4 internet. Therefore, we need to educate enterprises on the deterioration of the IPv4 internet in terms which they can understand.
For more information on this topic, I would suggest viewing my presentation from last year’s North American IPv6 Task Force (NAv6TF) meeting (https://youtu.be/fbk4H6EmZzI) or the UK telecom’s regulator Ofcom’s CGN report at http://stakeholders.ofcom.org.uk/binaries/research/technology-research/2013/cgnat.pdf.
A brief side note – I do not think that making IPv6 ‘better’ through more stringent security will work. Remember Microsoft Windows Vista? It was more secure. Businesses should have welcomed this. Instead, users widely hated Vista because the security got in their way. We do not want IPv6 to become the networking equivalent of Windows Vista.
I do agree that if we find desirable functionality that is only possible in IPv6 then this is a useful incentive towards IPv6 deployment. We have had clients that have deployed IPv6 for these types of reasons such as deploying Microsoft’s DirectAccess or because Apple mandated IPv6-only support for all apps in the Apple App Store.
We have been searching for an IPv6 “killer app” for over twenty years. It remains elusive. The problem is that the killer app is the Internet itself and both IPv4 and IPv6 appear to provide this.
Instead, we should focus on how the IPv4 Internet is measurably deteriorating. And how, in sharp contrast to IPv4, IPv6 overcomes all the things that are leading to problems in IPv4.
Overcoming Blockers: We have no budget for IPv6
Deploying IPv6 can require a significant budget. However, this is not necessarily the case. Indeed, with foresight it is possible to eliminate many elements of an IPv6 budget in their entirety.
It is prudent in business to avoid unnecessary costs. In the case of IPv6 deployment a few simple policies can both facilitate the deployment of IPv6 and reduce the budget required significantly. Here are some examples:
Purchasing
Implement a purchasing policy that states that all network hardware, software and services purchased must be “IPv6-ready”. Not doing this runs the risk of making purchases that will need to be replaced when IPv6 is deployed. Defining and communicating what “IPv6-ready” is can be difficult. However, for may enterprises this statement alone, without further definition, will go a long way to creating an IPv6 deployment ready environment without the need for any additional budget.
Note that RIPE and other organisations have produced helpful guidance on IPv6 purchasing.
IT Training
Mandating that all IT training that has any reference to IP networking must include IPv6 along with legacy IPv4. Do not forget to include IPv6 as a requirement when recruiting new IT staff.
Opportunities for Stealth Deployments
I am not advocating deploying IPv6 without authorisation, rather I am recommending that enterprises should be thinking of how other IT projects could be used to deploy IPv6. For example, an office move might be an opportunity to make a new network IPv6-ready, IPv6-enabled or even IPv6-only. We have clients, with no specific IPv6 budget, who have deployed new networks as IPv6-only. Not only does this have no IPv6 deployment cost, but it also avoids the additional cost of operating a dual-stack environment.
The common denominator in all the examples above is that to do this an organisation needs to be thinking of IPv6. There needs to be an acceptance that IPv6 is the future and a determined effort to seek opportunities to deploy it. Otherwise, IPv6 deployment will remain a project with a budget that may be difficult to justify.
Overcoming Blockers: We lose the benefits of NAT44
Currently there is no good IPv6 solution for the subgroup of enterprises that use NAT44 for multihoming. Some will resolve this problem by obtaining PI space and either running BGP themselves or having their ISPs advertise their PI space on their behalf. Others will resort to undesirable solutions such as Network Address Prefix Translation (NPTv6).
In the future, enterprises will be able to use new standards-based solutions such as Provisioning Domains (draft-ietf-intarea-provisioning-domains-01), Enterprise Multihoming using PA Addresses (draft-ietf-rtgwg-enterprise-pa-multihoming-06) or Source Address Dependent Routing (draft-ietf-rtgwg-dst-src-routing-06). Until then, this remains a problem that is most likely to be addressed by using NPTv6.
Final Comments
Underpinning everything in this post is the need for a change of thought. The world today thinks of IPv4 as being the current version of the Internet protocol. IPv6 is seen as an addition that can be added on as a secondary, less important protocol. For any movement in the deployment of IPv6 to take place, we need to have a change in thinking. We, and others, need to believe that IPv6 is the current version of the Internet protocol and that IPv4 is a legacy protocol, inferior, broken and deteriorating.