Feature versus Functional Parity in IPv6 – Why knowing the difference between them is important.
I am an IPv6 evangelist and so sometimes it is hard for me to let go of the fact that not everything will support IPv6 right away, no matter how much complaining I do (see Tom Coffeen’s post on the state of IPv6 and Cloud to understand some of my frustration!). But perspective is important and that is why I want to cover an often overlooked topic: understanding the difference between feature and functional parity, especially around IPv6.
I was recently on the Datanauts podcast with Ethan Banks and Chris Wahl talking about Assessing IPv6 Readiness when this topic came up. I was not able to cover in as much detail as I would have liked some of the practical considerations around how organizational divisions deal differently with IPv6 feature and functional disparities. Hence, this blog post!
So let’s first define some terms, so that we all start with the same basic understanding.
Feature parity – While there are a lot of definitions of parity, in this case we are talking about the ability of a product or service to fully operate with IPv6 just as it does for IPv4. Each feature and capability has IPv6 and IPv4 support and can operate in a dual-stack or single stack configuration and not require any special work on the part of the operator to support both. For the sake of argument we will assume any specific protocol properties are excluded. For instance, you wouldn’t see a Router Advertisement tuning feature in IPv4 since RAs are an IPv6 specific feature. However, you might see identical features available for first hop security in both IPv4 and IPv6.
Functional parity – I consider functional parity different from feature parity in the following ways. For one, the goal is different. You are attempting to get the same functional outcome. However, you do not require IPv6 end to end to achieve that outcome. It is easiest to explain this with an example. Logging is a very common thing to do in networks today and it is done for about every application, service, compute and network device you operate. Let’s assume you are using Splunk for logging data collection within your environment. You use it to correlate data between all the services. Splunk supports IPv6 – both as data within the log information that is sent to it, but also as a protocol to listen on for that remote systems log data.
Put simply, feature parity means that every system on your network must be able to connect to Splunk over IPv6 just as it does with IPv4 and it must be able to provide IPv4 and IPv6 data in that connection to the logging service. Functional parity, by comparison, simply requires that all those systems connect in some way (IPv4 or IPv6 or both) to the logging service and provide the logging data. Normally I would say it must include the capability to provide IPv6 information in the data set to the logging service but that might not be a requirement in all cases.
So what is the outcome difference between feature and functional parity? Specifically, it comes down to matching what your business needs are as well as the investment you must make to acquire the feature or function you need. For the majority of the companies functional parity is enough to fulfill their business needs for IPv6. I would include using IPv6 transition technologies in the functional category. There are a few cases where full feature parity is required. There are those that advocate for feature parity as the benchmark, like Ron Broersma with the Defense Research and Engineering Network (DREN) who has built and operates SPAWAR (one of the military’s most advanced enterprise networks). This is natural as these networks are IPv6 only and therefore needs full feature parity in order to effectively operate. It is difficult to meet the mission of an IPv6-only network without actual feature parity.
Next is a method for determining if you need feature or functional parity for IPv6 in whatever product or solution you are responsible for in your environment. This is relatively easy for those using public SaaS cloud products. These you have little control over and must simply track what those providers are doing around IPv6. For those that are still deploying and operating solutions in their own environment the process is a bit more involved.
First, the business use case and drivers should dictate what you need to support around IPv6. If your business application needs to support IPv6 then you likely need feature parity. An example of this is the recent announcement from Apple that all iOS apps in the app store would be required to support IPv6 in order to be included in the store to guarantee they functioned on all major mobile provider networks. This makes sense because those mobile providers have deployed and are preferring IPv6. This is a business driver that forced IPv6 feature parity.
However, you may be in a situation where your application is able to store and work with IPv6 data while it is still on a network that is IPv4-only. This might be the logging example where Splunk is more than capable of reporting and processing IPv6 data from a web server in the log stream. The web server is obviously providing that stream of data over an IPv4 network connection to Splunk but it still meets the functional requirement. You need a report or data processing for all the web connections (which happen to have IPv6 also) and since you can accomplish exactly that, you have functional parity. This functional parity might work for the interval of time required to deploy full IPv6 support. At that point, the path to full feature parity becomes available.
The most common mistake many companies make is in RFPs and RFIs that ask for feature parity capabilities while functional parity would suffice for their operational needs. This can increase the cost with little or no value added to the project. It could also limit the number of vendors or products you have available to evaluate. Rather than fixating on feature parity, it’s important to ask what their IPv6 roadmap is and what is their level of commitment to deliver IPv6 features (e.g., actual dates for code release and what features will appear). How they are progressing with past targets of getting IPv6 support into their product can also be a good indicator. Those are perhaps far better benchmarks to determine if you have picked a product or solution with a genuine IPv6 future. If they have been unable to deliver in the past their likelihood of success in the future is probably poor. This can greatly limit your ability to move from functional to feature parity. Build a rating scale that gives more weight to vendors that have done a good job with IPv6. It matters to your long term investments!
As a final thought, the ultimate goal is still a full migration to IPv6 which really does mean full IPv6 feature parity. The problem is that the costs may be prohibitively high to purchase IPv6 feature parity today when functional parity may meet immediate operational needs. In such a case, functional parity is the practical and cost effective approach. Understanding the difference can be the key to tackling your IPv6 adoption plan and staying on budget.
You can find me on twitter as @ehorley and remember…
IPv6 is the future and the future is now!
– Ed
