“It slices, it dices, it even makes Julienne fries!” “Yes, but does it support IPv6?”
Most of us in IT have spent a fair amount of time at tech trade shows over the years. We’re used to the attendee ritual of schlepping around from booth to booth with our bags of cheap, logo-emblazoned USB accessories and t-shirts: “Sorry, all we have left are XXL.” — or “IT medium,” as some wag once dubbed it.
As for me, I decided back around 2010 that I had accumulated enough IT t-shirts to clothe a small town and have since (mostly) held firm against the enticement to collect just one more. Not hunting for cool tees left me more time to hit up each dazzling display, each amiable cadre of savvy/slick tech marketers, with what is obviously the most important question that can ever be asked of any vendor: “Does your platform support IPv6?”
In the spirit of the carnival-like atmosphere of trade shows, responses to that query were often chipper and encouraging, if also rather suspect or vague:
“We’ve had IPv6 support from the very beginning!”
“Of course it supports… that!”
Or
“Give me your business card and I’ll have someone contact you.”
Very occasionally (bordering on the miraculous), I might be pleasantly surprised by a detailed response, credible for its technical accuracy and honesty about vendor roadmap priorities.
But the most frequent response was likely some variation of “We have limited or no support for IPv6 because [wait for it…] no one is asking for it.”
But here’s the wrinkle: If you stand inconspicuously within earshot after receiving that reply, you probably won’t have to wait long before another attendee asks the same question and receives the exact same reply. And then another, and another. Not every attendee, of course, but enough to make you wonder what obscure subjunctive mood of the phrase “no one is” you had failed to learn back when you were studying (or pretending to study) English grammar.
Fortunately, a vendor that just flat out refuses to support IPv6 these days is rare. And in a way, it actually makes our jobs a little easier: You can very likely just cross them off the list of vendors under consideration. This can be a real time-saver when that particular vendor’s space is crowded with competitors.
But that still leaves us with the challenging task of determining just exactly what “IPv6 support” means for those vendors who, when we asked, smiled, puffed up their chests, and boldly answered: “Of course it supports…that!”
Exactly What is IPv6 Support?
IPv6 Feature vs. Functional Parity
When we first think about deploying IPv6, a bedrock assumption is that we’ll be using IPv6 first and foremost to solve the IPv4 scarcity problem. For most operators and environments this is the primary use case for IPv6. That means using IPv6 to do what you now do with IPv4. Since the two protocols are not compatible and since most operators aren’t able to deploy IPv6 and then immediately turn off IPv4, that means that both protocols will be running in the network at the same time (i.e., dual-stack). This means that both protocols will be available to provide network functionality. And while the network is operating in this transitional phase of dual-stack, either or both of the protocols may be used to provide a particular feature or function. The ability of one protocol to deliver the same feature or function as the other is often referred to as parity. Parity between the protocols is obviously desirable: “I’ve been doing this with IPv4. I’ll be able to do the same thing going forward with IPv6.” But there’s a complicating factor involved that can best be summarized with the phrase feature vs. functional parity (for more context, see Ed Horley’s CoE blog covering this topic).
To explore what that phrase means, let’s pick on our favorite DDI platform along with one of the Ds it offers: DHCP. In Infoblox NIOS, DHCP as a feature is supported for both IPv4 and IPv6 (as DHCPv6). Furthermore, beyond this feature parity, there is also functional parity between the two. The function in this case is a host getting a usable IP address automagically (i.e., without having to manually configure one). But let’s imagine some parallel universe where Infoblox hadn’t been the forward-looking DDI vendor that included DHCPv6 in NIOS so many moons ago. In that case, we wouldn’t be able to claim feature parity between IPv4 and IPv6 for DHCP. But would we still have functional parity? Yes! In this particular case, an automagically configured address could be provided by the IPv6 protocol itself through its built-in mechanism of Stateless Address Auto-Configuration (SLAAC). In both universes, hypothetical and real, SLAAC is not something provided by the NIOS platform and so in our parallel universe Infoblox the vendor couldn’t claim it was providing functional parity. But the deployer of IPv6 would have functional parity with IPv4 DHCP nonetheless.
Would using SLAAC instead of DHCPv6 meet all of the operational requirements for the customer deploying IPv6? Of course, DHCP is doing more than simply providing the function of an automatically provisioned interface address. It’s also designed to give us the ability to track which addresses are assigned to what devices, an important feature to have in an enterprise network and one that isn’t really built into SLAAC. As a result, the functional parity for auto-addressing between DHCPv6 and SLAAC exists but is limited.
IPv6 Compliance
A more sophisticated version of the initial question of “Does your product or platform support IPv6?” might be “Is your product IPv6 compliant?” But what does that mean exactly? In most cases, there seems to be an assumption by the IT buyer asking that question that formal standards for IPv6 features and functions exist (generally understood to be IETF RFCs). A further assumption is that some threshold of meeting these standards can be surpassed by the vendor resulting in some condition of “compliance.” But hardware and software meeting this basic definition of compliance may not necessarily provide IPv6 features or functionality that meet the operational or design needs of the would-be purchaser. (And here the snarky voice in my head huffs “I mean, seriously. Have you ever actually read a major IPv6 RFC?! Those suckers are crammed full of potential features and functionality! Do I even need all that stuff for my network deployment and administration?!”) Also, “IPv6 compliance” for a feature or function may assume deployment in a dual-stack network. What happens when those same features are deployed in an IPv6-only environment?
With this in mind, a vendor may assert “We’re in compliance with IPv6 RFC $NUMBER.” And it’s entirely likely that some critical IPv6 functionality contained in the RFC is actually supported in the vendor’s product or platform. Still, what mission critical applications or operations will rely on this feature once you have fully deployed dual-stack IPv6 or migrated to IPv6-only? Should you leave the function and performance of these applications entirely to the mercy of vendor assurances of IPv6 support? Ideally, to better manage the risk of your IPv6 deployment, some independent validation of IPv6 features and functions is prudent.
Such independent verification and validation (IV&V) can take different approaches depending on the degree of risk management desired or required. IT product conformance testing can be an expensive and time-consuming process.
Validation of IPv6 Features and Functions: A Continuum for Assessing Risk
More Risk
We’ve already talked about the least amount of IPv6 feature support validation, resulting in perhaps the greatest operational risk: Vendor representative/marketing assertions and/or published lists of IETF RFCs complied with or conformed to. But other vendor validation steps might include:
- Roadmap review for IPv6 features and feature development
- An IPv6-only support timeline
- Lists of any IPv6 bugs and how (or if) they were resolved
Some independent validation can be accomplished by IT staff with a review of RFCs and a list of follow-up questions to the vendor to determine the actual degree of feature support along with any gaps.
Along these lines, the European Regional Internet Registry, RIPE, published the document RIPE-772 Requirements for IPv6 in ICT Equipment classifying network equipment types and what IPv6 RFCs align with each equipment type.
Less Risk
It’s less risky when vendor assertions of IPv6 compliance for their hardware and software are checked. Such claims can be measured against independent product validation testing by accredited third-party labs. For example, IPv6 Forum’s IPv6 Ready Logo program is “a conformance and interoperability testing program intended to increase user confidence by demonstrating that IPv6 is available now and is ready to be used.” The IPv6 Ready Logo program tests product support of the core IPv6 protocol and IPv6 CE router functionality.
Meanwhile, the University of New Hampshire Interoperability Lab (UNH-IOL) offers “accredited testing for both the USGv6 and IPv6 Ready Logo test programs” for the following product categories:
- IPv6 Application
- IPv6 CE Router
- IPv6 Host
- IPv6 Router
- Network Protection Products
They also offer a licensable tool (IOL INTACT) for on-premise pretesting and internal validation. The US government standard for IPv6 compliance tested by UNH-IOL is captured in the NIST USGv6 program documentation. (And for more on this topic check out the IPv6 Buzz Podcast Episode 85 “Is Your Network Ready for IPv6” and Episode 72 “NIST and Testing IPv6 Interoperability.”)
Least Risk
You might be reasonably confident that vendor claims of IPv6 feature and function support are reliable — especially based on third-party accredited lab testing of your hardware and software. But the least amount of risk to your production network from deploying IPv6 will come from testing IPv6 features and functions in a lab you build yourself (give a listen to IPv6 Buzz Episode 70 “Building an IPv6 Lab”). Such a lab will necessarily incorporate your existing operational environment, including both the network as well as the applications relying on it. It allows for the establishment of a baseline for application and service functionality prior to the introduction of IPv6 into the environment. IPv6 features and functions can be tested independently or as a whole. Operational wisdom can be gleaned and documented to be passed along to support staff. Such independent validation of IPv6 deployment and operation so specific to one’s network environment can’t be beat for reducing the risk that IPv6 deployment will impact something critical.
To sum up, vendor claims of IPv6 support should be welcomed but understood and further validated in the following contexts:
- There are subtle but real differences between IPv6 features and functionality and their parity with IPv4.
- “IPv6 compliance” with standards – including IETF RFCs – can be critical or entirely meaningless depending on how IPv6 is being deployed and for what purpose.
- Third-party-accredited lab testing of IPv6 features and functions can provide additional confidence that IPv6-enabled hardware and software will operate and perform as expected.
- A custom lab allows for independent validation of IPv6 deployment and operation specific to one’s network environment, lowering the risk of IPv6 deployment to the greatest degree.
Thanks for reading! Perhaps you are already evaluating vendor claims of IPv6 support or even testing IPv6 in a custom lab. Please leave a comment to share your questions or experience.
