Many of us assume that most vendors’ products or services support IPv6, right? If this question were asked in a Request for Proposal (RFP), they are sure to check the “my product is IPv6 ready” box. But what exactly does that mean—does that mean you can confidently deploy the device in your production IPv6 network? You see that IPv6 is listed as a supported protocol on the product spec sheet, but will it work in your environment? And what if your production network must operate IPv6-only?
Unfortunately, a number of products do not support top-to-bottom IPv6 today. We will delve into this topic to create a better understanding of what IPv6-only means, and attempt to nudge vendors, many of whom have devoted considerable resources to support IPv6 already, over the finish line. This blog will not call out or shame any particular vendor (though you know who you are!), rather it is an attempt to obtain better IPv6-only buy-in.
When I was younger, to make the point that IPv6 support should be standard, I often joked that “IPv6 is old enough to drink.” Sadly, I’ve been saying that for years now. Why are some vendors still centering their attention on IPv4? At this point IPv4 is merely a holdover that we should be accommodating, not focusing primary development around. Below I will attempt to provide some context on this topic.
The IPv6-only Federal mandate and enterprise push
There is a true need for network products and services to operate in the absence of IPv4. Public and private organizations alike have recognized this and are making the push. In November of last year (2020), the Office of Management and Budget (OMB) issued Memorandum M-21-07 “Completing the Transition to Internet Protocol Version 6 (IPv6)”, which outlines the Federal government’s strategic intent to “deliver its information services, operate its networks, and access the services of others using only IPv6.” There have been other Federal government IPv6 mandates dating back to 2005, but this document has more “teeth” and dictates concrete and aggressive IPv6-only goals that must be met. The memorandum includes typical structural directives dictating the creation of a project team, IPv6 pilots, drafting an implementation plan, etc. But at the heart of the directive are milestones to “fully enable native IPv6 operation.” The memorandum requires Federal agencies to develop and implement plans to ensure that “at least 80% of IP-enabled assets on Federal networks are operating in IPv6-only environments by the end of FY 2025,” with initial, incremental targets for 2023 (20%) and 2024 (50%). Finally, agencies must provide a plan and schedule to replace or retire systems that cannot be converted to IPv6. This is an aggressive directive. And to be clear, this mandate does not accommodate dual stack (IPv6 and IPv4) environments. Replacing any device that cannot operate in the absence of IPv4 should be a wakeup call for vendors wanting to continue to do business with the Federal government.
The Federal government does not have a monopoly on the IPv6-only focus. An ever-increasing number of enterprises are jumping on board too. The business drivers vary, but typically revolve around performance, scalability, simplicity, and address scarcity. Running IPv6 can also makes mergers and acquisitions (M&A) much simpler. Starting an IPv6 adoption program has long been a recommendation for enterprises, and those with vision have taken this guidance and acted on it. The operational cost of running IPv4 is going up (never mind the actual cost of IPv4 addresses) and enterprises realize it. The benefits, best practices, and lessons learned from those that have already rolled out IPv6-only networks was summarized in one of my previous Center of Excellence posts. It is good to see enterprises, which have traditionally lagged, starting to get onboard the IPv6-only adoption train. Proper IPv6-only product support from their vendors will be a key to their success.
What constitutes IPv6-only product support?
IPv6 protocol support cannot be encapsulated as a singular thing. In other words, support for IPv6 is not a simple “yes/no” matter. IPv6 is defined by hundreds of various RFCs and standards. A vendor may claim to “support IPv6”, but do they support RDNSS (RFC 8106), or IPv6-signaled LDP (RFC 7552), or Segment Routing v6 (SRv6, RFC 8986), or…? Perhaps you get the picture: “IPv6 support” can mean many different things that may or may not be operationally relevant to your organization and its network. Ultimately, an enterprise will need to create a feature/support matrix based on their individual networking requirements to assist in product selection. If an enterprise needs DHCPv6 (because they use DHCPv4 and want operational consistency), what version of Network Operating System (NOS) is required in the vendor’s code to support that feature?
When formulating this feature/support matrix, it is important to maintain a broad view of what constitutes IPv6-only. Generically, all three network planes (i.e., data, control, and management) need to function without IPv4. It is common for IPv6 vendor support to be strong and relatively mature in the data plane. Starting in the data plane makes sense if the assumption is that customers operate in a dual stack environment. The vendor wants to make sure, first and foremost, that they can move IPv6 packets. However, IPv6 support in the data plane alone is not sufficient for IPv6-only environments.
For vendors, supporting IPv6 is typically an evolution—especially if there is protocol baggage like a long history of IPv4 in the product line. A common progression is building IPv6 support into the data, then control, then management planes. There is even evolution within each plane. Initially, only static routes may be supported in the control plane. Later, support may be added for dynamic routing protocols such as OSPFv3 and MP-BGP.
While data plane features may be mature, vendor IPv6 support can be weaker when it comes to the control and management planes. The questions to ask your vendor to gauge their progress on IPv6 include, “Can I manage the device over IPv6?”, “Can the device be patched over an IPv6-only network?”, “Does the SDN underlay (control plane) support IPv6?” It is possible that an SDN fabric can pass IPv6 packets (data plane) but not be able to be managed, nor configured using IPv6-only. Also, the product should support full FCAPS management (fault, configuration, accounting, performance, security)—from GUI access to SNMP polling to RESTful APIs to logging to security. There should no management feature fall-off when migrating to IPv6. To assist, if a vendor claims that something can be done via IPv6, ask them for configuration scripts. That is a good initial step to ferret out whether such support truly exists.
Furthermore, an enterprise needs to take into consideration all aspects of its IT networking infrastructure. This includes hardware, software, firmware, applications, cloud partners, and “as-a-Service” environments that an organization may rely on. In general, as enterprises do an assessment of their environment, they should ask the question, “If IPv4 did not exist, would our hardware, applications, and extranets still operate as required?”
Resources and tools to assess IPv6 support
Embarking on an IPv6 adoption program can be intimidating—especially IPv6-only. The good news is that organizations do not need to start from scratch. Remember, IPv6 is old enough to drink, and there are numerous, excellent resources to assist in selecting the right products to meet your networking requirements.
There are two certification programs that your company can leverage to assist in IPv6 assessment. Products in compliance with these programs are not necessarily guaranteed to work with your requirements (see “Test, assess, and verify below”), but certification does provide a starting point. First, the IPv6 Ready Logo program is an IPv6 Forum-led initiative with the mission of defining test specifications for IPv6 conformance and interoperability, as well as increasing access to self-test tools. More information can be found on their website. A particularly useful link is the IPv6 Ready Logo Program Approved List database, which provides various methods to search for complaint devices in a number of different product classifications.
A second program that may be of assistance is the U.S. National Institute of Standards and Technology (NIST) USGv6. In conjunction with other U.S. governmental agencies, NIST has developed standards, a testing program, and tools to support the adoption of IPv6 in the U.S. government. Although USGv6 is governmentally focused, NIST makes it clear that their body of work is publicly available for use by any organization – public or private.
Neither NIST nor the IPv6 Forum have labs to conduct testing against their specifications; they rely on third party agencies for that. The University of New Hampshire Interoperability Lab (UNH-IOL) is the sole accredited testing facility for the USGv6 program, and the IPv6 Ready Logo has six – one of which also happens to be the UNH-IOL. The University of New Hampshire provides a number of great resources on their web site. The IOL also offers a testing suite called INTACT that includes protocol validation for IPv6 core, IPsec, DHCPv6, BGP, and CE routers—evaluating them for compliance against various IPv6-related RFCs. A video at the bottom of the INTACT webpage offers an excellent overview of the product. Their IPv6 Testing and Certification page provides additional links and information about the USGv6 and IPv6 Ready programs, as well as a link to their USGv6 Tested Registry. One note of caution, when looking for certifications and/or logos, ensure the “IPv6 readiness” category conforms with the function you want the device to perform. For example, a firewall may be IPv6 router certified, however it may not provide the IPv6 L3-7 security protections you require. Make sure you understand the context of the certification and how that applies to your specific requirements. Listen to our IPv6 Buzz podcast show #6 with Tim Winters of the UNH-IOL on “Why And How To Test IPv6 Interoperability“.
The programs above are focused on network platforms and infrastructure. Organizations will also want to ensure that their applications (likely developed in an IPv4 setting) work end-to-end in an IPv6-only environment. It is not uncommon for organizations to have developed in-house applications to support their business. For internally developed software, there are several tools to assist in IPv6 application development or updates–two will be noted here. Apple (which mandated IPv6-only support for iOS 9 apps in 2016) has a Supporting IPv6-only Networks site, which provides resources for app developers. Another excellent guide for coders is Dan York’s book Migrating Applications to IPv6. These resources are a good starting point to get developers on the proper track to support IPv6-only.
Test, assess, and verify
Not that we don’t trust logos and vendor claims of feature support, but even the best intentions are unable to cover every corner case and boundary condition. If possible, it is highly recommended to validate the functions you require in a POC lab. There is no substitute for a comprehensive proof-of-concept environment. Create test cases that vet your network architecture top-to-bottom and execute them in this safe environment. Turn IPv4 off and confirm deployment, management, and operational functionality. The absence of IPv4 will quickly expose any IPv6 support gaps.
Even small enterprises can build a POC environment. And it does not have to be expensive. Vendors and VARs have a vested interest in helping you succeed with the right product. Leverage them where possible. They may be able to provide loaner equipment or allow you to use their lab environments. Some larger vendors have sandboxes that may also be of assistance. In addition, virtual network simulation tools such as EVE-NG can be used to create and test complex network environments (routers, switches, ADCs, firewalls, Linux and Windows servers) for little expense. Finally, there are hosting environments like IPv6 Only Hosting that are great platforms to experiment with how tools and applications operate in an IPv6-only world. For additional expert tips, I recommend listening to our IPv6 Buzz podcast show #70 on Building an IPv6 lab.
Building a suitable lab and turning IPv4 off will expose any IPv6-only shortcomings. Today, IPv6-only is possible, and numerous entities (typically those that have complete control their networking and application stack) have successfully done it, but it still may be challenging. If a critical network component is not able to function IPv6-only, temporary workarounds may be needed to accommodate pockets of legacy IPv4. In general, however, if a tool, package, or application does not support IPv6, find a modern replacement. Take a cue from the U.S. government’s latest mandate – create a plan to retire these systems.
Conclusions
The push to turn off IPv4 is long overdue. Enterprises are recognizing the cost of hanging on to the legacy protocol, and the Federal government has a fresh mandate to update network elements to operate IPv6-only. This should be a wake-up call for networking vendors to support IPv6 across not only the data plane, but also the management and control planes. A recommendation is to turn IPv4 off when developing products—at this point IPv6 should be considered the default (which happens to be in line with operating system behavior).
Enterprises adopting IPv6 should take solace that there are numerous resources to assist in their journey. One recommendation is to work with vendors and communicate IPv6 requirements to them. This is not just for large companies, but even smaller enterprises. Finally, there is no substitute for creating a POC environment to test IPv6. It will not only help validate functionality, but also double as a training environment—an environment that will successfully allow you to test, verify, and ultimately implement… IPv6-only.
