{"id":7708,"date":"2022-05-06T14:31:29","date_gmt":"2022-05-06T21:31:29","guid":{"rendered":"https:\/\/blogs.infoblox.com\/?p=7708"},"modified":"2022-05-06T14:34:18","modified_gmt":"2022-05-06T21:34:18","slug":"evaluating-vendor-ipv6-support","status":"publish","type":"post","link":"https:\/\/www.infoblox.com\/blog\/ipv6-coe\/evaluating-vendor-ipv6-support\/","title":{"rendered":"Evaluating Vendor IPv6 Support"},"content":{"rendered":"

\u201cIt slices, it dices, it even makes Julienne fries!\u201d \u201cYes, but does it support IPv6?\u201d<\/h2>\n

Most of us in IT have spent a fair amount of time at tech trade shows over the years. We\u2019re used to the attendee ritual of schlepping around from booth to booth with our bags of cheap, logo-emblazoned USB accessories and t-shirts: \u201cSorry, all we have left are XXL.\u201d \u2014 or \u201cIT medium,\u201d as some wag once dubbed it.<\/p>\n

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: \u201cDoes your platform support IPv6?\u201d<\/p>\n

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:<\/p>\n

\u201cWe\u2019ve had IPv6 support from the very beginning!\u201d<\/p>\n

\u201cOf course it supports\u2026 that!\u201d<\/p>\n

Or<\/p>\n

\u201cGive me your business card and I\u2019ll have someone contact you.\u201d<\/p>\n

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.<\/p>\n

But the most frequent response was likely some variation of \u201cWe have limited or no support for IPv6 because [wait for it\u2026] no one is asking for it<\/strong>.\u201d<\/p>\n

But here\u2019s the wrinkle: If you stand inconspicuously within earshot after receiving that reply, you probably won\u2019t 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 \u201cno one is\u201d you had failed to learn back when you were studying (or pretending to study) English grammar.<\/p>\n

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\u2019s space is crowded with competitors.<\/p>\n

But that still leaves us with the challenging task of determining just exactly what \u201cIPv6 support\u201d means for those vendors who, when we asked, smiled, puffed up their chests, and boldly answered: \u201cOf course it supports\u2026that!\u201d<\/p>\n

Exactly What is IPv6 Support<\/em>?<\/h2>\n

IPv6 Feature vs. Functional Parity<\/h3>\n

When we first think about deploying IPv6, a bedrock assumption is that we\u2019ll 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\u2019t 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<\/em>). 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<\/em>. Parity between the protocols is obviously desirable: \u201cI\u2019ve been doing this with IPv4. I\u2019ll be able to do the same thing going forward with IPv6.\u201d But there\u2019s a complicating factor involved that can best be summarized with the phrase feature vs. functional parity<\/em> (for more context, see Ed Horley\u2019s CoE blog covering this topic<\/a>).<\/p>\n

To explore what that phrase means, let\u2019s 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<\/em> parity<\/em>, there is also functional parity<\/em> 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\u2019s imagine some parallel universe where Infoblox hadn\u2019t been the forward-looking DDI vendor that included DHCPv6 in NIOS so many moons ago. In that case, we wouldn\u2019t 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\u2019t claim it was providing functional parity. But the deployer of IPv6 would have functional parity with IPv4 DHCP nonetheless.<\/p>\n

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\u2019s 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\u2019t really built into SLAAC. As a result, the functional parity for auto-addressing between DHCPv6 and SLAAC exists but is limited.<\/p>\n

IPv6 Compliance<\/h3>\n

A more sophisticated version of the initial question of \u201cDoes your product or platform support IPv6?\u201d might be \u201cIs your product IPv6 compliant?\u201d 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 \u201ccompliance.\u201d 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 \u201cI 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?!\u201d) Also, \u201cIPv6 compliance\u201d 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?<\/p>\n

With this in mind, a vendor may assert \u201cWe\u2019re in compliance with IPv6 RFC $NUMBER.<\/em>\u201d And it\u2019s entirely likely that some critical IPv6 functionality contained in the RFC is actually supported in the vendor\u2019s 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.<\/p>\n

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.<\/p>\n

Validation of IPv6 Features and Functions: A Continuum for Assessing Risk<\/h2>\n

More Risk<\/h3>\n

We\u2019ve 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:<\/p>\n